А где почитать про лучшие практики? Есть большой схорон знаний. Или все часто?

А где почитать про лучшие практики? Есть большой схорон знаний. Или все часто?

Документация

А где почитать про лучшие практики? Есть большой схорон знаний. Или все часто?

https://docs.ansible.com/ansible/latest/user_guide/playbooks_best_practices.html

Кстати по best practice-ам. Вроде там это не описывается Насколько хорошая практика хардкодить имя группы в роль? Например есть роль для раббит кластера. Нужно в конфиг раббита засунуть список хостов группы раббита. Получается в роли зашивается зависимость от имени группы. Что-то мне подсказывает что это не очень хорошо. Как сделать это более грамотно?

Спасибо

Кстати по best practice-ам. Вроде там это не описывается Насколько хорошая практика хардкодить имя группы в роль? Например есть роль для раббит кластера. Нужно в конфиг раббита засунуть список хостов группы раббита. Получается в роли зашивается зависимость от имени группы. Что-то мне подсказывает что это не очень хорошо. Как сделать это более грамотно?

В роли делается переменная в которой задано имя группы

В роли делается переменная в которой задано имя группы

👍

В роли делается переменная в которой задано имя группы

Спасибо 👍🏽

у меня такая странная нужда

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

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

https://docs.ansible.com/ansible/latest/modules/add_host_module.html

Вот спасибо

Кстати по best practice-ам. Вроде там это не описывается Насколько хорошая практика хардкодить имя группы в роль? Например есть роль для раббит кластера. Нужно в конфиг раббита засунуть список хостов группы раббита. Получается в роли зашивается зависимость от имени группы. Что-то мне подсказывает что это не очень хорошо. Как сделать это более грамотно?

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

А так - with_items в топку, особенно для установки пакетов. Ветвление по триггерам наличия/отсутствия параметра прокси лучше делать иначе - без дублирования тасков, используя фильтр default(omit).

> А так - with_items в топку, особенно для установки пакетов. Почему?

Потому что надо лист передавать

Да. И?

А, и вместо with_items надо использовать loop

А, и вместо with_items надо использовать loop

Эээ.... Это не отвечает на мой вопрос )

Да. И?

С with items ты запускаешь пакетный менеджер n раз, вместо запуска 1 раз с передачей всех пакетов сразу

Да. И?

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

Не все модули это умеют только

Это как apt install a apt install b apt install c

Вместо apt install a b c

А это где-то описано в доках?

https://docs.ansible.com/ansible/latest/user_guide/playbooks_loops.html#comparing-loop-and-with Здесь этого не говорят

В бестпрактисах вроде.

Это как apt install a apt install b apt install c

https://docs.ansible.com/ansible/latest/modules/apt_module.html "When used with a loop: each package will be processed individually, it is much more efficient to pass the list directly to the name option."

@inqfen Стоп. Я сравниваю с loop, а ты говоришь о прямой передаче листа. Понял.

Не знал.

Да, а loop и with_items в общем-то одно и то же, но with_items это старый синтаксис и скоро оно начнёт ругаться, а потом перестанет работать

Ну они там пишут, что не скоро...

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

Меньше передеоываний потом

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

Ну и loop имеет разные плюшки по сравнению с with, это в доках есть

Я вижу много дополнительнй ухищрений, вроде |flatten(1)

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

Попробуйте зарелизить на galaxy роль со старым кодом - увидите, что будет

Попробуйте зарелизить на galaxy роль со старым кодом - увидите, что будет

Это достаточно странный аргумент ) К тому же, вряд ли кто-то будет выкладывать старый код. Хотя, в galaxy полно треша. Даже если и "приличия" и тренды соблюдены, с архитектурной точки зрения может быть ужас.

С with items ты запускаешь пакетный менеджер n раз, вместо запуска 1 раз с передачей всех пакетов сразу

Т.е. лучше всё же вот так? - name: Install a list of packages apt: name: "{{ packages }}" vars: packages: - foo - foo-tools

Т.е. лучше всё же вот так? - name: Install a list of packages apt: name: "{{ packages }}" vars: packages: - foo - foo-tools

Да

Т.е. лучше всё же вот так? - name: Install a list of packages apt: name: "{{ packages }}" vars: packages: - foo - foo-tools

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

Точнее в роли это в defaults делать

Потом в случае надобности можно переопределить через инвентори/vars, а так это хардкод

Есть плейбук с применением всех бест практикс?

- name: Install | system packages apt: name: "{{ packages }}" update_cache: yes vars: packages: - "{{ system_packages }}" —> variables

а item.state откуда взял?

Есть плейбук с применением всех бест практикс?

это лишь рекомендации. Следовать им или нет, зависит в общем то от репозитория.

И почему не проще - name: Install | system packages apt: name: "{{ system_packages }}" update_cache: yes

а item.state откуда взял?

забыл. Копировал для примера.

present по дефолту

ок

И почему не проще - name: Install | system packages apt: name: "{{ system_packages }}" update_cache: yes

ну в доке пример такой

хотя, дошло.

ну в доке пример такой

Для наглядности, не будут же они там defaults еще рисовать

ага

Есть параметр --forks=1, тогда ансибл будет по одному хосту играть плейбук. А как сделать что бы следующий хост "играл" только если предыдущий завершился без ошибок?

serial

forks это не то

serial

это заставит играть следующий хост только при успешной "игре" на предыдущем?

судя по описанию либо вы не правы про "serial", либо я плохо читаю (что не исключено))

https://docs.ansible.com/ansible/latest/user_guide/playbooks_delegation.html#maximum-failure-percentage

в сериал можно сказать, сколько максимально может упасть

Так что видимо таки проблемы с чтением

А так - with_items в топку, особенно для установки пакетов. Ветвление по триггерам наличия/отсутствия параметра прокси лучше делать иначе - без дублирования тасков, используя фильтр default(omit).

environment: "{{ proxy_env | default(omit) }}" Т.е. если задал proxy_env - используй, если не задан - пропусти environment

?

Еще есть вот такая штука https://docs.ansible.com/ansible/latest/user_guide/playbooks_error_handling.html#aborting-the-play

https://docs.ansible.com/ansible/latest/user_guide/playbooks_delegation.html#maximum-failure-percentage

хм.. вроде вы правы. Надо проверить)

https://docs.ansible.com/ansible/latest/user_guide/playbooks_delegation.html#maximum-failure-percentage

#memory

Еще есть вот такая штука https://docs.ansible.com/ansible/latest/user_guide/playbooks_error_handling.html#aborting-the-play

#memory

environment: "{{ proxy_env | default(omit) }}" Т.е. если задал proxy_env - используй, если не задан - пропусти environment

Да, environment в таск не передастся

По add_host так и не понял как на нем такску выполнить

Да, environment в таск не передастся

круто, кучу строк кода выкинуть ...

- name: Register packagist add_host: hostname: "packagist" groups: development ansible_ssh_host: "packagist.example.com” ansible_ssh_port: “2222” - name: Witelisting on packagist ufw: rule: allow src: "{{api_ip}}" comment: "{{api_hostname}}" when: inventory_hostname in groups['development’] TASK [api-role : Witelisting on packagist] ******************************************************************************************************************************************************** skipping: [de-fra.staging] Ну то есть он таску пытается выполить на хосте который в инвентори и она не проходит кондишн и скипается

По add_host так и не понял как на нем такску выполнить

В одном плее делаешь add_host, в другом на эти хосты уже пускаешь таски и роли

По add_host так и не понял как на нем такску выполнить

delegate_to или на отдельную группу через hosts

А как Вам идея использовать модуль package вместо веток для apt для yum, dnf... По доке: Installs, upgrade and removes packages using the underlying OS package manager. Ещё меньше строк кода.

update_cache правда придётся выкиуть

https://docs.ansible.com/ansible/latest/modules/package_module.html#package-module

А как Вам идея использовать модуль package вместо веток для apt для yum, dnf... По доке: Installs, upgrade and removes packages using the underlying OS package manager. Ещё меньше строк кода.

Наверное для простых вещей только, опций сильно меньше.

Посоны, подскажите как сохранять двойные кавычки при формировании листа