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

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

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

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

 / # корень хранилища
 + - www.domain.com/ # настройка для www
 | \--и т.д/
 | \ - apache2 /
 + - dev.domain.com/ # настройка для dev
 | + - и т.д. /
 | \ - опт /
 | \ - app1 /         
 | \ - conf / # конфигурация для app1 на dev
 \ - staging.domain.com/ # конфигурация для постановки

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

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

• мы хотим только один репозиторий
• должна быть возможность легко вносить изменения в центральный пульт
• наборы изменений должны содержать настоящего автора

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

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

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

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

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

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

1. Создайте git-репозиторий "etc_files".
2. Создайте ветку для каждого типа машины, например, «server / www», «server / dev» и т. Д.
   • git поддерживает косые черты в именах веток. Это помогает мне держать ветви прямо в моей голове.
   • Если у вас достаточно машин, у вас может быть ветвь для каждой отдельной машины.
3. Создайте ветку для каждой части совместно используемой инфраструктуры, например, «modules / apache», «modules / cups» и т. Д.
   • Эти ветки для хранения файлов, которые одинаковы для всех машин, например /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", которые вы затем сможете обновить почти так же, как сейчас.

Здесь что-то вроде куска, но похоже, что крюк после получения может сделать работу

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

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

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

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

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

~ $