Зачем нужен Ansible

Урок 1 - первый шаг в мир автоматизации серверов.

«Сервер настраивается один раз руками. Десять серверов настраиваются десять раз руками - и три из них чем-то отличаются, но никто не помнит чем».

Представь, что у тебя есть один сервер. Ты подключаешься по SSH, ставишь nginx, правишь конфиг, запускаешь сервис - готово. Час работы, всё работает. А теперь представь, что серверов стало двадцать. И каждый месяц добавляется пять новых. И на части из них кто-то «по-быстрому» поправил конфиг руками полгода назад. Это называется configuration drift - расхождение конфигураций, и оно убивает прод тише всего: всё работало, а потом один «уникальный» сервер падает в три часа ночи.

Ansible решает именно эту боль. Это инструмент управления конфигурацией (configuration management): ты описываешь желаемое состояние серверов в текстовых файлах, а Ansible приводит реальные машины к этому состоянию. Один и тот же файл, прогнанный по двадцати серверам, делает их одинаковыми. Прогнанный повторно - ничего не ломает.

Декларативно, а не пошагово

Ключевая идея: ты описываешь что должно быть, а не как это сделать по шагам. Не «выполни apt install nginx, потом проверь код возврата, потом если ошибка - сделай то-то». А просто: «пакет nginx должен быть установлен». Ansible сам разберётся, установлен ли он уже, и если да - не будет делать ничего. Это фундаментальное отличие от bash-скриптов.

Ручной подход                  Подход Ansible
--------------                 --------------
ssh server1                    один файл playbook.yml
  apt install nginx              "nginx установлен"
  vim nginx.conf                 "конфиг = вот этот шаблон"
  systemctl start nginx          "сервис запущен"
ssh server2                    ansible-playbook -> все 20 серверов
  ...повтор руками...            одинаково и повторяемо

Как работает под капотом

Ansible написан на Python. На твоей машине (она называется control node - управляющий узел) лежат текстовые файлы с описанием. Когда ты запускаешь команду, Ansible подключается к целевым серверам по обычному SSH, копирует на них маленькие Python-модули, выполняет их, собирает результат и удаляет временные файлы. На целевых серверах не нужно ставить никакого специального софта - только Python, который и так есть почти везде. Подробнее об этом «agentless»-подходе - в следующем уроке.

Каждый шаг описывается как задача (task), задачи собираются в плей (play), плеи - в playbook. А желаемое состояние выражается через модули - готовые кирпичики вроде «управляй пакетом», «управляй файлом», «управляй сервисом».

Частые ошибки новичка

Воспринимать Ansible как «bash по SSH». Технически да, но если ты пишешь playbook из одних команд shell: - ты теряешь главное: идемпотентность и декларативность. Используй модули.
Думать, что Ansible - это только про деплой приложений. Его область шире: настройка ОС, пользователи, фаерволы, пакеты, сервисы, а дальше - целые провижининги инфраструктуры.
Ставить агента. Люди по привычке ищут «как установить ansible-agent на сервер». Его нет. Ansible работает по SSH без агентов - это его преимущество.

Best practices

Храни все Ansible-файлы в git. Они и есть документация твоей инфраструктуры.
Одна задача - одно понятное действие. Читаемость важнее краткости.
Считай, что любой playbook будет запущен повторно. Пиши так, чтобы повтор был безопасен.

В реальной работе

На практике Ansible редко начинают с нуля на пустом сервере. Чаще задача звучит так: «есть двадцать машин, настроенных кое-как за два года разными людьми, приведи их к единому состоянию». Здесь декларативность спасает: ты описываешь эталон один раз, и Ansible подтягивает к нему каждый сервер, не ломая то, что уже верно. Постепенно весь репозиторий с playbook'ами превращается в живую документацию инфраструктуры - открыл файл и видишь, как именно настроен прод, без археологических раскопок по серверам. Команды ценят это особенно при онбординге: новый инженер читает не разрозненные вики-страницы, а исполняемый код, который гарантированно соответствует реальности, потому что именно он её и создаёт.

Итоги

Ansible превращает настройку серверов из ручного ремесла в воспроизводимый код. Ты описываешь желаемое состояние декларативно, а инструмент приводит к нему любое количество машин одинаково и безопасно. Дальше разберём, почему «без агента» - это так важно.