Pull to refresh

Comments 25

Стоит отметить, что пространство имён обработчиков (handler'ов) общее и не поддаётся шаблонизации. Возможны конфликты имён.

Т. е., если у вас две роли используют notify: restart nginx и имеют - name: restart nginx в своих handlers/*, то выполнятся только действия из одной роли. Порядок, конечно, детерминирован, но от этого не легче.

Об этой «особенности» забывают почти во всех вводных статьях. И в документации, до кучи. Хотя теперь есть упоминание про flush_handlers, который может использоваться, как workaround для обхода вышеописанной проблемы.
Спасибо, я сам на это не натыкался, поэтому и не знал.
> а он стоит по-умолчанию на всех современных linux системах
Чушь не несите. То, что python положили в убунту — не значит, что он стоит по-умолчанию «на всех современных linux-системах».

Debian в минимальной установке, arch, шлакварь — они прекрасно работают без питона.
Стоит сказать, что разработчики ansible предполагали, что python2 может не присутствовать или называться иначе, поэтому есть модуль raw (который выполняет просто команду по ssh) и параметры ansible_python_interpreter.
> и параметры ansible_python_interpreter.
Не поможет, если python-а нет вообще )

> модуль raw
Если его в плейбук вписывать — то будет на каждый запуск говорить «changed» на равку.
Проще, в общем, пойти руками и поставить python, если его там нет.

А вообще я больше про то, что автор не прав насчет того, что пайтон везде есть.
Не поможет, если python-а нет вообще )
А вообще я больше про то, что автор не прав насчет того, что пайтон везде есть.
А с этим я и не спорю. Ибо полностью согласен.

Если его в плейбук вписывать — то будет на каждый запуск говорить «changed» на равку.
Проще, в общем, пойти руками и поставить python, если его там нет.
Он скорее не для playbook'а, а для ansible some-group -m raw -a 'apt-get install -y python'. Хотя можно и при начальном provisioning принести python, если планируется использовать ansible.
> Если его в плейбук вписывать — то будет на каждый запуск говорить «changed» на равку.
Сделать экшн с командой raw, проверяющий/печатающий наличие Python на удалённой стороне. У экшна будут changed_when: False и register: test_python_presence_result.
Сделать второй экшн с командой raw, устанавливающий Python в случае, если test_python_presence_result показывает отсутствие Python.
Так ansible будет ругаться на отсутствие пайтона ещё на этапе GATHERING FACTS, емнип?
В случае, если на этапе бутстрапа вы заранее знаете что питон может отсутствовать, то можно добавить «gather_facts: no» в описание плея

P.S. с помощью raw можно даже сетевыми железками подруливать.
Спасибо, поставил вам плюсик. Формулировка, действительно, спорная.
А Ansible имеет какую-то обертку, которая позволяет пратформонезависимо ставить пакеты, делать настройки и т.п. или для каждой системы нужно писать свой сценарий?
Для каждой свой. Стоит понимать, что на разных дистрибутивах названия пакетов могут запросто отличаться и SCM это за вас не решит, всё равно будет вариативность.
Как уже сказали — не имеет. Но зато, умеет запускать или не запускать какие-то задачи в зависимости от условий в т.ч. в зависимости от платформы и архитектуры. Так что, если нужно поддерживать зоопарк — вы можете это сделать, не придется заводить разные роли для каждого случая.
Можно и в рамках одной роли. Просто использовать что-то типа when: ansible_os_family == "RedHat" and ansible_distribution_major_version == '6'. Тогда несоответствующие будут пропускаться, а подходящие обрабатываться.
Я сейчас столкнулся с странной задачей, которую не могу решить малыми силами.

Дано: 10 объектов (допустим, имён каталогов). В инвентори сколько-то серверов.

Надо раскидать round-robin'ом имена по разным серверам (то есть примерно по 2 шт на сервер).

Все роли выполняются в контексте сервера и сделать что-то вида:

file: path={{item}} mode=directory state=exist
with_next_unused_element: dir_list

как показывает практика, Ansible лучше всего использовать с внешними скриптами. Вот и в данном случае, я бы запускал плейбук не напрямую, а через баш-скрипт, который бы вызывал %YOU_NAME_IT% скрипт перед запуском ансибла, который бы формировал файл внешних переменных. Затем, в роли/таске/где-то-еще я бы подключал этот файл (нужно, чтобы он всегда был — пусть и пустой по дефолту) и делал бы примерно так:
file: path={{file_distribution[inventory_hostname]}} mode=directory state=exist
when: inventory_hostname in file_distribution
Спасибо, интересная мысль, попробую.
Внешние скрипты можно оформить в vars_plugins, примеры:
github.com/ansible/ansible/tree/devel/lib/ansible/inventory/vars_plugins
github.com/ginsys/ansible-plugins/blob/devel/vars_plugins/group_vars_dirs.py (под старую версию ansible, но совместимо)

Только нужно быть внимательным к порядку раскрытия переменных:
1. Сначала запускаются vars_plugins
2. На переменные из 1 накладываются переменные из inventory_dir/{group,host}_vars/
3. Сверху прилетают переменные из playbook_dir/{group,hosts}_vars

Поведение update или merge настраивается в ansible.cfg

Мы используем vars_plugins для разделения переменных пулов следующим образом:
— общие переменные для всех пулов лежат в /common_group_vars/ и читаются плагином
— переменные пулов лежат в /pools/<имя пула>/{group,host}_vars/ (инвенторий, соответственно в /pools/<имя пула>/hosts)
— глобальнные переменные, ссылающиеся на пулоспецифичные можно положить в /group_vars/

P.S. нужно быть осторожным с версией 1.9.x, оно пытается «раскрыть» при использовании lookup-плагина переменные, которые не используются не то что в текущем таске, но и вообще в плейбуке, поэтому если в переменных есть что-то что ссылается на ещё не созданное или просто ненужное именно сейчас, то можно получить остановку выполнения плейбука на ровном месте.
В общем то, да. Но мне комфортнее когда я контролирую то, что происходит. В том плане, что когда скрипт заранее генерирует файлик я всегда могу пойти и посмотреть что он там нагенерировал, могу перезапустить все с теми же параметрами, добавить в гит и т.д.
чем вам не угодили Makefile?
Да, в общем, ни чем. С тем же успехом можно пользоваться. Просто синтаксис баш скрипта мне поприятнее. К тому же, кучку баш скриптов можно назвать соответственно тому, что они делают и легко ориентироваться в них (поверьте, иногда это проблема).
Мейкфалы я использую для проектов, очень удобно зайти в любой проект написанный на любом языке, сделать make build и быть уверенным в том, что все получится.
Я правильно понял, что у них нету бесплатной и не ограниченной по времени лицензии для частного использования?
Для большинства примерений просто ansible (вместе с -play и -galaxy) за глаза и за уши. А он opensource'нутый и во всех дистрибутивах.

Хотя я бы из вредности настаивал на перетаскивании его из main в contrib, ибо предлагают (хотя бы для чего-то) юзать проприетарщину.
Недавно познакомился с ansible — показался очень удобным инструментом, но столкнулся с такой проблемой: https://toster.ru/q/394751. Может кто-то уже выкручивался из такой ситуации?
Sign up to leave a comment.