В этом уроке разберём, как запустить playbook в Ansible осознанно: сухой прогон, предпросмотр диффов, фильтрация по тегам и хостам, передача переменных и чтение вывода. Это база, которую гоняешь руками каждый день.
Базовый запуск: ansible run playbook и его параметры
Минимальная команда запуска выглядит так:
Код: Выделить всё
ansible-playbook -i inventory site.yml
Полезные ansible playbook параметры, которые стоит держать в голове:
- --check - сухой прогон, ничего не меняет на хостах
- --diff - показать, что именно изменится в файлах и конфигах
- -v / -vv / -vvv / -vvvv - уровень подробности вывода
- --limit - ограничить запуск частью хостов
- --tags / --skip-tags - запустить или пропустить задачи по тегам
- --start-at-task - начать с конкретной задачи
- --step - спрашивать подтверждение перед каждой задачей
- -e (--extra-vars) - передать переменные из командной строки
- --syntax-check - проверить синтаксис без выполнения
Сухой прогон --check и предпросмотр --diff
Главный инструмент уверенности - режим проверки (check mode). Плейбук проходит все задачи, докладывает, что бы он изменил, но реально ничего не трогает:
Код: Выделить всё
ansible-playbook site.yml --check
Код: Выделить всё
ansible-playbook site.yml --check --diff
Код: Выделить всё
- name: Развернуть конфиг nginx
ansible.builtin.template:
src: nginx.conf.j2
dest: /etc/nginx/nginx.conf
owner: root
group: root
mode: "0644"
notify: restart nginx
Важная оговорка: не все модули корректно работают в check mode. Если задача командного типа (ansible.builtin.command, ansible.builtin.shell) что-то проверяет и от её результата зависят следующие задачи, в сухом прогоне она может быть пропущена и плейбук выдаст ложные ошибки. На такой случай у задачи есть параметр check_mode: и поведение можно подкрутить:
Код: Выделить всё
- name: Узнать версию приложения
ansible.builtin.command: /opt/app/bin/version
register: app_version
check_mode: false
changed_when: false
Теги, ограничение хостов и старт с задачи
Теперь про то, как не гонять весь плейбук целиком. Сначала навешиваем теги на задачи или роли:
Код: Выделить всё
- name: Установить пакеты
ansible.builtin.dnf:
name:
- nginx
- firewalld
state: present
tags:
- packages
- name: Открыть порт HTTP
ansible.posix.firewalld:
service: http
permanent: true
state: enabled
immediate: true
tags:
- firewall
Код: Выделить всё
ansible-playbook site.yml --tags firewall
Код: Выделить всё
ansible-playbook site.yml --skip-tags packages
Код: Выделить всё
ansible-playbook site.yml --list-tags
Код: Выделить всё
ansible-playbook site.yml --limit web1.example.com
ansible-playbook site.yml --limit "webservers"
Код: Выделить всё
ansible-playbook site.yml --start-at-task "Открыть порт HTTP"
Связка check mode, тегов и --limit реально экономит время на экзамене EX294. Вместо того чтобы ждать прогон на всех хостах ради одного исправления, ты бьёшь точечно по нужной задаче и нужному узлу.
Передача переменных, проверка синтаксиса и линтер
Переменные с приоритетом выше почти всех остальных передаются через -e (--extra-vars):
Код: Выделить всё
ansible-playbook site.yml -e "app_version=2.4.1 env=staging"
Код: Выделить всё
ansible-playbook site.yml -e @vars/prod.yml
Код: Выделить всё
ansible-playbook site.yml --syntax-check
Код: Выделить всё
ansible-lint site.yml
Чтение вывода и отладка модулем debug
После прогона ansible печатает PLAY RECAP - сводку по каждому хосту:
Код: Выделить всё
PLAY RECAP *********************************************************
web1.example.com : ok=8 changed=3 unreachable=0 failed=0 skipped=2 rescued=0 ignored=0
- ok - задача отработала, состояние в норме (могло уже быть нужным)
- changed - задача внесла изменение (жёлтый цвет в выводе)
- unreachable - до хоста не достучались (SSH, DNS, ключи)
- failed - задача упала с ошибкой (красный)
- skipped - задача пропущена по условию when или тегам
- rescued / ignored - пойманные блоком rescue и проигнорированные ошибки
Когда непонятно, что внутри переменной или факта, выручает модуль ansible.builtin.debug. Печатает значение переменной или сообщение:
Код: Выделить всё
- name: Показать факт об ОС
ansible.builtin.debug:
var: ansible_facts['distribution']
- name: Вывести сообщение
ansible.builtin.debug:
msg: "Раскатываем версию {{ app_version }} на {{ inventory_hostname }}"
Код: Выделить всё
- name: Дамп всех фактов (только при -vv и выше)
ansible.builtin.debug:
var: ansible_facts
verbosity: 2
Типичные грабли
- --check на командных модулях даёт ложные failed - ставь check_mode: false на безопасные read-only команды.
- --start-at-task требует ТОЧНОГО имени задачи, как в name. Опечатка или другой регистр - и Ansible молча ничего не запустит.
- --limit с опечаткой в имени хоста не ошибка, а пустой прогон: 0 хостов. Всегда сверяйся с ansible-inventory --list.
- Забыл навесить тег на роль - и --tags её пропустит, хотя по логике она нужна. Проверяй через --list-tags.
- Переменная из -e перебивает почти всё, включая group_vars и host_vars. Удобно для разовых запусков, опасно если забыл, что её передал.
- changed=N на каждом повторном прогоне - звоночек, что плейбук не идемпотентен. Чаще всего виноваты command/shell без changed_when.
Возьми любой свой плейбук на пару задач (или собери из примеров выше) и прогони по шагам:
- ansible-playbook site.yml --syntax-check - убедись, что синтаксис чистый.
- ansible-playbook site.yml --check --diff - посмотри предпросмотр, ничего не меняя.
- Навесь теги packages и firewall, запусти ansible-playbook site.yml --tags firewall.
- Прогони --skip-tags packages и сравни PLAY RECAP.
- Запусти на одном хосте через --limit, потом с --step, нажимая y/n/c.
- Добавь задачу с ansible.builtin.debug и verbosity: 2, прогони обычно и с -vv - почувствуй разницу.
- Запусти плейбук дважды подряд - на втором разе добейся changed=0.
- Чем отличается --check от --diff и зачем их запускают вместе?
- Как запустить только задачи с тегом firewall и только на хосте web1?
- Что означает changed=5 на повторном запуске того же плейбука и хорошо ли это?
- Как сделать так, чтобы отладочная задача debug печаталась только при -vv, но молчала при обычном запуске?
ansible-playbook - это не "запустил и жди". Сухой прогон --check с --diff даёт уверенность до изменений, теги и --limit бьют точечно, --start-at-task поднимает плейбук с места падения, а debug с verbosity помогает понять, что внутри. Чтение PLAY RECAP и охота за идемпотентностью (changed=0 на повторе) отличают рабочий плейбук от случайно сработавшего. Эти рычаги ты будешь дёргать каждый день - и они же вытащат тебя на экзамене EX294, когда время на счету.
