Ну так их учить надо а не стебатся и занижать уровень требований

расскажу свою историю: в СНГ проекте делал большую автоматизацию, сделал, сдал в прод, и вяло вяло поддерживаю, потомучто все ок ко мне приходит переодически работяга из этой конторы с мелкими хотелками (которые решаются на уровне поправить host_vars/group_vars) в какой-то момент я научил его самому делать Pull Request , а остальное делал CI/CD после того как он начать делать пулл-реквессты, я перешел на русский язык в коммит мессаджах. что бы работяга понимал что происходит. такие вот условия работы в СНГ конторах

ну что получил работяга понятно, не ясно только стало ли это полезно для тебя и остальных

угу. Все конторы ломанулись обучать людей английскому.

но до сих пор когда вижу кириллцу в коммит-мессаджах, мне становится немного по не по себе

Регионы?

Сложнее всего с issue на gh

Ладно тут это всё очень офтоп

Жёсткий антипатерн. Выполнить скрипт на удаленном хосте используя shell: ssh host script.sh. как при этом форварднуть агент на удаленный хост?

Как только найду время буду ковырять vault от hashicorp

Расскажите о нем, есть опыт?

Пока нет, только доку мельком читал, но vault от ансибла точно не лучшее решение для более менее больших проектов

Раскройте эту мысль?

Ну и последнее: по невнимательности теряли секреты на мержах

Сравнение vault

ээ, а откатиться можно же всегда

Да, но не в процессе выкатки релиза узнаешь что vars отсутствует, и вот это все...

Такие проблемы должен отлавливать CI и CD на стейджинг при правильно построенном процессе

Тоесть сейчас это /inventory/имя_окружения/group_vars/all/secrets.yml

Ну, лично я писал Makefile, который генерил секрет из .env и из файликов в ~/.secrets_folder. Ну, или можно local плейбук накатать, который соберет секрет и потом еще дернет шифрование. А сам процесс добавление чего-то в секрет - это собственно добавление в шаблон секрета. Если используется общий сквозной секрет - то это уже извращеный подход. Но даже проблема с общим сквозным секретом решается генерацией. Ровно так же как lock файлы в пакетных манагерах. Кому как удобнее... Не понимаю в чем боль с мержем? Если один кто-то имеет право мержить, то все пилят просто в свои ветки свои секреты, а он уже потом смержит. Еще как альтернативу генерации могу предложить делать секреты как миграции (т.е. складировать тучу разных версий по таймстемпу). Ну и в плейбуке явно все это инклудить по glob или что-то вроде того, но это тоже какой-то изврат

Я написал выше как решил эти проблемы. Что значит просто пилят в свои ветки? Как потом мержить зашифрованные файлы?

Я написал выше как решил эти проблемы. Что значит просто пилят в свои ветки? Как потом мержить зашифрованные файлы?

Я написал выше как решил эти проблемы. Что значит просто пилят в свои ветки? Как потом мержить зашифрованные файлы?

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

Эм как?) У нас 2 ветки и мастер. Тоесть мы применили из 1 ветки последний, потом из 2 последний и потеряли из 1 ветки

Что значит обновляются в штатном режиме? Не руками разрабов а чьими?

Что значит обновляются в штатном режиме? Не руками разрабов а чьими?

разрабы в идеале секреты даже в глаза видеть не должны. есть такая роль - администратор безопасности.

И как это отвечает на вопрос каким образов креды попадут в мастер?

У каждого разраба креды свои или общие?

администратор безопасности сделает коммит - и попадут.

А ну пойду открывать вакансию, спасибо)

толсто. перечитай ещё раз - РОЛЬ, а не человек.

У каждого сервиса разные, но есть и совместные

Может пример кода есть? Я быстрее пойму

Ну, каждый кидает креды в свой файлик secrets/ —all.yml —vasya.yml —petya.yml Каждый пропишет себе в .env DEPLOY_ENV=vasya И дергать плейбук с нужным env env $(cat .env|xargs) ansible-playbook ... И уже в самом плейбуке подключать по переменной lookup('env', 'DEPLOY_ENV') Так можно разграничить частные секреты. А общими пусть Ваш мерж-суперадмин управялет.

Зачем это прописывать если окружения разделены на уровне inventory/env/...

Зачем это прописывать если окружения разделены на уровне inventory/env/...

и не надо. вот тот файлик где все креды лежат кидаешь в inventory/<name>/group_vars/all.

А при чем тут окружения к частным секретам?... На одном окружении может быть туча операторов

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

Частные секреты это для конкретного сервиса?

Блин, ну Ты жжешь)) Честно. Смотри. Общие секреты - клепает чувак, который у Вас там мержами заведует. Как он это делает - вообще его трудности. В идеале, они должны по крону опрашивать hashicorp vault или другую какую-то хрень и перегенериваться. Ну или по колбеку. И не нужно садить на это человека. (ротация кредов - то, о чем Тебе сказали выше) Частные секреты - если у каждого свой пароль от ажура, авс и прочих облаков и нужно чтобы тела ходили только под своими кредами. И самый простой способ - это напилить переменную окружения по которой подключать нужный секрет определенного чувака. И конечно же, каждый должен дергать плейбуки под своей переменной

нет. всё с окружения лежит в одном файле.

Вот и вернулись к hashicorp и к единственному неразрешенному вопросу с общими секретами)

2 разраба добавляют в разных ветках свои креды. Как мержить?

разрабы НЕ добавляют креды. процесс сломан. мерджить не надо.