~ / blog / iac-for-frontend-lead
iac-for-frontend-lead.md — vim
23 июля 2026 г. ⏱ ~3 мин · devopsпроцессымыслигайд

Infrastructure as Code глазами фронтендера

«Давайте поднимем такое же окружение для нового клиента» — фраза, после которой выяснилось, что повторить его никто не может. Как мы переезжали на Terraform.

Когда я пришёл в роль CTO, инфраструктура была собрана руками. Кто-то когда-то нажал кнопки в панели облака, что-то дотюнил по SSH, и всё работало. До фразы «давайте поднимем такое же окружение для нового клиента».

Оказалось, что «такое же» повторить никто не может. Знание жило в голове одного инженера и в истории bash на его машине.

Переход на IaC был одним из самых заметных изменений, которые мы сделали. Объясню, почему это касается и фронтендеров тоже.

Идея

Инфраструктура описывается текстовыми файлами, которые лежат в git. Не «зайди в панель и создай виртуалку», а:

resource "selectel_vpc_server_v2" "frontend" {
  name      = "frontend-prod-01"
  flavor_id = var.flavor_standard_4vcpu
  image_id  = var.image_ubuntu_24
  keypair   = var.ssh_key
}

terraform plan показывает разницу между тем, что описано, и тем, что есть в реальности. terraform apply приводит реальность к описанию.

И дальше на серверы начинает работать всё, что мы знаем про код: ревью изменений, история, откат, ветки, воспроизводимость.

Что это дало нам

Одинаковые окружения. dev, stage и prod — один модуль с разными переменными. Пропадает целый класс багов «на стенде работало». Для фронта это особенно чувствительно: половина странностей это разные версии nginx, разные заголовки и разные настройки CORS.

Видно, что произойдёт. plan в пайплайне пул-реквеста пишет: будет создано 2 ресурса, изменён 1, удалён 0. Строчка «будет удалён 1» однажды спасла нам продовую базу — заметили на ревью, а не после применения. Одного этого случая хватило, чтобы все перестали спорить про пользу подхода.

Восстановление вместо героизма. Упало окружение — применяем конфиг заново. А не «Саша, который это настраивал, в отпуске».

Стоимость видна заранее. Мы прикрутили в пайплайн Infracost, и в пул-реквесте сразу видно, сколько новая конфигурация добавит в месяц. Разговор про экономию из абстрактного стал конкретным — это плюс переговоры с провайдером неплохо сократили нам счета.

Три правила, без которых всё разваливается

State — удалённо и с блокировкой. Файл состояния это карта соответствия между кодом и реальными ресурсами. Локальный terraform.tfstate на ноутбуке инженера — гарантированная катастрофа при первом же параллельном применении:

terraform {
  backend "s3" {
    bucket = "company-tfstate"
    key    = "prod/frontend.tfstate"
  }
}

Никаких правок руками в панели. Как только кто-то что-то поменял мышкой, реальность разъезжается с кодом (это называется drift), и следующий apply либо это затрёт, либо упадёт. Правило простое и жёсткое: менять может только CI.

Секреты не в git. В коде только ссылки, значения в хранилище. И имей в виду: Terraform кладёт значения в state открытым текстом, так что state тоже должен быть закрытым хранилищем, а не просто «бакетом, о котором никто не знает».

Зачем это фронтенд-лиду

Можно всю карьеру не писать .tf. Но три вещи бьют по фронту напрямую:

CDN, кэширование и заголовки - это инфраструктура. Твой Cache-Control, brotli, HTTP/2 и TLS живут там.

Превью-стенды на каждый PR существуют только там, где окружение создаётся автоматически.

Разговор с девопсами становится предметным. «Сделайте нам стенд» превращается в пул-реквест, который можно обсудить и померить.

Есть ещё эффект, который я недооценивал: описанная инфраструктура это документация, которая не устаревает. В отличие от вики она обязана совпадать с реальностью, иначе plan сразу покажет расхождение.

Если у вас пока всё руками - не переписывай всё разом. Возьми одно новое окружение, опиши только его, дальше импортируй существующие ресурсы по одному. Большие миграции «всё за квартал» обычно заканчиваются наполовину сделанными и брошенными, я такое видел не раз.

Ссылки