От настройки серверов к автоматизации инфраструктуры

Урок 20 - финал: собираем целостный прод-проект и смотрим, куда расти дальше.

«Отдельные playbook'и - это инструменты. Хорошо организованный репозиторий - это инфраструктура как код».

Мы прошли путь от первой команды ping до ролей, Vault и тестирования. Финальный шаг - собрать всё в целостный проект, который можно отдать в CI/CD и развивать дальше, вплоть до автоматизации создания самой инфраструктуры.

Структура боевого репозитория

   ansible-project/
   +-- inventories/
   |   +-- production/
   |   |   +-- hosts.yml          <- хосты прода
   |   |   +-- group_vars/        <- переменные окружения
   |   +-- staging/
   |       +-- hosts.yml
   |       +-- group_vars/
   +-- roles/                     <- свои роли
   +-- requirements.yml           <- внешние роли/коллекции (пины)
   +-- site.yml                   <- главный playbook
   +-- ansible.cfg                <- настройки проекта

Ключевая идея: один и тот же код, разные инвентари. Прод и стейдж отличаются только содержимым inventories/ - хостами и переменными окружения. Playbook'и и роли одни и те же. Это и даёт уверенность: что протестировано на staging, поведёт себя так же на проде.

Главный playbook и окружения

# site.yml - оркестрирует роли по группам
- name: Базовая настройка всех серверов
  hosts: all
  become: true
  roles: [common]

- name: Веб-серверы
  hosts: web
  become: true
  roles: [nginx, webapp]

- name: Базы данных
  hosts: db
  become: true
  roles: [postgres]

# Запуск на staging
ansible-playbook -i inventories/staging/hosts.yml site.yml --check --diff
# После проверки - на прод
ansible-playbook -i inventories/production/hosts.yml site.yml --ask-vault-pass

CI/CD

В зрелом процессе playbook'и запускает не человек руками, а пайплайн: на каждый коммит CI прогоняет ansible-lint и --syntax-check, на merge в staging - применяет на стейдж, после ревью - на прод. Так автоматизация серверов сама становится автоматизированной и аудируемой.

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

При запуске Ansible сначала читает ansible.cfg (настройки: путь к инвентарю, поведение SSH, отключение host key checking для CI), затем указанный инвентарь, затем site.yml. Разделение по окружениям через каталоги инвентарей означает, что Ansible подставит правильные group_vars автоматически - тебе не нужно дублировать playbook'и под прод и стейдж.

Смоделируем, как один и тот же playbook исполняется в разных окружениях за счёт разных инвентарей.

# Один playbook, разные инвентари -> разное поведение
playbook = ["common", "nginx", "webapp"]   # одинаков для всех окружений

inventories = {
    "staging":    {"web": ["stg-web1"],            "db_pass": "stg_secret"},
    "production": {"web": ["web1", "web2", "web3"], "db_pass": "PROD_secret"},
}

def run(env):
    inv = inventories[env]
    print(f"== {env} ==")
    print("  хосты web:", inv["web"])
    print("  роли:", playbook)
    print("  секрет из Vault:", inv["db_pass"])

run("staging")
run("production")

Попробуй сам ▶ Роли и playbook идентичны, меняется только инвентарь: число хостов и секреты окружения. Это сердце подхода «инфраструктура как код» - воспроизводимость через единый код и параметризацию окружениями.

Куда расти: автоматизация инфраструктуры

Ansible настраивает существующие серверы. Следующий уровень - автоматизировать и создание самих серверов: Ansible умеет провижинить облачные ресурсы (через коллекции вроде amazon.aws, community.docker) - поднять виртуалки, сети, балансировщики, а затем тут же их настроить. В связке с инструментами IaC (например, Terraform для создания, Ansible для конфигурации) получается полный цикл: от пустого облака до работающего сервиса одним прогоном.

Частые ошибки

• Дублировать playbook'и под прод и стейдж. Разделяй окружения инвентарями, а не копиями кода.
• Запускать прод руками без проверки. Сначала staging и --check --diff, потом прод, в идеале - через CI.
• Хранить секреты прода и стейджа вперемешку. У каждого окружения - свой Vault и свои переменные.

Best practices

• Один код - много окружений: различия только в inventories/.
• Прогоняй ansible-lint и проверки в CI на каждый коммит.
• Двигайся от настройки серверов к провижинингу: Ansible + IaC дают полный цикл инфраструктуры.

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

Зрелый Ansible-проект перестаёт быть набором скриптов и становится частью платформы. Запуск из CI с аудитом (кто, когда, что применил), хранение секретов в Vault или внешнем менеджере, разделение окружений инвентарями, тесты ролей - всё это складывается в надёжный процесс изменения инфраструктуры. Следующий рубеж - связка с инструментами создания ресурсов: Terraform или облачные коллекции поднимают сами серверы, сети и балансировщики, а Ansible тут же их настраивает, и весь путь от пустого облака до работающего сервиса описан кодом в git. Дальше - Ansible Automation Platform с веб-интерфейсом, расписаниями и ролевым доступом, где автоматизацию запускают по кнопке даже те, кто не пишет YAML. Но в основе всего по-прежнему лежат идемпотентные playbook'и, инвентарь и роли, которые ты теперь умеешь писать.

Итоги

Боевой Ansible-проект - это репозиторий, где единый код применяется к разным окружениям через инвентари, проверяется в CI и хранит секреты в Vault. Отсюда открывается дорога к полной автоматизации инфраструктуры: создание ресурсов и их настройка одним кодом. Ты прошёл путь от ручного SSH до инфраструктуры как код - поздравляю!