В среде с несколькими системными администраторами я вижу несколько преимуществ добавления файлов конфигурации сервера в систему контроля версий. Наиболее примечательными являются возможность отслеживать изменения, кто их сделал, и, конечно же, возможность откатиться к корректным рабочим конфигурациям.
Меня в основном интересуют решения для 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