Как выполнить Ansible playbook?

Давай разберём эту штуку, как будто я тебе на кухне объясняю, пока чайник кипит. Всё просто, как три копейки, главное — не запутаться в этих флагах.

Ну, смотри. Основная команда, с которой ты будешь жить, — это ansible-playbook. Без неё ты нихуя не сделаешь. Это как ключ от квартиры, где деньги лежат.

Самый простой запуск, для самых смелых:

ansible-playbook site.yml

Вот и всё. Он возьмёт твой плейбук site.yml и стандартный файл с хостами (обычно где-то в /etc/ansible/hosts). Если у тебя там всё настроено — поехали. Но так, честно, редко кто работает, потому что inventory по умолчанию — это обычно пиздец и бардак.

А теперь по делу, как это в жизни выглядит:

1. Ты хочешь указать свой файл с хостами, а не тот дефолтный.

   ansible-playbook -i inventory/prod.yml deploy_web.yml

   -i — это, типа, «эй, дружок, смотри сюда, вот список машинок, с которыми работать». Без этого флага — доверия ебать ноль, он может налепить чего угодно.

2. «Я не на все сервера лезть хочу, а только на эти парочку!»

   ansible-playbook -i hosts.ini --limit webservers apache_install.yml
   ansible-playbook -i hosts.ini --limit db01.example.com mysql_config.yml

   --limit — твой лучший друг, когда нужно почесать не всю спину, а только одно место. Указал группу или конкретный хост — и он только туда и полезет. Остальные отдыхают.

3. «А как рутом-то выполнить? Мне же права нужны!»

   ansible-playbook -i hosts.ini --become -K system_update.yml

   --become — это волшебное слово, которое означает «сделай вид, что ты root (или sudo)». А -K — это «и, пожалуйста, спроси у меня пароль, а то я не доверяю». Без -K он попробует без пароля, и если не выйдет — облом.

4. «Бля, я боюсь запускать! А вдруг всё сломаю?» — самый здравый вопрос.

   # Посмотреть, что бы он сделал, но не делать
   ansible-playbook --check --diff configure_firewall.yml
   # Увидеть каждую его потную мысль
   ansible-playbook -vvv deploy.yml

   --check (дри-ран) — святое дело. Он пробежится, всё проверит, скажет, что мог бы изменить, но пальцем не пошевелит. --diff покажет, какие именно строки в файлах поменялись бы. А -vvv — это когда терпения ноль ебать, и ты хочешь видеть каждый чих, каждый запрос, чтобы понять, на каком шаге он обосрался.

5. «Мне нужно передать какие-то параметры, переменные там...»

   ansible-playbook -i staging.yml deploy.yml --extra-vars "version=2.1.4 env=staging"
   ansible-playbook -i prod.yml deploy.yml --extra-vars "@vars/prod_secrets.json"

   --extra-vars — твой карман для срочных записок. Кинул туда version=2.1.4 — и в плейбуке эта переменная появится. Можно прямо строкой, а можно из файла (с собачкой @). Удобно для паролей или номеров версий, которые меняются чаще, чем перчатки.

А вот как это обычно в жизни происходит, по шагам:

1. Пишешь и тестируешь где-то в песочнице, на какой-нибудь загнанной виртуалке (Vagrant — наш бро), или на staging-стенде. Никогда не лезь сразу в прод, это пидарас шерстяной так делает.
2. Запускаешь с --check --diff. Смотришь, что он собирается сделать. Если план выглядит как атака террористов — стоп, переписывай.
3. Если план ок — делаешь реальный запуск. Выдохнул и нажал Enter.
4. Для серьёзного продакшена часто используют AWX или Tower. Это такая красивая веб-морда поверх Ansible. Там можно кнопочки понажимать, логи красивые посмотреть, права раздать. Но под капотом-то всё равно та же самая команда ansible-playbook бегает.

Вот и вся магия. Ничего сверхъестественного, просто нужно понять, за какой рычаг дёрнуть. Главное — сначала проверяй, а потом уже жми на газ.