Что такое Terraform и инфраструктура как код: провайдеры, конфигурации, state, команды init, plan и apply. Когда инструмент полезен и что проверить перед внедрением.
Облачный сервер легко создать вручную. Сложнее через месяц точно повторить те же настройки для тестовой среды, вспомнить причину открытого сетевого порта и согласовать изменения между несколькими инженерами. Чем больше связанных ресурсов, тем заметнее расхождения между окружениями.
Terraform помогает описать инфраструктуру в файлах и применять изменения по проверяемому плану. Разберем, из чего состоит такой подход, какую роль играют провайдер и файл состояния, когда инструмент полезен команде и что нужно подготовить до первого рабочего запуска.
Terraform — инструмент для управления инфраструктурой по модели Infrastructure as Code (IaC), «инфраструктура как код». Инженер описывает желаемые ресурсы в конфигурационных файлах: например, виртуальную машину, сеть и правила доступа. Terraform сопоставляет описание с тем, чем уже управляет, показывает необходимые действия и после подтверждения обращается к API платформы.
Такой подход переносит обсуждение изменений из панели управления в работу с файлами. Конфигурацию можно хранить в системе контроля версий, проверять на ревью и использовать как основу для нескольких окружений. Это повышает повторяемость процесса, но само по себе не делает каждое изменение безопасным: ошибку в параметрах можно точно так же повторить.
Представьте, что приложению нужны подсеть, виртуальная машина и правило доступа для веб-трафика. При ручной настройке инженер последовательно создает эти объекты в панели. При IaC команда описывает их связи и параметры в конфигурации, а изменение проходит обычный для кода маршрут: правка, проверка, согласование и применение. Следующий инженер видит не только готовые объекты, но и намерение команды, зафиксированное в файлах.
Важно различать описание и результат. Файл .tf еще не означает, что виртуальная машина создана. Сначала нужен доступ к платформе и подходящий провайдер, затем — проверка плана и применение. Возможности Terraform для конкретного облака зависят от того, какие ресурсы и операции реализованы в его провайдере. Поэтому при выборе облачной инфраструктуры Nubes поддержку нужных операций нужно проверять отдельно; наличие Terraform само по себе ее не доказывает.
Terraform использует декларативные файлы на языке HCL. В них описывают, какой ресурс нужен, а не последовательность кликов для его создания. Чтобы понять конфигурацию, достаточно сначала разобраться в четырех сущностях: провайдере, ресурсе, модуле и состоянии.
Провайдер — подключаемый компонент, который связывает Terraform с API облачной платформы или другого сервиса. Он определяет доступные типы ресурсов и способы чтения, создания, изменения и удаления объектов. В конфигурации указывают источник провайдера и ограничения по его версии. Для работы также нужны соответствующие права в целевой системе.
Ресурс — управляемый объект, описанный блоком resource: виртуальная машина, подсеть или другой объект, который поддерживает выбранный провайдер. Его аргументы зависят от типа. Terraform строит зависимости между ресурсами по ссылкам в конфигурации: например, машина может использовать идентификатор созданной подсети. Инженеру все равно нужно понимать последствия операции: изменение параметра иногда приводит не к правке объекта на месте, а к его замене.
Рядом с ресурсами могут быть источники данных (data sources). Они читают сведения о существующих объектах, но сами не создают их. Это удобно, когда новой машине нужен идентификатор уже подготовленного образа или сети. Однако внешняя зависимость тоже требует проверки: если исходный объект изменится или исчезнет, очередной план может оказаться неожиданным.
Переменные позволяют передавать значения извне: имя окружения, размер ресурса или сетевой диапазон. Модуль объединяет несколько связанных ресурсов в повторно используемую часть конфигурации. Это помогает описывать похожие окружения без копирования больших фрагментов, но требует ясных входных параметров и контроля версий самого модуля.
Ограничение версии провайдера в required_providers задает допустимый диапазон. Файл .terraform.lock.hcl фиксирует выбранные версии и контрольные суммы провайдеров для повторяемой установки. Эти вещи дополняют друг друга: диапазон определяет правило выбора, lock file сохраняет конкретный выбор команды. Перед обновлением провайдера полезно отдельно просмотреть план изменений.
Terraform хранит state — состояние с привязками записей конфигурации к реальным объектам и данными, нужными для следующих операций. Без этой связи инструмент не сможет надежно определить, каким существующим объектом управляет конкретный блок resource. State не заменяет облачную платформу и не должен редактироваться как обычный текстовый конфиг.
Например, команда описала виртуальную машину в .tf и применила конфигурацию. В state сохраняется ее идентификатор. При следующем запуске Terraform может сопоставить описание, state и сведения от провайдера, чтобы предложить изменение или показать, что оно не требуется.
Если объект создан вручную до появления конфигурации, его нельзя просто записать в .tf и считать управляемым. Для включения существующего ресурса в управление нужна процедура импорта и сверка состояния с описанием. В противном случае план может предложить создать новый объект или конфликтовать с уже работающим. Для команды это аргумент начинать с небольшого, хорошо понятного участка инфраструктуры.
Рабочий цикл обычно выглядит так: подготовить конфигурацию, инициализировать проект, посмотреть план, обсудить его и только затем применить. Разделение проверки и применения особенно важно там, где изменение может остановить сервис или увеличить расходы.
Команда terraform init подготавливает рабочий каталог: настраивает backend, загружает нужные провайдеры и модули. Ее запускают при первом старте проекта и после существенных изменений в его настройках. Успешный init подтверждает подготовку локальной среды, но еще ничего не создает в облаке.
Команда terraform plan сравнивает конфигурацию, state и текущие данные, которые может прочитать провайдер. Результат показывает действия для каждого ресурса: создание, изменение, удаление или замену. Это момент для инженерного ревью: надо проверить не только число операций в итоговой строке, но и затронутые объекты, поля и возможный простой.
План — снимок расчета на определенный момент. Если после его проверки кто-то изменит инфраструктуру вручную или поменяет конфигурацию, вывод уже может не соответствовать новой ситуации. Поэтому нельзя считать однажды просмотренный план безусловной гарантией безопасного применения. Для контролируемого процесса команда может сохранять план в файл и применять именно проверенную версию, учитывая, что и такой план имеет срок актуальности.
Особого внимания заслуживает замена ресурса: план может показать удаление старого объекта и создание нового вместо изменения на месте. Для тестового окружения это может быть приемлемо; для базы данных или критичного сервиса — повод остановиться и проверить сохранность данных, зависимости и допустимое окно работ. Краткое «один ресурс изменится» без чтения деталей здесь недостаточно.
Команда terraform apply выполняет предложенные операции через API провайдера и обновляет state. До подтверждения нужно понимать, у каких объектов возможны замена или удаление и кто отвечает за откат при ошибке. Некоторые изменения обратимы новой конфигурацией, другие требуют отдельного восстановления данных или пересоздания ресурса. Версия файла в Git не является резервной копией базы данных или облачного диска.
Команда terraform destroy удаляет все ресурсы, которыми Terraform управляет в текущем рабочем каталоге и выбранном workspace: перечень объектов она определяет по state. Она полезна, например, для временного учебного окружения, но в рабочей среде требует такого же внимательного просмотра плана и контроля прав, как любое другое удаление.
Представим сервис с несколькими окружениями. Для разработки, тестирования и эксплуатации ему нужны схожие сети, машины и правила доступа, но с разными размерами ресурсов и правами. Если все создавать вручную, окружения постепенно расходятся. Конфигурация Terraform позволяет обсуждать отличия в файлах и повторять проверенный порядок развертывания.
Инструмент особенно полезен, когда ресурсы связаны друг с другом, инфраструктура меняется регулярно, а изменения проходят через ревью. Он помогает команде видеть, какие объекты добавятся или исчезнут, и включать проверку конфигурации в рабочий процесс CI/CD. При этом Terraform не выбирает архитектуру за инженера: состав ресурсов, сетевую схему, права и стоимость по-прежнему нужно проектировать и проверять людям.
Есть и ограничения. Провайдер может поддерживать не все возможности платформы или реализовывать их с задержкой. Для работы нужны права API; слишком широкие права повышают риск ошибки. Если кто-то изменит ресурс вручную, возникает дрейф: реальная среда расходится с описанием, и следующий план нужно разбирать с учетом этой разницы. Наконец, создание ресурсов обычно связано с расходами у облачного провайдера — даже если сама конфигурация короткая.
Для единственной редкой операции Terraform может добавить больше поддержки, чем пользы. А установка пакетов и настройка приложения внутри уже созданной машины часто требуют другого средства автоматизации. Решение стоит принимать по жизненному циклу ресурсов и процессу команды, а не по популярности инструмента.
Отдельный вопрос — смешанная инфраструктура. Один Terraform-проект может описывать объекты разных систем, если для них есть подходящие провайдеры и права. Но единый инструмент не делает эти системы одинаковыми: у каждого API собственные ограничения, способы замены и модель доступа. Перед объединением ресурсов в один процесс полезно понять, где проходит граница ответственности команд и как сбой одной платформы повлияет на применение изменений в другой.
На учебном компьютере состояние может храниться локально. Для командной работы обычно нужен общий backend с контролем доступа и резервированием: иначе у каждого участника появится собственная версия привязок, а параллельные изменения могут конфликтовать. Поддержка блокировки state зависит от выбранного backend, поэтому ее проверяют до совместных запусков.
State способен содержать чувствительные значения, в том числе данные, которые провайдер получил от внешней системы. Пометка sensitive помогает скрывать вывод в части интерфейса Terraform, но сама по себе не делает state безопасным хранилищем секретов. Доступ к нему нужно ограничивать и защищать по правилам выбранного backend. Хранить state в Git вместе с .tf-файлами не следует.
Для команды полезен понятный порядок: изменение конфигурации проходит ревью, план доступен проверяющим, apply выполняется с разрешенными правами, а state хранится в одном согласованном месте. Отдельно стоит определить, кто может исправлять дрейф и что делать после частично успешного применения. Такие процессы пересекаются с задачами DevOps-сервисов Nubes, но возможность конкретной Terraform-интеграции с ресурсами Nubes требует отдельного подтверждения.
Файлы конфигурации и state имеют разный режим работы. Первые удобно версионировать и обсуждать в запросе на изменение. Второй хранит текущие привязки и может меняться при каждом применении, поэтому для него важны контроль доступа, целостность и возможность восстановления. Если запускать apply с личного компьютера без общего процесса, команда быстро теряет уверенность, какая версия плана была одобрена и кто менял ресурсы последним.
Terraform и Ansible часто упоминают рядом, потому что оба помогают автоматизировать инфраструктурные задачи. Их типичный акцент различается: Terraform описывает жизненный цикл ресурсов через провайдеры и state, а Ansible часто используют для настройки систем, установки ПО и развертывания приложений на управляемых узлах. Это не жесткая граница: у Ansible есть модули для облаков, а Terraform может выполнять некоторые действия за пределами создания машин.
| Вопрос | Terraform | Ansible |
| Что обычно описывают | Ресурсы платформы и их связи: сеть, машина, доступные провайдеру сервисы | Задачи на узлах: пакеты, файлы конфигурации, службы и приложения |
| Как проверяют изменение | План операций над ресурсами до apply | Запуск и проверка задач playbook, режим предварительной проверки там, где он поддерживается |
| Что учитывают для совместной работы | Общий state, backend, блокировка и ревью плана | Inventory, роли, доступ к управляемым узлам и повторяемость playbook |
Например, Terraform может подготовить сеть и виртуальные машины, а Ansible — установить и настроить приложение на этих машинах. Реализация зависит от возможностей выбранной облачной платформы, ее провайдера и модулей Ansible. Такое разделение полезно как рабочая схема, а не как правило, запрещающее другим инструментам выполнять похожие операции.
При выборе инструмента полезно сформулировать конкретное изменение. «Создать подсеть и связать с ней новые машины» обычно предполагает работу с объектами облака и проверку плана их жизненного цикла. «Установить одинаковые пакеты на десять существующих машин» относится к настройке узлов. Когда задача охватывает оба шага, инструменты могут последовательно передавать друг другу результат, но эту связь нужно спроектировать и проверить, а не считать автоматической.
До первого рабочего apply команда должна ответить на несколько вопросов:
Terraform дает способ описывать ресурсы и заранее обсуждать изменения, а не заменяет проектирование, ревью и эксплуатационную ответственность. Начать разумно с ограниченного окружения и небольшой группы ресурсов: так легче проверить поддержку провайдера, процесс работы со state и качество плана до переноса подхода на более важные системы.