Как организовать работу с ролями Ansible для нескольких продуктов?

В проектах с несколькими продуктами я организую структуру Ansible ролей так, чтобы обеспечить переиспользование кода, изоляцию конфигураций и простоту управления. Вот как я это делаю:

Структура каталогов:

inventory/
├── production/
│   ├── hosts
│   └── group_vars/
├── staging/
│   ├── hosts
│   └── group_vars/

roles/
├── common/           # Общие роли для всех продуктов
│   ├── tasks/
│   ├── defaults/
│   └── templates/
├── product-a/        # Роли специфичные для продукта A
│   ├── tasks/
│   ├── vars/
│   └── meta/
└── product-b/        # Роли специфичные для продукта B
    ├── tasks/
    ├── vars/
    └── meta/

group_vars/
├── all/              # Глобальные переменные
├── product_a/        # Переменные для продукта A
└── product_b/        # Переменные для продукта B

site.yml              # Основной playbook
product-a.yml         # Playbook для продукта A
product-b.yml         # Playbook для продукта B

Ключевые практики:

1. Использование зависимостей ролей В roles/product-a/meta/main.yml:

   dependencies:
   - role: common
   vars:
     timezone: Europe/Moscow
   - role: nginx
   when: product_a_requires_nginx

2. Изоляция переменных по продуктам В group_vars/product_a/db.yml:

   database:
   name: product_a_db
   user: product_a_user
   password: "{{ vault_product_a_db_password }}"

3. Использование тегов для выборочного выполнения

   - name: Deploy Product A
   hosts: product_a_servers
   roles:
   - { role: product-a, tags: ['product-a', 'deploy'] }
   - { role: monitoring, tags: ['monitoring', 'product-a'] }

4. Динамические инвентори Для облачных сред использую динамические инвентори (AWS EC2, Azure RM) с тегированием инстансов по продуктам:

   # inventory/aws_ec2.yml
   plugin: aws_ec2
   filters:
   tag:Product: product-a
   instance-state-name: running

5. Использование Ansible Collections Для переиспользуемых компонентов создаю collections:

   # galaxy.yml
   namespace: company
   name: infrastructure
   version: 1.0.0

Такой подход позволяет командам работать независимо, переиспользовать общие компоненты и легко масштабировать инфраструктуру.