Какие Ansible playbook реализовывали

Реализованные Ansible Playbook: От базового управления до сложных оркестрационных сцен

За годы работы с Ansible я проектировал и реализовывал широкий спектр playbook, ролей (roles) и коллекций (collections), которые можно разделить на несколько ключевых категорий. Каждый playbook создавался с учетом идемпотентности, читаемости и возможности повторного использования.

1. Базовое управление инфраструктурой и обеспечение консистентности

Эти playbook формируют фундамент, обеспечивая единообразие базовой конфигурации на всех серверах.

• Базовое обеспечение (Bootstrap & Hardening): Серия playbook для первоначальной настройки новых виртуальных машин или физических серверов после их предоставления. Они выполняли:

    *   Настройку **SSH-доступа** (отключение root-логина, настройка ключей, изменение порта).
    *   Конфигурацию **firewall** (iptables или firewalld) и **SELinux**.
    *   Установку и настройку базового мониторинга (**collectd**, **Prometheus node_exporter**).
    *   Настройку централизованного сбора логов (**rsyslog** или **Fluentd** для отправки в ELK/Graylog).
    *   Применение политик безопасности (CIS Benchmarks) с помощью специализированных ролей, таких как `dev-sec.os-hardening`.

```yaml
# Пример фрагмента playbook для базовой настройки пользователя и sudo
- name: Ensure admin user exists with sudo privileges
  hosts: all
  tasks:
    - name: Create admin user
      ansible.builtin.user:
        name: "{{ admin_user }}"
        groups: sudo
        append: yes
        shell: /bin/bash
        generate_ssh_key: yes
        ssh_key_bits: 2048
      become: yes

    - name: Deploy authorized key for admin user
      ansible.builtin.authorized_key:
        user: "{{ admin_user }}"
        state: present
        key: "{{ lookup('file', '~/.ssh/id_rsa.pub') }}"
      become: yes
```

• Управление пакетами и обновлениями: Playbook для цикла обновлений безопасности.

    *   Регулярное обновление всех пакетов на тестовых стендах.
    *   Выборочное обновление только security-пакетов на production-окружении с предварительным созданием снапшотов ВМ и уведомлением в Slack.
    *   Установка специфичных наборов пакетов для разных типов серверов (например, `python3`, `git`, `curl` для всех, `gcc`, `make` только для dev-среды).

2. Развертывание и конфигурация сервисов (Service Deployment)

Здесь playbook становятся более специализированными, ориентируясь на конкретные приложения и middleware.

• Веб-серверы и балансировщики: Развертывание и тонкая настройка Nginx и Apache.

    *   Playbook для установки Nginx с модулями (headers-more, brotli), настройки TLS/SSL с помощью Let's Encrypt (через **certbot**), оптимизации параметров (worker_processes, keepalive_timeout) в зависимости от ресурсов хоста.
    *   Динамическая генерация конфигов виртуальных хостов из шаблонов Jinja2, с использованием переменных из групповых (`group_vars`) или хостовых (`host_vars`) файлов.

```jinja
{# Пример фрагмента шаблона Jinja2 для Nginx #}
server {
    listen 443 ssl http2;
    server_name {{ server_name }};

    ssl_certificate {{ ssl_cert_path }};
    ssl_certificate_key {{ ssl_key_path }};

    location / {
        proxy_pass http://{{ app_backend }};
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    access_log /var/log/nginx/{{ server_name }}-access.log json;
}
```

• Сервисы приложений и очереди: Развертывание стеков для поддержки приложений.

    *   Установка и кластеризация **Redis** (sentinel mode).
    *   Развертывание **RabbitMQ** с управлением vhost, пользователями и правами.
    *   Настройка **Node.js** или **Python** окружений с помощью менеджеров версий (nvm, pyenv).
    *   Полноценные playbook для развертывания **Docker** и **Docker Compose**, включая настройку демона, логирования (journald/JSON-file) и сетевых драйверов.

3. Оркестрация сложных развертываний и zero-downtime обновлений

Самые интересные и комплексные playbook, которые напрямую влияли на доступность сервиса.

• Blue-Green / Canary развертывания веб-приложений: Мы реализовывали стратегию, где Ansible управлял переключением трафика на уровне балансировщика (часто HAProxy или Nginx).

    1.  Playbook разворачивал новую версию приложения на отдельной группе хостов ("green").
    2.  Запускались интеграционные тесты.
    3.  Другой playbook постепенно (для Canary) или полностью (для Blue-Green) менял конфигурацию upstream в балансировщике, перенаправляя трафик на новую версию.
    4.  В случае обнаружения проблем (через мониторинг или health-checks) playbook выполнял откат конфигурации.

• Высокодоступный кластер базы данных (например, PostgreSQL): Создание отказоустойчивого кластера с репликацией и автоматическим/ручным переключением при сбое. Playbook решал задачи:

    *   Установка PostgreSQL на несколько нод.
    *   Настройка master-реплики (streaming replication).
    *   Конфигурация **pgBouncer** для пулинга соединений.
    *   Настройка **Patroni** или собственных скриптов на **bash/python** для управления failover, интегрированных с **etcd** или **Consul** для распределенного хранения состояния лидера. Ansible в этом случае использовался как инструмент первоначального развертывания и последующего безопасного переключения ролей вручную по команде.

4. Управление облачными ресурсами (Cloud Provisioning & Lifecycle)

Здесь Ansible выступал в роли инструмента Infrastructure as Code (IaC), часто в паре с Terraform.

• Создание и настройка виртуальных машин: Использование модулей amazon.aws, google.cloud или azure.azcollection для:

    *   Создания ВМ с определенными характеристиками (CPU, RAM, диск).
    *   Назначения тегов и меток для биллинга и управления.
    *   Добавления машин в динамические инвентари Ansible для последующей конфигурации.

• Управление сетевыми компонентами: Автоматизация создания Security Groups (AWS), firewall rules (GCP), load balancers и DNS-записей (Route53, CloudDNS).

  # Пример фрагмента playbook для создания Security Group в AWS
  - name: Provision AWS Security Group for Web Servers
    hosts: localhost
    connection: local
    collections:
      - amazon.aws
    tasks:
      - name: Create web security group
        amazon.aws.ec2_security_group:
          name: "web-sg-prod"
          description: "Allow HTTP/HTTPS from anywhere"
          vpc_id: "vpc-12345"
          rules:
            - proto: tcp
              from_port: 80
              to_port: 80
              cidr_ip: 0.0.0.0/0
            - proto: tcp
              from_port: 443
              to_port: 443
              cidr_ip: 0.0.0.0/0
          state: present
        register: sg_result
  

5. Роли для повторного использования (Reusable Roles)

Ключевым принципом было избегать монолитных playbook. Частая логика выносилась в роли:

• common: Базовая настройка (NTP, мониторинг, пользователи).
• ssl: Генерация и обновление TLS-сертификатов.
• deploy: Общий процесс выкатки артефакта (остановка сервиса, копирование файлов, миграции БД, запуск).
• backup: Настройка периодического резервного копирования (через borgbackup, pg_dump) и выгрузки в облачное хранилище.

Итог: Моя работа с Ansible всегда была направлена на создание самодокументируемой, надежной и эффективной автоматизации, которая не просто выполняет разовые задачи, но и кодирует лучшие практики и знания команды, снижая операционные риски и ускоряя циклы разработки. Playbook проектировались как код — с версионным контролем, ревью и тестированием (с помощью Molecule и TestInfra).