Как организовано хранение ролей в Ansible для нескольких команд

Организация ролей Ansible для нескольких команд

При работе с несколькими командами в Ansible критически важна чёткая структура хранения и разделения ролей, которая обеспечивает безопасность, переиспользование кода и минимизирует конфликты. Вот комплексный подход, который мы использовали в проектах с 5+ командами разработки.

Базовая структура репозитория

Я рекомендую следующий layout для enterprise-проектов:

ansible-repo/
├── requirements.yml           # Зависимости ролей из Galaxy
├── ansible.cfg               # Конфигурация Ansible
├── inventory/                # Инвентарь по командам/окружениям
│   ├── team_a/
│   ├── team_b/
│   └── production/
├── group_vars/              # Переменные по группам
├── host_vars/               # Переменные по хостам
├── playbooks/               # Плейбуки команд
│   ├── team_a/
│   ├── team_b/
│   └── common/
├── roles/                   # Основной каталог ролей
│   ├── requirements.yml     # Локальные требования
│   ├── team_a/             # Роли, специфичные для Team A
│   │   ├── web-app/
│   │   └── db-config/
│   ├── team_b/             # Роли, специфичные для Team B
│   │   ├── api-service/
│   │   └── cache-setup/
│   └── common/             # Общие роли для всех команд
│       ├── nginx/
│       ├── monitoring/
│       └── security/
└── collections/            # Ansible Collections (если используем)

Ключевые стратегии организации

1. Иерархическое разделение ролей

# ansible/roles/requirements.yml
- src: geerlingguy.nginx
  version: 3.1.0
- src: geerlingguy.docker
  version: 3.0.0
- src: https://git.internal.com/team-a/ansible-role-web.git
  scm: git
  version: main
  name: team_a.web

• Common roles - базовые инфраструктурные роли (nginx, docker, ssh-hardening)
• Team-specific roles - роли, содержащие бизнес-логику конкретного приложения
• Shared utility roles - утилитарные роли для логирования, тестирования

2. Система контроля доступа через Git

Используем Git submodules или Git subtrees для разделения ответственности:

# Каждая команда поддерживает свои роли в отдельных репозиториях
git submodule add https://git.company.com/team-a/ansible-roles.git roles/team_a
git submodule add https://git.company.com/team-b/ansible-roles.git roles/team_b

# Обновление всех submodules
git submodule update --init --recursive

3. Versioning и зависимоcти

Для каждой роли создаём meta/main.yml с явными зависимостями:

# roles/common/nginx/meta/main.yml
dependencies:
  - role: common.ssl
    vars:
      ssl_cert_path: "/etc/ssl/certs"
  - role: common.firewall
    when: configure_firewall | default(true)

4. Паттерн "Role Composition"

Вместо монолитных ролей используем композицию:

# playbooks/team_a/deploy-web.yml
- name: Deploy Team A Web Application
  hosts: web_servers
  vars_files:
    - "{{ playbook_dir }}/../vars/team_a/secrets.yml"
  roles:
    - role: common.nginx
      vars:
        nginx_sites:
          app1: "{{ team_a_app_config }}"
    - role: common.monitoring
    - role: team_a.web-app
      tags: team_a

Практические рекомендации

Политики именования

• Префикс роли по команде: team_a_, team_b_
• Семантическое версионирование: web-app-v1.2.0
• Чёткие README.md в каждой роли с примерами использования

Процесс код-ревью

1. Все изменения в common roles требуют approval от инфраструктурной команды
2. Team-specific roles ревьюятся внутри команды
3. Автоматические тесты с molecule для каждой роли

# molecule/default/molecule.yml
dependency:
  name: galaxy
driver:
  name: docker
platforms:
  - name: instance
    image: centos:7
provisioner:
  name: ansible
verifier:
  name: ansible

Управление секретами

• Используем Ansible Vault с разными ключами для команд
• Раздельные vault-файлы: team_a_vault.yml, team_b_vault.yml
• Интеграция с внешними secret managers (HashiCorp Vault, AWS Secrets Manager)

# Шифрование секретов для конкретной команды
ansible-vault encrypt \
  --vault-id team_a@prompt \
  vars/team_a/secrets.yml

Мониторинг и документация

Автоматическая документация

Генерируем документацию с помощью ansible-doc и кастомных скриптов:

#!/usr/bin/env python3
# generate-role-docs.py
import yaml
import os

for root, dirs, files in os.walk('roles'):
    if 'meta/main.yml' in files:
        with open(os.path.join(root, 'meta/main.yml')) as f:
            meta = yaml.safe_load(f)
            print(f"## {meta.get('galaxy_info', {}).get('role_name', root)}")
            print(f"**Команда:** {root.split('/')[1] if len(root.split('/')) > 2 else 'common'}")
            print(f"**Описание:** {meta.get('galaxy_info', {}).get('description', 'Нет описания')}")

Заключение

Опыт показывает, что успешная организация ролей для нескольких команд требует:

1. Баланса между стандартизацией и гибкостью - общие роли обеспечивают консистентность, team-specific роли дают свободу
2. Чётких договорённостей - соглашения по именованию, структуре переменных, версионированию
3. Инвестиций в инструментарий - автоматическая документация, тестирование, CI/CD пайплайны
4. Постоянного рефакторинга - регулярный аудит ролей на предмет дублирования и устаревания

Наиболее эффективной оказалась модель, где инфраструктурная команда поддерживает базовый набор common-ролей, а product-команды развивают свои специализированные роли, но с обязательным соблюдением интерфейсов и стандартов, определённых в common-слое. Это позволяет масштабировать практики Infrastructure as Code на десятки команд без потери управляемости.