Создавать ресурсы кликами в консоли удобно ровно до второго раза. Дальше начинаются вопросы: как воспроизвести то же самое в другом каталоге? как понять, что вообще создано? как откатить изменение? Ответ — инфраструктура как код (IaC): инфраструктуру описывают текстовыми файлами, которые хранят в git, ревьюят и применяют. В Yandex Cloud основной инструмент для этого — Terraform. Общие принципы IaC, не привязанные к облаку, разбирает статья про основы infrastructure as code; здесь — как это устроено в Yandex Cloud.

Почему Terraform

В отличие от AWS с его встроенным CloudFormation, у Yandex Cloud нет собственного «родного» языка описания инфраструктуры — стандартом де-факто выступает Terraform с официальным провайдером Yandex Cloud. Это открытый инструмент, который умеет управлять ресурсами десятков платформ на одном языке (HCL), поэтому знание переносимо: тот же Terraform описывает и AWS, и Kubernetes.

Идея простая: вы декларативно пишете, что должно существовать, а Terraform сам вычисляет, что для этого создать, изменить или удалить, сравнив ваше описание с текущим состоянием.

Провайдер и ресурсы

Провайдер (provider) — это плагин, который учит Terraform работать с конкретной платформой. Для Yandex Cloud его настраивают, указав, в каком облаке и каталоге работать и под каким сервисным аккаунтом:

provider "yandex" {
  cloud_id  = var.cloud_id
  folder_id = var.folder_id
  zone      = "ru-central1-a"
}

Ресурс (resource) — единица инфраструктуры: сеть, подсеть, виртуальная машина, кластер базы. Каждый описывается блоком:

resource "yandex_vpc_network" "main" {
  name = "main-net"
}

resource "yandex_vpc_subnet" "a" {
  name           = "subnet-a"
  zone           = "ru-central1-a"
  network_id     = yandex_vpc_network.main.id
  v4_cidr_blocks = ["10.0.1.0/24"]
}

Обратите внимание на yandex_vpc_network.main.id: ресурсы ссылаются друг на друга, и Terraform сам понимает порядок создания — сеть раньше подсети. Вам не надо это расписывать.

Команд всего несколько: terraform plan показывает, что изменится (это стоит читать всегда перед применением), terraform apply применяет, terraform destroy удаляет всё описанное.

Состояние (state) и где его хранить

Terraform помнит, что он создал, в файле состояния (state) — это его карта соответствия «описание ↔ реальные ресурсы». Ключевой момент для новичка: этот файл нельзя терять и нельзя держать локально при работе в команде, иначе двое применят изменения поверх друг друга и рассинхронизируют реальность.

Правильно — хранить state в общем месте. В Yandex Cloud это делают в Object Storage: благодаря совместимости с S3 подходит стандартный S3-backend Terraform, нацеленный на адрес хранилища Yandex Cloud, с блокировкой, чтобы двое не применяли одновременно.

terraform {
  backend "s3" {
    endpoint = "storage.yandexcloud.net"
    bucket   = "my-tfstate"
    key      = "prod/terraform.tfstate"
    region   = "ru-central1"
  }
}

Переменные и модули

Хардкодить значения в описании — плохо: production и staging отличаются парой параметров, а не всем файлом. Для этого есть:

  • переменные (variables) — вынести различия (размер машины, число узлов, идентификатор каталога) в параметры и подставлять разные значения для разных сред;
  • модули (modules) — свернуть кусок инфраструктуры (например, «сервис + база + сеть») в переиспользуемый блок и разворачивать его в разных средах одним вызовом с разными параметрами.

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

Где это применяется

Terraform — стандартный способ управлять инфраструктурой Yandex Cloud в любом серьёзном проекте: инфраструктура лежит в git рядом с кодом, изменения проходят ревью в pull request, а применяет их конвейер доставки, а не человек руками в консоли. Это убирает «а кто и что там накликал» и делает инфраструктуру воспроизводимой.

Типичные ошибки новичков:

  • держат state локально в командной работе — рассинхрон и затёртые изменения;
  • применяют apply не глядя в plan — и удаляют лишнее;
  • хардкодят значения вместо переменных — копипастят описания вместо переиспользования;
  • кладут секреты прямо в .tf-файлы и коммитят в git — секреты берут из Lockbox, а не из кода.

Что учить дальше: общие концепции IaC — в основах infrastructure as code; как устроена доставка через конвейер — в принципах CI/CD; что именно вы описываете — сеть, вычисления, данные. Тот же Terraform для AWS разобран в статье про Terraform в AWS.