Назад | Перейти на главную страницу

Управление файлами зоны

У нас есть собственный DNS сервер (BIND) по разным причинам, в том числе из-за того, что мы очень часто развертываем и уничтожаем машины и что иногда нам нужно очень быстро балансировать нагрузку через DNS.

Однако теперь, когда у нас есть хороший 60 серверов, нам как бы сложно отслеживать все записи, и мы склонны делать ошибки при редактировании файла зоны. Пока ничего плохого (мы используем другого поставщика DNS в качестве резервной копии), но я ищу способ получше, чем просто редактировать файл вручную.

Кроме того, поскольку нам очень легко развернуть новые экземпляры с печально известным повар, делать это вручную - это то, что отнимает больше всего времени! Было бы интересно, если бы мы могли это автоматизировать. Кто-нибудь знает об этом? Как правильно редактировать и поддерживать этот файл зоны?

Я знаю, что сейчас исполнился месяц, но я только что закончил настраивать небольшую автоматизированную систему, чтобы управлять этим за нас. Он состоит из репозитория git, который содержит:

  1. Все основные зоны и файлы конфигурации.
  2. Все вторичные зоны и файлы конфигурации.
  3. Скрипты сборки для моего вторичного сервера имен - Ubuntu 10.0.4LTS
  4. Очень простой рецепт Capistrano, который может обновлять как первичный, так и вторичный серверы имен.

Когда я хочу обновить файлы зоны - вот процесс.

git pull #to make sure it's current.
#Open the zone file and edit.
git diff #verify the change is what I want.
git commit -a; git push
cap primary:update #that also sends a notify to my secondary who pulls down the new zone
cap secondary:update #if I'm just updating the secondary.

Это работает очень легко - мне не нужно входить в систему на нескольких серверах, чтобы что-то делать - и довольно легко увидеть, что я меняю.

Кроме того, это дает мне хорошую историю изменений.

Если вам нужна копия репо - просто дайте мне знать, и я дам вам DM.

Это боль, связанная с мощью конфигурации текста. Я считаю, что 60 файлов зон - это небольшое количество, чтобы иметь дело, если вам не нужно ежедневно их менять, но, возможно, вы сможете лучше обслуживать сервер, который поддерживает данные DNS из базы данных (например, PostgreSQL), например PowerDNS. Это позволяет вам создавать простые скрипты / страницы / приложения для работы с данными (вы даже можете предоставить клиентский интерфейс).

Вы даже можете настроить привязку как подчиненную по отношению к серверу, используя SQL, она автоматически загрузит информацию о зоне с главного сервера.

Что касается лучших практик:

  • Очистите файл зоны от бесполезных комментариев,
  • Обеспечить правильное использование табуляции / пробелов
  • Используйте доменные имена для файлов зоны
  • я использую vim макросы для редактирования нескольких файлов, но вы можете сделать это с помощью sed и других инструментов

Вы можете использовать поиск Chef для динамического создания файлов зон в качестве шаблонов с помощью Chef, используя обнаруженное имя хоста / fqdn и ip-адрес узлов.

hosts = search(:node, "*:*")

template '/path/to/zonefile' do
  source 'zonefile.erb'
  variables(:hosts => hosts)
  owner 'root'
  group 'root'
  mode 0644
end

И шаблон будет повторять hosts переданная переменная с использованием имени хоста, fqdn и ipaddress каждого результата поиска. Надуманный пример:

<% @hosts.each do |h| -%>
<%= h['fqdn'] %>. IN A <%= h['ipaddress'] %>
<% end -%>

Поскольку я предполагаю, что все ваши серверы определены в вашей конфигурации шеф-повара, как насчет того, чтобы просто сгенерировать файлы зоны, используя эти данные? Не знаю, есть ли у шеф-повара какие-то внутренние функции для этого, но похоже, что сценарий должен быть относительно тривиальным. Чтобы все было разделено, можно было бы делегировать эти «динамические» серверы в отдельную зону.

При этом вы уверены, что хотите использовать DNS для балансировки нагрузки?

Скрипты проверки целостности, которые делают такие вещи, как проверка увеличения серийного номера, и SCM, возможно, с чем-то вроде Subversion или каким-то другим предпочтительным локальным ядом, чтобы иметь историю и возможность возврата.

Когда у вас есть данные в чем-то вроде svn, у вас могут быть инструменты, которые добавляют / удаляют отдельные хосты, при этом позволяя людям редактировать файл зоны.

В противном случае существуют различные варианты перемещения данных из плоских файлов в базы данных. PowerDNS - это одно, патчи DLZ для Bind - другое. Я отмечу, что с точки зрения производительности, если это общедоступные зоны, вы, вероятно, захотите сохранить сервер с поддержкой базы данных в качестве скрытого мастера и позволить AXFR / IXFR распространять изменения на общедоступные мастера, которые могут выполнять привязку акций. Для внутренних зон (corp.example.com) это, вероятно, перебор.

Попробуйте эти правила

  • Настройте свой главный DNS-сервер для уведомления подчиненного об изменении зоны.
  • Отредактируйте файлы зоны с помощью инструмента, который автоматически увеличивает ваши версии. Я использую emacs.
  • Храните файл зоны в системе контроля версий (CVS, Subversion или GIT).
  • Перед фиксацией или перезагрузкой главного сервера отличите файл зоны от системы управления версиями. Визуально проверьте свои изменения, желательно по письменной спецификации изменений. Используйте спецификацию изменения как сообщение фиксации.
  • Используйте перезагрузку для обновления изменений вместо перезапуска главного сервера привязки. Рассмотрим сценарий для обновления конфигурации зоны из системы управления версиями и перезагрузки главного сервера за один шаг.
  • Используйте короткие тайм-ауты в конфигурации вашей зоны. Она должна быть меньше ожидаемой частоты между изменениями.
  • Если вы управляете как прямой, так и обратной зонами, подумайте об использовании инструмента, который генерирует оба файла из общей спецификации.

Для 60 серверов модуль BIND для Webmin должен работать нормально. Также проверьте этот список

Изменить: я не читал первое предложение вопроса.

Я не знаю, есть ли дешевый способ сделать это, кроме раскрутки собственных сценариев, через puppet / chef или независимо.

Я знаю некоторые коммерческие решения «управления DNS», которые работают поверх BIND. Они также предоставляют простые веб-интерфейсы и API-интерфейсы SOAP / Rest для быстрого добавления / удаления записей. При необходимости я могу предоставить информацию для этих компаний, так как недавно мы оценили несколько продуктов.