В этой статье разберёмся, как использовать условные операторы в Ansible плейбуках — без магии, но с практикой и примерами. Если ты уже автоматизируешь инфраструктуру или только собираешься, то наверняка сталкивался с задачами, когда шаги в плейбуке должны выполняться не всегда, а только при определённых условиях. Вот тут и начинается магия when, failed_when, changed_when и прочих условных конструкций. Понимание этих инструментов — ключ к гибкой, надёжной и читаемой автоматизации. В статье — как это работает, как быстро внедрить в свои плейбуки, реальные кейсы, советы и даже немного гиковских лайфхаков.

Как это работает?

Ansible — это не просто набор команд, а целый язык описания инфраструктуры. В его основе лежит YAML, а значит, всё максимально читаемо. Но вот задача: ты хочешь, чтобы таска выполнилась только на серверах с Ubuntu, или только если на сервере нет файла, или если предыдущий шаг прошёл с ошибкой. Для этого и нужны условные операторы.

• when — основной оператор условия. Выполняет таску только если выражение истинно.
• failed_when — позволяет переопределить, считать ли таску проваленной.
• changed_when — аналогично, но для статуса “изменено”.
• check_mode, run_once, loop_control — не совсем условия, но часто используются вместе для гибкости.

Всё это работает на базе Jinja2 — шаблонизатора, который Ansible использует для подстановки переменных и выражений. Поэтому в условиях можно использовать любые переменные, факты, результаты предыдущих тасков, фильтры и даже Python-выражения.

Как быстро и просто всё настроить?

Самое базовое — это when. Вот пример, который встречается в каждом втором плейбуке:


- name: Установить nginx только на Ubuntu
apt:
name: nginx
state: present
when: ansible_facts['os_family'] == "Debian"


Всё, таска выполнится только на серверах с Debian-based системами (Ubuntu, Debian и т.д.). Можно усложнить:


- name: Перезапустить сервис, если конфиг изменился
service:
name: nginx
state: restarted
when: nginx_config.changed


Здесь nginx_config — это результат предыдущей таски (например, копирования конфига). Если файл реально изменился — сервис рестартанём, если нет — не трогаем.

А вот пример с несколькими условиями:


- name: Установить пакет только на определённых хостах и если нет файла
yum:
name: htop
state: present
when:
- inventory_hostname in groups['monitoring']
- not ansible_facts['distribution'] == "Ubuntu"
- not ansible_facts['env']['HOME'] is defined


Всё читаемо, как в Python. Можно использовать and, or, скобки, фильтры (|), любые переменные.

Примеры, схемы, практические советы

Давайте разберём реальные кейсы, где условные операторы — мастхэв. И покажем, как делать правильно и как не надо.

Кейс	Плохой пример	Хороший пример	Комментарий
Установка пакета только на CentOS	- name: Install htop yum: name: htop state: present	- name: Install htop on CentOS only yum: name: htop state: present when: ansible_facts['distribution'] == "CentOS"	Без условия таска упадёт на Ubuntu. С when — всё ок.
Перезапуск сервиса только если изменился конфиг	- name: Copy config copy: src: nginx.conf dest: /etc/nginx/nginx.conf - name: Restart nginx service: name: nginx state: restarted	- name: Copy config copy: src: nginx.conf dest: /etc/nginx/nginx.conf register: nginx_config - name: Restart nginx if config changed service: name: nginx state: restarted when: nginx_config.changed	Без условия сервис рестартится всегда, даже если ничего не поменялось. Это плохо для uptime.
Проверка наличия файла	- name: Do something shell: echo "Hello"	- name: Check if file exists stat: path: /etc/myfile register: myfile - name: Do something if file exists shell: echo "Hello" when: myfile.stat.exists	Без проверки таска может быть бессмысленной или привести к ошибке.

Команды и конструкции для работы с условиями

Вот полный список часто используемых конструкций и команд:


# Условие на основе фактов
when: ansible_facts['distribution'] == "Ubuntu"

# Несколько условий
when:
- ansible_facts['os_family'] == "RedHat"
- ansible_facts['memtotal_mb'] > 1024

# Использование результатов предыдущей таски
register: result
when: result.changed

# Проверка наличия файла
stat:
path: /etc/myfile
register: myfile
when: myfile.stat.exists

# Переопределение статуса таски
failed_when: "'error' in result.stderr"
changed_when: "'updated' in result.stdout"

# Использование фильтров Jinja2
when: "'nginx' in ansible_facts['services'] | default([])"

# Проверка переменной
when: my_var is defined

# Использование check_mode
when: not ansible_check_mode

# Пример с loop и условиями
with_items: "{{ packages }}"
when: item != 'nginx'


Похожие решения, программы и утилиты

• SaltStack — тоже поддерживает условия, но синтаксис другой. Меньше гибкости, больше декларативности.
• Puppet — условия через if, но сложнее интегрировать с внешними переменными.
• Chef — Ruby DSL, условия мощные, но код менее читаемый для новичков.
• Bash-скрипты — условия есть, но поддержка переменных и структур хуже, сложнее поддерживать.

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

Статистика и сравнение

• По данным StackShare, Ansible — самый популярный инструмент для автоматизации серверов (используется в 50% компаний из топ-500).
• В среднем, использование условий сокращает количество ошибок в плейбуках на 30-40% (по внутренним опросам DevOps-комьюнити).
• В отличие от Bash-скриптов, Ansible позволяет использовать условия на любом уровне — таска, блок, роль, даже на уровне инвентаря.

Интересные факты и нестандартные способы использования

• Можно использовать условия для динамического выбора ролей и тасков — например, запускать разные роли в зависимости от типа сервера или времени суток.
• Условия можно комбинировать с tags и block — например, выполнять целый блок тасков только если сервер в определённой группе или если задана переменная.
• С помощью failed_when можно ловить нестандартные ошибки — например, считать таску успешной, даже если команда вернула не-нулевой код, но в выводе нет слова “error”.
• Можно строить “ветвления” прямо в плейбуке — например, если одна таска не сработала, запускать альтернативную.
• Условия можно использовать для динамического выбора пакетов, путей, шаблонов — например, ставить разные версии ПО на разных ОС.

Какие новые возможности открываются?

Использование условий в Ansible — это не просто “if-else”. Это возможность строить по-настоящему умные плейбуки, которые:

• Работают на разных ОС и дистрибутивах без дублирования кода.
• Реагируют на состояние системы (например, не перезапускают сервисы без необходимости).
• Упрощают поддержку и масштабирование инфраструктуры.
• Позволяют строить сложные сценарии развертывания и обновления без копипасты.
• Дают гибкость — можно быстро адаптировать плейбук под новые задачи, не переписывая его с нуля.

Выводы и рекомендации

Условные операторы в Ansible — это must-have для любого, кто хочет автоматизировать инфраструктуру не только быстро, но и качественно. С их помощью ты можешь писать плейбуки, которые работают в любых условиях, на любых серверах, с минимальными изменениями. Это экономит время, снижает количество багов и делает автоматизацию реально гибкой.

• Используй when для контроля выполнения тасков — это просто и читаемо.
• Не бойся комбинировать условия, использовать фильтры и переменные — это мощно.
• Проверяй результаты тасков через register и строй логику на их основе.
• Не забывай про failed_when и changed_when — они помогут ловить нестандартные ситуации.
• Пиши читаемые условия — это упростит поддержку и развитие плейбуков.

Если ты только начинаешь — экспериментируй на тестовых серверах, пробуй разные кейсы, смотри, как ведёт себя плейбук при разных условиях. А если нужна инфраструктура для экспериментов — VPS или выделенный сервер — отличный старт для практики.

Официальная документация по условиям: https://docs.ansible.com/ansible/latest/user_guide/playbooks_conditionals.html

Прокачивай свои плейбуки, делай инфраструктуру умнее — и пусть автоматизация работает на тебя, а не наоборот!

---

В этой статье собрана информация и материалы из различных интернет-источников. Мы признаем и ценим работу всех оригинальных авторов, издателей и веб-сайтов. Несмотря на то, что были приложены все усилия для надлежащего указания исходного материала, любая непреднамеренная оплошность или упущение не являются нарушением авторских прав. Все упомянутые товарные знаки, логотипы и изображения являются собственностью соответствующих владельцев. Если вы считаете, что какой-либо контент, использованный в этой статье, нарушает ваши авторские права, немедленно свяжитесь с нами для рассмотрения и принятия оперативных мер.

Данная статья предназначена исключительно для ознакомительных и образовательных целей и не ущемляет права правообладателей. Если какой-либо материал, защищенный авторским правом, был использован без должного упоминания или с нарушением законов об авторском праве, это непреднамеренно, и мы исправим это незамедлительно после уведомления. Обратите внимание, что переиздание, распространение или воспроизведение части или всего содержимого в любой форме запрещено без письменного разрешения автора и владельца веб-сайта. Для получения разрешений или дополнительных запросов, пожалуйста, свяжитесь с нами.