BIM API в контуре aero + вывод наружу

Релиз идёт из base без единого патча, и это проверено по исходникам
bim-backend-v2, а не принято на веру:

  * DJANGO_HOST в base уже правильный (backend-svc.django:80) — редкость,
    у processing и workspaces там лежал несуществующий backend:8000;
  * DB_CERT_PATH_2/3/4 указывают на сертификат управляемой СУБД Яндекса,
    которого в контуре нет, но зануления не требуют: файл читается только
    под флагом ENABLE_SSL, а при нуле к строке подключения дописывается
    ?sslmode=disable и путь не трогается;
  * пять комплектов POSTGRES_*_N в vault-шаблоне смотрят на один хост —
    в проде это реплики, в контуре СУБД одна.

Django ходил в никуда: BIMV2_INTERNAL_HOST в base ведёт в namespace
bim-api к сервису bim-backend-v2-service, а релиз разворачивается в
namespace bim и называет сервис backend-svc. Поправлено в обоих релизах
django — backend и celery.

Наружу выведен отдельным поддоменом bim.sarex.local.lonsdaleites.ru, а не
префиксом на домене платформы: своего фронтенда у сервиса нет, общего с
платформой origin тоже, а его пути конфликтовали бы с маршрутом /api/
django. Имя добавлено в dnsNames сертификата — без этого браузер получил
бы сертификат без него.

Обвязка: regcred и роль Vault для namespace bim, apps/bim в
gitea_sync_paths, секрет secrets/apps/bim/postgres (база bim_db и роль bim
уже заведены в contour.databases).

ИЗВЕСТНЫЙ РИСК, проверяется логами первого пода. В ветке develop у
bim-backend-v2 миграции катятся при старте httpserver, ошибка фатальна, а
адрес БД внутри RunOnStartup взят не из конфига, а из константы
rc1b-sse4o3n9vea392g4.mdb.yandexcloud.net:6432. Из контура он недостижим.
Если этот код попал в образ contour_f9f2a39-dirty, под уйдёт в
CrashLoopBackOff и лечиться это будет только пересборкой образа.

aero/roles/sarex_stack/defaults/main.yml

@@ -88,6 +88,7 @@ registry_secrets:
   - {name: regcred, namespace: measurements}
   - {name: regcred, namespace: processing}
   - {name: regcred, namespace: workspaces}
+  - {name: regcred, namespace: bim}
 
 # Поднимать стек (docker compose up -d). Требует запущенной службы docker и
 # docker login в cr.yandex — по умолчанию выключено.
@@ -157,6 +158,7 @@ gitea_sync_paths:
   - apps/measurements
   - apps/processing
   - apps/workspaces
+  - apps/bim
 
 # Рабочая копия репозитория gitea на хосте (клон, живёт между прогонами).
 gitea_sync_workdir: "{{ deploy_dir }}/gitea-sync"
@@ -243,6 +245,7 @@ vault_k8s_roles:
   - {name: processing, namespaces: [processing]}
   - {name: measurements, namespaces: [measurements]}
   - {name: workspaces, namespaces: [workspaces]}
+  - {name: bim, namespaces: [bim]}
 
 # Боевые креды инфраструктурных сервисов. Пути и имена ключей заданы чартами
 # (см. vaultRoot у minio и auth.vault у rabbitmq в infrastructure/*/aero) —
@@ -370,6 +373,18 @@ vault_app_secrets:
   # django, той самой учётки из secrets/apps/django/superuser выше. Из этого же
   # пути django в base читает django_zitadel_access_token, но в контуре Zitadel
   # нет и та аннотация удалена в apps/django/aero — здесь удалять её НЕ нужно.
+  # --- Секреты приложения bim ---------------------------------------------
+  # Структура задана vault-шаблоном в apps/bim/base/backend.yaml: он собирает
+  # ПЯТЬ комплектов POSTGRES_*_N из одних и тех же ключей. В проде это разные
+  # кластеры-реплики, в контуре СУБД одна — шаблон просто повторяет её пять раз,
+  # поэтому здесь достаточно одного набора значений.
+  - path: secrets/apps/bim/postgres
+    data:
+      host: postgresql.postgresql.svc.cluster.local
+      port: "5432"
+      database: "{{ sarex_postgres_bim_db }}"
+      username: "{{ sarex_postgres_bim_user }}"
+      password: "{{ sarex_secrets.SAREX_BIM_DB_PASSWORD }}"
   - path: secrets/vault/common/django_auth
     data:
       key: "{{ (superuser_name ~ ':' ~ superuser_password) | b64encode }}"
@@ -410,6 +425,11 @@ sarex_postgres_processing_user: processing
 sarex_postgres_workspaces_db: workspace_db
 sarex_postgres_workspaces_user: workspace
 
+# То же для bim. Должно совпадать с записью bim_db в contour.databases
+# (infrastructure/postgresql/aero).
+sarex_postgres_bim_db: bim_db
+sarex_postgres_bim_user: bim
+
 # Бакет медиафайлов django. ВНИМАНИЕ: чарт MinIO бакеты не создаёт — его нужно
 # завести отдельно, иначе загрузка файлов будет падать.
 sarex_django_s3_bucket: sarex-media-storage

apps/bim/aero/kustomization.yaml

@@ -0,0 +1,36 @@
+---
+apiVersion: kustomize.config.k8s.io/v1beta1
+kind: Kustomization
+namespace: bim
+resources:
+  - ../base
+
+# Патчей к самому релизу НЕТ, и это проверено, а не «руки не дошли».
+#
+# 1. DJANGO_HOST в base уже правильный — http://backend-svc.django...:80.
+#    Это редкость: у processing и workspaces в base лежал несуществующий
+#    backend.django:8000, здесь адрес корректный.
+#
+# 2. DB_CERT_PATH_2/3/4 указывают на /root/yandex_pg.pem — сертификат
+#    управляемой СУБД Яндекса, которого в контуре нет. Зануление не нужно:
+#    в bim-backend-v2 файл читается ТОЛЬКО под флагом —
+#      if !cfg.IntegrationTest && cfg.EnableSSL { GetTLSCert(cfg.DBCertPath) }
+#    а при ENABLE_SSL=0 (значение из base) к строке подключения дописывается
+#    ?sslmode=disable и путь не трогается вовсе.
+#
+# 3. Пять комплектов POSTGRES_* в vault-шаблоне base смотрят на один и тот же
+#    хост — так и задумано: в проде это разные кластеры-реплики, в контуре
+#    СУБД одна, и шаблон просто повторяет её пять раз.
+#
+# ВНИМАНИЕ, ИЗВЕСТНЫЙ РИСК. В ветке develop у bim-backend-v2 миграции
+# накатываются при старте httpserver и ошибка фатальна:
+#   if err := appmigrations.RunOnStartup(cfg); err != nil {
+#       log.Fatalf("Error applying migrations: %v", err)
+#   }
+# а внутри RunOnStartup адрес БД взят не из конфига, а из константы
+#   const v5ClusterAddr = "rc1b-sse4o3n9vea392g4.mdb.yandexcloud.net:6432"
+# Из контура этот хост недостижим. Если тот же код попал в образ
+# contour_f9f2a39-dirty, под будет падать в CrashLoopBackOff с этим текстом —
+# и лечится это только сборкой образа, конфигурацией здесь ничего не сделать.
+# Образ, впрочем, собран с master и с пометкой -dirty, то есть руками, так что
+# там может быть уже исправлено. Проверяется по логам первого же пода.

apps/django/aero/kustomization.yaml

@@ -68,6 +68,17 @@ patches:
       # четыре, и все четыре у celery: у backend те же переменные уже указывают
       # внутрь кластера. WORKFLOWS_USE=1, так что оставить как есть — значит
       # получить зависания на недоступном домене вместо явной ошибки.
+      # BIM API. В base адрес ведёт в namespace bim-api к сервису
+      # bim-backend-v2-service — ни того, ни другого в контуре нет: релиз
+      # разворачивается в namespace bim и называет сервис backend-svc.
+      # См. apps/bim/aero.
+      - op: test
+        path: /spec/values/services/celery/envs/8/name
+        value: BIMV2_INTERNAL_HOST
+      - op: replace
+        path: /spec/values/services/celery/envs/8/value/_default
+        value: http://backend-svc.bim.svc.cluster.local:80
+
       - op: test
         path: /spec/values/services/celery/envs/15/name
         value: SERVER_API_HOST
@@ -153,6 +164,16 @@ patches:
         path: /spec/values/services/backend/envs/2/value/_default
         value: "False"
 
+      # BIM API — то же, что у celery выше: в base адрес ведёт в namespace
+      # bim-api к сервису bim-backend-v2-service, а в контуре это namespace bim
+      # и сервис backend-svc.
+      - op: test
+        path: /spec/values/services/backend/envs/10/name
+        value: BIMV2_INTERNAL_HOST
+      - op: replace
+        path: /spec/values/services/backend/envs/10/value/_default
+        value: http://backend-svc.bim.svc.cluster.local:80
+
       # --- Администратор платформы --------------------------------------------
       # Учётка приезжает из Vault под именами, которые ждёт штатная
       # createsuperuser --noinput. Секрет кладёт ansible

clusters/aero/apps/kustomization.yaml

@@ -12,3 +12,6 @@ resources:
   # Воркспейсы: api и фронтенд-ремоут. Фронтенд наружу не публикуется — его
   # подгружает главный фронтенд платформы через свой nginx (/workspaces-v2/).
   - ../../../apps/workspaces/aero
+  # BIM API. Django обращается к нему через BIMV2_INTERNAL_HOST — адрес там
+  # чужой (namespace bim-api), поправлен патчем в apps/django/aero.
+  - ../../../apps/bim/aero

infrastructure/istio-config/aero/istio-config.yaml

@@ -146,6 +146,26 @@ spec:
                     prefix: /
                   service: frontend-svc.django.svc.cluster.local
                   port: 80
+            # BIM API. Отдельный поддомен, а не префикс на домене платформы:
+            # у сервиса нет своего фронтенда и нет общего с платформой origin,
+            # а его пути (/ping, /api/...) на общем домене конфликтовали бы с
+            # маршрутом /api/ django. Внутри кластера django обращается к нему
+            # напрямую по backend-svc.bim, этот маршрут — для внешних клиентов
+            # и отладки.
+            #
+            # Имя добавлено в dnsNames сертификата ниже: без этого браузер
+            # получит сертификат, в котором его нет.
+            bim:
+              namespace: gateway
+              hosts:
+                - bim.sarex.local.lonsdaleites.ru
+              gateways:
+                - gateway/contour-gateway
+              routes:
+                - path:
+                    prefix: /
+                  service: backend-svc.bim.svc.cluster.local
+                  port: 80
             # Management UI RabbitMQ.
             rabbitmq:
               namespace: gateway
@@ -203,6 +223,7 @@ spec:
                 - dashboard.sarex.local.lonsdaleites.ru
                 - rabbitmq.sarex.local.lonsdaleites.ru
                 - minio.sarex.local.lonsdaleites.ru
+                - bim.sarex.local.lonsdaleites.ru
               issuerRef:
                 # Боевой издатель, см. infrastructure/cert-manager/aero/configs.
                 name: letsencrypt-issuer-istio