Введение
У Willow Commons уже есть работающий сайт сообщества. Прежде чем переносить его, выясните, какой адрес на самом деле использует клиент. Сохранённая запись DNS, ответ в кэше и ответ сайта описывают разные части пути запроса.
Сначала вы воспользуетесь обычным сайтом, сравните настоящий авторитетный сервер с независимым кэширующим резолвером и измените отдельное учебное имя. Имя сайта, которым пользуется сообщество, в этом модуле не меняется. Два HTTP-бэкенда и службы DNS подготовлены в изолированных сетевых пространствах имён Linux, использующих общее ядро одной VM.
Предполагается, что вы умеете вводить команды в терминале, распознавать пути и переключать вкладки. Лабораторная работа объясняет необходимые команды DNS и небольшие изменения конфигурации. Учётная запись публичного домена и опыт администрирования BIND не нужны. Отведите около 40 минут, включая чтение и обычные ошибки; это оценка автора.
Откройте работающий сайт по имени
На этом шаге вы прочитаете существующий сайт сообщества и сохраните его настоящую программу мероприятий. Начните с Community Preview, затем выберите Warm Client. Ожидаются страница Willow Commons, три встречи и метка old location. Выберите Download the programme и откройте загруженный текст. Метка расположения идентифицирует бэкенд, а не изображает успешное выполнение.
Прочитайте метку расположения вверху, затем воспользуйтесь Download the programme под тремя встречами. На изображении показан настоящий ответ исходного бэкенда.
Предпросмотр выполняет реальный DNS-запрос и HTTP-запрос с выбранного клиента курса. Его внешний URL платформы — шлюз для браузера; он не означает, что ваш компьютер использует DNS курса. Обновление браузера отправляет новый запрос, не очищая кэш резолвера курса. Пока не используйте Fresh Client.
Переключитесь в терминал Warm Client. Он начинает работу в /home/labex/project/site-move/warm со своими настройками резолвера. pwd выводит текущий каталог:
pwd
DNS, система доменных имён, сопоставляет имя с адресом. Запись A сопоставляет имя с IPv4-адресом. Затем HTTP использует этот адрес и порт для запроса содержимого. Здесь имя — site.community.test; 8081 — порт HTTP, а не значение записи DNS. .test — зарезервированный суффикс для тестирования, а не публичный домен сообщества.
curl выполняет HTTP-запрос. --noproxy '*' исключает использование любых прокси для этого запроса; кавычки сохраняют звёздочку как буквальный символ. -f считает ошибки HTTP неудачей, -s скрывает индикатор выполнения, а -S сохраняет вывод ошибок. --max-time 5 ограничивает запрос пятью секундами:
curl --noproxy '*' -fsS --max-time 5 http://site.community.test:8081/
Ожидается HTML с Willow Commons и old location. Терминал показывает исходный текст, а браузер отображает ту же страницу. Теперь загрузите настоящий текстовый ресурс. -o programme.txt сохраняет ответ в текущем каталоге этого клиента:
curl --noproxy '*' -fsS --max-time 5 -o programme.txt http://site.community.test:8081/programme.txt
cat выводит сохранённый файл:
cat programme.txt
Ожидаются все три встречи, информация о входе без ступенек и Service location: old. Наличие файла или статус HTTP сами по себе не доказывают правильность содержимого.
Если curl сообщает Could not resolve host, проверьте написание имени. Failed to connect означает, что HTTP-соединение не установлено; это отличается от HTTP 404, когда сервер ответил, но путь отсутствует. Исправьте опечатку и повторите показанный URL. Не меняйте DNS платформы, /etc/hosts или файл резолвера курса. Если вы открыли другой терминал, используйте настоящую вкладку Warm Client и перед сохранением выполните cd /home/labex/project/site-move/warm. Файлы и рабочие каталоги принадлежат соответствующему клиенту, а загрузка браузера — вашему браузеру.
Сравните авторитетный сервер и кэш
На этом шаге вы отличите исходную запись от временной кэшированной копии. Оставайтесь в Warm Client. Авторитетный сервер обслуживает community.test; его адрес — 10.94.0.2. Кэширующий резолвер клиента слушает 127.0.0.1, петлевой адрес внутри этого клиента. У второго клиента отдельные резолвер и кэш.
dig задаёт вопрос DNS. @10.94.0.2 явно выбирает сервер. A запрашивает IPv4-адрес. +noall скрывает обычные разделы dig, а +answer показывает строки ответа:
dig @10.94.0.2 site.community.test A +noall +answer
Ожидается строка такой формы:
site.community.test. 120 IN A 10.94.0.10
Столбцы — имя, TTL, класс, тип и адрес. TTL, время жизни, — число секунд, в течение которых ответ может оставаться в кэше. IN — класс Internet. Завершающая точка обозначает полное имя DNS. Пробелы и табуляция могут отличаться.
Теперь спросите резолвер клиента курса:
dig @127.0.0.1 site.community.test A +noall +answer
Адрес должен оставаться 10.94.0.10, но TTL может быть меньше, поскольку предыдущий запрос заполнил кэш. sleep 5 ждёт пять реальных секунд, не меняя DNS:
sleep 5
dig @127.0.0.1 site.community.test A +noall +answer
Обычно оставшийся TTL уменьшается. Если срок предыдущей копии истёк, резолвер снова спрашивает авторитетный сервер, и TTL возвращается ближе к 120. Чтение этой работы может занять весь интервал. Это нормальное истечение срока, а не неисправность кэша. Успевать в окно наблюдения сразу после подготовки среды не требуется.
Для следующего изменения используйте отдельное имя. Оно указывает на тот же старый бэкенд, но не является официальным именем сайта сообщества:
dig @127.0.0.1 practice.community.test A +noall +answer
Следите за именем, адресом и оставшимся TTL. Успешное разрешение имени не доказывает доступность сайта: на шаге 1 выполнялся отдельный HTTP-запрос. Запустите проверку этого шага, затем прочитайте следующий шаг перед началом короткой последовательности изменения и сравнения.
Измените учебную запись и дождитесь истечения срока копии
На этом шаге вы проверите небольшое изменение записи, загрузите его в авторитетный сервер и увидите, почему меньший TTL не сокращает срок уже кэшированной копии. Разрешено менять только practice и необходимый серийный номер SOA в community.zone. Сохраните официальную запись site, keep, сервер имён и оба сайта.
Сначала прочитайте инструкции редактирования ниже. Затем в Warm Client ещё раз запросите учебное имя непосредственно перед переключением вкладок:
dig @127.0.0.1 practice.community.test A +noall +answer
Если осталось всего несколько секунд, дождитесь конца этого интервала и запросите снова, пока авторитетный сервер хранит исходную запись. Это обновляет окно наблюдения настоящим DNS-запросом, а не очищает кэш. Новая копия действует до 120 секунд. Работайте в своём темпе и воспользуйтесь абзацем восстановления, если пропустите окно.
Переключитесь в DNS Desk, рабочий каталог которого — /home/labex/project/site-move. Прочитайте файл:
cat community.zone
Зона — авторитетный набор данных для части DNS. $TTL 120 задаёт время жизни по умолчанию. practice 120 IN A 10.94.0.10 явно задаёт срок и адрес учебного имени. SOA, Start of Authority, содержит серийный номер версии. Увеличивайте его при публикации изменения и сохраняйте остальные значения SOA. Время жизни DNS и таймеры SOA выполняют разные функции. Здесь @ обозначает начало зоны, community.test.. NS указывает её авторитетный сервер, а запись A для ns задаёт адрес этого сервера. Скобки объединяют поля SOA в одну запись. Существующие значения обновления, повтора, истечения срока и отрицательного кэширования относятся к администрированию зоны: оставьте их неизменными. Это не TTL учебной записи A.
Следующий here-document записывает небольшую зону целиком. > заменяет файл. Кавычки в 'ZONE' сохраняют $TTL буквально вместо подстановки переменной оболочки. Последний ZONE должен начинаться с начала строки. Скопируйте весь блок:
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 120 IN A 10.94.0.10
practice 45 IN A 10.94.0.20
keep 120 IN A 10.94.0.10
ZONE
Изменились только адрес и срок учебной записи, а также серийный номер. named-checkzone проверяет всю сохранённую зону, не загружая её. Первый аргумент — имя зоны, второй — файл:
named-checkzone community.test community.zone
Ожидаются loaded serial 2, затем OK. Это результат проверки файла, а не доказательство загрузки работающим авторитетным сервером. При ошибке синтаксиса прочитайте файл, восстановите полный блок и проверьте снова. Некорректный сохранённый файл оставляет прежнюю работающую зону доступной до успешной загрузки допустимой версии.
sudo выполняет эту единственную административную команду. Предоставленный узкоспециализированный помощник вызывает настоящий rndc reload community.test BIND внутри авторитетного сервера курса; ни один кэш не перезапускается:
sudo /opt/labex/site-move/reload-zone
Ожидается zone reload queued. Запросите работающий авторитетный сервер, чтобы подтвердить реально загруженные данные. У рабочего стола нет резолвера курса по умолчанию, поэтому эта диагностика явно входит в сетевое пространство имён авторитетного сервера. ip netns exec site-authority выполняет только следующую команду в этой сети курса:
sudo ip netns exec site-authority dig @10.94.0.2 practice.community.test A +noall +answer
Ожидается 45 IN A 10.94.0.20. Переключитесь в Warm Client и запросите его кэш:
dig @127.0.0.1 practice.community.test A +noall +answer
Пока остаётся часть исходного срока, он может возвращать 10.94.0.10, даже если осталось больше 45 секунд. Новый TTL в 45 секунд применяется к новым копиям и не переписывает старый кэшированный ответ. Оба бэкенда продолжают работать, пока клиенты могут обоснованно получать разные ответы.
Подождите наблюдаемый оставшийся TTL плюс одну секунду и запросите снова. Например, если показано 37 секунд, для этой копии достаточно sleep 38. Следующая консервативная пауза покрывает исходный максимум в 120 секунд целиком, даже если вы не записали точное значение:
sleep 121
dig @127.0.0.1 practice.community.test A +noall +answer
Теперь ожидается 10.94.0.20 с оставшимся TTL не больше 45. Прочитайте фактическую строку: завершение таймера само по себе ничего не доказывает. Выполните HTTP-запрос по имени с того же клиента:
curl --noproxy '*' -fsS --max-time 5 http://practice.community.test:8081/programme.txt
Ожидается Service location: new с полной программой мероприятий. Официальный site.community.test по-прежнему обслуживает старое расположение.
Если вы пропустили различие: завершённый результат остаётся верным. Для повторного наблюдения используйте только practice: в DNS Desk верните его строку к practice 120 IN A 10.94.0.10 и увеличьте текущий серийный номер SOA с помощью nano community.zone. nano — текстовый редактор: перемещайтесь стрелками, меняйте только эту строку и серийный номер, нажмите Ctrl+O, Enter для сохранения, затем Ctrl+X для выхода. Проверьте и загрузите зону теми же командами выше. Дождитесь естественного истечения текущего наблюдаемого TTL учебного клиента, запросите его, чтобы получить старый адрес со сроком до 120 секунд, затем снова измените только practice на новый адрес и 45 секунд с ещё большим серийным номером. Проверьте, загрузите и сразу сравните. Завершите естественным истечением срока и настоящим запросом к новому сайту. Никогда не сбрасывайте официальный сайт, не перезапускайте резолверы и не подменяйте содержимое сайтов ради повторения окна.
При опечатке в пути используйте pwd и cd /home/labex/project/site-move в DNS Desk, прежде чем перечитать файл. Ошибки синтаксиса и неверное содержимое — разные проблемы: проверьте файл, работающий авторитетный сервер, кэш, а затем запросите HTTP. Запустите окончательную проверку, когда учебный клиент разрешает новый адрес.
Резюме
Вы использовали работающий сайт по имени, сохранили его полную программу мероприятий и отделили авторитетные данные от кэшированных ответов DNS и HTTP-содержимого. Вы проверили ограниченное учебное изменение и убедились, что уменьшение TTL не сокращает срок существующей копии. Официальный сайт сообщества и старый бэкенд остаются доступными. Следующий модуль применяет эти знания к поэтапной миграции адреса.
