Что такое Ansible

Проблема: скрипты разъезжаются

Представь: у тебя пять серверов, и ты их настраиваешь руками. На каждом запустил один набор команд, но всегда что-то чуть отличается. Потом нанял коллегу, и он настроил шестой по-своему. Через год никто не помнит, почему на web-3 другая версия nginx.

Bash-скрипт тоже не спасает. Он не знает текущего состояния системы. Запустишь дважды, и он может сломать то, что работало. Каждый сервер обрастает ручными правками, которые нигде не зафиксированы.

Ansible решает это иначе: ты описываешь желаемое состояние системы, а не последовательность команд. Ansible выясняет, что уже так, а что надо привести в порядок.

Agentless push-модель

Главное отличие Ansible — он agentless. На управляемые серверы не надо ставить никакого агента или демона. Ansible просто подключается по SSH и делает своё дело.

Как это выглядит в деталях:

1. Control node читает инвентарь (список хостов).
2. По SSH подключается к каждому managed node.
3. Копирует небольшой Python-модуль во временный каталог.
4. Выполняет его, забирает JSON с результатом.
5. Удаляет временный файл.

Весь жизненный цикл — одно подключение по SSH, ни одного постоянного процесса на целевом сервере.

Это push-модель: инициатива всегда на control node. Ты запускаешь playbook, и control node сам идёт на хосты и применяет изменения. Целевые серверы пассивны: они вообще не знают про Ansible и ничего сами не запрашивают.

Бывает и наоборот: pull-модель. Так по умолчанию работают Puppet и Chef: на каждый хост ставится агент-демон, который периодически сам ходит на центральный master-сервер, забирает свою конфигурацию и применяет её локально. Это требует агента на каждом сервере плюс master с сертификатами - целую инфраструктуру. (SaltStack гибче: умеет и push, и pull.)

На практике pull-системы сейчас встречаются редко. Простота Ansible («есть SSH — уже работает», на хосты ничего не ставить) вытеснила их в большинстве команд. Знать про них полезно для общего кругозора, но дефолт сегодня — push-модель.

Что нужно поставить

На control node:

• Python 3.9+ (Ansible написан на Python; точная минимальная версия зависит от релиза ansible-core, актуальную смотри в матрице поддержки)
• сам Ansible.

Сначала разберись, что именно ставишь. Пакетов два, и называются они похоже.

ansible-core — движок: сам исполнитель, ansible-playbook, ansible-vault и небольшой набор встроенных модулей (ansible.builtin.*). ansible — мета-пакет: тот же core плюс несколько сотен коллекций сообщества (модули для AWS, Docker, PostgreSQL и прочего). Весит он заметно больше. Для учёбы и обычной работы бери мета-пакет ansible, а ansible-core — когда нужен минимум и коллекции ставятся отдельно через ansible-galaxy.

Теперь как ставить. Привычный совет pip install ansible на свежих системах падает:

error: externally-managed-environment

Так ведут себя Debian 12, Ubuntu 23.04 и новее. Причина — PEP 668: системный Python помечен как управляемый пакетным менеджером, и pip отказывается в него писать, чтобы не сломать системные утилиты.

Рабочие варианты:

# pipx — ставит в изолированное окружение, команды видны в PATH
pipx install --include-deps ansible

# или руками через venv
python3 -m venv ~/.venvs/ansible
~/.venvs/ansible/bin/pip install ansible

Либо просто из репозитория дистрибутива, если версия устраивает:

sudo apt install ansible

Пакет дистрибутива обычно отстаёт от свежего релиза на несколько месяцев. Для учебы это нормально, для работы чаще берут pipx: управлять версией проще.

На managed nodes:

• SSH-демон (почти всегда уже есть)
• Python (обычно тоже есть; про запуск без Python — отдельный урок)

Ansible не работает как control node на Windows нативно. На Windows нужен WSL. Но таргетом Windows быть может, чаще всего через WinRM. Управление по SSH тоже работает (экспериментально с 2.8, стабильнее на свежих релизах).

Идемпотентность — тизер

Если Ansible говорит «nginx должен быть установлен и запущен», он сначала проверяет: а вдруг уже установлен и запущен? Если да, ничего не делает. Запускай playbook хоть десять раз, результат тот же.

Это называется идемпотентность. Подробно разберём в уроке 5.

Когда Ansible подходит, а когда нет

Хорошо:

• Конфигурация серверов: пакеты, конфиги, пользователи, сервисы.
• Деплой приложений на парк машин.
• Ad-hoc операции: «выполни uptime на всех staging-серверах».
• Provisioning облачных ресурсов (есть модули для AWS, GCP, Hetzner).

Не его зона:

• Оркестрация контейнеров — это Kubernetes.
• CI/CD-pipeline сам по себе — это GitLab CI, GitHub Actions.
• Управление состоянием в реальном времени (Ansible не демон).

Что важно запомнить

Ansible решает проблему воспроизводимости: описываешь желаемое состояние, а не последовательность команд.

Agentless: на managed nodes ничего не ставится. Только SSH и Python.

Control node нужен Python + ansible. На Windows control node работает только через WSL.

ansible-core — движок, ansible — он же плюс коллекции сообщества. Ставить в системный Python через pip на Debian 12 и Ubuntu 23.04+ не получится (PEP 668): используй pipx, venv или пакет дистрибутива.

Push-модель (Ansible): control node сам идёт на хосты по SSH. Pull-модель (Puppet, Chef по умолчанию) требует агента на каждом хосте и master-сервер, сегодня встречается редко.

В следующем уроке — inventory и ad-hoc команды.