Введение
Willow Commons переносит сайт на новый адрес сервера. Сообщество должно продолжать использовать site.community.test, а исходное расположение должно оставаться доступным во время перехода. Оба бэкенда уже содержат свои действительные программы мероприятий; ваша задача — миграция DNS, а не публикация содержимого.
Сначала завершите Определите адрес, используемый клиентом. Эта независимая среда снова начинается с официального имени на старом адресе, отдельного авторитетного сервера и кэширующих резолверов, а также готовых старого и нового HTTP-сервисов. Предыдущая VM не используется. Вы подготовите TTL, измените адрес и проверите реальную работу клиентов и полное содержимое. Отведите около 50 минут, включая чтение и обычные ошибки; это оценка автора.
Это контролируемое локальное упражнение DNS. Оно не обещает глобального распространения, отсутствия простоя, переноса у публичного регистратора или возможности немедленно удалить старый сервер.
Подготовьте окно перехода
На этом шаге вы проверите нормальный сервис и новый бэкенд до сокращения TTL официальной записи. Начните в Community Preview, выберите Warm Client и прочитайте существующую страницу Willow Commons с меткой old location. Не используйте Fresh Client до изменения адреса. Его отдельный резолвер ещё не запрашивал этот сайт.
Переключитесь в Warm Client. Команды и параметры curl те же, что в первом модуле. Сначала запросите существующий сервис по имени:
curl --noproxy '*' -fsS --max-time 5 http://site.community.test:8081/programme.txt
Ожидается полная программа с Service location: old. Затем проверьте подготовленный новый бэкенд по адресу с теми же путём и портом:
curl --noproxy '*' -fsS --max-time 5 http://10.94.0.20:8081/programme.txt
Ожидаются те же три встречи и информация о входе с Service location: new. Эта прямая проверка готовности намеренно обходит DNS; она не доказывает миграцию клиента, обращающегося по имени. Оставьте оба сайта неизменными.
Запросите текущую копию Warm Client:
dig @127.0.0.1 site.community.test A +noall +answer
Ожидается старый адрес с TTL не больше 120. Если подготовленная копия истекла во время чтения, этот настоящий запрос получает ещё одну копию всё ещё действующей старой записи. Срок выполнения не отсчитывается от открытия работы.
Переключитесь в DNS Desk, в /home/labex/project/site-move, и прочитайте файл записей и подготовленный план бэкендов:
cat backends.tsv
cat community.zone
В рамках миграции разрешены изменения адреса A и TTL для site, а также необходимого серийного номера SOA. practice зарезервирован для необязательных повторяемых наблюдений; сохраните keep, сервер имён и все байты сайтов. У подготовленной старой записи настоящий TTL в 120 секунд. Упражнение намеренно использует секунды; это не утверждение, будто суточный срок кэша в рабочей системе исчезает за две минуты.
До изменения адреса уменьшите только TTL официальной записи. Этот полный буквальный here-document использует изученный в первом модуле синтаксис записи файла:
cat > community.zone <<'ZONE'
$TTL 120
@ IN SOA ns.community.test. admin.community.test. (2 60 30 3600 30)
@ IN NS ns.community.test.
ns IN A 10.94.0.2
site 45 IN A 10.94.0.10
practice 120 IN A 10.94.0.10
keep 120 IN A 10.94.0.10
ZONE
named-checkzone community.test community.zone
Ожидаются loaded serial 2 и OK; исправьте любые ошибки синтаксиса до повторной загрузки:
sudo /opt/labex/site-move/reload-zone
Подтвердите данные работающего авторитетного сервера, а не только сохранённого файла:
sudo ip netns exec site-authority dig @10.94.0.2 site.community.test A +noall +answer
Ожидается 45 IN A 10.94.0.10. Старый бэкенд всё ещё является авторитетным назначением. Переключитесь в Warm Client:
dig @127.0.0.1 site.community.test A +noall +answer
Старая кэшированная копия сохраняет свой прежний оставшийся срок. Не считайте оставшийся TTL 40 доказательством получения новой политики в 45 секунд: у старой 120-секундной копии тоже может остаться 40 секунд.
Дождитесь истечения наблюдаемой старой копии и запросите снова. Можно ждать последние показанные оставшиеся секунды плюс одну. Следующая полная консервативная команда покрывает исходный максимум в 120 секунд:
sleep 121
dig @127.0.0.1 site.community.test A +noall +answer
Ожидается старый адрес с заново полученным TTL около 45. Этот последний DNS-запрос важен: истечение удаляет старую копию, но само не получает замену. Нативный обмен DNS фиксирует ответ со старым адресом и сокращённым сроком. Проверка читает этот существующий обмен до собственных проб и никогда не выполняет подготовку за вас.
Если ответ отсутствует или содержит другой адрес, перечитайте точные выводы авторитетного сервера и клиента до продолжения. Исправьте файл в DNS Desk, проверьте и загрузите его снова, затем повторите запрос по имени в Warm Client. Не перезапускайте и не очищайте резолвер. Запускайте проверку этой стадии только после фактического получения старого адреса с сокращённым сроком.
Измените адрес и сравните два клиента
На этом шаге вы перенесёте официальное имя и сравните поведение независимых клиентов. Прочитайте шаг до начала короткой последовательности. Следующий warm-запрос показывает оставшееся окно сравнения; попадание в кэш не запускает TTL заново. Только новая копия, полученная после естественного истечения, начинает новый срок в 45 секунд независимо от подготовки среды. Медленное редактирование может упустить видимую разницу; миграция остаётся верной, а отдельное учебное имя ниже позволяет повторить наблюдение.
В Warm Client обновите текущее наблюдение:
dig @127.0.0.1 site.community.test A +noall +answer
Если оставшийся TTL почти исчерпан, дождитесь его истечения и запросите снова перед редактированием, пока авторитетный сервер ещё возвращает старый адрес. Затем переключитесь в DNS Desk. Измените официальный адрес A, сохраните TTL 45 секунд и увеличьте серийный номер:
cat > community.zone <<'ZONE'
$TTL 120
@ IN SOA ns.community.test. admin.community.test. (3 60 30 3600 30)
@ IN NS ns.community.test.
ns IN A 10.94.0.2
site 45 IN A 10.94.0.20
practice 120 IN A 10.94.0.10
keep 120 IN A 10.94.0.10
ZONE
named-checkzone community.test community.zone
sudo /opt/labex/site-move/reload-zone
sudo ip netns exec site-authority dig @10.94.0.2 site.community.test A +noall +answer
Работающий авторитетный сервер теперь должен возвращать 45 IN A 10.94.0.20. Если он всё ещё возвращает старый адрес, сохранённый файл и загруженные данные не совпадают: проверьте синтаксис и результат повторной загрузки до интерпретации кэша клиента.
Переключитесь в Warm Client:
dig @127.0.0.1 site.community.test A +noall +answer
curl --noproxy '*' -fsS --max-time 5 http://site.community.test:8081/programme.txt
В течение оставшегося срока копии он может обоснованно использовать старый адрес и возвращать Service location: old. Переключитесь в Fresh Client, который начинает в /home/labex/project/site-move/fresh со своим резолвером:
dig @127.0.0.1 site.community.test A +noall +answer
curl --noproxy '*' -fsS --max-time 5 http://site.community.test:8081/programme.txt
Ожидаются новый адрес и полная программа с Service location: new. Во время перехода DNS два клиента могут использовать одно имя, но обращаться к разным действительным бэкендам. Это независимые пространства имён клиентов Linux и процессы кэша в одной VM, а не два физических устройства или независимые VM.
Если оба уже показывают new: срок warm-копии естественно истёк до сравнения. Продолжайте официальную миграцию; для прохождения не нужны снимок экрана или историческое перекрытие. Для повторения явления без отмены миграции используйте practice.community.test, как в первом модуле. В DNS Desk оставьте site на новом адресе, установите только practice на старый адрес и 120 секунд и увеличьте текущий серийный номер через nano community.zone (Ctrl+O, Enter, Ctrl+X). Проверьте и загрузите зону снова. В Warm Client дождитесь истечения текущей учебной копии, затем запросите practice, чтобы начать новое окно. Измените только practice на новый адрес и 45 секунд с ещё большим серийным номером, проверьте и загрузите снова, затем сравните practice через оба клиента. Официальная запись site всё время остаётся перенесённой. Завершите учебное наблюдение естественным истечением; никогда не очищайте кэш и не заменяйте содержимое сайтов.
Если официальный адрес был изменён до завершения подготовки TTL, изученным способом верните только site на старый адрес и 45 секунд с большим серийным номером. Проверьте, загрузите снова и дождитесь истечения текущего ответа Warm Client. Запросите старый адрес с коротким TTL, затем снова переключите с ещё большим серийным номером. Оба исходных бэкенда доступны, поэтому такой ограниченный откат DNS исправляет порядок без сброса сервисов или удаления работы. Конечная цель по-прежнему — новый официальный адрес. Запустите проверку стадии после подтверждения изменения на работающем авторитетном сервере.
Подтвердите новый адрес через DNS
На этом шаге вы докажете, что контролируемые клиенты получают новое содержимое, а старый сервис остаётся доступным. Начните в Warm Client. Его исходная копия миграции действует не более 60 секунд по разрешённой политике; показанный путь использует 45. Посмотрите оставшийся TTL:
dig @127.0.0.1 site.community.test A +noall +answer
Если ещё показан старый адрес, подождите оставшиеся секунды плюс одну и повторите запрос. Эта полная консервативная пауза покрывает максимально разрешённый короткий срок:
sleep 61
dig @127.0.0.1 site.community.test A +noall +answer
Ожидается 10.94.0.20 с оставшимся TTL не больше 45 для показанной политики. Правильного адреса недостаточно: запросите главную страницу и сохраните полную программу через это имя:
curl --noproxy '*' -fsS --max-time 5 http://site.community.test:8081/
curl --noproxy '*' -fsS --max-time 5 -o programme.txt http://site.community.test:8081/programme.txt
cat programme.txt
Ожидаются настоящая главная страница new location и программа Service location: new со всеми тремя встречами и информацией о входе. Если DNS правилен, но содержимое неверно, исследуйте фактические путь и адрес бэкенда; изменение старого сайта так, чтобы он выглядел новым, не разрешено.
Переключитесь в Fresh Client и независимо сохраните тот же полный ресурс:
dig @127.0.0.1 site.community.test A +noall +answer
curl --noproxy '*' -fsS --max-time 5 -o programme.txt http://site.community.test:8081/programme.txt
cat programme.txt
Ожидается то же содержимое нового расположения. Переключитесь в Community Preview, при необходимости вернитесь на страницу выбора кнопкой Back браузера, выберите каждый клиент и обновите настоящую страницу. Теперь оба показывают new location. Используйте Download the programme в каждом представлении и откройте полный текст. Эти запросы браузера используют выбранный клиент курса независимо от DNS компьютера с браузером.
Прочитайте метку new location вверху и исходную ссылку на программу под тремя встречами. Каждый клиент должен показывать эту настоящую страницу нового бэкенда.
Вернитесь в Warm Client, чтобы доказать сохранение требуемых функций. Запросите старый бэкенд напрямую:
curl --noproxy '*' -fsS --max-time 5 http://10.94.0.10:8081/programme.txt
Ожидается исходная программа старого расположения. Запросите не связанное с миграцией имя у авторитетного сервера:
dig @10.94.0.2 keep.community.test A +noall +answer
Ожидается неизменное 120 IN A 10.94.0.10. Старый сервис по-прежнему входит в условия перехода. Не останавливайте его после миграции двух клиентов: эти наблюдения не доказывают обновление всех клиентов в реальном мире.
Если сохранённый файл содержит прежнее расположение, повторите ту же команду загрузки в правильной вкладке клиента после изменения его реального DNS-ответа. Если путь неверен, восстановите его с помощью pwd и cd /home/labex/project/site-move/warm или соответствующего каталога fresh. Итоговые проверки читают существующие доказательства DNS и повторной загрузки до своих запросов. Повторная оценка не очищает кэш и не загружает авторитетную зону заново; обычное чтение может дополнять нативные журналы.
Резюме
Вы проверили новый бэкенд, уменьшили TTL, пока старый адрес оставался авторитетным, и позволили настоящему клиенту получить эту политику. Затем вы изменили адрес, сравнили результаты независимых клиентов и проверили полное новое содержимое после естественного истечения. Исходное имя, старый бэкенд и не связанные с миграцией записи остаются доступными. Это наблюдения контролируемых клиентов, а не гарантия глобального распространения DNS.
