Оба пода уходили в рестарты, причины разные и обе — мои.
1. bim-api:
psycopg2.OperationalError: FATAL: database "bimapidb" does not exist
Имя базы у приложения ЗАХАРДКОЖЕНО и переменной не задаётся — в
entrypoint_api.sh (yoyo apply ... /bimapidb) и в models/database.py
(PooledPostgresqlExtDatabase('bimapidb', ...)). Переменной DB_NAME в
коде нет вообще, я подставлял её впустую. Запись в contour.databases
переименована bim_db -> bimapidb, DB_NAME из vault-шаблона убран.
Пустая bim_db остаётся в СУБД: бутстрап умеет только создавать. Данных
в ней нет — проверено, ноль таблиц.
2. bim-worker:
Exception: ENV_VARIABLE NOT SET: GOOGLE_APPLICATION_CREDENTIALS
settings.py делает check_settings(): проходит по ВСЕМ ключам ENV_FIELDS
и падает на первом незаданном, до проверки флагов дело не доходит.
Убирать переменную вместе с Google-хранилищем было нельзя. Возвращена;
файла по этому пути нет и не нужно — при FEATURE_ENABLE_GCLOUD=false
его никто не открывает, важно лишь наличие самой переменной.
Отсюда правило для этого приложения: набор переменных должен повторять
apps/bim/dsinv целиком, образ там тот же (870965d1...). Менять можно
только значения — адреса, бакет, брокер, — но не состав.
Разворачивается ИМЕННО bimbackend (Python, пара api + worker), а не
platform/bim-backend-v2 из apps/bim/base — тот откачен коммитом 285255e.
../base здесь намеренно не подключён.
Различить два приложения по образу нельзя: оба пушат bim-api. Различие в
тегах — у bimbackend полный SHA коммита (CI пушит bim-api:${CI_COMMIT_SHA}
с master), у bim-backend-v2 contour_*. Взят 870965d1..., тот же, что
крутится в dsinv.
Манифесты обычные, а не universal-chart: в репозитории сервис так и описан
(apps/bim/dsinv), своего чарта у него нет.
Отличия от dsinv:
* секреты из Vault вместо secretKeyRef на несуществующие Secret'ы;
штатный entrypoint файлы читать не умеет, поэтому обёрнут в sh -ec;
* PROCESSING_API_URL и WORKSPACES_API_URL приведены к именам контура —
в dsinv это workflows-service:8000 и workspaces-service:8000, здесь
оба сервиса называются backend-svc и слушают 80;
* RABBIT_HOST у воркера в dsinv указывает на rabbitmq-service.bim —
брокера в этом namespace нет ни там, ни здесь; у api в том же файле
адрес правильный. Поставлен общий брокер контура, vhost корневой;
* S3_BUCKET переведён на общее медиахранилище sarex-media-storage;
* убраны GOOGLE_APPLICATION_CREDENTIALS и том с ключом — Google в
контуре нет, флаг FEATURE_ENABLE_GCLOUD и так выключен;
* NodePort с прибитым 31352 заменён на ClusterIP: наружу сервис выходит
через общий Gateway;
* снят nodeSelector name=generic, imagePullSecrets переведён на regcred.
ИЗВЕСТНОЕ ОГРАНИЧЕНИЕ, принято осознанно. S3 у этого приложения на MinIO
не настраивается: в storage/s3.py адрес зашит в код —
endpoint_url='https://storage.yandexcloud.net'
переменной окружения для него нет. Из контура он недостижим, поэтому
операции с файлами будут падать по таймауту, а остальные эндпоинты живы.
Альтернативы — пересборка образа с вынесенным endpoint либо перевод на
BIM_CURRENT_STORAGE=local (тип есть в storage/storages.py).
Наружу выведен на bim.sarex.local.lonsdaleites.ru, имя добавлено в
dnsNames сертификата. Тот же адрес приложение знает про себя через
BIM_API_EXTERNAL_HOST и строит по нему ссылки.
Коммит c8eefab развернул platform/bim-backend-v2 (Go, один httpserver) —
он приезжает из apps/bim/base. Нужен же aero/bimbackend: Python, пара
api + worker, S3-бакет sarex-bim-storage, связки с processing и
workspaces. В iac он лежит не в base, а отдельными манифестами
bim-api.yaml и bim-worker.yaml (см. apps/bim/dsinv).
Спутать их легко: ОБА пушат в реестр один и тот же образ bim-api, и
различить можно только по содержимому — v2 пишет в лог
"Starting BIMv2 API server", а у bimbackend точки входа
entrypoint_api.sh и entrypoint_worker.sh.
Откатывается всё: релиз, маршрут наружу, имя в сертификате, адрес
BIMV2_INTERNAL_HOST у django и обвязка (роль Vault, секрет, regcred,
путь синхронизации). Заводить их заново под bimbackend дешевле, чем
править остатки под другой сервис — у него могут отличаться и namespace,
и имя базы.
База bim_db при этом НЕ трогается и пересоздания не требует: проверено
до отката — ноль таблиц, 9 МБ пустого шаблона. v2 к ней подключился, но
схему не создал, миграции не отработали.
Релиз идёт из 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 и лечиться это будет только пересборкой образа.
