Послуги з автоматизації та управління конфігурацією

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

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

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

Як автоматизація інфраструктури змінює повсякденну роботу DevOps?

Замість щоденних ручних правок — одноразове написання playbook, який потім виконується сотні разів без помилок. Замість перевірок "чи все працює після змін" — вбудована валідація через validate та автоматичні тести. Замість пошуку, хто і коли змінив конфіг, — повне версіонування в git. Інфраструктура стає відтворюваною: будь-який інженер за хвилину піднімає ідентичне середовище з нуля.

Чому ідемпотентність — головна вимога 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 рівні пріоритету змінних, і плутанина між ними — джерело важко діагностованих багів.

Ідемпотентні модулі: що обрати замість shell?

Модуль template змінює файл тільки якщо він змінився — це коректно. command: sed -i 's/old/new/' /etc/app.conf — не ідемпотентно, виконається кожного разу. Правильно: модуль lineinfile або replace. Для складних конфігів — template з Jinja2.

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. Ansible 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 зберігаються зашифрованими і ніколи не передаються користувачеві — тільки використовуються при запуску.

Приклад: AWX as code через Ansible Collection awx.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 

Вся конфігурація AWX зберігається в git і застосовується через той же Ansible — infrastructure as code рекурсивно.

RBAC в AWX

RBAC реалізовано через принцип мінімальних привілеїв: Organizations → Teams → Users. Команда розробників бачить тільки Job Templates для деплою свого додатка і не може змінювати Credentials. DevOps бачать всі Job Templates, можуть змінювати Inventories. Тільки адміністратори AWX керують Credentials і системними налаштуваннями.

Workflow Job Templates — ланцюжки Job Templates з розгалуженням за результатом: run tests → (success) → deploy to staging → (success) → run smoke tests → (success) → wait for approval → deploy to production. Нода approval блокує workflow до ручного підтвердження — зручно для production deploys.

Rundeck: операційні завдання без програмування

Rundeck займає іншу нішу — не конфігураційний менеджмент, а операційні завдання. Перезапустити сервіс, очистити кеш, створити backup, запустити SQL-скрипт. Цільова аудиторія — не тільки DevOps, але й DBA, розробники, підтримка. Job Options з валідацією (regexp) запобігають випадковим помилкам у параметрах. Інтеграція з ServiceNow, PagerDuty, Jira дозволяє запускати Job автоматично по webhook при створенні тікета певного типу. Типова схема: алерт в PagerDuty → webhook в Rundeck → автоматичний runbook (перезапуск сервісу, звільнення диска).

SaltStack: коли потрібна швидкість реакції

Salt працює в push-режимі (як Ansible) і в pull-режимі через постійне ZeroMQ-з'єднання між майстром і міньйонами. Це дає затримку 1–3 секунди замість кількох секунд на встановлення SSH-з'єднання. salt '*' cmd.run 'systemctl status nginx' виконається на всіх міньйонах одночасно і поверне результати за 1–3 секунди. На 500 серверах це критично для аварійних сценаріїв, де Ansible програв би у швидкості через SSH-з'єднання.

Порівняння інструментів автоматизації

Що входить в роботу з автоматизації

Ми надаємо повний цикл — від аудиту до супроводу. Ось як будується проєкт:

1. Аудит поточної інфраструктури — інвентаризація серверів, ПЗ, залежностей, ручних процесів.
2. Проєктування архітектури автоматизації — вибір інструменту, структура roles, CI/CD‑пайплайн.
3. Написання playbooks / jobs — ідемпотентно, з Vault, динамічним inventory, тестами.
4. Налаштування централізованого управління — AWX / Tower, Rundeck, RBAC, webhooks.
5. Документація — runbook, опис workflows, інструкції для операторів.
6. Навчання команди — воркшоп з Ansible / AWX / Rundeck (2–3 дні).
7. Post‑production підтримка — 1 місяць супроводу, виправлення інцидентів, доопрацювання.

Всі артефакти передаємо в git‑репозиторій. Після завершення проєкту ви отримуєте повністю відтворювану інфраструктуру як код.

Терміни типових завдань

Вартість розраховується індивідуально після аналізу поточної інфраструктури та завдань автоматизації. Гарантуємо фіксовану ціну та терміни — без прихованих доопрацювань. Середня економія клієнтів після впровадження становить від 500 000 до 2 000 000 гривень на рік за рахунок скорочення простоїв та зниження кількості інцидентів.

Чому обирають нас

• Понад 5 років автоматизації інфраструктури, 50+ завершених проєктів.
• Сертифіковані спеціалісти Red Hat Ansible Automation (RHCE).
• 98% проєктів здані в строк, середній MTTR знижений на 70%.
• Працюємо з AWS, GCP, Azure, Yandex Cloud, Selectel.
• Використовуємо Ansible (Wikipedia) та AWX (Wikipedia) — open‑source інструменти без vendor‑lock.

Отримайте консультацію інженера — ми проаналізуємо поточну інфраструктуру та підготуємо план автоматизації за один робочий день. Замовте аудит автоматизації та оцініть економію для вашого проєкту. Свяжіться з нами, щоб обговорити деталі.