Linux

Существующие решения, позволяющие использовать контроль версий для файлов конфигурации сервера

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

Меня в основном интересуют решения для Unix/Linux, но мне также были бы любопытны реализации для Windows.

 

Ответ 1

Я тестировал данное решение в течение некоторого времени, пробуя разные scms (RCS, Subversion, git). У меня сейчас отлично работает настройка git с setgitperms.

Обработка прав доступа к файлам и владения доступом:

  • RCS – основное решение

  • Subversion – использует оболочку svn, которая вполне работоспособна

  • git: setgitperms - обрабатывает отлично ( post-checkout хотя требуется довольно свежая версия git с поддержкой хуков)

 

Кроме того, если вы не хотите в /etc управлять всеми версиями, а только теми файлами, которые вы действительно изменили, вам понадобится scm, поддерживающий такое использование.

  • RCS - работает только с отдельными файлами.

  • Subversion – сложное решение.

  • Git - поместите "*" в .gitignore файл верхнего уровня и добавьте только те файлы, которые вы хотите использовать с git add --force

 

Наконец, есть несколько проблемных каталогов, в которых пакеты могут сбрасывать фрагменты конфигурации, которые затем читаются какой-либо программой или демоном ( /etc/cron.d/etc/modprobe.d и т. д.). Некоторые из этих программ достаточно умны, чтобы игнорировать файлы RCS (например, cron), некоторые - нет (например, modprobe). То же самое и с .svn каталогами.

 

Ответ 2

Другой вариант - использовать инструмент автоматической настройки сервера, такой как Puppet или Cfengine, для создания сценария конфигурации вашего сервера на декларативном языке.

Это дополнительная работа с использованием интерфейса,  такой утилиты, как Puppet, позволяет автоматически перестраивать и настраивать сервер с минимальным вмешательством человека.

 

Ответ 3

Я экспериментировал с etckeeper, который, кажется, работает очень хорошо. Мне не нужен централизованный сервер, что может быть важно в некоторых ситуациях. Вы можете использовать несколько различных серверных программ DVCS, так что можно выбрать наиболее популярный. Мне кажется, что это работает очень хорошо, но я еще не пробовал заставить других специалистов, среди которых я работаю, начать его использовать.

 

Ответ 4

В последнее время я использовал Chef. Он не только сохраняет шаблонные.erb) конфигурации в системе контроля версий, но и позволяет выполнять различные действия (например, перезапуск службы после того, как вы загрузили конфигурации на узел). Chef помогает с управлением пакетами, поэтому можно проверить зависимости с любым узлом, с которым вы взаимодействуете (т. е. должен быть установленный пакет sudo). Chef кажется легко расширяемым с Ruby, поэтому, если у вас есть какие-либо настраиваемые процессы, вы можете легко написать сценарий в рамках предоставленной структуры.

В целом очень легко управлять множеством серверов одновременно.

 

 

Ответ 5

Я предпочитаю Mercurial, поскольку это просто набор файлов с некоторыми метаданными, хранящимися в скрытых каталогах (легко управлять, легко изучить, легко использовать).

Мои файлы Puppet находятся в /usr/local/etc/puppet/(FreeBSD 7.1). Вот все, что потребовалось, чтобы добавить к нему Mercurial:

> cd /usr/local/etc/puppet

> hg init

 

Все изменения фиксируются простым "hg commit". Также довольно просто откатить каждый сервер до заданной версии файла (скажем, sudoers) с помощью одной команды.

Ответ 6

Вот пример использования из реальной жизни: использование Subversion для управления файлами конфигурации на 4 разных серверах. Я бы рекомендовал использовать контроль версий для файлов конфигурации по той же причине, по которой вы бы использовали их с кодом - это резервная копия и механизм отмены одновременно. 

Идея состоит в том, что у вас может быть один репозиторий, в котором можно проверять определенные папки на серверах (например, /var/named /), поэтому у меня есть история изменений и резервная копия файлов конфигурации (резервная копия является бонусом, т.е. если вы допустили ошибку использования приложения конфигурации GUI, которая удалила ваши отредактированные вручную дополнения cough Server Admin в Mac OS X Server cough ). Затем его легко протестировать на тестовом сервере и впоследствии обновить рабочий сервер файлами, которые работают без ручного копирования.

Схожие статьи

Linux

Целесообразно ли блокировать ICMP?

Linux

Безопасные сетевые файловые системы для Linux?

Linux

Запуск jmap, получение которого невозможно без открытия файла сокета

Linux

Linux API для отображения запущенных процессов

×