Ответ
Список ролей в плейбуке Ansible — это директория roles: в секции плейбука, где перечисляются роли для применения к целевым хостам. Роль — это автономная, структурированная единица организации задач, переменных, файлов, шаблонов и обработчиков.
Пример использования в плейбуке (playbook.yml):
- name: Configure web and database servers
hosts: all
become: yes
roles:
- common # Базовая настройка (часовой пояс, пользователи)
- nginx # Установка и настройка веб-сервера
- { role: postgresql, tags: database } # Роль с параметрами и тегом
- role: app_deploy
vars:
app_version: "2.1.0"Ключевые особенности списка ролей:
- Порядок выполнения: Роли выполняются в порядке, указанном в списке, до любых задач, определённых непосредственно в плейбуке.
- Параметризация: Можно передавать переменные роли напрямую в списке, используя синтаксис словаря.
- Условное выполнение и теги: Ролям можно назначать теги (
tags) или условия (when), что позволяет выполнять их выборочно. - Повторное использование: Основная сила ролей — возможность их повторного использования в разных плейбуках и проектах.
Структура роли (например, roles/nginx/):
roles/nginx/
├── tasks/ # Основные задачи (main.yml)
├── handlers/ # Обработчики (например, перезагрузка nginx)
├── templates/ # Шаблоны Jinja2 (nginx.conf.j2)
├── files/ # Статические файлы для копирования
├── vars/ # Переменные роли с высоким приоритетом
├── defaults/ # Переменные по умолчанию (низкий приоритет)
└── meta/ # Зависимости от других ролейПочему это важно: Использование ролей превращает набор скриптов в управляемую, модульную и легко тестируемую инфраструктуру как код (IaC). Это стандартный подход в Ansible для организации сложных конфигураций.
Ответ 18+ 🔞
А, ну слушай, про роли в Anсибле! Это же, блядь, основа основ, ебать мои старые костыли. Если ты до сих пор пишешь плейбуки одной простыней в тысячу строк — ты, прости, распиздяй и смерд пердящий. Роли — это как раз то, что превращает твой бардак в нормальную, модульную хуйню, которую можно переиспользовать.
Вот смотри, в плейбуке есть такая секция roles:. Это как список гостей на твою вечеринку по настройке серверов. Ты просто перечисляешь, кто должен прийти и в каком порядке.
Вот как это выглядит в деле (playbook.yml):
- name: Настраиваем веб и базу
hosts: all
become: yes
roles:
- common # Сначала база — часовой пояс, пользователи, всякая обязательная фигня
- nginx # Потом веб-сервер ставим
- { role: postgresql, tags: database } # А вот это уже роль с параметром, чтоб только по тегу запускать
- role: app_deploy
vars:
app_version: "2.1.0" # И сюда переменные свои пихаемЧто тут важно понять, ёпта:
- Порядок — всё: Они отработают ровно в том порядке, в котором ты их написал. И что самое главное — до всех задач, которые ты напишешь прямо в плейбуке. Не перепутай.
- Можно навешивать хуйню: Теги (
tags), условия (when) — всё как у людей. Хочешь запустить только базу?ansible-playbook site.yml --tags databaseи похуй на всё остальное. - Сила в переиспользовании: Вот это, блядь, главный кайф. Написал роль для установки
nginxодин раз — и таскай её из проекта в проект, как шлюху дешёвую. Никакого копипаста, один хер.
А внутри-то какая структура, спросишь? Да вот, смотри, обычная роль nginx выглядит как папка:
roles/nginx/
├── tasks/ # Главный файл с задачами (main.yml) — тут вся основная работа
├── handlers/ # Обработчики (например, команда на перезагрузку nginx после изменения конфига)
├── templates/ # Шаблоны Jinja2 (например, nginx.conf.j2) — чтоб конфиги были гибкие
├── files/ # Просто статические файлы, которые надо скопировать как есть
├── vars/ # Переменные для роли — приоритет высокий, перебивают defaults
├── defaults/ # Переменные по умолчанию (низкий приоритет) — если ничего не передали, будут они
└── meta/ # Зависимости — тут пишешь, какие другие роли нужно выполнить ДО этойИтог, чувак: Если не используешь роли, то ты просто ебанько, который усложняет себе жизнь. Это стандарт де-факто для организации всего этого пизда рулю под названием IaC (Infrastructure as Code). Всё становится чисто, понятно и, главное, не вызывает волнение ебать при попытке что-то изменить через полгода.