Как организовать процесс автоматизации с использованием атомарных ролей в Ansible?

Мы строим инфраструктуру как код на Ansible, используя атомарные (одноцелевые) роли. Это позволяет создавать переиспользуемые, тестируемые и комбинируемые компоненты.

Структура и принцип: Каждая роль отвечает за одну логическую задачу: установка пакета, настройка сервиса, управление конфигурацией.

ansible/roles/
├── common/               # Базовая настройка (users, ssh, updates)
├── nginx/                # Установка и настройка веб-сервера
│   ├── tasks/main.yml
│   ├── handlers/main.yml
│   ├── templates/nginx.conf.j2
│   └── defaults/main.yml
├── node-exporter/        # Установка Prometheus-экспортера
└── postgresql/           # Установка и настройка СУБД

Пример атомарной роли nginx (tasks/main.yml):

- name: Install nginx
  apt:
    name: nginx
    state: latest
  notify: restart nginx

- name: Deploy nginx configuration
  template:
    src: nginx.conf.j2
    dest: /etc/nginx/nginx.conf
  notify: reload nginx

Использование в плейбуке: Плейбук становится декларативным списком требуемых ролей.

- name: Configure web server
  hosts: webservers
  become: yes
  roles:
    - role: common
    - role: nginx
      vars:
        nginx_worker_processes: 4
    - role: node-exporter

Преимущества такого подхода:

• Переиспользование: Роль postgresql может использоваться в плейбуках для бэкенда, аналитики и тестовых стендов с разными переменными.
• Тестируемость: Каждую роль можно независимо тестировать с помощью molecule, создавая для нее изолированные сценарии (converge, verify).
• Совместная разработка: Роли хранятся в отдельных репозиториях или коллекциях (Ansible Galaxy), версионируются и могут разрабатываться разными командами.
• Ясность: Плейбук четко показывает, что должно быть на сервере, а детали как это сделать скрыты внутри роли.