Ребята, привет. Подскажите хорошие книжки в которых подробно написано про

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

12factor, и прочие очевидные вещи не очень интересуют. Нужна глубокая конкретика на примерах с плюсами и минусами тех или иных подходов. С принципами знаком.

12 factor apps, если еще не читал ссылка в мане у бота в канале.

12factor, и прочие очевидные вещи не очень интересуют. Нужна глубокая конкретика на примерах с плюсами и минусами тех или иных подходов. С принципами знаком.

Дока CircleCI и Gitlab ? :)

и какое отношение оба инструмента имеют к конфигурированию приложений ?

А или по Ansible? :) При сборке докера все же конфигурируется немного?

Она не отвечает на вопросы: - Где хранить кофнигурацию, - В каком виде хранить конфигурацию - Как доставлять конфигурацию на целевые узлы? - Как добавлять конфигурацию для новых приложений? и т.п.

Вы вообще не про то

прочитай вопрос автора, плиз, чтобы не сыпать баззвордами. кубер вон человеку посоветуй, он же тоже "решает" вопрос "конфигурации" (нет)

Тогда я наверно, не знаю, что есть конфигурирование приложений по вашей терминологии.

давай начнём сначала - а что именно ты хочешь ? виртуалки/докеры/кубернетисы/что-то еще ? в чём вопрос собственно ?

Если натянуть сову на Кубер то мой вопрос скорее о том: - Ка потом весь этот YAML зоопарк менеджить. Хотя меня не конкретно Кубер интересует, а в целом, какие есть подходы, какие есть инструменты, их плюсы/минусы.

Не принципиально. Есть набор бинарников. Хочу организовать менеджмент их конфигурации для разных сред чтобы: - Иметь возможность деплоить любую версию приложения подставляя ей ту конфигурацию которую хочется. При этом не трогая код и репозиторий с приложением. - Иметь возможность управлять конфигурацией приложений. При этом не трогая код и репозиторий с приложением.

Книжку конкретную не подскажу. Ямлы в репах или репе: где-то целеесообразно хранить рядом с приложениями в их же репах, где-то создают монорепы со всеми приложениями. Всё это очень желательно в Helm. Где-то используются Hashicorp Vault для секретов, хорошая штука, рекомендую. Где-то добавляется Consul, тогда конфиги можно на лету оттуда подтягивать. Можно ещё в Gitlab variables хранить и разделять там окружения и права, тоже удобно. Но всё это меняется в зависимости от специфики компании, зрелости команды, специфики проектов. Можно завести себе отдельную репу для конфигураций.

Вот этот весь зоопарк я знаю. Думал может есть какие то уже сложившиеся подходы по организации самих репозиториев й Ямлами/конфигами или самих баз внутри Consul/Vault. Best Practices или кейсы каких-то компаний может. Прежде чем самому весь этот зоопарк заводить хочется ознакомится кто как это до меня уже делал и менеджил

если затянуть сову в кубер - будет сова с автохилингом. хер знает чего это решает, но сова с автохилингом - заявка на инновацию. если же по вопросам: 0. Еще раз порекомендую 12 factor apps. Общий концепт - конфигурация отдельно, приложение отдельно. 1. Как потом весь этот YAML зоопарк менеджить. git 2. Хотя меня не конкретно Кубер интересует, а в целом, какие есть подходы, какие есть инструменты, их плюсы/минусы. отдельно хочу отметить решения по хранению секретов - vault. для всех инструментов выше альтернативы есть, но рекомендую начать с best praсtices инструментов, если будет неуютно - поищите альтернативы. еще в рекомендашке канала есть DevOps HandBook - оно именно рассказывает "как можно решать задачи", а не "каким инструментом".

окай. есть Configuration Management решения - ansible, salt если вопрос именно про конфиги - в gitlab есть environment если кубер - там весьма удобен helm очень важна специфика

Если найдёте релевантную литературу, то отпишитесь, пожалуйста, интересно будет взглянуть. Я строю все эти решения из опыта + постоянно нахожусь в контексте индустрии + много разных компаний и проектов.

> Общий концепт - конфигурация отдельно, приложение отдельно. Это ясно. В одном репе всю кофнигурацию или в разных репах? Если в разных по какому принципу? В чем плюсы/минусы? > 1. Как потом весь этот YAML зоопарк менеджить. git Принято. Кроме git получается других подходов нет?

Человек не про софт спрашивает, а про принципы.

в любой системе контроля версий из альтернатив гиту - mercurial

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

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

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

https://t.me/devops_ru/805519

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

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

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

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

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

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

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

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

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

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

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

А как Compose совмещают с Кубером? Используют то и другое? Зачем Compose, если есть Кубер?

в прод деплоим уже конкретные релизы без латест и остального, дев и мастер это у нас дев и тест)

Один конфиг каждого приложения на каждое окружение. Окружений могут быть десятки (В каждом свои параметры для каждого приложения).

у нас нет кубера в том сегменте о котором я говорю - только композерус

если у вас gitlab - то там есть специальная концепция - environment, в которую можно отдельные конфиги вписывать. минус - оно не версионируется можно загнать всё это в vault (если залеплоенные приложухи имеют доступ к общему волту) можно в ansible - там весьма хорошее разделение окружений, которое весьма понятно.

Это можно версионировать если держать в отдельной репе и оттуда обновлять через api :) Про Gitlab

не надо этой чёрной магии.

С помощью api можно очень крутые решения строить, Gitlab это значительно больше, чем очередной cicd :)

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