Предыстория
Озадачившись получением фидбэка и более точной приоритезацией задач, разработчики Plesk завели аккаунт на UserVoice — http://plesk.uservoice.com. Тем самым организовали место, где клиенты могут предлагать свои нововведения, писать, что именно им не нравится, голосовать за нужные им функции (те, что набирают большинство голосов, попадают в разработку). Один из популярных запросов, которые мы получили от наших пользователей – это «Automate slave DNS support». Это довольно старый запрос на функциональность, которую хотят почти все администраторы Plesk-серверов. Чтобы раз и навсегда закрыть этот вопрос, мы решили сделать соответствующее Plesk-расширение. Какие причины были сделать это именно так? Что именно мы сделали?
Существует несколько причин, по которым хостеру могут потребоваться минимум два NS-сервера (или даже больше):
- Вы купили домен у регистратора. Чтобы домен был делегирован, большинство регистраторов (например, российские nic.ru, Reg.ru, webnames.ru и т.д.) требуют, чтобы доменную зону обслуживала минимум пара серверов имен (NS);
- У вас несколько серверов с хостингом, вы еще не «доросли» до использования продуктов уровня Parallels Automation или Parallels Plesk Automation, но хотите использовать единый набор NS-серверов для всех хостящихся у вас доменов;
- Вы хотите иметь свои NS-сервера и не зависеть от третьих лиц;
- Вы хотите, чтобы в whois информации вашего домена были ваши NS-сервера. Вот, например, вывод данных whois по домену parallels.com:
Domain Name: PARALLELS.COM Registrar: MONIKER ONLINE SERVICES LLC Whois Server: whois.moniker.com … Name Server: NS1.PARALLELS.COM Name Server: NS2.PARALLELS.COM Name Server: NS3.PARALLELS.COM …
Как видим, причин иметь свои NS-сервера достаточно. Обычно для решения этих задач хостеры настраивают пару серверов имен в режиме master-slave. При этом на обоих серверах создаются доменые зоны, но управление ресурсными записями доменных зон происходит только на мастере. А вторичный (slave) сервер имен загружает изменения автоматически с мастера. Таким образом, у вас всегда активны два сервера имен с идентичным набором доменных зон и с идентичным набором ресурсных записей.
Единственная неприятная мелочь — создавать/удалять зону нужно на обоих серверах. Автоматически этого не происходит. Поэтому создаем доменную зону на мастере. Затем создаем доменную зону на slave, указав адрес master-сервера. Все, теперь, добавляя доменные ресурсные записи на мастере, мы можем быть уверенными, что slave автоматически заберет их оттуда.
Как мы это реализовали?
Интеграция Parallels Plesk Panel и slave DNS много лет была не очень тривиальной задачей. Подразумевается, что Plesk-сервер выполняет роль мастера. В Plesk реализованы режимы slave/master для доменной зоны, существует глобальный список IP-адресов, которым можно делать запрос на получение доменных зон. Но механизма создания новых доменных зон на slave-сервере нет. И не будет. Потому, что концепция Plesk — это панель автоматизации хостинговых операций в рамках одного сервера. Если вам нужна интеграция нескольких серверов, разделение по типам сервисов – то у Parallels есть другие продукты: Parallels Plesk Automation, Parallels Operation Automation, и, в конце концов, большое комплексное решение Parallels Automation.
«Ну и в чем проблема?» — спросите вы. А дело в том, что существует ряд пользователей Plesk, которым перечисленные выше продукты не требуются, они overqualified для решения их конкретных задач. А нужна им только интеграция с slave-сервером имен.
Чтобы решить эту проблему, в свое время каждый администратор Plesk писал свои собственные программные решения. Или покупал коммерческие. Или вручную выполнял операцию создания/удаления доменных зон на slave-сервере.
Казалось бы, что сложного? У Plesk есть локальный NS-сервер, пусть будет мастером, есть система событий, давайте повесим выполнение нашего скрипта на события «создание DNS-зоны» и «удаление DNS зоны». Все будут счастливы. К сожалению, именно таких событий в Plesk нет.
Разработчики Plesk не только разрабатывают Plesk, но еще и сами постоянно пользуются своим продуктом. Поэтому мы сделали для пользователей Plesk расширение, которое позволяет интегрировать Plesk с внешним slave-сервером имен, на котором стоит BIND9. Скачать его бесплатно, без смс, можно по ссылке — autoinstall.plesk.com/extensions/packages/slave-dns-manager-1.0-1.zip
Как это работает?
У Plesk в качестве локального NS-сервера используется BIND. У него есть возможность удаленного управления с помощью штатной утилиты rndc. Никто нам не мешает на удаленном сервере поставить BIND и управлять им через rndc. В Plesk 11.5 появился механизм «Custom DNS backend». Через него можно подключить сторонний DNS-сервис, например AWS Route53. Почитать об этом подробнее можно в документации.
В двух словах смысл этой функциональности можно описать как возможность зарегистрировать в Plesk скрипт, который будет получать JSON описание DNS-зоны, что нужно сделать с зоной, при каждом создании/обновлении/удалении любой активной зоны в Plesk. Это все, что нам нужно. При реализации этой функциональности подразумевалось, что вы не будете ставить локальный BIND с Plesk, а будете использовать внешний сервис. Но! Удалять локальный BIND совсем не обязательно. Скрипт может работать параллельно с локальным DNS-сервисом. Вот эту идею наше расширение и использует.
Алгоритм работы расширения следующий:
- В настройках расширения регистрируем slave-сервер
- IP-адрес slave-сервера автоматически добавляется в список тех, кому разрешен трансфер доменных зон с Plesk-сервера
- Когда в Plesk создается/обновляется/удаляется активная доменная зона, Plesk создает/изменяет/удаляет доменную зону в локальном DNS-сервисе
- Далее запускается скрипт, который получает имя домена, команду (создать/обновить/удалить)
- Скрипт запускает rndc команду для каждого подключенного slave-сервера
- Slave-серверы синхронизируют доменные зоны с Plesk-сервера
Таким образом, мы получили очень простую и очень прочную схему работы со slave-серверами имен. Все проблемы, связанные с форматом файлов зон, соединением и рестартом сервиса, берет на себя сам DNS-сервис. Администратору нужно настроить slave-сервер только 1 раз для работы с внешним Plesk. Теперь можно идти к регистратору и сказать, что Plesk-сервер и slave-сервер являются NS-серверами ваших доменов. И благодаря этому мы решили все задачи, перечисленные в начале поста.
А теперь чуть подробнее, с большим количеством технических деталей.
Настраиваем slave-сервер имен (на примере сервера с Debian 7):
- Ставим BIND
apt-get install bind9 - Разрешаем создание новых зон через rndc. В файл
/etc/bind/named.conf.options, внутри директивы options {}, пишем:
allow-new-zones yes; - Указываем, с какого IP-адреса можно получать управляющие команды, и говорим BIND слушать все доступные сетевые интерфейсы. В файле
/etc/bind/named.conf.localпишем:
controls { inet * port 953 allow { <PLESK_IP>; <ANOTHER_PLESK_IP> 127.0.0.1; }; }; - Обязательно запоминаем ключ доступа, он расположен в файле
/etc/bind/rndc.key:
key "rndc-key" { algorithm hmac-md5; secret "vwOxonI4n4CVRUhKAOAAIA=="; };
Все, на этом настройка slave-сервера имен закончена.
Следующим шагом идем в наш Plesk и ставим расширение (мы уже говорили выше, где его скачать). На странице расширения добавляем наш slave-сервер, указав его IP и ключ. Расширение создаст конфигурационный файл для утилиты rndc, в котором будут настройки нашего slave-сервера. Теперь Plesk все создаваемые, обновляемые и удаляемые зоны будет транслировать на slave-сервер автомагически, выполняя следующие команды для каждого настроенного slave-сервера:
- Создание
/usr/sbin/rndc -c slave.config addzone example.com '{ type slave; file "/var/lib/bind/example.com"; masters { <PLESK_IP>; }; };' - Обновление
/usr/sbin/rndc -c slave.config refresh example.com - Удаление
/usr/sbin/rndc -c slave.config delzone example.com
Теперь при добавлении доменов в Plesk DNS-зона автоматически создается как на master-сервере, так и на slave-сервере.
Кстати, мы читаем комментарии и отвечаем на вопросы (также в нашем tech-блоге разработчиков Parallels Plesk Panel – тоже: devblog.plesk.com).
Ссылки
ссылка на оригинал статьи http://habrahabr.ru/company/parallels/blog/200452/
Добавить комментарий