Ответ
В Ansible есть несколько практических способов ограничить выполнение задач конкретным набором хостов.
1. Флаг --limit при запуске плейбука
Самый частый способ — указать шаблон или группу при запуске.
# Выполнить только на хостах из группы 'webservers'
ansible-playbook deploy.yml --limit webservers
# Выполнить на хосте с конкретным именем
ansible-playbook deploy.yml --limit web01.prod
# Использовать шаблоны (например, все хосты в .prod домене)
ansible-playbook deploy.yml --limit '*.prod'
# Комбинировать несколько групп через двоеточие
ansible-playbook deploy.yml --limit 'webservers:databases'2. Динамическое определение хостов в самом плейбуке Можно параметризовать целевые хосты, используя переменные.
# playbook.yml
- hosts: "{{ target | default('all') }}"
tasks:
- debug:
msg: "Running on {{ inventory_hostname }}"Запуск: ansible-playbook playbook.yml -e "target=webservers"
3. Использование тегов (tags) для фильтрации задач
Теги позволяют запускать не весь плейбук, а только помеченные задачи, но они всё равно выполнятся на всех хостах, указанных в hosts:.
- hosts: all
tasks:
- name: Install Nginx
apt:
name: nginx
tags:
- nginx
- install
- name: Configure firewall
ufw:
rule: allow
port: '80'
tags: firewallЗапуск только задач с тегом nginx: ansible-playbook playbook.yml --tags nginx.
4. Предварительный фильтр с помощью --list-hosts
Перед запуском полезно проверить, на каких хостах будет выполняться плейбук с учётом лимита:
ansible-playbook playbook.yml --limit webservers --list-hosts
Ответ 18+ 🔞
Да ты посмотри, какая тут простая, блядь, магия! В Ansible-то, оказывается, не надо на каждый хост руками лезть — есть же нормальные способы отфильтровать, где что запускать. Сейчас разложу, как говорится, по полочкам, а то некоторые до сих пор думают, что надо вручную по списку бегать.
1. Флаг --limit — наш главный друг и помощник
Это, блядь, самый частый и удобный способ, ёпта. Запускаешь плейбук и сразу говоришь ему: «Слушай, дружок, не распыляйся, работай вот тут и только тут». Как будто начальник даёт задание не всему отделу, а конкретному Петровичу.
# Гони задачи только на тех, кто в группе 'webservers' сидит
ansible-playbook deploy.yml --limit webservers
# Или вот конкретно на web01.prod — пусть знает, что его выделили
ansible-playbook deploy.yml --limit web01.prod
# А можно и по маске всех накрыть, типа все в домене .prod
ansible-playbook deploy.yml --limit '*.prod'
# Ну или скормить ему сразу несколько групп через двоеточие — пусть сам разбирается
ansible-playbook deploy.yml --limit 'webservers:databases'Проще некуда, правда? Волнение ебать от такой простоты пропадает.
2. Динамика в самом плейбуке — для гибких и хитрых А если хочешь, чтобы сам плейбук был универсальным, как швейцарский нож? Тогда параметризуй целевые хосты через переменные. Это как сказать: «Я пока не знаю, на ком запускать, решим в момент старта».
# playbook.yml
- hosts: "{{ target | default('all') }}"
tasks:
- debug:
msg: "Running on {{ inventory_hostname }}"А запускаешь потом так: ansible-playbook playbook.yml -e "target=webservers". Подозрение ебать чувствую, что этот способ любят те, кто вечно меняет планы на ходу.
3. Теги (tags) — чтобы не делать лишнего
Теги — это такая хитрая жопа. Они не ограничивают хосты, они фильтруют задачи. То есть плейбук побежит по всем указанным в hosts: серверам, но выполнит только то, что помечено нужным тегом. Удобно, когда надо, например, только софт поставить, а конфиги не трогать.
- hosts: all
tasks:
- name: Install Nginx
apt:
name: nginx
tags:
- nginx
- install
- name: Configure firewall
ufw:
rule: allow
port: '80'
tags: firewallЗапустишь с --tags nginx — и он на всех хостах только Nginx поставит, а до фаервола даже не дотронется. Экономия времени — овердохуища!
4. Предварительная разведка --list-hosts
А это, блядь, для параноиков и осторожных. Прежде чем нажать на красную кнопку и запустить всё нафиг, можно проверить, а на кого именно оно, собственно, пойдёт. Удивление пиздец иногда бывает, когда думаешь, что лимит на одну группу, а Ansible тебе вываливает список на полэкрана.
ansible-playbook playbook.yml --limit webservers --list-hosts
Вот так, коротко и без воды. Главное — понимать, что для чего. А то бывает, чувак тегами хочет хосты ограничить, а потом охуевает, почему задача на всех выполнилась. Э, бошка, думай!