В этом уроке разбираемся, почему инфраструктура промышленного уровня строится в разы дольше, чем кажется на старте. Это не про лень и не про плохих инженеров. Это про скрытую сложность, которую новички просто не видят, потому что демки и туториалы её честно прячут.
Боль: оценка "на глаз" всегда врёт
Классика. Менеджер спрашивает: "сколько займёт поднять окружение в Yandex Cloud?". Ты прикидываешь: ну, сеть, пара ВМ, база, балансировщик... дня три? Через три недели ты всё ещё дебажишь, почему бэкапы не восстанавливаются, а알ерты молчат, когда сервис лежит.
Дело в том, что terraform plan apply на голую виртуалку и реальная прод-инфраструктура как код - это две разные вселенные. Первое - hello world. Второе - система, которой можно доверить деньги, данные и сон дежурного инженера. Терраформ тут ни в чём не виноват, инструмент быстрый. Долго не писать HCL, долго - довести инфраструктуру до состояния, в котором её не стыдно отдать в эксплуатацию.
Yak shaving: почему ты бреешь яка
Есть отличный термин - yak shaving (бритьё яка). Это когда ты сел сделать простую задачу, но чтобы её сделать, надо сначала сделать другую, а для неё - третью, и вот ты уже бреешь яка, хотя начинал с "подними мне базу".
Реальный пример из terraform yandex cloud. Задача: поднять managed PostgreSQL.
- Чтобы поднять базу, нужна сеть и подсеть.
- Чтобы сеть была безопасной, нужны security groups с правилами.
- Чтобы хранить terraform state не локально, а в Object Storage, нужен бакет.
- Чтобы создать бакет, нужен сервисный аккаунт с правами и статический ключ доступа.
- Чтобы выдать права, надо разобраться с ролями IAM в облаке.
Скрытая сложность и неполный список требований
Главная ловушка прод-инфры - неполный список требований. Заказчик (или ты сам) формулирует: "нужен сервис, доступный из интернета". И всё. А за этой фразой прячется:
- Безопасность. Security groups, приватные подсети, шифрование дисков, секреты не в открытом виде, принцип наименьших привилегий в IAM.
- Мониторинг. Метрики, логи, дашборды, алерты. Если сервис упал и никто не узнал - значит, мониторинга нет.
- Бэкапы. И не просто "включили бэкапы", а проверенное восстановление. Бэкап, который ни разу не разворачивали, - это шум, а не бэкап.
- Отказоустойчивость (HA). Несколько зон доступности, балансировщик, реплики базы. Одна ВМ в одной зоне - это не прод, это демка с амбициями.
- Масштабирование. Группы инстансов с автоскейлингом, чтобы чёрная пятница не положила сервис.
- Документация. README, описание модулей, схема сети. Через полгода ты сам не вспомнишь, зачем тут эта подсеть.
- CI/CD. terraform plan в pull request, apply через пайплайн с ревью, а не с ноутбука "ну я быстренько".
Практика: видно разницу глазами
Вот так выглядит "демо-прод", который собирают за полчаса и показывают на конференциях:
Код: Выделить всё
resource "yandex_compute_instance" "app" {
name = "app"
platform_id = "standard-v3"
zone = "ru-central1-a"
resources {
cores = 2
memory = 4
}
boot_disk {
initialize_params {
image_id = "fd8..." # образ Ubuntu
}
}
network_interface {
subnet_id = yandex_vpc_subnet.subnet_a.id
nat = true # публичный IP прямо на ВМ
}
}
А теперь кусок того, что нужно реально, - группа инстансов с автоскейлингом и распределением по зонам. Тут сразу и HA, и масштабирование:
Код: Выделить всё
resource "yandex_compute_instance_group" "app_ig" {
name = "app-ig"
service_account_id = yandex_iam_service_account.ig_sa.id
instance_template {
platform_id = "standard-v3"
resources {
cores = 2
memory = 4
}
boot_disk {
initialize_params {
image_id = "fd8..."
size = 20
}
}
network_interface {
network_id = yandex_vpc_network.net.id
subnet_ids = [yandex_vpc_subnet.subnet_a.id, yandex_vpc_subnet.subnet_b.id]
}
}
scale_policy {
auto_scale {
initial_size = 2
max_size = 6
measurement_duration = 60
cpu_utilization_target = 70
}
}
allocation_policy {
zones = ["ru-central1-a", "ru-central1-b"]
}
deploy_policy {
max_unavailable = 1
max_expansion = 2
}
}
Код: Выделить всё
resource "yandex_mdb_postgresql_cluster" "db" {
name = "prod-db"
environment = "PRODUCTION"
network_id = yandex_vpc_network.net.id
config {
version = "16"
resources {
resource_preset_id = "s3-c2-m8"
disk_type_id = "network-ssd"
disk_size = 50
}
backup_window_start {
hours = 3
minutes = 0
}
}
host {
zone = "ru-central1-a"
subnet_id = yandex_vpc_subnet.subnet_a.id
}
host {
zone = "ru-central1-b"
subnet_id = yandex_vpc_subnet.subnet_b.id
}
}
Типичные грабли
- Считать только время на написание HCL. Написать ресурс - 20 минут. Проверить, что он переживёт apply на чистом окружении, починить циклические зависимости, дождаться, пока кластер реально поднимется (managed-базы создаются по 10-15 минут), - вот где время.
- Игнорировать "обвязку". state, бэкенд, модули terraform, переменные, секреты. Это не код инфраструктуры напрямую, но без него прод не живёт.
- "Потом добавим мониторинг". Не добавите. Прикручивать наблюдаемость к работающему проду в десять раз больнее, чем заложить сразу.
- Один большой main.tf. Без разбивки на модули terraform через полгода это болото, которое страшно трогать.
- Путать opentofu и terraform в команде. Если часть людей на opentofu, а часть на terraform, договоритесь на берегу про версию и провайдеров, иначе state будет ловить сюрпризы.
Кодить ничего не надо, упражнение на голову. Но сделай руками, на бумаге или в заметках:
- Возьми любую свою "простую" задачу, например "поднять веб-сервис в Yandex Cloud".
- Выпиши все семь требований прод-инфры из урока и честно ответь по каждому: есть оно у тебя или нет.
- Для каждого недостающего прикинь, какие ресурсы terraform yandex cloud придётся добавить (балансировщик, группа инстансов, бэкап, security group и так далее).
- Сложи грубые оценки времени. Сравни с первой интуитивной цифрой "за вечер". Поразись.
- Что такое yak shaving и почему это нормальная часть работы над инфраструктурой как код?
- Перечисли по памяти семь категорий требований к прод-инфраструктуре.
- Почему "бэкап есть" и "бэкап работает" - это разные вещи?
- Чем демо-конфиг с одной ВМ принципиально отличается от прод-конфига с группой инстансов и managed-базой?
Терраформ быстрый - долго не он, а доведение инфраструктуры до прод-готовности. "Готовая к проду" значит: безопасность, мониторинг, бэкапы (проверенные), HA, масштабирование, документация и CI/CD закрыты, а не отложены "на потом". Большая часть времени уходит на скрытую сложность и yak shaving, а не на печатание HCL. Когда в следующий раз будешь давать оценку - умножай интуицию на список из семи пунктов, а не на оптимизм. И закладывай обвязку (terraform state, модули, бэкенд) с самого начала, а не после первого инцидента.
