тогда внутри ансибла это действительно превращается в unicode, и всё в ажуре

главное - не заниматься фигнёй с минусами вот, скобками, вот этим вот всем

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

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

delegate_to?

Угу понял спс

В продолжение треда про vault, я вот с коллегами уже изрядно постучался с ним

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

*помучался

Самое жестокое это мерж)

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

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

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

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

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

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

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

Про не лучшее решение?

Да

Ну смотрите, когда в ансибл репозиторий пушит много людей а мержить имеют право не все возникают конфликты

Я про зашифрованные полностью файлы

Частично удалось решить проблему 2 вещами:

1) секреты для сервисов (то что не нужно людям) шифруются в vars как encrypted string

2) если нужно в зашифрованный файл что-то положить это пугает отдельным pr и тут же пинают тех кто может мержить

Не очень впечатляет длинна путей до секретов когда у тебя несколько окружений

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

Хм. Я понял о чем вы говорите и не думаю что это большая проблема чтобы смотреть в другую сторону

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

Ну говорю, я сейчас не дёшево решил

Но на будущее хочу на hashicorp всё-таки посмотреть

Кстати норм тема для статьи на хабру...

Сравнение vault

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

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

Сравнение vault

Я не до конца понимаю вашу боль по поводу мержей, видимо нужно смотреть на конкретные примеры

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

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

а. я думал совсем теряли, и мне даже интересно стало как в гите можно всё потерять

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

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

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

Ага) как раз стейдж и поднимаю)))

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

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

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

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

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

Ну, а как lock файлы мержат? Тупо применять последний

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

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

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

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

На сколько я понял, ansible-vaut не предполагался никогда для передачи кредов кому-то. Это утилита для того, чтобы каждый оператор не вводил каждый раз свои креды, которые он получил по други защищенным каналам.

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

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

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

Ну, смотри. Проблема не нова. Разрабы с этим уже как-то живут лет 10. С composer.lock, package-lock.json, Gopkg.lock и прочими. Почему не заюзать этот опыт с автоматически генерированными файлами в сферу криптованных файлов?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

а кто будет выполнять действия за эту роль - это уж как в бизнес-процессах конкретной организации заведено.

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

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

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

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

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

есть. но как-то тупо креды, хоть и волтом закрыте, в чат сливать, не? —- serv1: [ 'login': 'login', 'password': 'pass'] и в файле такого вида перечисляешь все креды окружения, потом его волтишь. далее в роли ссылаешься на результат уже этого файла: {{ serv1['login'] }} ..... {{ serv1[''password'] }} Вторую подстановку разработчик может хоть себе на лоб написать - ничего не изменится. Она сработает только при запуске плейбука с корректно раскрытым волтом.

Ну, каждый кидает креды в свой файлик 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/env/...

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

Парни стоп

У меня уже это все сделано

И лежат там креды

И env прописывать не надо

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

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

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

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

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

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

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

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

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

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

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

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

И проблема это моя с мержем, я их и мержу потом...

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

Ну, можете и excel парсить с кредами)) Тут уже у каждого свой полет фантазии. Но, кстати, если будут общие секреты и частные, то нужно будет общие еще в частные засовывать, потому что вроде нельзя дернуть плейбук с несколькими файлами паролей от ansible-vault.

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

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

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

Они должны мне прислать их голубями и я добавлю?

Удобств не добавляет

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

Да, он по ходу переработался с этими мержами)))) У них там кто-то первый костыльнул, и теперь они за ним 40 лет по мержам и ходят)

Удобств не добавляет

Тебе уже предложили варианты. За 2 часа по 15$/час могу решить Вашу проблему с мержами.

Чот я вас не понял всеравно. Если использовать hashicorp для кредов то на кой хрен их перегенеривать в ансибловый?

Чот я вас не понял всеравно. Если использовать hashicorp для кредов то на кой хрен их перегенеривать в ансибловый?

не hashicorp, а ansible-vault!

не hashicorp, а ansible-vault!

Ещё раз, пишем роль которая генерит нам файл секретов и пушит их в мастер?

От того что вы написали меня в дрожь бросает начиная с makefile

Как бы занудно это не звучало, но стремление к организации "правильных" процессов ограждает от ряда проблем и оригинальных костылей

работает с esxi без центра?

Не проверял

Не проверял

да, уже вижу

"template: ", в esxi такого нет

Да я ради темплейта всё и делал

только из-за этого пришлось свалить с esxi на стенде( , неудобно автоматизировать развертывание

Ну мне и тот и другой нужен

У меня нет ssh на всферу. А пакеру нужен именно он

у меня и сферы нет)

Страдай чо

Страдай чо

Да ну, сменил гипервизор, ансиблю что хочу)

Да ну, сменил гипервизор, ансиблю что хочу)

На что?

На что?

Hyperv ?

Hyperv ?

Виндовс... неожиданно, я думал kvm будет)

Hyperv ?

И как? Какие тонкости/нюансы? Подводные камни?

Виндовс... неожиданно, я думал kvm будет)

Я из стенда сделал жирный десктоп, старый сыну отдал. А линукс на десктопе я не хочу больше

И как? Какие тонкости/нюансы? Подводные камни?

Ну как провайдер не так распространен, да у меня частный случай, можно и виртбокс.

Вагрант+ансибл+hyperv - хватает

Я из стенда сделал жирный десктоп, старый сыну отдал. А линукс на десктопе я не хочу больше

Почему не хочешь? Для работы хватает, поиграть уже мало правда