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