Перейти к содержанию

0005. Состояние Terraform в секрете кластера

Дата: август 2026. Состояние: принято.

Контекст

Файл состояния Terraform нельзя держать в репозитории: в нём лежат сгенерированные пароли Grafana и PostgreSQL, а ещё он ломается при одновременном запуске из двух мест. Хранение локально на узле означает, что состояние живёт в одном экземпляре без блокировки и исчезает вместе с узлом.

Обычное промышленное решение — объектное хранилище с блокировкой: S3 с таблицей DynamoDB или аналог у облачного провайдера. Это требует внешнего доступа и хранения ключей от него где-то ещё.

Решение

Хранить состояние в секрете самого кластера, штатным механизмом Terraform:

backend "kubernetes" {
  secret_suffix = "metroskop"
  namespace     = "kube-system"
}

Блокировка при этом делается через объект аренды Kubernetes — тот же механизм, которым контроллеры выбирают ведущий экземпляр. Второй одновременный terraform apply не начнётся, пока первый не отпустит аренду.

Последствия

Что получили. Состояние не в репозитории, блокировка настоящая, никаких дополнительных ключей доступа. Права на чтение секрета уже ограничены правами доступа к кластеру: кто может править платформу, тот и так имеет полный доступ.

Чем заплатили. Круговая зависимость: состояние платформы хранится внутри той самой платформы, которой оно управляет. Потеря кластера — потеря состояния. На стенде это терпимо, потому что описание платформы полностью в репозитории: terraform init в новом кластере создаст состояние заново, а apply приведёт его к описанному виду.

Для рабочей системы такая схема не годится: там состояние должно переживать кластер. Первое, что нужно поменять при переносе, — вынести его в объектное хранилище.

Что рассматривалось

Локальный файл — самое простое и самое хрупкое: ни блокировки, ни сохранности.

Объектное хранилище — правильно для рабочей системы, но добавляет внешнюю зависимость и ключи доступа, которые в открытом проекте показать негде.

Отказ от Terraform в пользу манифестов Helm — тогда исчезает главное, зачем Terraform взят: единый план изменений с предварительным просмотром и фиксацией версий чартов.