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

<p>в среде с несколькими системными администраторами я вижу несколько преимуществ добавления файлов конфигурации сервера в систему контроля версий. наиболее примечательным является способность отслеживать изменения, кто их внес, и, конечно, возможность отката к известным рабочим настройкам.</p><p>я в основном интересуюсь решениями для unix/linux, но мне было бы любопытно также реализовать windows.</p>

<p>я тестировал это дома (~ 3 хоста) в течение некоторого времени, пробуя разные scms (rcs, subversion, git). настройка, которая отлично работает для меня сейчас, это git с хуком <a href="http://repo.or.cz/w/git.git?a=tree;f=contrib/hooks;h=6424331a3a920429e610ac2494b857de7e520d8f;hb=head"><code>setgitperms</code></a> .</p><p>что нужно учитывать:</p><p>обработка прав доступа к файлам и владения</p><ul> <li>rcs: делает это изначально</li> <li>subversion: последний раз, когда я пытался, вам понадобилась обертка вокруг <code>svn</code>, чтобы сделать это</li> <li>git: ловушка <code>setgitperms</code> обрабатывает это прозрачно (нужна довольно свежая версия git с поддержкой <code>post-checkout</code> крючки, хотя)</li> </ul><p>кроме того, если вы не хотите, чтобы все ваши <code>/etc</code> под контролем версий, но только те файлы, которые вы на самом деле изменили (например, я), вам понадобится scm, поддерживающий этот вид использования.</p><ul> <li>rcs: все равно работает только с отдельными файлами.</li> <li>subversion: я обнаружил, что это сложно.</li> <li>мерзавец: нет пробем, поставь "<code>*</code> "на верхнем уровне <code>.gitignore</code> файл и добавьте только те файлы, которые вы хотите использовать <code>git add --force</code></li> </ul><p>наконец, есть несколько проблемных каталогов под <code>/etc</code> где пакеты могут отбрасывать фрагменты конфигурации, которые затем считываются какой-либо программой или демоном (<code>/etc/cron.d</code>, <code>/etc/modprobe.d</code>, так далее.). некоторые из этих программ достаточно умны, чтобы игнорировать файлы rcs (например, cron), некоторые - нет (например, modprobe). то же самое с <code>.svn</code> каталоги. опять же большой плюс для git (создает только один верхний уровень <code>.git</code> каталог).</p>

<p>я сделал это неофициально с помощью git, но есть также проект <a href="http://kitenet.net/~joey/code/etckeeper">etckeeper</a> , который является более полной и подробной реализацией.</p>

<p>другой вариант - использовать инструмент автоматического конфигурирования сервера, такой как <a href="http://reductivelabs.com/products/puppet/">puppet</a> или <a href="http://www.cfengine.org/">cfengine</a> , чтобы создавать сценарии конфигурации вашего сервера на декларативном языке.</p><p>это дополнительная работа с интерфейсом, но использование такой утилиты, как puppet, позволяет автоматически перестраивать и настраивать сервер с минимальным вмешательством человека.</p>

<p>я экспериментировал с <a href="http://kitenet.net/~joey/code/etckeeper/">etckeeper</a> , который, кажется, работает довольно хорошо. мне не требуется централизованный сервер, что может быть важно в некоторых ситуациях. вы можете использовать несколько разных бэкэндов dvcs, так что вы можете выбрать тот, который вам наиболее знаком. кажется, это работает очень хорошо для меня, но я еще не пытался найти других техников, где я работаю, чтобы начать использовать его.</p>

<p>я в последнее время изучаю <strong> <a href="http://wiki.opscode.com/display/chef/home">chef</a> </strong>. он не только сохраняет настройки <a href="http://wiki.opscode.com/display/chef/templates">временные</a> (.erb) в управлении версиями, но и позволяет выполнять действия (например, <a href="http://wiki.opscode.com/display/chef/resources#resources-service">перезапуск службы</a> после загрузки настроек на узел). chef помогает с управлением пакетами, поэтому вы можете <a href="http://wiki.opscode.com/display/chef/recipes#recipes-asimplerecipe">проверить зависимости</a> с любым узлом, с которым вы взаимодействуете (т.е. должен быть установлен пакет sudo). кажется, что chef легко расширяется в ruby, поэтому, если у вас есть какие-то пользовательские процессы, вы можете просто написать его в предоставленной среде.</p><p>но все еще не пробовали, и вам нужно установить ruby на клиенте и сервере с соответствующими гемами (это действительно не так уж сложно). в целом, управлять многими серверами очень просто. один раз.</p>

<p>я нахожусь в процессе внедрения puppet во всей нашей инфраструктуре, и это очень способствует сохранению данных в контроле версий.</p><p>я предпочитаю mercurial, так как это просто набор файлов с некоторыми метаданными, которые хранятся в скрытых каталогах (легко управлять, легко понять, легко использовать).</p><p>мои файлы puppet находятся в/usr/local/etc/puppet/(freebsd 7.1). все, что нужно, чтобы добавить к нему mercurial:</p><pre><code>> cd /usr/local/etc/puppet > hg init </code></pre><p>все изменения фиксируются с помощью простого "hg commit". если изменение что-то скрывает, я могу откатить каждый сервер до заданной версии файла (скажем, sudoers) с помощью одной команды.</p><p> <a href="http://www.selenic.com/mercurial/wiki/tutorial">отличное введение в mercurial</a> </p>

<p>я использую subversion на серверах, которыми я управляю. работает отлично. я также настроил экземпляр <a href="http://trac.edgewall.org/">trac</a> , поэтому у нас есть представление временной шкалы, система тикетов, просмотр и т.д.</p><p>используя символические ссылки, cron и subversion, я также настроил автоматическое распространение конфигурации на основе репозитория subversion, где каждый сервер linux обновляет репозиторий с помощью <code>svn update</code> со сценариями (например, сценарии брандмауэра).</p>

<p>вот реальный пример использования: используется subversion для управления файлами конфигурации на 4 разных серверах. я бы рекомендовал использовать контроль версий для файлов конфигурации по той же причине, по которой вы использовали бы их с кодом - это резервная копия и кнопка отмены все в одном. если бы я управлял гораздо большим количеством серверов, а их конфигурация была намного ближе, я бы использовал что-то вроде puppet, как подробно описано в ответе бербериха.</p><p>идея состоит в том, что у вас может быть один репозиторий, в котором вы можете извлекать определенные папки на серверах (например,/var/named /), поэтому у меня есть история и резервная копия файлов конфигурации (резервная копия является бонусом, если вы допустили ошибку использования приложения конфигурации gui, которое стирает ваши отредактированные дополнения <em>кашель</em> администратор сервера в mac os x server <em>кашель</em>). затем его легко протестировать на тестовом сервере и впоследствии обновить рабочий сервер файлами, которые работают без копирования файлов вручную.</p>

<p>я создал проект несколько лет назад, чтобы сделать именно это: <a href="https://thomas.apestaart.org/thomas/trac/wiki/projects/savon">savon</a> </p><p>он использует subversion для хранения файлов и имеет некоторые дополнительные функции, такие как отслеживание владения, разрешения и контекст selinux. это также позволяет вам логически разделять изменения файловой системы по слоям, так что вы можете, например, отслеживать изменения, которые должны поступать на все ваши веб-серверы отдельно.</p>

<p>subversion очень прост в настройке и использовании и имеет множество ресурсов:</p><p> <a href="http://polishlinux.org/apps/subversion-howto/">базовые инструкции</a> </p><p> <a href="http://svnbook.red-bean.com/">svn book</a> </p><p> <a href="https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878\_11-6167205.html">обзор управления документами</a> </p>

<p>большая часть наших изменений управляется с помощью нашей системы help desk, даже для рутинных видов обслуживания. мы постепенно перемещаем нашу документацию в вики для собственного использования и того, что публикуем для конечных пользователей. публикация изменений конфигурации и обсуждение, стоящее за ней, приятно видеть в нашей внутренней сети.</p>

<p>в течение многих лет я использовал rcs для файлов, которые я начал изменять, но пару лет назад я начал ставить весь/etc под контроль git. требуется некоторая работа, чтобы проверить файлы в виде отдельных файлов (иногда я прибегаю к огромной проверке "различных обновлений"), и я написал несколько сценариев, чтобы помочь с этим, но упомянутое etckeeper кажется очень интересным, я попробую немедленно.</p>