Repinoid
58c519e712
Проблема: у части сервисов пароль пользователя генерирует платформа и кладёт его в
секрет Vault РОДИТЕЛЬСКОГО инстанса. vault_secrets родителя — Computed и обновляется
только при его Read, поэтому внутри одного apply после create_user пароль недоступен
(Invalid index). Из-за этого в pg/outputs.tf приходилось читать vault_secrets кластера,
а стенду требовались два apply.
Решение: подресурс-пользователь отдаёт пароль СВОИМ выходом сразу после create_user.
- types.go: GenSubresource.VaultUserPassword (признак из данных спека);
- loader.go: признак = подресурс user + у сервиса есть vault-выходы + create_user
принимает username и НЕ принимает password; имя сервиса нигде не проверяется;
- templates/subresource.go: поле модели + Computed/Sensitive атрибут password,
чтение Vault родителя в Create (GetInstanceStateDetails + GetInstanceVaultSecrets)
и перенос уже полученного пароля в Update (чтобы Computed-атрибут не стал unknown);
- resources_core/subresource_user_password.go: ExtractUserPassword — разбор
{"<username>":{"password":"..."}} с безопасным возвратом пустой строки;
- writers: регрессионный тест «фича включена/выключена».
Проверено генерацией и сборкой test-стенда: выход получили 4 подресурса
(postgres_user, kafka_user, clickhouse_user, mongodb_user); mariadb_user НЕ затронут
(там пароль входной); k8s_*_user и vc_org_user не затронуты (пользователь
адресуется не через username). go test ./... — ok, go build — чисто.
TOOLS — Генераторы Terraform-провайдера Nubes
Каждый инструмент — независимый Go-модуль.
Канонический пайплайн (порядок шагов)
# 1) YAML-спеки сервисов из API (per-stand!)
./TOOLS/scripts/01_generate_yamls.sh --profile TOOLS/config/dev
# 2) Go-ресурсы + документация из этих YAML
./TOOLS/scripts/02_generate_resources_and_docs_v2.sh --profile TOOLS/config/dev
# 3) (релиз) сборка 3 платформ + публикация в реестр
./TOOLS/scripts/03_build_and_upload_provider.sh --profile TOOLS/config/dev
--profile обязателен: без него скрипты выходят с кодом 2 (никаких дефолтов).
Шаг 1 — безопасная генерация YAML
01_generate_yamls.sh работает по принципу «сначала во временное, потом атомарная замена»:
- генерация идёт в staging-каталог
generated/<stand>/resources_yaml.staging.<pid>/; - рабочий
generated/<stand>/resources_yaml/не удаляется и не модифицируется до полного успеха; - при полном успехе старый каталог уезжает в бэкап
resources_yaml.bak-<UTC>, а staging встаёт на его место (атомарныйmvв пределах одного FS), хранятся последниеKEEP_BACKUPS(по умолчанию 5); - при любой ошибке замена отменяется: старый каталог цел, частичный результат лежит в staging для разбора, скрипт выходит с кодом 1;
- в каталоге лежит маркер
.stand, защищающий от генерации не в тот стенд.
Перегенерировать все стенды подряд:
for s in dev test prod; do
./TOOLS/scripts/01_generate_yamls.sh --profile TOOLS/config/$s || break
done
Примечание: часть параметров API отдаёт со случайным
default-суффиксом (db-ievgpdvu→db-ujama5rbи т.п.), поэтому побайтовое сравнение двух прогонов даёт различия в этих строках — это не регрессия.
yaml-generator
API Nubes → resources_yaml/*.yaml
cd yaml-generator && go build -o ../bin/yaml-generator .
./bin/yaml-generator
Структура: main.go + internal/{client,config,normalize,spec,types}.
resource-generator
resources_yaml/*.yaml → internal/resources_gen/*.go + registry.go
cd resource-generator && go build -o ../bin/resource-generator .
./bin/resource-generator
Структура: main.go + internal/{helpers,loader,params,templates,types,writers}.
Как запускать правильно
Не запускайте TOOLS/resource-generator/bin/resource-generator вручную и не полагайтесь на старый бинарник из TOOLS/resource-generator/bin/.
Используйте канонический скрипт из корня репозитория, он всегда пересобирает генераторы из текущих исходников перед запуском:
./TOOLS/scripts/02_generate_resources_and_docs_v2.sh --profile TOOLS/config/dev
Для других стендов подставляйте нужный профиль:
./TOOLS/scripts/02_generate_resources_and_docs_v2.sh --profile TOOLS/config/test
./TOOLS/scripts/02_generate_resources_and_docs_v2.sh --profile TOOLS/config/prod
Это устраняет случайный запуск устаревшего бинаря и гарантирует, что новые kind из YAML, включая modifier, будут обработаны текущим кодом генератора.
docs-generator
resources_yaml/*.yaml → Markdown-документация в docs/30_registry/resources/
cd docs-generator && go build -o ../bin/docs-generator .
# Документация ресурсов
./bin/docs-generator
# Operations-документация
./bin/docs-generator --ops
Структура: main.go + internal/{types,writers,ops}.