Terraform — это инструмент Infrastructure as Code, или IaC, который позволяет описывать инфраструктуру в конфигурационных файлах и автоматически создавать, изменять или удалять необходимые ресурсы. С его помощью можно управлять виртуальными машинами, сетями, балансировщиками, хранилищами, DNS, базами данных и другими инфраструктурными объектами.
Terraform использует декларативный подход. Инженер описывает не последовательность ручных действий, а желаемое конечное состояние. Например, в конфигурации можно указать, что должны существовать три виртуальные машины, сеть и балансировщик. Terraform сравнит это описание с текущей инфраструктурой и определит, какие изменения необходимо выполнить.
Инструмент широко применяется в DevOps, SRE, облачной инфраструктуре, CI/CD и автоматизации дата-центров. Особенно полезен Terraform там, где инфраструктура регулярно изменяется или должна воспроизводиться в нескольких окружениях.
Что такое Terraform простыми словами
Представим, что администратору нужно создать пять виртуальных серверов. При обычном подходе он открывает панель облачного провайдера, несколько раз заполняет формы, выбирает процессор, память, диски и сеть.
Если через месяц такую же инфраструктуру потребуется создать еще раз, все действия придется повторять вручную.
Terraform позволяет один раз описать инфраструктуру в файле. После этого инструмент автоматически обращается к API облака или другого сервиса и создает необходимые ресурсы.
Terraform превращает инфраструктуру из набора ручных действий в декларативное описание, которое можно хранить, проверять и использовать повторно.
Для чего нужен Terraform
Terraform используется прежде всего для автоматизации управления инфраструктурными ресурсами.
- создание виртуальных машин;
- настройка виртуальных сетей;
- создание подсетей и маршрутов;
- управление балансировщиками нагрузки;
- создание хранилищ;
- управление DNS;
- создание управляемых баз данных;
- развертывание Kubernetes-кластеров;
- управление правами и ролями;
- создание одинаковых test и production-окружений;
- автоматизация инфраструктуры через CI/CD.
Как работает Terraform
Инженер создает конфигурационные файлы, в которых описывает требуемые ресурсы. Terraform читает эти файлы, определяет провайдеров и сравнивает желаемое состояние с фактическим.
Типовой рабочий процесс выглядит следующим образом.
- Описать инфраструктуру.
- Инициализировать рабочую директорию.
- Проверить план изменений.
- Применить изменения.
- Сохранить конфигурацию в Git.
- При необходимости изменить описание и повторить процесс.
Если ресурс уже существует и соответствует конфигурации, Terraform обычно не создает его повторно. Если параметры изменились, инструмент рассчитывает необходимые действия.
Что такое HCL
Конфигурации Terraform обычно описываются с помощью HCL, или HashiCorp Configuration Language. Это декларативный язык конфигурации, ориентированный на описание инфраструктурных ресурсов.
В конфигурации указываются тип ресурса, его имя и параметры.
resource "example_server" "web" {
name = "web-server"
cpu = 2
ram = 4096
}Конкретные типы ресурсов и параметры зависят от используемого provider.
Что такое Resource
Resource — инфраструктурный объект, которым управляет Terraform.
Это может быть виртуальная машина, сеть, диск, DNS-запись, балансировщик или другой объект.
В конфигурации каждый ресурс имеет тип и локальное имя. Например, один блок описывает сервер, другой — сеть, а третий — хранилище.
Terraform использует эти описания для определения желаемого состояния инфраструктуры.
Что такое Provider
Provider — компонент, который позволяет Terraform взаимодействовать с конкретной платформой или сервисом.
Terraform сам по себе не знает, как создать виртуальную машину у конкретного облачного провайдера. Эту логику реализует provider.
Provider обращается к API соответствующей платформы и предоставляет Terraform набор доступных ресурсов и источников данных.
| Компонент | Назначение |
|---|---|
| Terraform | Определяет желаемое состояние и план изменений |
| Provider | Взаимодействует с API конкретной платформы |
| Resource | Описывает создаваемый или управляемый объект |
| State | Связывает конфигурацию с реальной инфраструктурой |
Что такое terraform init
Команда инициализации подготавливает рабочую директорию Terraform.
На этом этапе загружаются необходимые providers и настраивается backend для хранения состояния, если он используется.
Обычно init выполняется после создания нового проекта или изменения состава providers и backend.
Что такое terraform plan
Plan показывает, какие изменения Terraform собирается выполнить.
Например, он может сообщить, что будет создано две виртуальные машины, изменено одно правило сети и удален старый диск.
Просмотр плана — один из важнейших этапов безопасной работы. Он позволяет обнаружить неожиданное удаление или замену критичного ресурса до применения.
Перед изменением production-инфраструктуры план необходимо рассматривать как обязательный этап проверки, а не как формальность.
Что такое terraform apply
Apply применяет рассчитанные изменения к реальной инфраструктуре.
Terraform обращается к API providers и создает, изменяет или удаляет ресурсы.
В production-среде apply желательно выполнять через контролируемый процесс: после Code Review, автоматических проверок и подтверждения плана.
Запуск с персонального ноутбука без журналирования и контроля повышает риск случайных изменений.
Что такое terraform destroy
Destroy используется для удаления инфраструктуры, которой управляет текущая конфигурация Terraform.
Команда полезна для временных test-окружений, которые после завершения работы необходимо полностью удалить.
Для production ее применение требует особой осторожности, поскольку удаление инфраструктурных ресурсов может привести к длительному простою или потере данных.
Что такое Terraform State
State — данные о соответствии ресурсов из конфигурации реальным объектам инфраструктуры.
Например, в коде ресурс называется web-server, а в облаке ему соответствует определенный уникальный идентификатор. Terraform сохраняет эту связь в state.
Состояние помогает инструменту понимать, какие ресурсы уже созданы и что изменилось с момента предыдущего запуска.
Почему State важен
Без корректного состояния Terraform сложнее определить, каким реальным объектом он управляет.
State нельзя воспринимать как обычный временный файл, который всегда можно безопасно удалить. Повреждение или потеря состояния может значительно усложнить последующие изменения инфраструктуры.
В командной работе его обычно хранят в централизованном backend, а не на компьютере одного инженера.
Почему State нужно защищать
State может содержать технические параметры инфраструктуры и потенциально чувствительные значения.
Поэтому доступ к нему должен быть ограничен. Также важно исключить одновременное неконтролируемое изменение одного состояния несколькими инженерами.
Для этого применяют централизованное хранение и механизмы блокировки.
Что такое Backend
Backend определяет, где Terraform хранит состояние и как с ним работает.
Для личного тестового проекта state может храниться локально. Для командной эксплуатации более удобен удаленный backend.
Он позволяет нескольким инженерам работать с одной инфраструктурой и уменьшает риск использования устаревших локальных файлов.
State Locking
State Locking предотвращает ситуацию, когда два процесса одновременно пытаются изменять одну инфраструктуру.
Например, один инженер создает сервер, а второй в это же время меняет сеть. Без блокировки оба процесса могут получить разные представления о текущем состоянии.
Механизм блокировки делает операции последовательными и уменьшает риск повреждения state.
Что такое Variable
Variables позволяют передавать параметры в конфигурацию Terraform.
Например, количество серверов, размер виртуальной машины или название окружения можно не фиксировать непосредственно в ресурсе, а передавать через переменные.
Это делает конфигурацию переиспользуемой.
Один и тот же код можно применить для development и production, используя разные значения.
Что такое Output
Outputs позволяют получить важные значения после создания инфраструктуры.
Например, Terraform может вывести внешний IP-адрес созданного балансировщика или имя базы данных.
Outputs также могут использоваться другими конфигурациями и автоматизированными процессами.
Что такое Data Source
Data Source используется для получения информации о существующем объекте, которым Terraform не обязательно управляет напрямую.
Например, инфраструктурный код может найти уже существующую сеть или образ виртуальной машины и использовать его параметры при создании новых ресурсов.
Это удобно, когда часть инфраструктуры создается Terraform, а часть уже существует.
Что такое Module
Module — переиспользуемый набор Terraform-конфигураций.
Например, компания может создать стандартный модуль веб-приложения, который включает сеть, виртуальные машины, балансировщик и базовые правила безопасности.
Другие проекты используют этот модуль, передавая только необходимые параметры.
Модули уменьшают дублирование и помогают стандартизировать инфраструктуру.
Зачем нужны модули
Без модулей команды часто копируют одинаковый код между проектами. Со временем версии начинают различаться, а исправления приходится вручную переносить в десятки конфигураций.
Модуль создает единый переиспользуемый компонент.
- меньше копирования кода;
- единые стандарты;
- проще обновлять типовые схемы;
- быстрее запускать новые проекты;
- удобнее проводить Code Review.
Terraform и Infrastructure as Code
Infrastructure as Code — общий подход, а Terraform — конкретный инструмент его реализации.
IaC описывает принцип управления инфраструктурой через код. Terraform предоставляет язык, workflow и providers для практического применения этого принципа.
Поэтому Terraform и IaC нельзя считать полными синонимами.
Terraform и декларативный подход
Terraform ориентирован на описание желаемого состояния.
Инженер указывает, что должно существовать, а инструмент самостоятельно строит зависимость операций.
Например, если сервер должен находиться в новой сети, Terraform сначала создаст сеть, а затем ресурс, который зависит от нее.
Это упрощает работу по сравнению с ручным описанием каждой API-операции.
Что такое Dependency Graph
Terraform анализирует связи между ресурсами и строит граф зависимостей.
Если один ресурс использует результат другого, инструмент понимает порядок создания.
Независимые ресурсы при возможности могут обрабатываться параллельно.
Корректные зависимости особенно важны в больших конфигурациях с сетями, серверами и балансировщиками.
Terraform и Git
Terraform-конфигурации обычно хранятся в Git.
Это дает инфраструктуре историю изменений. Можно увидеть, кто изменил размер сервера, когда было добавлено сетевое правило и почему появился новый ресурс.
Изменения проходят Code Review так же, как программный код.
При этом state обычно не следует хранить в обычном Git-репозитории вместе с конфигурацией.
Terraform и CI/CD
Terraform хорошо интегрируется с CI/CD-процессами.
Например, после Pull Request pipeline проверяет формат файлов, валидирует конфигурацию и формирует план.
После согласования изменения отдельный этап применяет план к нужному окружению.
Такой процесс делает изменения инфраструктуры контролируемыми и оставляет историю действий.
Terraform и DevOps
Terraform является одним из распространенных инструментов DevOps-автоматизации.
Он позволяет разработчикам и инфраструктурным инженерам использовать единый воспроизводимый процесс создания окружений.
Например, вместо заявки администратору на ручное создание тестового сервера команда запускает заранее подготовленный модуль Terraform.
Terraform и SRE
SRE стремится снижать объем ручной эксплуатационной работы. Terraform помогает автоматизировать создание инфраструктуры и уменьшать toil.
При аварии SRE-команде проще создать новый набор ресурсов по проверенной конфигурации, чем восстанавливать параметры вручную.
Также инфраструктурные изменения становятся проверяемыми и воспроизводимыми.
Terraform и облачная инфраструктура
Облачные платформы являются одним из основных сценариев применения Terraform, потому что большинство облачных ресурсов управляется через API.
С помощью конфигурации можно создавать виртуальные сети, вычислительные ресурсы, диски, балансировщики и управляемые сервисы.
Особенно полезен Terraform для компаний, которые регулярно создают новые окружения или работают сразу с несколькими проектами.
Terraform и Multi-cloud
Terraform способен работать с различными providers в рамках единого подхода.
Это позволяет одной команде использовать похожий workflow для разных облачных и инфраструктурных платформ.
Однако наличие Terraform не делает разные облака полностью одинаковыми. У каждого поставщика есть собственные типы ресурсов, сетевые модели и сервисы.
Поэтому multi-cloud конфигурация все равно требует понимания особенностей каждой платформы.
Terraform и Kubernetes
Terraform можно использовать для создания инфраструктуры Kubernetes: сети, виртуальных машин, управляемого кластера и связанных облачных компонентов.
Он также может управлять некоторыми объектами внутри Kubernetes через соответствующие providers.
При этом для постоянного управления большим количеством Kubernetes-манифестов часто используются специализированные инструменты.
Практическая граница определяется архитектурой и процессами конкретной команды.
Terraform и Ansible
Terraform и Ansible часто применяются совместно.
Terraform обычно отвечает за создание инфраструктурных ресурсов, а Ansible — за настройку операционной системы и программного обеспечения внутри серверов.
| Terraform | Ansible |
|---|---|
| Создает виртуальные машины | Настраивает операционные системы |
| Создает сети | Устанавливает пакеты |
| Создает балансировщики | Изменяет конфигурационные файлы |
| Управляет облачными ресурсами | Автоматизирует настройку серверов |
Граница не абсолютна, поскольку возможности инструментов частично пересекаются.
Terraform и Docker
Terraform и Docker работают на разных уровнях.
Docker используется для упаковки и запуска приложений в контейнерах. Terraform может создавать серверы, сети и кластеры, на которых эти контейнеры будут работать.
Например, Terraform создает облачную инфраструктуру, а система контейнеризации размещает на ней приложение.
Terraform и Configuration Drift
Configuration Drift возникает, когда реальная инфраструктура начинает отличаться от описанной конфигурации.
Например, инженер вручную меняет размер виртуальной машины через панель управления, но не изменяет Terraform-код.
При следующем plan инструмент обнаружит различие и может предложить вернуть ресурс к описанному состоянию.
Поэтому при использовании Terraform ручные изменения желательно минимизировать.
Импорт существующей инфраструктуры
Terraform может использоваться не только для новых проектов. Существующие ресурсы можно связывать с Terraform State и постепенно переводить под управление IaC.
Однако сам факт импорта не всегда автоматически создает полноценное и удобное описание всей существующей инфраструктуры.
Перед миграцией необходимо разобраться в текущих ресурсах, зависимостях и рисках.
Изменение ресурсов
Не каждое изменение инфраструктуры выполняется одинаково.
Некоторые параметры можно изменить без удаления ресурса, а другие требуют его замены.
Например, Terraform Plan может показать, что изменение определенного параметра приведет к удалению старого объекта и созданию нового.
Поэтому plan необходимо внимательно проверять перед каждым критичным apply.
Lifecycle
Terraform предоставляет механизмы управления жизненным циклом ресурсов.
Например, иногда важно сначала создать новый объект и только после этого удалить старый, чтобы уменьшить простой.
В других случаях нужно предотвратить случайное удаление особо критичного ресурса.
Такие настройки необходимо использовать осознанно, поскольку они влияют на стандартную логику управления.
Секреты в Terraform
Пароли, API-ключи и токены не следует напрямую записывать в конфигурацию и сохранять в Git.
Даже после удаления значение может остаться в истории репозитория.
Также чувствительная информация потенциально может оказаться в state, поэтому защита состояния имеет особое значение.
Для секретов используют специализированные хранилища и защищенные механизмы передачи значений в pipeline.
Terraform автоматизирует инфраструктуру, но не должен превращать конфигурацию и State в открытое хранилище секретов.
Terraform и безопасность
Автоматизация позволяет стандартизировать защитные настройки. Например, через общий модуль можно создавать ресурсы только с заданными сетевыми правилами и шифрованием.
Но ошибка в конфигурации также масштабируется автоматически.
Если модуль содержит слишком широкое правило сетевого доступа, оно может быть применено сразу к десяткам систем.
Поэтому Terraform-код необходимо проверять через Code Review и автоматические политики.
Policy as Code
Policy as Code позволяет автоматически проверять инфраструктуру на соответствие правилам компании.
Например, можно запрещать создание публичных баз данных или ресурсов без обязательных тегов.
Если Terraform Plan нарушает политику, CI/CD-процесс блокирует применение.
Такой подход особенно полезен в крупных организациях с большим количеством инфраструктурных команд.
Terraform и Disaster Recovery
Terraform значительно упрощает воссоздание инфраструктуры после крупной аварии.
Если серверы, сети и балансировщики описаны в коде, многие ресурсы можно создать заново автоматизированно.
Однако Terraform не является системой Backup. Он может восстановить структуру инфраструктуры, но не содержимое бизнес-баз и файлов.
Поэтому Disaster Recovery должен сочетать IaC и резервное копирование данных.
Terraform и Immutable Infrastructure
Terraform хорошо сочетается с подходом Immutable Infrastructure, при котором инфраструктурные объекты стараются не изменять вручную после создания.
Если требуется новая конфигурация, старый ресурс заменяется новым, созданным по актуальному описанию.
Это уменьшает накопление незадокументированных изменений и Configuration Drift.
Преимущества Terraform
- декларативное описание инфраструктуры;
- автоматизированное создание ресурсов;
- поддержка большого количества providers;
- возможность просматривать план до применения;
- интеграция с Git и CI/CD;
- переиспользование модулей;
- воспроизводимость окружений;
- уменьшение ручных ошибок;
- удобство для облачной инфраструктуры;
- возможность работать с несколькими типами платформ.
Недостатки и риски Terraform
Terraform требует дисциплины и понимания инфраструктуры. Сам инструмент не защищает от неправильного архитектурного решения.
- ошибочный apply может затронуть много ресурсов;
- State требует защиты и резервирования;
- необходимо контролировать версии providers;
- ручные изменения создают drift;
- большие монолитные конфигурации становятся сложными;
- ошибка в модуле может распространиться на несколько проектов;
- для настройки ПО внутри серверов часто нужны дополнительные инструменты.
Типичные ошибки при работе с Terraform
- Запускать apply без просмотра plan.
- Хранить секреты непосредственно в Git.
- Не защищать State.
- Хранить командной State только на локальном компьютере.
- Регулярно менять ресурсы вручную через облачную панель.
- Создавать одну огромную конфигурацию для всей компании.
- Не использовать Code Review.
- Не разделять production и test.
- Не контролировать потенциальное удаление ресурсов.
- Считать Terraform заменой резервному копированию.
Как организовать проект Terraform
Шаг 1. Определить границы инфраструктуры
Следует решить, какие ресурсы будут управляться Terraform и как разделить их между окружениями.
Шаг 2. Настроить удаленный State
Для командной работы состояние желательно хранить централизованно и защищать от одновременных изменений.
Шаг 3. Создать модули
Повторяющиеся инфраструктурные компоненты полезно вынести в переиспользуемые модули.
Шаг 4. Хранить код в Git
Все изменения инфраструктуры должны иметь историю и проходить Review.
Шаг 5. Автоматизировать проверки
Pipeline может выполнять форматирование, валидацию и анализ плана.
Шаг 6. Ограничить ручной Apply
Production-инфраструктуру лучше менять через контролируемый CI/CD-процесс.
Шаг 7. Контролировать Drift
Следует отслеживать ручные изменения и возвращать их в Terraform-конфигурацию либо отменять.
Практический пример
Компания размещает SaaS-приложение в облаке. Для каждого нового клиента требуется отдельная сеть, несколько виртуальных машин, база данных и балансировщик.
Раньше администратор создавал все ресурсы вручную. На один проект уходило несколько часов, а конфигурации постепенно начинали отличаться.
Команда создала Terraform-модуль типового окружения. В него вошли сеть, серверы, правила доступа и балансировщик.
Для нового проекта теперь достаточно передать название окружения, количество серверов и необходимые размеры ресурсов.
Pipeline формирует Terraform Plan, инженер проверяет изменения, после согласования выполняется Apply.
Если клиенту требуется дополнительный сервер, команда изменяет одно значение в конфигурации. Terraform видит разницу и создает только недостающий ресурс.
В результате развертывания стали быстрее, а инфраструктура разных проектов — более единообразной.
Terraform для бизнеса
Terraform особенно полезен компаниям, где инфраструктура становится слишком большой или динамичной для ручного управления.
Он помогает уменьшить зависимость от конкретного администратора. Вместо знания о том, какие кнопки были нажаты при создании сервера, остается конфигурация в репозитории.
Это упрощает аудит, запуск новых окружений и восстановление после аварий.
При этом внедрение Terraform само по себе не делает инфраструктуру надежной. Необходимы архитектурные стандарты, мониторинг, резервное копирование и процессы управления изменениями.
Когда нужен Terraform
- компания активно использует облачные ресурсы;
- инфраструктура регулярно изменяется;
- есть несколько окружений;
- ресурсы создают несколько инженеров;
- нужно хранить историю изменений;
- важно использовать Code Review;
- применяется CI/CD;
- требуется стандартизация инфраструктуры;
- развиваются DevOps и SRE-практики.
Когда Terraform может быть избыточным
Для одного небольшого сервера, который практически не изменяется, внедрение отдельного Terraform-процесса может оказаться сложнее ручного управления.
Но по мере роста количества ресурсов ценность автоматизации быстро увеличивается.
Особенно полезен Terraform, когда один и тот же тип инфраструктуры необходимо создавать многократно и с минимальными различиями.
Связанные термины
| Термин | Связь с Terraform |
|---|---|
| Infrastructure as Code | Подход, который реализует Terraform |
| HCL | Язык конфигурации, используемый для описания ресурсов |
| Provider | Компонент взаимодействия Terraform с внешней платформой |
| Resource | Объект инфраструктуры, которым управляет Terraform |
| State | Данные о соответствии конфигурации реальным ресурсам |
| Module | Переиспользуемый набор Terraform-конфигураций |
| Git | Используется для хранения и проверки инфраструктурного кода |
| CI/CD | Автоматизирует проверки Plan и применение инфраструктуры |
| DevOps | Подход, в котором Terraform часто используется для автоматизации инфраструктуры |
| SRE | Использует IaC для сокращения ручной работы и восстановления инфраструктуры |
| Ansible | Инструмент автоматизации конфигурации, часто используемый вместе с Terraform |
| Configuration Drift | Расхождение реального состояния инфраструктуры с Terraform-конфигурацией |
Краткий итог
Terraform — инструмент Infrastructure as Code для декларативного управления инфраструктурой. Он позволяет описывать серверы, сети, хранилища и другие ресурсы в конфигурационных файлах и автоматически приводить реальную инфраструктуру к нужному состоянию.
Ключевыми понятиями Terraform являются Provider, Resource, State, Plan, Apply и Module. Plan позволяет заранее увидеть предполагаемые изменения, State связывает код с реальными ресурсами, а модули помогают повторно использовать стандартные конфигурации.
Terraform особенно полезен для облачной инфраструктуры, DevOps, SRE и CI/CD. При этом безопасная эксплуатация требует защиты State, исключения секретов из репозитория, Code Review и внимательной проверки каждого плана перед применением к production-среде.
