Використовуйте git для декількох файлів конфігурації сервера

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

Це питання схоже на Використання контролю версій для файлів конфігурації сервера? , але у нас є деякі особливі вимоги, які не відповідають пропозиціям з цього питання.

Поточна установка використовує субверсію для файлів конфігурації. Відповідне сховище виглядає приблизно так

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

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

Під час обговорення міграції до git я намагався записати основні вимоги до версії конфігурації сервера:

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

Чи є приємний спосіб мати всю конфігурацію в одному сховищі та мати лише піддоріжку як робочу копію? В даний час я розглядаю два підходи, але хотів спершу поставити це питання тут

1. Якщо сховище .git знаходиться у фіксованому місці, наприклад, десь у / var , ми можемо зв’язати підподібний шлях із робочого каталогу "target". Основна проблема: я б не знав про спосіб "посилання" з / etc на інший каталог, щоб лише імпортувати вміст, за винятком посилання на окремі файли
2. Я знайшов іншу альтернативу в цьому питанні про те , що передбачає наявність декількох гілок в одному сховищі. Це, безумовно, збільшило б складність, але я міг бачити, як ми намагаємося таким чином.

Використання git на одній машині для управління файлами конфігурації працює чудово, але я вважаю, що повинен бути хтось, хто ним користується так, як ми хотіли б ним користуватися.

Дякую,
Каріем

Я раніше вживав щось подібне; ось як це працювало.

Налаштування репо

1. Створіть git repo, "etc_files".
2. Створіть гілку для кожного типу машини, наприклад, "server / www", "server / dev" тощо.
   • git підтримує косої риси у назвах гілок. Це допомагає мені тримати гілки прямо в голові.
   • Якщо у вас досить мало машин, ви можете мати гілку для кожної окремої машини.
3. Створіть гілку для кожного фрагмента спільної інфраструктури, наприклад "модулі / апачі", "модулі / чашки" тощо.
   • Ці гілки призначені для зберігання файлів, однакових між усіма машинами, наприклад /etc/resolv.conf. Це будуть файли, які ви зберігаєте зараз у "svn: externals".

Побудова нової машини

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

Зміна гілок машин

Зміна коду в одній гілці машини проста; просто git checkoutвідповідну галузь у вашому середовищі розробки, внесіть зміни та поверніть їх до центрального репо. Усі машини в цій гілці автоматично отримають зміни наступного разу, коли запуск роботи cron.

Зміна гілок модуля

Зміна коду для відділення модуля лише дещо складніше, оскільки воно включає два кроки:

1. git checkout відповідне відділення модуля
2. Внесіть зміни та зафіксуйте їх на централізованому сервері.
3. git checkoutкожна гілка машини, яка використовує цю гілку модуля, а потім об'єднує гілку модуля в неї. git з’ясує, що ви з’єднали цю гілку модуля раніше і лише помітите зміни, що відбулися з моменту останнього загального батька.

Цей метод має як переваги, так і недоліки. Одна з переваг полягає в тому, що я можу внести зміни до відділення модуля і застосувати його до потрібних гілок машин, які дозволяють машинним гілкам, які не залишаються зі старшою версією, поки вони не будуть готові. Тоді недолік полягає в тому, що вам потрібно пам’ятати, щоб об’єднати свою гілку модуля в кожну гілку машини, яка може використовувати її. Я використовую сценарій, який перетинає дерево фіксації і автоматично робить це злиття для мене, але все ще може бути болем.

Як альтернатива, новіші версії git підтримують щось, що називається " підмодулі ":

Підмодулі дозволяють вбудовувати закордонні сховища у виділений підкаталог дерева-джерела, завжди вказаний на певний комітет.

Це дозволить вам створити щось трохи схоже на дерева "svn: externals", які ви могли б потім оновити приблизно так само, як зараз.

Тут трохи нуда, але це здається, що повідомлення про отримання пошти може зробити цю роботу

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

Це також здається, що ви хочете щось більше, як лялька чи шеф-кухар, ніж git, для цього це дозволить вам запустити git для управління конфігураціями та модулями в центрі, а маріонетка \ шеф-кухар керувати розгортанням та підтвердженням для вас

ось швидка робота, про яку я подумав
1. Майте центральний сховище у прицілі /var/repo
2. Поставте файли, які є глобальними для всіх доменів у цьому каталозі.
3. Створення філій для кожного поддомена /var/repo/subdomain1, і /var/repo/subdomain2т.д.
4. Створіть поштовий гак , де будь-який поштовх до галузей злитий з майстром.

Отже, коли ви змінюєте конфігурацію, /var/repo/subdomain2вона негайно об'єднується з master, щоб ви могли повністю витягнути репо і мати всі конфігураційні файли.
Коли ви хочете витягнути окремі конфігурації піддомену, просто витягніть відповідну гілку.

Як ви ставите свої конфігураційні файли /var/repo/*- це зовсім інше питання (вкладки cron, я можу придумати)

~ $