Настройка Terraform для разных стендов

Дата: 2026-08-31

Матрица стендов

Стенд	Рабочие каталоги	Provider source	API endpoint	Версия в найденных Terraform-файлах
DEV	`DEV_STAND/CRUD`, `DEV_STAND/POSTGRES`, `DEV_STAND/IOT_KAFKA_DEMO`, `DEV_STAND/SHTURVAL_MGMT`	`tf-registry.containerk8s.services.ngcloud.ru/nubes-dev/nubes`	`https://lk-api-gateway-dev.ngcloud.ru/api/v1/svc`	обычно `3.x`
TEST	`TEST_STAND/CRUD`, `TEST_STAND/PG`, `TEST_STAND/POSTGRES`, `TEST_STAND/MARIA_DB`, `TEST_STAND/IOT_RMQ_DEMO`, `TEST_STAND/buck0`, `TEST_STAND/kuber`	`tf-registry.containerk8s.services.ngcloud.ru/nubes-test/nubes`	`https://lk-api-gateway-test.ngcloud.ru/api/v1/svc`	обычно `5.x`
PROD	`PROD_STAND/PG1`, `PROD_STAND/POSTGRES`, `PROD_STAND/RABBIT`	`tf-registry.containerk8s.services.ngcloud.ru/nubes/nubes`	`https://lk-api-gateway.ngcloud.ru/api/v1/svc`	обычно `2.x`

Provider выбирается в terraform { required_providers { nubes { ... } } } конкретного рабочего каталога. API endpoint задаётся в блоке provider "nubes".

Что настраивать

Перейти в конкретный каталог конфигурации, например TEST_STAND/PG.
Создать локальный файл terraform.tfvars по шаблону terraform.tfvars.example, если он есть.
Заполнить только переменные, объявленные в main.tf/variables.tf:
- api_token — токен того же стенда;
- realm — Kubernetes-платформа/кластер;
- s3_uid или s3_user_uid — UUID S3 для backup или ресурса bucket;
- s3_name — имя S3, если это предусмотрено конфигурацией;
- дополнительные org_uid, vdc_uid, edge_uid, sizing_policy — только для соответствующих ресурсов.
Проверить имена ресурсов и параметры в остальных .tf-файлах: resource_name, домены, git_revision, CPU, memory, replicas, disk, PostgreSQL version, backup schedule и adopt_existing_on_create.
Выполнить Terraform из этого же каталога:

terraform init
terraform plan
terraform apply

Для CRUD-конфигураций с PostgreSQL сначала требуется первый terraform apply для базы, пользователя и БД, затем второй terraform apply для приложений. Это прямо указано в TEST_STAND/CRUD/README.md.

Передача токена

Токен не следует хранить в репозитории. Допустимые варианты:

export TF_VAR_api_token="..."
terraform plan

или локальный terraform.tfvars, исключённый из публикации. Не использовать PROD-токен в DEV/TEST и не использовать TEST-токен в PROD.

State и backend

В проверенных стендах нет блока backend и отдельных backend-конфигураций. Если backend не добавлен локально, Terraform использует локальный state в рабочем каталоге (terraform.tfstate). Нельзя запускать два разных стенда с одним state; для общего или удалённого state нужен отдельный backend с уникальным bucket/key для каждого стенда.

Профили сборки provider

TOOLS/config/{dev,test,prod}/profile.env используется скриптами сборки и публикации provider, а не Terraform-манифестами стендов:

Профиль	API	Token file	Namespace	Версия профиля
`dev`	dev Gateway	`secrets/dev.token`	`nubes-dev`	`3.0.7`
`test`	test Gateway	`secrets/test.token`	`nubes-test`	`5.0.6`
`prod`	production Gateway	`secrets/prod.token`	`nubes`	`2.0.7`

Для сборки использовать профильный pipeline из HOWTO-UPLOAD.md, а не смешивать профиль одного стенда с Terraform-конфигурацией другого.

Найденные расхождения и риски

docs/ops/STANDS.md содержит устаревшие deck-api-*, старые пути devops/profiles и версии, не совпадающие с TOOLS/config/*/profile.env и частью Terraform-файлов.
Версии provider неоднородны даже внутри одного стенда: перед запуском нужно сверять required_providers конкретного каталога с опубликованной версией.
В PROD_STAND/PG1/terraform.tfvars обнаружен токен в открытом виде. Его нужно отозвать/заменить в Nubes и удалить из локального файла перед публикацией или передачей репозитория.
В отдельных PROD-файлах встречаются захардкоженные пароли и адреса внешних сервисов; их следует перенести в переменные/секретное хранилище перед использованием в общем доступе.
TEST_STAND/PG/README.md указывает версии и структуры параметров, которые могут отличаться от текущего main.tf; источником истины для запуска считать сам каталог Terraform и lock-файл после terraform init.

Синхронизация на VM

DEV_STAND/sync.sh и TEST_STAND/sync.sh синхронизируют конфигурацию на VM и исключают .terraform, state и lock-файл. Перед синхронизацией проверить целевой стенд и не переносить state между стендами.

6.3 KiB Raw Blame History Unescape Escape