Услуги по автоматизации и управлению конфигурацией

Автоматизация инфраструктуры: Ansible, AWX, Rundeck, SaltStack

Задача звучит просто: обновить конфигурацию nginx на 200 серверах. Руками — это два дня и неизбежно несколько расхождений между серверами. Наша команда за 15 минут пишет Ansible playbook, прогоняет его и получает идентичную конфигурацию на каждом сервере с фиксацией изменений в git. Автоматизация не просто ускоряет — она убирает класс проблем, возникающий от ручного управления.

Мы автоматизируем инфраструктуру с 2019 года — более 5 лет, выполнили свыше 50 проектов: от стартапов с 10 серверами до enterprise-кластеров на 2000 машин. Стек — Ansible, AWX, Rundeck, SaltStack. Подход всегда один: идемпотентность, версионирование, RBAC, документация. Результат — время простоя сокращается на 80%, а количество инцидентов из-за человеческого фактора падает втрое.

Почему идемпотентность — главное требование production?

Начинающие пишут Ansible как bash-скрипты с command и shell везде. Production-grade Ansible — это идемпотентные задачи с правильными модулями, управлением переменными и разделением ролей. Идемпотентность гарантирует, что при повторном запуске playbook не внесёт лишних изменений. Без неё каждое выполнение рискует сломать конфигурацию, а откат становится лотереей.

Структура role вместо плоского playbook

roles/ nginx/ tasks/ main.yml install.yml configure.yml handlers/ main.yml templates/ nginx.conf.j2 vhost.conf.j2 defaults/ main.yml vars/ main.yml files/ ssl/ 

defaults/main.yml — переменные с низким приоритетом, которые легко переопределить. vars/main.yml — переменные с высоким приоритетом, редко переопределяемые. Это важно: Ansible имеет 22 уровня приоритета переменных, и путаница между ними — источник труднодиагностируемых багов.

Идемпотентность — основное требование

Модуль template изменяет файл только если он изменился — это корректно. command: sed -i 's/old/new/' /etc/app.conf — не идемпотентно, выполнится каждый раз. Правильно: модуль lineinfile или replace.

Handlers и notify

Nginx не нужно перезапускать, если конфиг не изменился:

# tasks/configure.yml - name: Deploy nginx config template: src: nginx.conf.j2 dest: /etc/nginx/nginx.conf owner: root mode: '0644' validate: 'nginx -t -c %s' notify: Reload nginx # handlers/main.yml - name: Reload nginx systemd: name: nginx state: reloaded 

validate с nginx -t проверит конфиг перед копированием. Если валидация упала — задача не выполнится, сервер не получит сломанный конфиг. Handler сработает один раз в конце play, даже если несколько задач его нотифицировали.

Секреты через Ansible Vault

ansible-vault encrypt_string 'секретный_пароль' --name db_password создаёт зашифрованную строку, которую можно хранить прямо в vars/main.yml. Vault password file через --vault-password-file или переменную окружения ANSIBLE_VAULT_PASSWORD_FILE — для CI/CD без интерактивного ввода.

Динамический inventory

Для AWS — aws_ec2 плагин:

# inventory/aws_ec2.yml plugin: amazon.aws.aws_ec2 regions: - eu-central-1 filters: tag:Environment: production instance-state-name: running keyed_groups: - key: tags.Role prefix: role - key: placement.availability_zone hostnames: - private-ip-address 

ansible-inventory -i inventory/aws_ec2.yml --graph покажет автоматически сгенерированную структуру групп по тегам EC2. Больше не нужно вручную обновлять hosts-файл при изменении инфраструктуры.

Как AWX масштабирует Ansible на команду?

Запускать ansible-playbook с ноутбука — нормально для одного инженера. Когда playbooks запускают 10 человек, нужна централизация: кто, что, когда запускал, с каким результатом. AWX (open‑source версия Ansible Tower) решает именно это.

Что даёт централизация Ansible через AWX?

Job Templates — это playbook + inventory + credentials + extra vars. Создаётся один раз, запускается сколько угодно раз с одинаковыми параметрами или с override через Survey.

Survey — форма с параметрами, которую заполняет оператор перед запуском. Например: выбор окружения (staging/production), версия приложения для деплоя, флаг run_migrations. Это позволяет отдать запуск плейбука команде без доступа к коду.

Credentials в AWX хранятся зашифрованными и никогда не передаются пользователю — только используются при запуске. SSH-ключ, AWS credentials, Vault password — всё это хранится в AWX и не копируется на рабочие станции.

- name: Create Job Template awx.awx.job_template: name: "Deploy Application" job_type: run inventory: "Production Inventory" project: "Infrastructure" playbook: deploy.yml credentials: - "SSH Production" - "Vault Password" survey_enabled: yes survey_spec: name: "Deploy Survey" description: "" spec: - question_name: "Application version" variable: app_version type: text required: yes - question_name: "Run database migrations" variable: run_migrations type: multiplechoice choices: "yes\nno" default: "no" state: present