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

Почему Terraform

У Google был свой инструмент описания инфраструктуры (Deployment Manager), но его развитие остановлено, и стандартом де-факто в GCP стал Terraform с официальным провайдером Google. Это открытый инструмент, который управляет ресурсами десятков платформ на одном языке (HCL), поэтому знание переносимо: тот же Terraform описывает и AWS, и Kubernetes.

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

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

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

provider "google" {
  project = var.project_id
  region  = "europe-west1"
}

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

resource "google_compute_network" "main" {
  name                    = "main-vpc"
  auto_create_subnetworks = false
}

resource "google_compute_subnetwork" "app" {
  name          = "app"
  region        = "europe-west1"
  network       = google_compute_network.main.id
  ip_cidr_range = "10.0.1.0/24"
}

Ресурсы ссылаются друг на друга (google_compute_network.main.id), и Terraform сам понимает порядок создания — сеть раньше подсети. Команд несколько: terraform plan показывает, что изменится (это стоит читать всегда), terraform apply применяет, terraform destroy удаляет.

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

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

Правильно — хранить state в общем месте. В GCP это делают в Cloud Storage: у Terraform есть backend gcs, который держит state в бакете с блокировкой, чтобы двое не применяли одновременно.

terraform {
  backend "gcs" {
    bucket = "my-tfstate"
    prefix = "prod"
  }
}

Нативные инструменты

Помимо Terraform, у GCP есть два родных подхода, о которых полезно знать:

  • Config Connector — управление ресурсами GCP в стиле Kubernetes: вы описываете облачные ресурсы как объекты кластера. Удобно тем, кто и так живёт в GKE.
  • Infrastructure Manager — управляемый сервис, который запускает ваш же Terraform на стороне Google, снимая заботу о хранении state и запуске.

Для большинства команд ответ по умолчанию — обычный Terraform: он переносим между облаками и лучше всего документирован.

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

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

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

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

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