а разве так можно?

https://github.com/ansible/ansible/issues/11175

вижу вот это только, но все равно какая-то странная фича

Я вот и спрашиваю просто как бы получил задание дать програмистам путь к playbook они говорять как нам указать путь к ним , я говорю максимум что могу это роли посоздавать а путь ... ) Я просто все из папки с плейбуками выполняю

Путь к плейбуку - обязательный параметр команды ansible-playbook. Если нужна переменная - пусть будет переменная PLAYBOOK_PATH, и вызывать просто ansible-playbook $PLAYBOOK_PATH

Добрый день, коллеги Кейс: Есть вставляемый конфиг, который имеет собственный стиль (пустые строки, проблемы). Когда делаю include, то правило касательно пробелов соблюдается только для первой строки. Все остальные вставляются от 0 позиции (те вначале) Что ожидаю: data: conf: | # General some data Что получаю: data: conf: | # General some data Что было испробовано: |/|+/|-/""/''/[] Есть идеи?

Добрый день, коллеги Кейс: Есть вставляемый конфиг, который имеет собственный стиль (пустые строки, проблемы). Когда делаю include, то правило касательно пробелов соблюдается только для первой строки. Все остальные вставляются от 0 позиции (те вначале) Что ожидаю: data: conf: | # General some data Что получаю: data: conf: | # General some data Что было испробовано: |/|+/|-/""/''/[] Есть идеи?

data: config.json: |- {{ lookup('file', 'files/matrix/riot.json') | indent(4) }}

conf: |2

conf: |2

не сработало, последующий текст все равно стартует от начала строки

смотри, вот тестовый плейбук: `--- - name: 'Ololo tasks' hosts: all connection: local gather_facts: no vars: ololo: |2 ololo1 ololo2 tasks: - debug: msg="{{ ololo }}" `

ох, кривости, извиняюсь)

короче, для some data добавь пробелы ещё

data: config.json: |- {{ lookup('file', 'files/matrix/riot.json') | indent(4) }}

как отдельный таск сработало... сейчас попробую запихнуть в исходные файл, чтобы не плодить таски, Спасибо!

Асинхронночка в ансибл огонь)

смотри, вот тестовый плейбук: `--- - name: 'Ololo tasks' hosts: all connection: local gather_facts: no vars: ololo: |2 ololo1 ololo2 tasks: - debug: msg="{{ ololo }}" `

там конфиг на 600+ строчек) его в варс пихать изврат))) да и разрабы хотят динамики

Неделю юзаю код асинхронный.

Эм, асинхронность в ансибл?)

Неделю юзаю код асинхронный.

Как так?

Эм, асинхронность в ансибл?)

Ага, мало кто знает, мало кто юзает. Даю фидбек, это охренеть как круто

А в доку можно ткнуть?)

Я в метро гугли async ansible

Забавно)

У меня с полпинка завелось, никаких сложностей не возникло.

У меня с полпинка завелось, никаких сложностей не возникло.

Не все модули его поддерживают

Не все модули его поддерживают

Не все

unarchive например не поддерживает

- name: Stop wildfly service: name: wildfly state: stopped register: stop_wildfly async: 120 poll: 0 - name: Waiting until wildfly stopped async_status: jid: "{{ stop_wildfly.ansible_job_id }}" register: job_result until: job_result.finished retries: 15 delay: 15 Вот кусок из плейбука для примера.

Если нужно остановить десяток другой вайлдфлаев, так он отработает быстрее.

archive и unarchive имеют баг с экслюдами, поэтому я через шелл написал таск. А мы же понимаем что ждать пока он выполниться нам не обязательно, поэтому выполняем асинхронно, и пока создаётся архив делаем другие таски. - name: Create archive liferay from source zone shell: "tar {% for ex_path in exclude_paths[side_name[:3]] %}--exclude={{ ex_path }} {% endfor %}-c -z -f /tmp/liferay.{{ side_name[:3] }}.{{ ansible_date_time.date }}.tgz liferay" args: chdir: /opt warn: false register: src_archive async: 1800 poll: 0

дампы бд туда же, старт сервисов, нотификейшены, чистка временных кусочков после работы, установка пакетов. Это уже не маленький список который можно распараллелить и ускорить время выполнения.

Господа, что делать, когда одна роль использует питон2, а другая питон3?

как в одном плейбуке это увязать нормально?

Господа, что делать, когда одна роль использует питон2, а другая питон3?

Делай 2 плейбука в одном файле

эммм?

и где определять интерпретатор, в роли?

- name: Unlock remote access to hosts hosts: "all" gather_facts: false vars: python: или как его там tasks: - some_tasks - name: Unlock remote access to hosts hosts: "all" gather_facts: false vars: python: или как его там tasks: - some_tasks

Кажется понял, ща протестирую

при dependencies не работает, сейчас попробую без

все, разобрался, спасибо за наводку 👍

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

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

--skip-tags=SKIP_TAGS

Куда это?

ansible-playbook --skip-tags=SKIP_TAGS ...

Я хочу в плейбуке

Я хочу в плейбуке

Я бы на вашем месте роль разбил на несколько частей в этом случае...

Я хочу в плейбуке

нельзя так, теги только при запуске плейбуков

Ну тогда ладно

Я хочу в плейбуке

Вы хотите странного

Я тут хочу странного.... есть кучка var files с частями словаря, как бы их в плейбуке в один лист словарей собрать? Пример: app1.yml app: - name: app1 path: foo app2.yml app: - name: app2 path: bar

А собрать бы такое: apps: - name: app1 path: foo - name: app2 path: bar

А собрать бы такое: apps: - name: app1 path: foo - name: app2 path: bar

https://blog.crisp.se/2016/10/20/maxwenzin/how-to-append-to-lists-in-ansible

https://blog.crisp.se/2016/10/20/maxwenzin/how-to-append-to-lists-in-ansible

О, спасибо, нагугливал это, но на гитхаб не переходил, а там как раз то что нужно: https://github.com/betrcode/ansible-append-list/blob/master/README.md

Я тут хочу странного.... есть кучка var files с частями словаря, как бы их в плейбуке в один лист словарей собрать? Пример: app1.yml app: - name: app1 path: foo app2.yml app: - name: app2 path: bar

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

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

Не, там список, с ним прокатит. Вот, со словарём так не получится, да

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

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

В итоговом списке словарей этого ключа верхнего уровня вовсе быть не должно

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

Очень важен. Если его правильно выбрать, то без приседаний можно список итоговый собрать.

Очень важен. Если его правильно выбрать, то без приседаний можно список итоговый собрать.

Итак, входные данные: var/app1.yml app: - name: app1 path: foo var/app2.yml app: - name: app2 path: bar И переменная с выбором apps_list: [ app1, app2] я решил свой вопрос вот таким образом: - name: apps | Combine list of apps block: - name: apps | Combine list of apps | Select apps from var files include_vars: name: "{{ item }}" dir: "vars" files_matching: "{{ item }}" extensions: - yml - yaml with_items: - "{{ apps_list }}" when: - apps_list is defined - name: apps | Combine list of apps | Create default 'apps' set_fact: apps: [] - name: apps | Combine list of apps | Add selected to list 'apps' set_fact: apps: "{{ apps }} + {{ vars[ item ].app }}" with_items: - "{{ apps_list }}" when: - apps_list is defined - debug: var: apps

на выходе в дальнейший плей получаю: apps: - name: app1 path: foo - name: app2 path: bar как и задумывал. PS: может пригодится кому

Словари мержить по хешам же можно, сыкотно, но для тестов годится

Словари мержить по хешам же можно, сыкотно, но для тестов годится

мне нжен был не мерж словаря, а объединение списка словарей 🤔

мне нжен был не мерж словаря, а объединение списка словарей 🤔

А это я не тебе. Иди спать, 3 часа ночи.

мне нжен был не мерж словаря, а объединение списка словарей 🤔

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

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

декларативность никуда не пропала, эта часть логики на jinja|yml нужна внутри роли для правильного подключения шаблонов ресурсов

У роли есть конкретные места для переменных - так же, как и у инвентори. include_vars - это то, что стоило бы обос.... в общем, облить чем-нить и сжечь.

Показанный подход лично меня спровоцировал бы на ошибку: словари одинаково называются, плюс имеют одинаковые ключи.

А это ой.

У роли есть конкретные места для переменных - так же, как и у инвентори. include_vars - это то, что стоило бы обос.... в общем, облить чем-нить и сжечь.

механизм include вообще не удобный и не красивый, да но какие есть варианты, если эти переменные не относятся к переменным хоста и переменным плейбука ps: в puppet есть loadyml и loadjson, в salt есть include с логикой на jinja

Чтобы от таких ошибок уберечься, я обычно делаю параметризированные роли, которые вот это вот всё ожидают извне, либо имеют минимально разумные дефолтные значения. Да, сложно. Да, будут повторяться вызовы роли с разными параметрами. Но зато декларативность. Тогда к чему именно относятся эти переменные, если они вообще хоть сколько нибудь переменные? Если перестать себе врать и начать назвать их не переменными, а просто списками в рамках роли, то окрываются интересные перспективы 😉 p.s. в ansible есть include_vars и from_json (jinja), да и логику там совершенно отбитую можно запилить, вопрос в другом - а насколько трудоёмкость поддержки это всё окупит?

Чтобы от таких ошибок уберечься, я обычно делаю параметризированные роли, которые вот это вот всё ожидают извне, либо имеют минимально разумные дефолтные значения. Да, сложно. Да, будут повторяться вызовы роли с разными параметрами. Но зато декларативность. Тогда к чему именно относятся эти переменные, если они вообще хоть сколько нибудь переменные? Если перестать себе врать и начать назвать их не переменными, а просто списками в рамках роли, то окрываются интересные перспективы 😉 p.s. в ansible есть include_vars и from_json (jinja), да и логику там совершенно отбитую можно запилить, вопрос в другом - а насколько трудоёмкость поддержки это всё окупит?

👍

Я согласен с Арамисом (c)

Плодить такую наркоманию ради ввода параметров роли явно избыточно

Кто это юзал? Поделитесь впечатлением.. https://github.com/vstconsulting/polemarch

Кто это юзал? Поделитесь впечатлением.. https://github.com/vstconsulting/polemarch

Мне не зашло, вот скоро буду форман пробовать

Мне не зашло, вот скоро буду форман пробовать

А что не так? Хотел просто вечером попробовать развернуть в докере

Тогда пробуй

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

нашел, похоже мне нужен DEFAULT_HASH_BEHAVIOUR

нашел, похоже мне нужен DEFAULT_HASH_BEHAVIOUR

Ты хочешь странного. Не надо так.

нашел, похоже мне нужен DEFAULT_HASH_BEHAVIOUR

Это лучше не трогать без необходимости