0005. Состояние Terraform в секрете кластера¶
Дата: август 2026. Состояние: принято.
Контекст¶
Файл состояния Terraform нельзя держать в репозитории: в нём лежат сгенерированные пароли Grafana и PostgreSQL, а ещё он ломается при одновременном запуске из двух мест. Хранение локально на узле означает, что состояние живёт в одном экземпляре без блокировки и исчезает вместе с узлом.
Обычное промышленное решение — объектное хранилище с блокировкой: S3 с таблицей DynamoDB или аналог у облачного провайдера. Это требует внешнего доступа и хранения ключей от него где-то ещё.
Решение¶
Хранить состояние в секрете самого кластера, штатным механизмом Terraform:
Блокировка при этом делается через объект аренды Kubernetes — тот же механизм,
которым контроллеры выбирают ведущий экземпляр. Второй одновременный
terraform apply не начнётся, пока первый не отпустит аренду.
Последствия¶
Что получили. Состояние не в репозитории, блокировка настоящая, никаких дополнительных ключей доступа. Права на чтение секрета уже ограничены правами доступа к кластеру: кто может править платформу, тот и так имеет полный доступ.
Чем заплатили. Круговая зависимость: состояние платформы хранится внутри той
самой платформы, которой оно управляет. Потеря кластера — потеря состояния. На
стенде это терпимо, потому что описание платформы полностью в репозитории:
terraform init в новом кластере создаст состояние заново, а apply приведёт
его к описанному виду.
Для рабочей системы такая схема не годится: там состояние должно переживать кластер. Первое, что нужно поменять при переносе, — вынести его в объектное хранилище.
Что рассматривалось¶
Локальный файл — самое простое и самое хрупкое: ни блокировки, ни сохранности.
Объектное хранилище — правильно для рабочей системы, но добавляет внешнюю зависимость и ключи доступа, которые в открытом проекте показать негде.
Отказ от Terraform в пользу манифестов Helm — тогда исчезает главное, зачем Terraform взят: единый план изменений с предварительным просмотром и фиксацией версий чартов.