Перенос многих сайтов на новый сервер - как самый быстрый способ обновить их записи DNS?

Вы ищете термин CNAME, и ответ на ваш вопрос - да и нет.

Во-первых, вот пример того, как CNAME работает в файле зоны.

example.se  IN SOA  ns1.example.se. hostmaster.example.se. (
            [....]
            )

server1    A       10.1.2.3
www        CNAME   server1

Теперь вам просто нужно обновить server1 запись, чтобы переместить оба server1 и www на новый IP-адрес.

CNAME не обязательно должен указывать на адрес в том же домене; это могло также выглядеть так:

example.se  IN SOA  ns1.example.se. hostmaster.example.se. (
            [....]
            )

www         CNAME   server1.example.org.

Теперь, когда вы обновляете запись A для server1 в зоне example.org, рекорд для www.example.se будет следовать без какой-либо дополнительной настройки.

Плохая часть, с вашей точки зрения, заключается в том, что это не работает для записи вершины - это означает «голый» домен. Другими словами, вы можете сделать www.example.com в CNAME, но вы не можете сделать это с помощью example.com. Это связано с тем, что при использовании записи CNAME у вас не может быть никаких дополнительных записей для этой записи - это означает, что у вас не может быть записей почтового сервера или записей сервера имен ... что означает, что домен перестанет работать.

Лучшее решение - использовать какое-либо программное обеспечение для управления конфигурацией, такое как puppet, chef или ansible, для создания файлов зоны из шаблона. Если по какой-то причине это невозможно для вас, я бы использовал сценарий для замены IP-адресов во всех файлах.

Вы также захотите уменьшить значение TTL для домена в свое время до миграции. (И не забудьте обновить серийный номер файла зоны - у меня есть, и очень неловко ...)

Во-первых, ответ зависит от того, как реализован ваш DNS. Вы используете самостоятельный хостинг, например, привязку, несвязку или другие DNS-серверы? Используют ли ваши DNS-серверы текстовые файлы для настройки, используют ли они графический интерфейс (например, серверы Windows), используют ли они API сценариев (например, PowerShell), или они используют веб-интерфейс (обычно, если вы передали DNS на аутсорсинг). Аутсорсинговый DNS также иногда имеет REST API, который вы можете использовать.

Вероятно, вы захотите использовать либо API сценариев для выполнения обновлений, либо отредактировать текстовый файл, поскольку и то, и другое можно легко автоматизировать. Если это текстовый файл, вы даже можете подготовить его заранее и просто скопировать на место при выполнении миграции.

Между прочим, внесение такого рода изменений в ваш масштаб - вот почему многие люди сейчас используют инструменты DevOps, такие как Chef, Ansible, Puppet, Salt, ... Очевидно, что это большие инструменты, требующие планирования, так что это не будет незамедлительной помощи для этой конкретной потребности, но это может облегчить вам жизнь в долгосрочной перспективе.

Еще несколько важных соображений:

• Проверьте свой TTL. Примерно за день или неделю до миграции измените TTL на самый короткий, который вы можете сделать. Увеличьте TTL после завершения миграции.

• Не забудьте увеличить серийный номер в записи SOA! API и веб-интерфейсы могут делать это автоматически, а могут и не делать. Если ваш DNS-сервер использует текстовые файлы, вы должны помнить об этом.

• В зависимости от характера сервера посмотрите, сможете ли вы на некоторое время запустить старый и новый параллельно. Если вы можете, возможно, вам не придется выполнять все обновления DNS сразу.

Если я правильно понимаю, у старого сервера один IP-адрес, а у нового тоже только один.

Итак, что вы можете сделать, так это настроить новый сервер и просто перенаправить весь соответствующий http / https / ftp / любой трафик на старый IP-адрес, а затем обновить записи DNS, чтобы отобразить новый IP-адрес.

Если у вас только один IP-адрес, вы можете использовать простой поиск / замену, чтобы сразу изменить все IP-адреса в DNS (не забудьте обновить серийный номер) и дождаться, пока истечет ваш текущий TTL. Как только TTL истечет, вы можете просто удалить маршруты на новом сервере и изменить другие настройки, чтобы он обслуживал сайты напрямую, а не перенаправлял.

Очевидно, что перед удалением маршрутов веб-сайты должны были быть перемещены на новое место. Это имеет то преимущество, что вам не нужно полагаться на другие DNS-серверы для своевременного обновления своих записей, вы можете просто «подождать». Чтобы сократить этот период, вы можете уменьшить TTL, но имейте в виду, что некоторые кеши DNS игнорируют настройки TTL, поэтому я больше не полагаюсь на TTL.

Изменить / дальнейшее объяснение: Чтобы было легче понять:

Вы также можете просто установить свой новый сервер прямо сейчас, настроить все и переместить все свои сайты на новый IP-адрес, а ЗАТЕМ направить весь трафик со старого сервера на новый сервер.

Например. у вашего старого сервера есть IP 192.0.2.1 у вашего нового сервера есть IP 198.51.100.2

Ваш DNS указывает на 192.0.2.1 для всех сайтов (?) и веб-сервер решает, какой контент обслуживать по имени запрошенного домена, например example.com -> /var/www/sites/example.com и www.example.com -> /var/www/sites/example.com.

Итак, вы просто включаете это:

example.com -> 192.0.2.1

В это (как только вы переместили сайты на 198.51.100.2):

example.com -> 192.0.2.1 -> 198.51.100.2

Затем измените записи DNS, чтобы они указывали на 198.51.100.2:

example.com -> 198.51.100.2

Проблема с DNS заключается в том, что обновление никогда не происходит мгновенно, поэтому для некоторых ваших клиентов example.com по-прежнему будет указывать на 198.51.100.2 в течение переменного времени (либо установленный вами TTL, либо, если они его игнорируют, кто знает, как длинный).

Итак, моя точка зрения такова: вместо того, чтобы полагаться на DNS, перенаправляйте трафик на уровень IP, чтобы сократить время простоя. Надеюсь, это проясняет ситуацию.

В Ubuntu вы можете сделать это с пересылкой и NAT (например, маршрутизация http и https для вашего старого пункта назначения 198.51.100.2 в новое место назначения 198.51.100.2; эти настройки выполняются на вашем старом сервере):

echo 1 > /proc/sys/net/ipv4/ip_forward

iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -p tcp --dport 80 -m state --state NEW -j ACCEPT
iptables -A FORWARD -p tcp --dport 443 -m state --state NEW -j ACCEPT

iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 198.51.100.2:80
iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination 198.51.100.2:443
iptables -t nat -A POSTROUTING -j MASQUERADE

Быстрое решение (не самое элегантное, но, вероятно, работающее) - просто заменить старый ip на новый с помощью простого поиска-замены.

Сначала сделайте резервную копию файлов зоны.

Затем проверьте наличие проблем:

grep 'ol\.d\.i\.p' *.zone

Проверьте, есть ли какие-либо строки, в которых нет записей, которые вы хотите заменить

Затем замените ip:

sed -i 's/ol\.d\.i\.p/ne.w.i.p/g' *.zone
grep 'ne\.w\.i\.p' *.zone # check if the new lines look correct

Этого не следует делать в сценарии, который запускается каждый день, но для разовой миграции этого может быть достаточно, чтобы решить проблему, не запуская программирование сложных инструментов миграции.

• В grep команда просто ищет строки, содержащие регулярное выражение (здесь: буквальное совпадение ip, . необходимо экранировать, потому что они имеют особое значение в регулярном выражении).
• sed используется для строковых операций с потоками или файлами (с помощью -i вариант). s/regex/replacement/g заменяет регулярное выражение (такое же, как в grep команда) с заменой (новый ip). /g означает глобальный, что гарантирует, что ip заменяется несколько раз, если есть несколько совпадений в одной строке.