c8eefab4b6
Релиз идёт из 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 и лечиться это будет только пересборкой образа.
37 lines
2.5 KiB
YAML
37 lines
2.5 KiB
YAML
---
|
||
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, то есть руками, так что
|
||
# там может быть уже исправлено. Проверяется по логам первого же пода.
|