Ответ
Запуск зависит от контекста: локальная разработка, CI/CD или управляемая платформа.
1. Локальная разработка и ад-hoc задачи:
Использую ansible-playbook напрямую, часто с --check (dry-run) и --diff для предварительной проверки.
# Базовый запуск
ansible-playbook -i inventories/prod/hosts.yml site.yml
# Запуск с тегом и лимитом на группу хостов
ansible-playbook -i inventories/staging/hosts.yml deploy_app.yml --tags "web" --limit "staging_webservers"
# Проверка изменений без применения (обязательно перед продакшеном)
ansible-playbook -i inventories/prod/hosts.yml site.yml --check --diff
2. В CI/CD пайплайне (GitLab CI):
stages:
- deploy
deploy_to_staging:
stage: deploy
script:
- ansible-playbook -i inventories/staging/hosts.yml deploy.yml --vault-id staging@prompt
only:
- main
Здесь --vault-id используется для расшифровки секретов из Ansible Vault.
3. Через систему управления (AWX/Ansible Automation Platform):
- Создаю Job Template, который связывает плейбук, инвентори, credentials и лимиты.
- Запускаю вручную через веб-интерфейс или автоматически по расписанию (Schedule).
- AWX также предоставляет REST API для интеграции с внешними системами.
4. Для регулярных задач (обновление, бэкапы):
Использую systemd таймер или cron.
# Пример cron задачи для ежедневного бэкапа конфигов
0 2 * * * /usr/bin/ansible-playbook -i /etc/ansible/hosts /opt/ansible/backup_configs.yml
Ключевой принцип: для продакшена всегда предварительный запуск с --check, использование Vault для секретов и четкое версионирование плейбуков и инвентори в Git.