В среде с несколькими системными администраторами я вижу несколько преимуществ добавления файлов конфигурации сервера в систему контроля версий. Наиболее примечательными являются возможность отслеживать изменения, кто их сделал, и, конечно же, возможность вернуться к известным рабочим конфигурациям.
Меня в основном интересуют решения для Unix / Linux, но мне также были бы любопытны реализации для Windows.
Я тестировал это дома (~ 3 хоста) в течение некоторого времени, пробуя разные scms (RCS, Subversion, git). У меня сейчас отлично работает настройка git с setgitperms крючок.
Что нужно учитывать:
Обработка прав доступа к файлам и владения
svn сделать этоsetgitperms hook обрабатывает это прозрачно (требуется довольно свежая версия git с поддержкой post-checkout хотя крючки)Кроме того, если вы не хотите, чтобы /etc под контролем версий, но только с файлами, которые вы фактически изменили (например, я), вам понадобится scm, поддерживающий такое использование.
*"на верхнем уровне .gitignore файл и добавьте только те файлы, которые вы хотите использовать git add --forceНаконец, есть несколько проблемных каталогов в /etc где пакеты могут отбрасывать фрагменты конфигурации, которые затем читаются какой-либо программой или демоном (/etc/cron.d, /etc/modprobe.d, и т.д.). Некоторые из этих программ достаточно умны, чтобы игнорировать файлы RCS (например, cron), некоторые - нет (например, modprobe). То же самое с .svn каталоги. Снова большой плюс для git (создает только один верхний уровень .git каталог).
Я сделал это неофициально с помощью git, но есть также etckeeper проект, который представляет собой более полную и детальную реализацию.
Другой вариант - использовать инструмент автоматической настройки сервера, например Кукольный или Cfengine для создания сценария конфигурации вашего сервера на декларативном языке.
Это дополнительная работа на интерфейсе, но использование такой утилиты, как Puppet, позволяет автоматически перестраивать и настраивать сервер с минимальным вмешательством человека.
Я экспериментировал с etckeeper который, кажется, работает очень хорошо. Мне не нужен централизованный сервер, что может быть важно в некоторых ситуациях. Вы можете использовать несколько различных серверных программ DVCS, так что вы можете выбрать тот, который вам наиболее знаком. Мне кажется, это очень хорошо работает, но я еще не пробовал заставить других специалистов, в которых я работаю, начать его использовать.
Я изучал Повар в последнее время. Он не только сохраняет шаблонный (.erb) конфигов в системе контроля версий, но позволяет выполнять действия (например, перезапуск службы после того, как вы загрузили конфиги на узел). Chef помогает с управлением пакетами, так что вы можете проверить зависимости с любым узлом, с которым вы взаимодействуете (т.е. должен иметь установленный пакет sudo). Chef кажется легко расширяемым в Ruby, поэтому, если у вас есть какие-либо настраиваемые процессы, вы можете просто написать сценарий в рамках предоставленной структуры.
Но до сих пор не пробовал, и вам нужно установить Ruby на клиенте и сервере с соответствующими гемами (это действительно не так уж и сложно). В целом выглядит очень легко управлять множеством серверов одновременно.
Я нахожусь в процессе внедрения Puppet в нашей инфраструктуре, и это очень способствует хранению данных в системе контроля версий.
Я предпочитаю Mercurial, поскольку это просто набор файлов с некоторыми метаданными, хранящимися в скрытых каталогах (легко управлять, легко понимать, легко использовать).
Мои файлы Puppet находятся в / usr / local / etc / puppet / (FreeBSD 7.1). Все, что потребовалось, чтобы добавить к нему Mercurial:
> cd /usr/local/etc/puppet
> hg init
Все изменения фиксируются простым "hg commit". Если что-то связано с изменением, я могу откатить каждый сервер до заданной версии файла (скажем, sudoers) с помощью одной команды.
Я использую Subversion на управляемых мной серверах. Работает отлично. Я также создал Trac Например, у нас есть представление временной шкалы, система продажи билетов, просмотр и т. д.
Используя символические ссылки, cron и Subversion, я также установил автоматическое распространение конфигурации на основе репозитория Subversion, где каждый сервер Linux обновляет репозиторий, используя svn update со скриптами (например, скриптами брандмауэра).
Вот пример использования из реальной жизни: использовала Subversion для управления файлами конфигурации на 4 разных серверах. Я бы рекомендовал использовать контроль версий для файлов конфигурации по той же причине, по которой вы бы использовали их с кодом - это резервная копия и кнопка отмены одновременно. Если бы я управлял гораздо большим количеством серверов, и они были бы намного ближе по конфигурации, я бы использовал что-то вроде Puppet, как подробно описано в ответе berberich.
Идея состоит в том, что у вас может быть один репозиторий, в котором вы можете проверять определенные папки на серверах (например, / var / named /), поэтому у меня есть история и резервная копия файлов конфигурации (резервная копия является бонусом, если вы допустили ошибку использования приложения конфигурации графического интерфейса, которое стирает ваши отредактированные вручную дополнения кашель Администратор сервера в Mac OS X Server кашель). Затем его легко протестировать на тестовом сервере и впоследствии обновить рабочий сервер файлами, которые работают без ручного копирования файлов.
Несколько лет назад я создал проект именно для этого: Савон
Он использует Subversion для хранения файлов и имеет некоторые дополнительные функции, такие как отслеживание прав собственности, разрешений и контекста SELinux. Это также позволяет вам логически разделить изменения файловой системы на слои, чтобы вы могли, например, отслеживать изменения, которые должны поступать на все ваши веб-серверы отдельно.
Subversion очень проста в установке и использовании, и есть много ресурсов:
Большинство наших изменений управляются с помощью нашей системы службы поддержки, даже если это касается планового обслуживания. Мы медленно перемещаем нашу документацию в вики для нашего собственного использования и того, что мы публикуем для конечных пользователей. Публикация изменений конфигурации и их обсуждение - это хорошо, если мы будем открыты в нашей интрасети.
В течение многих лет я использовал rcs для файлов, которые начал изменять, но пару лет назад я начал отдавать все / etc под контроль git. Требуется некоторая работа, чтобы проверять файлы крупными партиями (иногда я прибегаю к огромным проверкам «различных обновлений»), и я написал несколько сценариев, чтобы помочь с этим, но упомянутый etckeeper кажется очень интересным, я немедленно попробую.