Files
tf_provider/docs/ops/REGISTRY_REFACTORING.md
“Naeel” 2af2d2af16 chore: registry.kube5s.ru → tf-registry.containerk8s.services.ngcloud.ru
- All code/script/.tf defaults replaced
- Docs annotated with  LEGACY
2026-08-10 11:17:57 +04:00

3.8 KiB

Рефакторинг конфигурации реестра — история решений

Дата: 2026-08-09

Контекст

При заливке провайдера в DEV-стенд (nubes-dev) возникла ошибка:

No such property: resourceRealm for class: Script26

Провайдер был собран из YAML'ов TEST-стенда, но запущен против DEV API. У разных стендов — разные API, разные скрипты бэкенда, разные параметры.

Проблема 1: схема версий

Вопрос: почему 5.1.17 нельзя заливать в DEV?

Ответ: первая цифра версии жёстко привязана к стенду:

  • 2.* = PROD
  • 3.* = DEV
  • 5.* = TEST

Источник: docs/ops/STANDS.md

Проблема 2: хардкод старых доменов

Вопрос: почему скрипты ссылаются на registry.kube5s.ru <!-- ⛔ LEGACY: registry.kube5s.ru ЗАКРЫТ. Актуальный хост: tf-registry.containerk8s.services.ngcloud.ru --> <!-- ⛔ LEGACY: registry.kube5s.ru <!-- ⛔ LEGACY: registry.kube5s.ru ЗАКРЫТ. Актуальный хост: tf-registry.containerk8s.services.ngcloud.ru --> ЗАКРЫТ. Актуальный хост: tf-registry.containerk8s.services.ngcloud.ru -->, go-registry.containerk8s.dev.nubes.ru?

Ответ: реестр переехал на tf-registry.containerk8s.services.ngcloud.ru, но:

  • profile.env (все 3 стенда) — старые REGISTRY_HOST, S3_BUCKET
  • build-provider.sh — старый дефолт REGISTRY_HOSTNAME
  • docs-generator/main.go — хардкод registry.kube5s.ru <!-- ⛔ LEGACY: registry.kube5s.ru ЗАКРЫТ. Актуальный хост: tf-registry.containerk8s.services.ngcloud.ru -->/nubes-dev/nubes

Проблема 3: размазанная конфигурация

Вопрос: почему registry-настройки в 6 разных местах?

Ответ: исторически сложилось. Реестр воспринимался как часть стенда, а не как независимый сервис.

Решение: единый registry.env

Принцип: реестр — НЕЗАВИСИМЫЙ сервис. Его настройки НЕ зависят от стенда.

Было:

profile.env → REGISTRY_HOST, REGISTRY_HOSTNAME, S3_BUCKET, S3CFG_REGISTRY
build-provider.sh → хардкод дефолтов
docs-generator → хардкод provider-source

Стало:

registry.env (НОВЫЙ) → REGISTRY_HOSTNAME, S3_BUCKET, S3_ENDPOINT
profile.env → только стенд-специфика: API, токен, namespace, версия
скрипты → source registry.env + profile.env → всё из конфигов, ноль хардкода

Принятые решения

  1. Создать TOOLS/config/registry.env — единый источник правды о реестре
  2. Очистить profile.env — убрать все registry-параметры
  3. 02_generate...v2.sh — добавить -provider-source в вызов docs-generator
  4. build-provider.sh — заменить старый дефолт на актуальный
  5. main.go — fallback namespace: nubes-testnubes-dev
  6. tf_registry/server/build-provider.sh — синхронизировать после правок
  7. Креды S3 — НЕ в registry.env, только через env-переменные (безопасность)
  8. docs-generator — дефолт не трогаем, скрипт всегда передаёт явный -provider-source