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

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

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

85 голосов | спросил Dave K 6 Maypm09 2009, 21:46:10

12 ответов


52

Я тестировал это дома (~ 3 хоста) в течение некоторого времени, пытаясь разного scms (RCS, Subversion, git). Настройка, которая отлично работает для меня прямо сейчас, - это git with setgitperms .

Что нужно учитывать:

Обработка разрешений и прав на файл

  • RCS: делает это изначально
  • Subversion: последнее, что я пробовал, вам понадобилось обертка вокруг svn, чтобы сделать это
  • git: крючок setgitperms обрабатывает это прозрачно (требуется довольно недавняя версия git с поддержкой post-checkout), однако)

Кроме того, если вы не хотите, чтобы все ваши /etc находились под контролем версий, но только файлы, которые вы фактически изменили (например, я), вам понадобится scm, который поддерживает этот вид использования.

  • RCS: все равно работает только на отдельных файлах.
  • Subversion: Я нашел это сложным.
  • git: no probem, поместите «*» в файл верхнего уровня .gitignore и добавьте только те файлы, которые вы хотите использовать git add --force

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

ответил 8jean 6 Maypm09 2009, 22:23:35
28

Я сделал это неофициально с git, но есть и проект etckeeper , который является более полной и детализированной реализацией.

ответил pjz 6 Maypm09 2009, 21:47:45
23

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

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

ответил berberich 6 Maypm09 2009, 22:03:47
10

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

ответил Zoredache 6 Maypm09 2009, 22:10:17
6

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

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

ответил bluehavana 28 Mayam09 2009, 00:49:03
3

Я занимаюсь реализацией Puppet по всей нашей инфраструктуре, и это очень способствует сохранению его данных в контроле версий.

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

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

> cd /usr/local/etc/puppet
> hg init

Все изменения совершаются с помощью простого «hg commit». Если какое-то изменение шланги, я могу отбросить каждый отдельный сервер к определенной версии файла (скажем, sudoers) с помощью одной команды.

Отличное введение в Mercurial

ответил sh-beta 6 Maypm09 2009, 23:59:20
3

Я использую Subversion на серверах, которыми я управляю. Работает отлично. Я также создал Trac , поэтому у нас есть временная шкала, система билетов, просмотр и т. д.

Используя символические ссылки, cron и subversion, я также настраиваю автоматическое распределение конфигурации на основе репозитория subversion, где каждый сервер Linux обновляет репозиторий с помощью svn update с помощью сценариев (например, сценарии брандмауэра).

ответил Martin C. 7 Maypm09 2009, 20:19:30
2

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

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

ответил Chealion 6 Maypm09 2009, 23:11:18
1

Я создал проект несколько лет назад, чтобы сделать именно это: Савон

Он использует subversion для хранения файлов и имеет некоторые дополнительные функции, такие как право собственности на трекинг, разрешения и контекст SELinux. Это также позволяет вам логически разделить ваши изменения файловой системы в слоях, так что вы можете, например, отслеживать изменения, которые должны отправляться на все ваши веб-серверы отдельно.

ответил Thomas Vander Stichele 12 Mayam09 2009, 11:13:02
0

Subversion очень легко настроить и использовать, и есть много ресурсов:

Базовый How-To

Книга SVN

Документ Обзор управления

ответил Jimmie R. Houts 6 Maypm09 2009, 21:58:15
0

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

ответил Waldo 6 Maypm09 2009, 22:30:04
0

В течение многих лет я использовал rcs для файлов, которые я начал изменять, но пару лет назад я начал добавлять все /etc под управление git. Это требует некоторой работы по проверке файлов в зернистых пакетах (иногда я прибегаю к огромной проверке «различных обновлений»), и я написал несколько сценариев, чтобы помочь с этим, но упомянутый выше упоминаемый этпитер кажется очень интересным, я сразу же попробую.

ответил hlovdal 7 Mayam09 2009, 00:26:16

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132