Привет, Хабр! На связи Алексей Тюняев, директор по облачным продуктам Рег.облака.
Когда инфраструктура небольшая, личного кабинета обычно хватает: зашел, создал сервер, настроил — готово. Но как только серверов становится больше, появляются повторяющиеся операции, командная работа и необходимость воспроизводить окружения, ЛК начинает ограничивать. Именно здесь в игру входит Terraform. В этой статье разберу, что такое Terraform, как он работает и когда его действительно стоит использовать.
Навигация по тексту
Когда возможностей личного кабинета больше не хватает
Перейти на Terraform стоит, когда сходятся три фактора:
Инфраструктура усложнилась.
У вас уже не один-два сервера, а десятки ресурсов: виртуальные машины, сети, балансировщики, базы данных. Управлять этим через интерфейс — значит тратить часы на клики.Над инфраструктурой работает команда.
Несколько человек вносят изменения параллельно, и важно понимать, кто и что поменял. Личный кабинет такую прозрачность не дает.Появилось несколько окружений — dev, staging, prod.
Их нужно разворачивать по одному шаблону и согласованно обновлять, иначе среды начнут расходиться.
В таких случаях компании переходят к инструментам автоматизации. Один из самых распространённых — Terraform.
Ключевые концепции Terraform
Terraform — инструмент из категории Infrastructure as Code (IaC). Прежде чем разбирать, как с ним работать, стоит понять несколько базовых идей, на которых он построен.
Декларативность
Инженер описывает желаемое состояние инфраструктуры, а не последовательность шагов для его достижения. Вы говорите: «нужен сервер с такими-то параметрами» — Terraform сам разбирается, как его создать или привести к нужному виду.
Модель ресурсов
Инфраструктура представлена в виде совокупности взаимосвязанных объектов — ресурсов. Сервер, SSH-ключ, сеть, база данных — каждый из них описывается отдельным блоком конфигурации. Ресурсы могут ссылаться друг на друга: например, при создании сервера можно указать SSH-ключ, определенный в том же файле.
Модульность
Описание инфраструктуры можно разбить на модули — переиспользуемые блоки конфигурации. Один раз описал стандартное окружение, применяешь его для каждого нового проекта без дублирования кода.
Хранение состояния (state)
Terraform фиксирует текущее состояние инфраструктуры в специальном файле — state. Он нужен, чтобы при следующем применении конфигурации Terraform понимал, что уже существует, а что нужно создать, изменить или удалить.
Провайдеры
Провайдеры — это плагины, которые обеспечивают взаимодействие Terraform с конкретным облаком, SaaS-сервисом или локальной платформой. У Рег.облака есть собственный провайдер — regcloud.
Как это работает: настройка и пример создания сервера
Перед началом работы Terraform нужно установить — это разовый шаг. Дальше работа строится по одному и тому же циклу из нескольких команд:
Написание кода — описание требуемой инфраструктуры на языке HCL или JSON.
terraform init — инициализация рабочей директории и установка нужных провайдеров.
terraform plan — планирование изменений: Terraform показывает, что будет создано, изменено или удалено.
terraform apply — применение изменений.
terraform destroy — удаление инфраструктуры, если она больше не нужна.
Настройка провайдера
Сначала нужно подключить провайдер и передать ему токен доступа и адрес API, с помощью которого провайдер будет общаться с облаком. Это делается в двух файлах: main.tf с описанием провайдера и terraform.tfvars с переменными.
# main.tf variable "token" { type = string description = "API token" } variable "api_url" { type = string description = "API URL" } terraform { required_providers { regcloud = { source = "tf.reg.cloud/regru/regcloud" } } } provider "regcloud" { token = var.token api_url = var.api_url }
# terraform.tfvars token = "<токен доступа из личного кабинета>" api_url = "https://api.cloudvps.reg.ru"
Пример создания сервера
После настройки провайдера можно описывать ресурсы. Вот как выглядит создание SSH-ключа и сервера:
resource "regcloud_ssh_key" "example_key" { name = "example_key1" public_key = file("./assets/id_rsa_example.pub") } resource "regcloud_server" "example_server1" { name = "example_server_001" size = "c1-m1-d60-hp" image = "ubuntu-24-04-amd64" region_slug = "openstack-msk1" ssh_keys = [regcloud_ssh_key.example_key.fingerprint] backups = false lifecycle { ignore_changes = [ ssh_keys ] } }
Параметры size и image задаются через slug — уникальные идентификаторы тарифов и образов. Актуальные значения доступны в документации, в API и в личном кабинете Рег.облака.
Результат terraform plan
Перед применением всегда стоит запустить terraform plan: команда покажет, какие именно ресурсы будут созданы, изменены или удалены. Это позволяет проверить конфигурацию до того, как она реально применится к инфраструктуре.
Добавление сервера и изменение тарифа
Если нужно добавить еще один сервер или, например, поменять тариф существующего — достаточно внести правки в конфигурационный файл и снова запустить terraform apply. Terraform сам определит разницу между текущим и желаемым состоянием и применит только нужные изменения.
Чего Terraform не делает
Важно понимать границы ответственности инструмента, чтобы не ждать от него лишнего.
Не инициализирует ПО внутри сервера. Terraform создаёт и настраивает инфраструктуру, но не занимается тем, что происходит внутри виртуальной машины после ее запуска. Для этого обычно используется cloud-init — скрипт первоначальной настройки, ссылку на который можно указать прямо в Terraform-коде.
Не выполняет операции, не связанные с изменением инфраструктуры. Перезагрузить сервер или переустановить образ — не его задача.
Terraform отвечает только за предоставление инфраструктуры. Всё остальное — зона ответственности других инструментов (например, Ansible).
Преимущества Terraform
Если коротко о том, почему Terraform стоит рассмотреть:
Декларативный подход. В отличие от работы напрямую через API, где нужно описывать последовательность действий — создать сеть, дождаться готовности, создать подсеть, потом машину — в Terraform вы описываете желаемый результат. Как к нему прийти, инструмент разберется сам.
Понятный язык HCL — читается как конфиг, а не как код, и подходит для совместной работы.
Поддержка сотен провайдеров — от облаков до DNS-сервисов и систем мониторинга, всё описывается в одном стиле.
Модульность — упрощает поддержку сложных и гибридных инфраструктур.
Воспроизводимость и предсказуемость — один и тот же код дает одинаковый результат в любом окружении.
Интеграция с CI/CD — инфраструктурой можно управлять как кодом: с контролем версий, ревью и историей изменений.
Terraform не отменяет личный кабинет — он просто решает проблемы, которых в личном кабинете еще нет. Пока серверов два, а вся «инфраструктура как код» помещается в README с командами для bash, Terraform будет избыточным. Но как только появляется второй человек с правами на прод, третье окружение или необходимость объяснить аудиту, кто и когда поднял эту виртуалку, — ручное управление превращается в источник инцидентов, а не в способ их избежать.
А вы на каком этапе ушли от ручного управления к IaC — и что стало последней каплей?