Автоматизация облаков — запускаем вторичные DNS с помощью Ansible
Некоторое время назад мы с коллегами по хостинговому бизнесу обсуждали вопросы автоматизации рутинных операций на собственных серверах, а затем вопрос зашел об организации системы DNS-серверов, развертывании вторичных DNS, их переносах и так далее. В этой заметке мы попытаемся рассмотреть эти вопросы с практической точки зрения.
Когда в хозяйстве всего лишь несколько выделенных серверов или VDS, речь редко заходит о какой-либо серьезной автоматизации. Однако если счет обслуживаемых систем идет на сотни или тысячи, а определенные операции должны быть произведены на нескольких серверах, следует задуматься над использованием специального программного обеспечения для управления конфигурациями.
Есть много решений для configuration management, мы же остановимся на Ansible. Причина выбора именно этого инструмента проста — для использования Ansible не нужно на серверы или VDS загружать какие-либо специальные «демоны», так как все действия производятся через безопасные ssh-подключения. Следует также отметить отличную документацию и большую библиотеку готовых модулей.
Приступим — на первом этапе установим Ansible на наш управляющий сервер. Если используется Centos, то подключим репозиторий EPEL и инсталлируем Ansible:
|
1 |
# yum install ansible |
Для управления подчиненными серверам система использует SSH, поэтому сразу подготовим пару ключей:
|
1 |
# ssh-keygen |
Файл /root/.ssh/id_rsa.pub (публичный ключ) нам будет нужен в дальнейшем — на наших вторичных NS-серверах содержимое этого файла нужно будет загрузить в /root/.ssh/authorized_keys.
Несколько слов о схеме работы DNS-серверов, которую мы хотим реализовать. Представим, что у нас есть основной сервер с BIND (назовем его ns.domain.com), где хранятся оригинальные доменные зоны. Для обработки внешних запросов мы будем использовать только вторичные NS-серверы на базе PowerDNS с поддержкой supermaster, которые будут загружать оригинальные зоны с ns.domain.com после их изменения. Основной сервер не будет принимать участие в обработке запросов, он будет так называемым «hidden primary».
Займемся нашими вторичными DNS-серверами, для этого закажем в разных локациях несколько SSD VDS минимальной конфигурации, имена хостов укажем ns1.domain.com, ns2.domain.com и так далее. По окончании инсталляции виртуальных машин загрузим в /root/.ssh/authorized_keys наш публичный ключ и проверим, что ssh-доступ с управляющего сервера успешен.
Перейдем к настройке Ansible. В файле /etc/ansible/hosts опишем IP-адреса созданных VDS в группе nameservers:
|
1 2 3 |
[nameservers] 1.1.1.1 2.2.2.2 |
После этого уже можно производить некоторые действия с группой серверов. Например, можно проверить их доступность для Ansible:
|
1 2 3 4 5 6 7 8 9 10 |
ansible nameservers -m ping 1.1.1.1 | success >> { "changed": false, "ping": "pong" } 2.2.2.2 | success >> { "changed": false, "ping": "pong" } |
Еще один пример — выполнение команд на группе серверов. Например, можно посмотреть состояние памяти:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
# ansible -m shell -a 'free -m' nameservers 1.1.1.1 | success | rc=0 >> total used free shared buffers cached Mem: 490 95 395 0 7 36 -/+ buffers/cache: 51 439 Swap: 490 0 490 2.2.2.2 | success | rc=0 >> total used free shared buffers cached Mem: 490 96 394 0 7 36 -/+ buffers/cache: 52 437 Swap: 490 0 490 |
Продолжим с подготовкой вторичных NS. Мы будем использовать PowerDNS вместе с MySQL — база данных будет использоваться для хранения доменных зон и настроек supermasters. Установим из Ansible Galaxy готовый модуль для инсталляции MySQL-сервера на Centos/RHEL:
|
1 |
# ansible-galaxy install geerlingguy.mysql |
Для установки и настройки вторичных PowerDNS мы подготовили собственный модуль. Загрузим и распакуем его в /etc/ansible:
|
1 2 |
cd /etc/ansible wget -O - http://itldc.com/downloads/ansible/ansible-powerdns-itldc.tgz | tar xvzf - |
Файл pdns-secondary-itldc.yml — это playbook, алгоритм подготовки сервера. В нем необходимо поменять пароли для MySQL и явно указать IP-адрес основного DNS-сервера. Обратите внимание на то, что мы сбрасываем настройки iptables. Делать это или изменять конфигурацию файрвола, решите сами.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
--- - hosts: nameservers vars: mysql_root_password: CHANGEME_MYSQLPASSWORD mysql_packages: - mysql - mysql-server - MySQL-python remote_user: root pdns_user: pdns pdns_group: pdns pdns_dbuser: pdns pdns_dbpassword: CHANGEME_PDNS_MYSQL_PASSWORD pdns_dbname: pdns pdns_supermaster: 1.2.3.4 tasks: - name: test connection ping: - name: flushing iptables (may need change in your environment) command: /sbin/iptables -F - name: saving empty iptables configuration command: /etc/init.d/iptables save roles: - { role: geerlingguy.mysql } - { role: itldc.pdns } |
После этого запускаем наш playbook:
|
1 |
# ansible-playbook ./pdns-secondary-itldc.yml |
Примерно через минуту-две у нас будут полность готовы вторичные NS. Теперь нам достаточно на основном сервере описать в нужных доменных зонах имена новых NS (ns1.domain.com, ns2.domain.com и так далее), проверить в named.conf разрешение allow-transfer для IP-адресов вторичных NS и перезапустить BIND. Не забудьте в domain.com явно описать записи типа A для вторичных NS. После перезапуска основной NS отошлет сообщение NOTIFY на каждый из secondary, затем произойдет загрузка зоны. При изменении доменной зоны на основном сервере и смене серийного номера в SOA данные на вторичные NS будут загружаться автоматически.
В лог-файле /var/log/messages загрузка новой доменной зоны на вторичный сервер имен выглядит так:
|
1 2 3 4 5 6 7 8 9 10 |
Apr 4 10:21:07 ns2 pdns[3076]: Received NOTIFY for domain.net from 3.3.3.3 for which we are not authoritative Apr 4 10:21:07 ns2 pdns[3076]: Created new slave zone 'domain.net' from supermaster 3.3.3.3, queued axfr Apr 4 10:21:07 ns2 pdns[3076]: Initiating transfer of 'domain.net' from remote '3.3.3.3' Apr 4 10:21:07 ns2 pdns[3076]: 1 slave domain needs checking, 0 queued for AXFR Apr 4 10:21:07 ns2 pdns[3076]: Received serial number updates for 1 zones, had 0 timeouts Apr 4 10:21:07 ns2 pdns[3076]: Domain 'domain.net' is stale, master serial 2011022017, our serial 0 Apr 4 10:21:07 ns2 pdns[3076]: Initiating transfer of 'domain.net' from remote '3.3.3.3' Apr 4 10:21:08 ns2 pdns[3076]: AXFR started for 'domain.net' Apr 4 10:21:08 ns2 pdns[3076]: Transaction started for 'domain.net' Apr 4 10:21:08 ns2 pdns[3076]: AXFR done for 'domain.net', zone committed with serial number 2011022017 |
После проверок доступности нужных доменных зон можно вносить изменения у регистраторов доменов. Теперь наша DNS-система не только будет работать быстрее, но и надежнее — ведь наши SSD VDS доступны к заказу в нескольких локациях в Европе, СНГ и США.