Назад | Перейти на главную страницу

Используйте git для нескольких файлов конфигурации сервера

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

Этот вопрос похож на Используете контроль версий для файлов конфигурации сервера?, но у нас есть некоторые особые требования, которые не работают с предложениями по этому вопросу.

Текущая установка использует Subversion для файлов конфигурации. Соответствующий репозиторий выглядит примерно так

 / # root of repository
 +--www.domain.com/     # configuration for www
 |  \--etc/
 |     \--apache2/
 +--dev.domain.com/     # configuration for dev
 |  +--etc/
 |  \--opt/
 |     \--app1/         
 |         \--conf/     # configuration for app1 on dev
 \--staging.domain.com/ # configuration for staging

С Subversion это будет работать нормально, потому что можно просто проверить подкаталог репозитория. Кроме того, вы можете использовать svn: externals, чтобы указать на одну общую структуру для нескольких различных настроек конфигурации. Нам оставалось только иметь дело с .svn файлы во всех версионных каталогах. С другой стороны, Git нет svn: externals и редкие кассы всегда требовать, чтобы путь от корня до фактического каталога был одинаковым.

Обсуждая переход на git, я попытался записать основные Требования для управления версиями конфигурации сервера:

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

  1. Если .git репозиторий находится в фиксированном месте, например где-то в / var, мы могли бы ссылаться на дополнительный путь из «целевого» рабочего каталога. Основная проблема: я бы не знал, как "связать" с /и т.д в другой каталог, чтобы импортировать только содержимое, за исключением символьных ссылок на отдельные файлы
  2. Я нашел другую альтернативу этот ТАК вопрос, предлагая иметь несколько веток в одном репозитории. Это, безусловно, увеличило бы сложность, но я видел, как мы пытаемся это сделать.

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

Спасибо
Карием

Я использовал что-то подобное раньше; вот как это работало.

Настройка репо

  1. Создайте репозиторий git "etc_files".
  2. Создайте ветку для каждого типа машины, например, «server / www», «server / dev» и т. Д.
    • git поддерживает косую черту в именах веток. Это помогает мне держать ветки прямо в голове.
    • Если у вас мало машин, вы можете вместо этого создать ветку для каждой отдельной машины.
  3. Создайте ветку для каждой части общей инфраструктуры, например "модули / apache", "модули / чашки" и т. д.
    • Эти ветки предназначены для хранения файлов, одинаковых на всех машинах, например /etc/resolv.conf. Это те файлы, которые вы сейчас храните в репозиториях "svn: externals".

Создание новой машины

  1. На новой машине клонируйте репозиторий git и проверьте ветку для этого типа машины.
    • Я делаю это клоном только для чтения, чтобы люди не могли вносить изменения с производственных машин без тестирования.
  2. Настройте задание cron для автоматического git pull репо каждый день.

Смена ветвей машины

Изменить код в отдельной машинной ветви просто; просто git checkout соответствующую ветку в вашей среде разработки, внесите изменения и зафиксируйте их обратно в центральное хранилище. Все машины в этой ветке автоматически получат изменения при следующем запуске задания cron.

Изменение ветвей модуля

Изменить код для ветки модуля немного сложнее, так как он состоит из двух шагов:

  1. git checkout соответствующая ветвь модуля
  2. Внесите свои изменения и передайте их на централизованный сервер.
  3. git checkout каждая ветвь машины, которая использует эту ветвь модуля, а затем объединяет ветку модуля с ней. git выяснит, что вы ранее объединили эту ветку модуля, и заметит только изменения, произошедшие с момента последнего общего родителя.

У этого метода есть как преимущества, так и недостатки. Одним из преимуществ является то, что я могу внести изменения в ветвь модуля и применить его к ветвям машины, которые в этом нуждаются, что позволяет ветвям машины, которые не остаются в старой версии, пока они не будут готовы. Таким образом, недостатком является то, что вы должны не забыть объединить ветвь модуля с каждой ветвью машины, которая может ее использовать. Я использую сценарий, который просматривает дерево коммитов и автоматически выполняет это слияние для меня, но это все равно может быть проблемой.

В качестве альтернативы более новые версии git поддерживают так называемое "подмодули":

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

Это позволит вам построить что-то вроде деревьев "svn: externals", которые вы затем сможете обновлять почти так же, как и сейчас.

вот быстрая работа, о которой я подумал
1. Создайте центральный репозиторий, скажем, /var/repo
2. Поместите в этот каталог файлы, которые являются глобальными для всех доменов.
3. Создайте ветки для каждого поддомена. /var/repo/subdomain1,/var/repo/subdomain2 и т.п.
4. Создайте обработчик сообщений, в котором любое нажатие на ветку объединяется с мастером.

Итак, когда вы меняете конфигурацию /var/repo/subdomain2 он немедленно объединяется с мастером, поэтому вы можете полностью вытащить репо и иметь все файлы конфигурации
Если вы хотите получить индивидуальные конфигурации поддоменов, просто потяните соответствующую ветку.

Как вы помещаете свои файлы конфигурации в /var/repo/* совсем другое дело (вкладки cron, я могу придумать)

~ $

Немного нюанс здесь, но похоже, что крючок для приема сообщений может сделать эту работу

Мастер репо хранится в / var / master
крючок клонирует его в / var / localclone
затем копирует конкретные детали хоста
Вам нужно будет настроить ловушку .git / post-receive локально на каждом сервере (с соответствующими настройками).

Также похоже, что вам нужно что-то больше похоже на марионетку или шеф-повар, чем на git, потому что это позволит вам запускать git для централизованного управления конфигурациями и модулями, а puppet \ chef будет управлять развертыванием и проверкой за вас.