Инфраструктура как код: Terraform и Ansible — что автоматизируют и как учить

Новички часто спрашивают, что выбрать — Terraform или Ansible, как будто это конкуренты. Граница проходит по моменту, когда появляется машина. До этого работает Terraform: он сравнивает описание с тем, что уже есть в облаке, и создаёт, меняет или удаляет ресурсы. После — Ansible: он заходит на готовый сервер и проверяет, стоит ли там нужная версия nginx и совпадает ли конфиг с шаблоном. Каждый умеет немного заходить на чужую территорию, но там заметно слабее, поэтому в проектах их обычно используют вместе.

Что автоматизируют и кому это полезно

Terraform описывает желаемое состояние декларативно: вы пишете, что в облаке должны быть сеть, две машины и группа безопасности, а не последовательность нажатий. Команда terraform plan показывает разницу между описанием и реальностью, terraform apply её устраняет. О созданных ресурсах Terraform помнит через файл состояния (state): в нём записано, какой объект в облаке соответствует какому блоку кода.

Ansible работает без агента на серверах: ему нужен доступ по SSH и Python на управляемой машине. Список серверов хранится в inventory, а действия — в плейбуках на YAML, составленных из модулей: «установить пакет», «скопировать шаблон», «перезапустить сервис». Хорошо написанный плейбук идемпотентен: повторный запуск ничего не меняет там, где всё уже в нужном виде.

Администратору Ansible полезен даже без облака: двадцать серверов в стойке с одинаковыми пользователями и ключами — его прямая задача. Разработчику чаще нужен Terraform, когда окружение поднимают под ветку и сносят после проверки. Один сервер, который настраивают раз в год, проще сделать руками. Подход окупается, когда появляется второе одинаковое окружение или второй человек, которому нужно понимать первое.

Учебный пример: тестовый стенд, который поднимается за минуты

Условная ситуация. Команда поддерживает веб-приложение на Python с базой PostgreSQL. Тестовый стенд в Yandex Cloud год назад собрали вручную через консоль, и никто не помнит, какие порты открыты. Нужно описать стенд кодом, чтобы для каждой крупной ветки поднимать отдельную копию.

Шаги идут от ресурсов к настройке, а заканчиваются проверкой повторного запуска: Ansible некуда подключаться, пока Terraform не создал машину, а без повторного прогона нельзя убедиться, что описание полное.

1. В Terraform описывают сеть, подсеть, группу безопасности (порт 22 только с адреса офиса, 443 для всех) и виртуальную машину. Имя окружения задаётся переменной, чтобы копии не конфликтовали.
2. Запускают terraform plan и читают вывод: «+» означает создание, «~» — изменение на месте, «-/+» — удаление и создание заново. Последний знак у рабочей базы данных — повод остановиться и разобраться.
3. После apply Terraform выдаёт IP-адрес машины через output, а из него собирается inventory для Ansible.
4. Плейбук Ansible разбит на роли: базовая настройка (пользователи, ключи, обновления), PostgreSQL, приложение с юнитом systemd и конфигом из шаблона Jinja2, nginx.
5. Плейбук запускают второй раз. В итоговой сводке должно быть changed=0 — значит, описание идемпотентно.
6. После проверки ветки стенд удаляют командой terraform destroy.

В результате копия стенда поднимается без участия человека, а любое отличие между копиями видно в истории Git.

Куда на самом деле попадают пароли

В примере есть ловушка. Пароль к базе передают в Terraform через переменную db_password и помечают её sensitive = true, после чего кажется, что секрет спрятан. В документации HashiCorp о чувствительных данных сказано иначе: эта пометка только скрывает значение в выводе командной строки и в интерфейсе HCP Terraform, а само значение записывается и в файл состояния, и в файл плана. Локальное состояние — обычный текстовый файл, где секрет лежит в открытом виде. Команда terraform output с ключами -json или -raw тоже покажет его без маскировки.

Отсюда два правила. Файл terraform.tfstate не добавляют в Git, даже в закрытый репозиторий, а хранят в удалённом бэкенде с шифрованием и ограниченным доступом, например в Object Storage. Доступ к такому хранилищу равен доступу ко всем паролям, которые через него прошли.

С версии 1.10 в Terraform появились эфемерные значения: переменные и выходы дочерних модулей с ephemeral = true не сохраняются ни в состоянии, ни в плане. В версии 1.11 добавились write-only аргументы ресурсов, например passwordwo у awsdbinstance: значение уходит провайдеру и не записывается. Раз Terraform его не хранит, он не видит, что пароль изменился, поэтому рядом есть парный аргумент версии, passwordwo_version, — для смены пароля его увеличивают на единицу. Поддержка таких аргументов зависит от провайдера, её проверяют в описании конкретного ресурса.

С чего начать и в каком порядке осваивать

Порядок строится так, чтобы каждый шаг опирался на предыдущий, а ошибки на первых этапах ничего не стоили. Ansible учат на локальных виртуальных машинах, без облачных счетов; Terraform без облака почти бесполезен, и к нему переходят, уверенно освоив сервер и Git.

1. Linux на уровне администратора: пакеты, systemd, права, журналы, SSH-ключи.
2. Git: ветки, запросы на слияние, .gitignore.
3. Ansible на двух локальных машинах: inventory, первый плейбук, модули вместо shell-команд, шаблоны, затем роли и переменные.
4. Terraform в облаке: провайдер, ресурсы, переменные, outputs, чтение plan.
5. Связка: Terraform создаёт машины, Ansible их настраивает.
6. Удалённое состояние, модули Terraform и запуск plan в CI при каждом запросе на слияние.

Для Yandex Cloud учтите деталь установки: в пошаговом руководстве Yandex Cloud провайдеры ставят через зеркало terraform-mirror.yandexcloud.net, прописав блок provider_installation в файле .terraformrc (для Terraform 0.13 и новее).

Упражнения и типичные ошибки

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

Второе упражнение — для Terraform: создайте машину, поменяйте у неё в консоли облака метку и запустите plan. Terraform предложит вернуть описанное в коде, и станет ясно, почему после перехода на код ручные правки запрещают.

Типичные ошибки новичков повторяются. Пишут задачи через shell вместо модулей, и плейбук отчитывается об изменениях при каждом запуске. Держат состояние на ноутбуке одного человека, и коллега, запустивший apply со своей копией, создаёт дубли ресурсов. Ведут одно состояние на тестовое и рабочее окружения, и ошибка в тесте задевает рабочие ресурсы. Нажимают apply, не читая plan.

Если хочется освоить Ansible отдельно и с проверкой работ, посмотрите онлайн-курс Skillbox «Ansible для DevOps-инженера». По описанию на курсе 24 часа практики и 7 заданий в тренажёре и на стендах Yandex Cloud с письменной обратной связью наставника: inventory, плейбуки, идемпотентность, роли и шаблоны. Программа рассчитана на системных администраторов и начинающих DevOps-инженеров; срок обучения на странице указан по-разному, его стоит уточнить у школы.

С какими профессиями связан навык

Для DevOps-инженера и инженера облачных систем Terraform и Ansible — ежедневный набор, этим профессиям посвящены отдельные статьи на нашем сайте. Системному администратору навык помогает перейти от ручного обслуживания к описаниям, которые проходят ревью. Бэкенд-разработчику достаточно читать и править готовые модули, чтобы самому поднимать стенд.

Как навык влияет на доход

Отдельной статистики зарплат «за Terraform» или «за Ansible» в открытых источниках нет: это требования вакансий, а не должности. Ближе всего к теме данные по администрированию. В исследовании Хабр Карьеры за первое полугодие 2026 года медиана в этой специализации составила 229 тысяч рублей в Москве, 200 тысяч в Санкт-Петербурге и 150 тысяч в других регионах. Это фактические зарплаты из анонимного калькулятора (45 226 анкет по всему IT), а не предложения в вакансиях; разбивки по уровням и инструментам нет.

Влияние навыка видно по задачам, которые вы можете взять на себя: администратор, описывающий серверы кодом, может претендовать на вакансии DevOps и облачных инженеров. Отфильтруйте вакансии своего региона по названию инструмента и посмотрите, где он обязателен, а где желателен.

Как выбрать обучение

Главное в программе — облачный стенд, где вы сами создаёте и удаляете ресурсы, и проверка кода, а не тесты на знание команд. Уточните, кто оплачивает облако, разбирают ли удалённое состояние и секреты, есть ли проект со связкой Terraform и Ansible.

Короткий вариант, где инфраструктуре как коду отведён отдельный блок, — онлайн-курс Merion Academy «DevOps-инженер с нуля». Он рассчитан на четыре месяца по 2–5 часов в неделю: видеоуроки, лабораторные после каждого блока, тесты. Из восьми блоков один посвящён Infrastructure as Code, Terraform и Ansible названы среди технологий, но темы по ним и проверку работ преподавателем на странице не описывают — это стоит уточнить у школы.

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

Тем, кто меняет профессию, подойдёт, например, онлайн-курс Eduson Academy «DevOps-инженер + ИИ». Он рассчитан примерно на 7 месяцев, совмещает записи уроков с занятиями в Zoom и включает блоки об управлении конфигурацией и облаках GCP и AWS. В дипломной работе нужно автоматизировать инфраструктуру развёртывания учебного репозитория, настроить CI/CD и мониторинг. Terraform и Ansible на странице прямо не названы, поэтому инструменты и формат проверки уточните у школы.

До оплаты любой программы попробуйте первое упражнение из этой статьи: если плейбук с шаблоном и повторный запуск с changed=0 показались понятными, обучение ляжет на готовую основу.

Сравнить школы по формату, цене и отзывам поможет рейтинг онлайн-школ по DevOps и инфраструктуре. Это широкий рейтинг всего направления, а не только инфраструктуры как кода.