Часто люди подходят к ансиблу не с той стороны, используя стереотипы традиционных императивных скриптов

В нем все совпадает, кроме словаря env, который передается контейнеру

Мне нужно в зависимости от того, мастер это или слейв передать нужный env

а это 2 разных словаря

Мне нужно в зависимости от того, мастер это или слейв передать нужный env

А чем определяется - мастер это или слейв?

переменной node_type она задается в плейбуке

Подскажите как в jinja получить значение tag. project_envs: { "staging": { "tag": "{{ lookup('env','IMAGE_TAG') | default('latest-staging', true)}}", }, "production": { "tag": "{{ lookup('env','IMAGE_TAG') | default('latest-production', true)}}", } } При этом staging или production берется из другой переменой.

типа если node_type == master, то env = master_env

переменной node_type она задается в плейбуке

Т.е. тип нод вы определяете в плейбуке?

С разбивкой по серверам?

Т.е. тип нод вы определяете в плейбуке?

да. роль стартуется на хосты в указанием мастер он или слейв

Отлично

Только тогда логичнее перенести разбиение в группы

И вешать соответствующие переменные на group_vars

Тогда и в плейбуке ничего не нужно мутить

Сервер из группы подтянет все нужные переменные

типа hosts: slaves tasks: - name: postgres include_role: postgres vars: node_type: slave other_var: ...

на хосты master соответственно переменная отличается

типа hosts: slaves tasks: - name: postgres include_role: postgres vars: node_type: slave other_var: ...

Вот это vars - можно просто вынести в инвентарь

В group_vars

На группу slaves одни значения, на группу master - другие

И все

Видимо придется, я для них не создавал отдельных group vars просто

Аналогично и с энвом

Так как это единственное что отличается

Нужно просто использовать инструменты по назначению

А не втыкать костыли на пустом месте

Заодно и код роли предельно упрощается, без зависимостей от лишних переменных

А не втыкать костыли на пустом месте

+1

Заодно и код роли предельно упрощается, без зависимостей от лишних переменных

+2

Нужно просто использовать инструменты по назначению

+100

Про Best Practice генерации конфигов: словарь или просто пачка переменных Хотел узнать как лучше всего реализовать задачу. Необходимо генерировать конфиги java-приложений, которые можно описать словарями. Например: --web-security.anonymous-paths[1]=/user/registration.json --web-security.anonymous-paths[2]=/user/confirmation.json --web-security.anonymous-paths[3]=/user/check/secret.json --web-security.anonymous-paths[4]=/user/password/reset.json --web-security.anonymous-paths[5]=/user/password/reset/set.json --web-security.anonymous-paths[6]=/token/login.json --web-security.anonymous-paths[7]=/token/refresh.json Есть и более сложные моменты - и таких роутов на гейтвее может быть 10-50-100: --zuul.routes.oauth.path=/oauth/** --zuul.routes.oauth.service-id=oauth --zuul.routes.oauth.strip-prefix=false --zuul.routes.oauth.sensitiveHeaders='' --zuul.routes.ipn.path=/ipn/** --zuul.routes.ipn.service-id=ipn --zuul.routes.ipn.strip-prefix=false --zuul.routes.ipn.sensitiveHeaders='' Но проблема в том, что правка файла с переменными, где они хранятся, находится в руках, например, QA, которые могут поломать YAML к примеру и тогда генерация шаблона просто перестанет работать. Также вижу проблему с добавлением новых опций в конфиги от разработчиков - им надо учиться jinja2 для работы со словарем. Хотя достаточно просто сейчас в лоб записать в шаблон конфига +1-10-100 переменных без всяких словарей и шаблон будет всегда читаемым. По сути вопрос простой: ансиблируем с использованием словарей и jinja2 или решаем в лоб путем постоянного добавления новых переменных, но оставляем максимально простой шаблон для генерации конфигов.

Если у человека руки из жопы, то это его проблема как мне кажется

Не надо на это ориентироваться)

вопрос не в руках из жопы, а в сложности генерации

у меня вот голова в жопу превращается, если я такое вот напишу

https://everythingshouldbevirtual.com/automation/ansible-defining-variables-as-dictionaries/

А конфиги сами не меняются?

Я джинджирую так сказать, но у меня конфиги постоянны

Туда просто нужные значения переменных из inventory идут

А конфиги сами не меняются?

немного бекграунда: конфиги нужны для пачки микросервисов. они живые. постоянно добавляются опции. например новые роуты. сами конфиги надо генерировать потому что они используются сейчас в 6 окружениях + версионируются

Ну тогда джинджа да

немного бекграунда: конфиги нужны для пачки микросервисов. они живые. постоянно добавляются опции. например новые роуты. сами конфиги надо генерировать потому что они используются сейчас в 6 окружениях + версионируются

есть какой-то формат, данные могут вообще быть не локальными, а сидеть в сервисе конфигурации.

Туда просто нужные значения переменных из inventory идут

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

есть какой-то формат, данные могут вообще быть не локальными, а сидеть в сервисе конфигурации.

да. я понимаю это. но его нет

сервиса типа consul/etcd

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

Да, с циклами и словарями удобнее

У самого так

И if там же

я это понимаю

вопрос в том, как этот самолет поддерживать

Потому что для тестинга и прода например конфиг может немного отличаться

да. я понимаю это. но его нет

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

Потому что для тестинга и прода например конфиг может немного отличаться

для конкретной версии конфиг одинаковый. это застолбили

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

да. люто плюсую про валидацию

но

тогда будет под каждое окружение свой сервис

тогда будет под каждое окружение свой сервис

не обяз.

обязательно

они должны быть автономными

можно сделать сервис с namespaces

не

автономные

они должны быть автономными

как надо так и делай :) я не знаю твоих мнимых и реальных издержек.

🙏

понял. спасибо)

Подскажите как в jinja получить значение tag? btype: 'staging' project_envs: staging: tag: VAL1 production: tag: VAL2 Например это возвращает ошибку {{project_envs[btype].tag}}

Подскажите как в jinja получить значение tag? btype: 'staging' project_envs: staging: tag: VAL1 production: tag: VAL2 Например это возвращает ошибку {{project_envs[btype].tag}}

потому что такого атрибута в project_envs нет.

а, сорри, ступил может быть. оштбку покажешь?

сек

"project_envs[btype].tag": "VARIABLE IS NOT DEFINED!: 'dict object' has no attribute u'staging}}'"

"project_envs[btype].tag": "VARIABLE IS NOT DEFINED!: 'dict object' has no attribute u'staging}}'"

'staging}}'

да но откуда она появляется - debug: var: project_envs[btype].tag

да но откуда она появляется - debug: var: project_envs[btype].tag

это значение btype

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

btype: 'staging'

Товарищи! Столкнулся с такой проблеммой: есть два хоста с CentOS 7, развернутые из разных "золотых" образов, прокручиваю на них плейбук, на одном все нормально, на втором ansible создает большую кучу процессов ssh-agent и не закрывает их по завершении плейбука. Настройки sshd идентичные. Не могу понять в чем дело. Кто-нибудь сталкивался с подобным поведением?

btype: 'staging'

Оно видимо где-то переопределено

Товарищи! Столкнулся с такой проблеммой: есть два хоста с CentOS 7, развернутые из разных "золотых" образов, прокручиваю на них плейбук, на одном все нормально, на втором ansible создает большую кучу процессов ssh-agent и не закрывает их по завершении плейбука. Настройки sshd идентичные. Не могу понять в чем дело. Кто-нибудь сталкивался с подобным поведением?

sudo?

Да, на обоих делаю через ansible_become