Кстати упоминали, что Ansible может перестать быть актуальным для облачных приложений, потому что все уходит в Кубер.
И что я неправильно предложил выше? Дока по Gitlab + Ansible/Kuber  ? :)

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

очень много вопросов - какую задачу решаете - от этого и выбирать способ устройства репок.

Бывает удобно хранить и в одной репе, т.к. деплоится это всё из разных папок и по only: changes и другим маскам. Версии конфигов фиксируются так же как и приложений: тегами, номерами релизов в файлах и т.п.

Ansible это одно, Terraform то другое. Что же вы так на buzzword'ы эти реагируете? Для каждой задачи свой инструмент и Ansible вполне жив. Хотя если дело касается облачных провайдеров, то там большинство задач решается Terraform/Terragrunt

Не понимаю, зачем внутри докер контейнера или гостевухи что-то кроме Debian (Бубунту)/Alpine, ну RedHat изредка, остальное вроде экзотика?

Предположим храним конфиги в отдельной репе. Сами приложения хранятся в отдельных репах.
В таком случае пайплайн деплоя должен (по каким то параметрам) взять артефакты конфигурации (для соотв. приложения) а артефакты релиза (соотв приложения), слить их вместе и раскатать на целевые машины, правильно?

А в kvm/qemu? Речь пока не о контейнерах. С контейнерами то выбор очевидный - начинать с alpine и если что-то не получается из за базы пробовать debian/ubuntu.

Примерно так да.

Чем для виртуалок не подходит Alpine? Я не пытаюсь кого-то переубедить, мне просто самому интересно для обучения.

можно и так сделать, как ты написал.

можно раскидать их по разным environment, чтобы они отдельно хранились

можно делать репку сделать зависимую история, чтобы где-то были маппинги - app_version, conf_version, env_name

повторюсь - зависит от процесса разработки и задач, которые вы хотите решать.

вот простой вопрос - в чём цель отделить конфиги от приложения ?
ИБ, разделение доступов, ревность разрабов, что кто-то без ведома коммитит конфиги в мастер ?

Часто куберу делается доступ к реестру контейнеров и в применяемой конфигурации helm указывается какую версию скачать и откуда взять конфиг.

Спасибо. Остается вот такой еще конкретный вопрос. Допустим я хочу помеять конфиг (какие то в нем параметры) но оставить ту же версию приложения которая сейчас крутится (предположим v1.2.3). Как может выглядеть в таком случае пайплайн для обновления этого конфига, так чтобы приложение с ним перезапустилось или его подтянуло?

сколько версий конфигов у вас может одновременно крутится ?
по одной на окружение ?

Да ни чем, кроме того что образ для openstack придется самому собирать, и поддержка cloud-init недавно появилась.

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

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

@antonikucherov
если по одной версии конфигов на окружение - положите всё в vault и забирайте оттуда.

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

Деплоите latest в прод и меняете теги по пути от dev до prod? Это плохо