Что это простыми словами

Terraform — это программа, которая создаёт и настраивает серверы и облачную инфраструктуру по текстовому описанию.

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

В мире IT «офис» — это серверы, базы данных, сети в облаке. Terraform позволяет описать их в файле и разворачивать одной командой, а не кликать вручную в интерфейсе облачного провайдера.

Официальное определение

Теперь, когда суть понятна, вот как Terraform описывают в вакансиях и документации. Эту формулировку вы будете встречать в требованиях к DevOps- и SRE-инженерам.

«Terraform — open-source инструмент категории IaC (Infrastructure as Code) от HashiCorp для декларативного описания, провижининга и управления облачной и on-premise инфраструктурой через провайдеры».

Разберём по словам. «Open-source» — бесплатная программа с открытым кодом. «IaC» (Infrastructure as Code, инфраструктура как код) — подход, при котором серверы и сети описываются в текстовых файлах, как рецепт, а не настраиваются вручную. «Декларативный» — вы пишете не «как сделать», а «что должно быть в итоге», а Terraform сам разбирается с шагами. «Провижининг» — процесс создания и первоначальной настройки ресурсов. «Провайдеры» — это плагины, которые позволяют Terraform общаться с конкретными облаками: AWS, Google Cloud, Azure и другими. «On-premise» — оборудование, которое стоит в собственном дата-центре компании, а не арендуется в облаке.

Какую задачу решает

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

Terraform решает три проблемы сразу:

  • Воспроизводимость — одинаковые окружения создаются по одному файлу, без расхождений.

  • История изменений — файлы хранятся в системе контроля версий (как история правок документа), и всегда видно, кто и что поменял.

  • Автоматизация — развернуть сотню серверов так же просто, как один: запустил команду и подождал.

Кто им пользуется

Terraform не привязан к языку программирования — это отдельный инструмент для управления инфраструктурой. Им пользуются несколько ролей:

  • DevOps-инженер — основной пользователь. Настраивает и поддерживает инфраструктуру, пишет Terraform-конфигурации для всех окружений.

  • SRE-инженер (Site Reliability Engineer — специалист по надёжности систем) — использует Terraform, чтобы инфраструктура разворачивалась предсказуемо и без ошибок.

  • Облачный архитектор — проектирует инфраструктуру и описывает её в виде Terraform-модулей.

  • Бэкенд-разработчик — реже, но в небольших командах разработчики сами пишут простые Terraform-конфигурации для своих сервисов.

Если в вакансии DevOps или SRE стоит Terraform — это ожидаемо и стандартно. Если Terraform встречается в вакансии разработчика — уточните у нанимающего менеджера, насколько глубоко нужны эти знания.

Аналоги / чем заменяется

Задачу управления инфраструктурой через код решают и другие инструменты:

  • Pulumi — похож на Terraform, но конфигурации пишутся на обычных языках программирования (Python, TypeScript). Удобен разработчикам, которые не хотят учить отдельный синтаксис.

  • Ansible — инструмент для настройки уже существующих серверов. Часто используется вместе с Terraform: Terraform создаёт серверы, Ansible их настраивает.

  • CloudFormation — аналог от Amazon, работает только с их облаком AWS. Кто знает CloudFormation, справится с аналогичными задачами в AWS.

  • OpenTofu — бесплатный форк Terraform с открытым кодом, появившийся после того, как HashiCorp изменила лицензию. Синтаксис практически идентичен, опыт переносится напрямую.

Переход между Terraform и OpenTofu — почти бесшовный, разница минимальна. Переход на Pulumi или CloudFormation потребует переобучения, но концептуальное понимание IaC переносится.

Что не путать

  • Terraform ≠ Ansible. Terraform создаёт инфраструктуру с нуля (серверы, сети, базы данных), а Ansible настраивает то, что уже создано (устанавливает программы, меняет конфиги). В реальных проектах они нередко работают вместе.

  • Terraform ≠ Docker. Docker упаковывает приложение в контейнер — изолированную коробку, которая везде работает одинаково. Terraform решает другую задачу: где и как запустить эти контейнеры, какие серверы для этого нужны.

  • Terraform ≠ Kubernetes. Kubernetes управляет запущенными контейнерами внутри кластера, а Terraform создаёт сам кластер и облачные ресурсы вокруг него. Они решают задачи на разных уровнях и часто применяются вместе.

  • Terraform ≠ язык программирования. Конфигурации пишутся на специальном языке HCL (HashiCorp Configuration Language), который больше похож на структурированный текст, чем на программирование. Знать его — не то же самое, что уметь программировать.

  • Terraform ≠ облако. Terraform — инструмент для работы с облаком, но само облако (AWS, Azure, Google Cloud) — отдельная тема. Знание Terraform не означает знания конкретного облака, и наоборот.

Насколько это важно при отборе

Короткий ответ: для DevOps- и SRE-инженера Terraform — стандартное требование, а не бонус.

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

Когда требование можно смягчить: если кандидат уверенно работал с OpenTofu или Pulumi и понимает принципы IaC — он освоит Terraform быстро, за одну-две недели. Концепция одна, меняется только синтаксис. Опыт с CloudFormation переносится чуть сложнее, но инженер с таким бэкграундом в целом понимает, о чём идёт речь.

Главный сигнал при отборе DevOps — понимание принципов IaC в целом. Кандидат, который умеет думать «инфраструктурой как кодом», адаптируется к конкретному инструменту. Кандидат, который только кликал в консоли облака, — нет.

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