Стратегия Git для хранения конфигураций докеров для нескольких машин

Question

У меня есть несколько узлов докера - для аргументов ради, давайте в качестве примера будем использовать 3.На этих 3 хостах у меня всего 10 приложений.Каждый будет автономным или частью стека.Большинство приложений содержат некоторые постоянные данные (файлы конфигурации и т. П.).

В прошлом я использовал плоскую структуру SVN.

docker-data
  stack1
    app1
    app2
    app3
  stack2
    app4
    app5
  stack3
   app6
   app7
  app8
  app9

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

Где хост 1 = стек 1, хост 2 = стек2, хост3 = стек3 и app8 и 9

Как частьвосстановления я собирался посмотреть на переход к git и лучшую структуру.

Я видел, как кто-то предложил всю мою структуру перейти в git как мастер с веткой для каждого хоста.

master
  docker-data
    stack1
      app1
      app2
      app3
    stack2
      app4
      app5
    stack3
      app6
      app7
    app8
    app9
host1
   docker-data
    stack1
      app1
      app2
      app3   

Это казалось довольно хорошим подходом.Но что меня поразило, так это то, как его изначально настроить.

Если все мои приложения находятся в мастере, как мне инициализировать ветку для хоста один и только тянуть app1, 2 и 3?

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

И, наконец, я хочу переместить app8 в ветку host1 с хоста 3.

Это слишком сложно?и есть ли какие-либо сообщения или команды, которые могли бы помочь мне облегчить это?

Answer 1

В целом, не рекомендуется использовать разные ветки Git для конфигурации на разных системах, потому что вы сталкиваетесь с проблемами, с которыми вы столкнулись. Если вы сделаете это, вы также, вероятно, столкнетесь с конфликтами, если вам потребуется какое-либо слияние.

Типичным способом управления конфигурацией для разных систем является какая-то система шаблонов. Например, вы можете использовать ERB Ruby для написания шаблонов, а затем настроить каждый хост с помощью файла конфигурации YAML, с шагом сборки, создавая выходной каталог с конфигурациями для каждого хоста. У вас будет только одна основная ветвь с дополнительными ветвями функций, которые будут объединены по мере готовности.

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