Ansible

01Идея: желаемое состояние по SSH

Представьте, что вы пишете чек-лист настройки сервера: установить nginx, скопировать конфиг, открыть порт 443, запустить сервис. Ansible превращает этот чек-лист в код. Control node — ваш ноутбук или CI-раннер с установленным Ansible — подключается к managed nodes по SSH, копирует небольшие Python-модули, запускает их и удаляет. Каждая задача (task) вызывает модуль — apt, copy, template, user или service — и описывает конечное состояние (state: present, state: started), а не команды, которые к нему ведут. Модуль сначала проверяет текущее состояние и меняет только то, что отличается, сообщая ok или changed. Это свойство — идемпотентность — означает, что один и тот же плейбук можно запускать каждый день как проверку дрейфа. Ansible распространяется как ansible-core (движок и встроенные модули) плюс коллекции — пакеты модулей для облаков, баз данных и сетевых устройств, — собранные вместе в пакете ansible community.

• Control node: где работает Ansible. Managed nodes: серверы.
• Модуль: единица работы (apt, template, service).
• Идемпотентность: второй запуск сообщает ok, а не changed.

02Установка, inventory и ad-hoc команды

Устанавливайте Ansible на control node через pipx или pip в отдельное окружение — так не будет конфликтов с системным Python. Inventory перечисляет управляемые хосты и группирует их, в формате INI или YAML. Группы позволяют отдельно нацеливаться на веб-серверы или базы данных, а папки group_vars/ и host_vars/ хранят переменные для групп и хостов. Прежде чем писать плейбуки, проверьте связь ad-hoc командами — разовыми вызовами модулей из командной строки. ansible all -m ping не использует ICMP: он заходит по SSH и проверяет Python. Используйте SSH-ключи и не-root пользователя с sudo; become: true в Ansible повышает привилегии для задач, которым это нужно. Держите ansible.cfg в проекте, чтобы задать путь к inventory и разумные значения по умолчанию.

1# install on the control node
2pipx install --include-deps ansible
3 
4# inventory.yml
5all:
6  children:
7    web:
8      hosts:
9        web1: { ansible_host: 203.0.113.10 }
10        web2: { ansible_host: 203.0.113.11 }
11  vars:
12    ansible_user: your_user
13 
14# test connectivity and gather facts
15ansible -i inventory.yml all -m ping
16ansible -i inventory.yml web -m ansible.builtin.setup -a "filter=ansible_distribution*"

03Ваш первый плейбук

Плейбук — это список play; каждый play нацелен на хосты и выполняет задачи по порядку. Пример устанавливает nginx на группу web, разворачивает конфигурацию сайта из шаблона Jinja2 и убеждается, что сервис запущен. Строка notify запускает handler, только если шаблон действительно изменился, так что nginx перезагружается один раз в конце play, а не при каждом запуске. Всегда используйте полные имена модулей вроде ansible.builtin.apt — так понятно, из какой коллекции модуль. Сначала запустите с --check --diff, чтобы увидеть, что изменится, ничего не меняя, а потом по-настоящему. Второй настоящий запуск должен показать changed=0; если нет — какая-то задача не идемпотентна и её нужно исправить.

1- name: Configure web servers
2  hosts: web
3  become: true
4  tasks:
5    - name: Install nginx
6      ansible.builtin.apt:
7        name: nginx
8        state: present
9        update_cache: true
10    - name: Deploy site config
11      ansible.builtin.template:
12        src: templates/site.conf.j2
13        dest: /etc/nginx/sites-available/default
14        mode: "0644"
15      notify: Reload nginx
16    - name: Ensure nginx is running
17      ansible.builtin.service: { name: nginx, state: started, enabled: true }
18  handlers:
19    - name: Reload nginx
20      ansible.builtin.service: { name: nginx, state: reloaded }

04Переменные, шаблоны и секреты

Переменные позволяют одному плейбуку работать для многих окружений: одна и та же роль настраивает staging и production с разными значениями из group_vars/staging.yml и group_vars/production.yml. Шаблоны используют синтаксис Jinja2 — {{ variable }}, простые циклы и условия, — чтобы рендерить конфигурационные файлы из этих переменных. Facts — это переменные, которые Ansible автоматически собирает с каждого хоста: версия ОС, память, IP-адреса; они полезны для условий вроде when: ansible_distribution == 'Ubuntu'. У приоритета переменных много уровней; не усложняйте: разумные значения — в defaults роли, переопределения для окружений — в group_vars. Для секретов Ansible Vault шифрует файлы или отдельные значения паролем, так что их можно безопасно хранить в Git. В CI передавайте пароль от vault из хранилища секретов CI или получайте секреты во время запуска из менеджера вроде HashiCorp Vault через lookup-плагин.

1# group_vars/production/vars.yml
2app_domain: example.com
3app_workers: 4
4db_password: "{{ vault_db_password }}"
5 
6# group_vars/production/vault.yml (encrypted)
7# ansible-vault create group_vars/production/vault.yml
8# vault_db_password: change-me
9 
10# run with the vault password
11ansible-playbook -i inventory.yml site.yml --ask-vault-pass

05Роли и коллекции: структура, которая масштабируется

Когда плейбуки разрастаются, разбивайте их на роли — стандартную структуру папок с tasks, handlers, templates, files, defaults и meta. Роль хорошо делает одну вещь, например nginx, postgres или базовый hardening, а site-плейбук собирает роли для групп хостов. ansible-galaxy role init создаёт скелет. Коллекции упаковывают роли, модули и плагины вместе под одним namespace; их ставят из Ansible Galaxy или приватного hub через requirements.yml с зафиксированными версиями — так же, как вы фиксируете npm-пакеты. Тестируйте роли через Molecule: он поднимает контейнер или VM, применяет роль, запускает её повторно для проверки идемпотентности и проверяет результат. Линтуйте через ansible-lint в CI, чтобы ловить устаревший синтаксис, отсутствующие имена и рискованные паттерны.

1# requirements.yml
2collections:
3  - name: community.general
4    version: ">=10.0.0,<11.0.0"
5  - name: ansible.posix
6    version: ">=2.0.0"
7 
8# site.yml
9- hosts: web
10  become: true
11  roles:
12    - base_hardening
13    - nginx
14 
15# ansible-galaxy collection install -r requirements.yml

06Как на самом деле выполняется задача

Для каждой задачи Ansible рендерит аргументы модуля через Jinja2 на control node, упаковывает код модуля (AnsiballZ) и отправляет его по SSH, затем запускает удалённым Python и читает обратно JSON. По умолчанию он делает это одновременно для forks хостов (по умолчанию 5) со стратегией linear, при которой каждый хост завершает задачу, прежде чем любой хост начнёт следующую. На масштабе важна настройка производительности: увеличьте forks, включите pipelining в ansible.cfg (он убирает лишние SSH-раунды, но требует, чтобы sudo не требовал TTY), держите включённым мультиплексирование SSH ControlPersist и отключайте или кэшируйте сбор фактов, когда они не нужны. Стратегия free позволяет быстрым хостам уходить вперёд. Долгие задачи можно запускать асинхронно через async и poll, чтобы не держать соединения открытыми.

1# ansible.cfg
2[defaults]
3inventory = inventory.yml
4forks = 25
5gathering = smart
6fact_caching = jsonfile
7fact_caching_connection = .ansible_facts
8fact_caching_timeout = 3600
9 
10[ssh_connection]
11pipelining = True
12ssh_args = -o ControlMaster=auto -o ControlPersist=60s

07Rolling-обновления с serial и health check

Изменения в production никогда не должны попадать на все хосты сразу. serial принимает число, процент или список вроде [1, 5, "25%"], что даёт канареечный хост, затем небольшую пачку, затем большие. delegate_to выполняет задачу на другой машине — обычно чтобы вывести текущий хост из балансировщика. В сочетании с until и retries health check ждёт, пока сервис станет здоровым, прежде чем двигаться дальше. max_fail_percentage прерывает play, когда в пачке падает слишком много хостов, и не даёт плохому релизу распространиться. any_errors_fatal останавливает всё при первом сбое — это полезно для кластеров баз данных, где частичные изменения опасны.

1- hosts: web
2  become: true
3  serial: [1, 5, "25%"]
4  max_fail_percentage: 0
5  tasks:
6    - name: Deploy new release
7      ansible.builtin.include_role: { name: app_release }
8    - name: Wait until healthy
9      ansible.builtin.uri:
10        url: "http://{{ ansible_host }}:8080/healthz"
11        status_code: 200
12      register: health
13      until: health.status == 200
14      retries: 20
15      delay: 3
16      delegate_to: localhost

08Динамический inventory, AWX и Execution Environments

Статические файлы inventory в облаке быстро устаревают. Inventory-плагины вроде amazon.aws.aws_ec2, azure.azcollection.azure_rm или google.cloud.gcp_compute опрашивают провайдера и строят группы по тегам, так что сервер с тегом role=web автоматически попадает в группу web. Чтобы запускать Ansible как общий сервис, а не с ноутбуков, AWX (open-source upstream Red Hat Ansible Automation Platform) даёт веб-интерфейс, ролевой доступ, хранилище credentials, расписания, API и аудит-логи. Execution Environments — это контейнерные образы, в которые упакованы ansible-core, коллекции и Python-зависимости; их собирают через ansible-builder и запускают через ansible-navigator или AWX. Они решают классическую проблему «у меня на control node работает», делая среду выполнения автоматизации такой же воспроизводимой, как образы приложений, которые она деплоит.