c8555d432c
8 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
emelinda
|
96d0d2e373 |
BIM в контуре aero: api и worker из aero/bimbackend
Разворачивается ИМЕННО bimbackend (Python, пара api + worker), а не
platform/bim-backend-v2 из apps/bim/base — тот откачен коммитом
|
||
|
emelinda
|
285255e628 |
Откат BIM v2: развёрнут не тот сервис
Коммит
|
||
|
emelinda
|
c8eefab4b6 |
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 и лечиться это будет только пересборкой образа.
|
||
|
emelinda
|
e55958f7cb |
Workspaces в контуре aero: api и фронтенд-ремоут
apps/workspaces/aero — оверлей поверх base:
* DJANGO_HOST в base неверен дважды: сервиса backend не существует
(он backend-svc), и 8000 — это targetPort контейнера, а сервис
принимает на 80. Проверено в кластере: backend-svc:80 отдаёт 200,
backend-svc:8000 таймаутит, backend:8000 не резолвится. Та же
ошибка была в base у processing/engine-low.
* ENVIRONMENT/DJANGO_ORIGINATOR — «prod» заменён на aero: значение
уезжает в Sentry и в заголовки запросов к смежным сервисам.
* DOCUMENTATION_HOST переписан на честное имя внутри кластера.
Выключить интеграцию нечем: DOCUMENTATION_LOGGER_FEATURE гасит
только логирование, а GetDocumentByWS вызывается из обработчика
GET workspace безусловно. Сервиса documentations в контуре нет и
не будет — карточка воркспейса отдаётся без документа.
Фронтенд идёт из base без патчей и наружу НЕ публикуется: это Module
Federation remote srx_workspaces, его подгружает главный фронтенд
платформы. Версия — v2, и это не выбор: в бандле
sarex-frontend-dev:contour_5.22.0 лежит строка
/workspaces-v2/module/remoteEntry.js и имя ремоута srx_workspaces,
обращений к v1 нет вовсе. У v1 (platform/workspaces-frontend) к тому же
нет ни одной contour-сборки.
nginx-configmap: исправлен порядок директив в трёх location'ах.
set обязан идти ДО rewrite ... break — обе принадлежат
ngx_http_rewrite_module, и флаг break прекращает обработку его
директив, поэтому set после него не выполнялся. Переменная оставалась
пустой, nginx писал «no host in upstream :80» и отдавал 500. Так падали
и /workspaces-v2/..., и /workflows/... — маршрут / при этом работал,
из-за чего дефект и не был замечен раньше.
Обвязка: regcred и роль Vault для namespace workspaces, apps/workspaces
в gitea_sync_paths, секреты secrets/apps/workspaces/postgres и
secrets/vault/common/django_auth. Последний — вопреки имени пути НЕ
токен Zitadel: workspaces читает оттуда ключ key и кладёт его в
DJANGO_BASIC_AUTH, то есть это base64 логина и пароля администратора
django. Совпадение проверено в кластере по sha256.
|
||
|
emelinda
|
c7c194feaa |
Processing в контуре aero: api и engine-low
Развёрнут частично, и это осознанно:
* engine удалён — в base у него replicaCount 0, то есть он выключен и там,
а образ прибит к тегу с опечаткой в имени (workflows-endigne_prod);
* frontend удалён — адреса бэкендов зашиты в образ на этапе сборки через
__BUILD_ENV__, и ни один готовый профиль не смотрит на домен контура.
Подключать его имеет смысл только вместе с пересборкой образа.
Отключены смежные сервисы, которых в контуре нет: documentations (PDM,
filestream), resources, bim-api, workspace, issues, comparisons, mailgun,
SMTP. Оставлен только S3. Вместе с флагом ENABLE_SMTP убрана аннотация
инжекции secrets/vault/common/smtp_auth — секрета нет, и vault-agent-init
оставил бы под в Init:Error, не дойдя до флага.
S3 приезжает из Vault отдельным файлом: приложение читает по пути из
S3_SERVICE_ACCOUNT целый JSON, а не пару переменных. Набор ключей повторяет
engine/yc-s3-service-account.json из compose-стека, который так же смотрел
в MinIO.
Планирование подов задач: engine работает kubernetes-исполнителем и сам
создаёт Job'ы, подставляя им nodeSelector dedicated=processing. Выделенных
нод в контуре нет, поды висли бы в Pending — как это уже было у postgresql.
ENABLE_TOLERATION и DEFAULT_NODE_SELECTOR_* сняты.
Заодно у celery поправлены четыре адреса на wb.sarex.io — чужой контур,
недостижимый из aero. У backend те же переменные уже вели внутрь кластера;
при WORKFLOWS_USE=1 расхождение давало бы зависания вместо явной ошибки.
Патчи адресуются по индексу env, поэтому перед каждым replace стоит op: test
на имя переменной: смена порядка в base уронит сборку явно, а не перезапишет
соседнее значение.
|
||
|
emelinda
|
51b9120797 |
Measurements в контуре aero + декларативное заведение бакетов
Django обращается к сервису измерений при MEASUREMENTS_USE_MEASUREMENTS=1 (значение по умолчанию в base), так что без него часть API отвечала ошибкой. Сервис переименован в measurements-service, как в brusnika-*. В base он называется measurements-svc, а django ходит на measurements-service — переименовать сервис дешевле, чем патчить переменную в двух релизах django. Бакеты теперь заводит Job в infrastructure/minio/aero, а не команда руками. Чарт MinIO этого не умеет: форк не принимает ни buckets, ни provisioning. Так бакет django был создан императивно и не пережил бы пересоздание контура — развернув всё с нуля, получили бы работающий MinIO и приложения, падающие на отсутствующем бакете. Measurements сломался бы на этом сразу: имя бакета зашито в его vault-шаблоне. Идемпотентность даёт mc mb --ignore-existing. Сайдкар istio у Job отключён: контейнер задачи выходит, envoy продолжает работать, и под навсегда остаётся Running. |
||
|
emelinda
|
ee1881e516 |
feat(aero): django в k3s — backend, frontend, s3-proxy и выход наружу
Первый прикладной сервис переехал из compose в кластер. Развёрнуты backend, frontend, redis, srx-admin и s3-proxy; celery выключен до следующего шага. Платформа доступна по https://sarex.local.lonsdaleites.ru — корень отдаёт frontend, /api/ и /admin/ уходят в backend, /media/ в s3-proxy. Kafka и Zitadel в контуре не развёрнуты, и приложению они не нужны: SERVER_KAFKA_ENABLED в base уже False, а zitadel_enabled в sarex-backend читается ровно в одном месте — update_ams_user(), которая при выключенном флаге сразу выходит. Но аннотации инжекции этих секретов пришлось убрать: vault-agent-init не рендерит шаблон для несуществующего секрета и роняет под в Init:Error ещё до старта приложения. nginx-configmap заменён целиком. В base зашиты upstream'ы на namespace pm, workspaces и processing; nginx резолвит их при старте и падал с "host not found in upstream". pm убран как ненужный, для остальных двух адрес вынесен в переменную с resolver — их резолвинг откладывается до запроса, поэтому появление сервисов позже не потребует правки конфига. Заменять пришлось именно патчем: объект с тем же kind+name уже приходит из base, и добавление его в resources валит сборку слоя целиком. Секреты django в Vault: postgres, rabbitmq, minio и общие RSA-ключи JWT. RabbitMQ и MinIO подключены под административными кредами — отдельных пользователей приложения чарты создавать не умеют, это осознанный долг. Задача создания суперпользователя переписана с docker compose exec на kubectl exec. ВНИМАНИЕ: она пока НЕ РАБОТАЕТ — команда падает, вывод скрыт no_log. Механизм проверен отдельно и исправен, значит ошибка на стороне Django. Чтобы увидеть причину, нужно временно снять no_log. |
||
|
emelinda
|
565faa0e17 |
feat(aero): базовый слой контура — Vault↔k3s, GitOps-синхронизация, выход наружу
Топология k3s: 1 мастер + 2 воркера (убран k3s-worker-3 с томом).
Vault ↔ k3s. Vault живёт в compose, вне кластера, поэтому получает
статический IP 172.28.0.13, DNS-мост в namespace vault и token reviewer
(SA vault-auth + system:auth-delegator). Ansible включает auth/kubernetes,
передавая адрес apiserver, CA и JWT ревьюера явно, и заводит политику с
ролями. Секрет token reviewer'а читается целиком в JSON: вариант
-o jsonpath={.data.ca\.crt} НЕ работает — модуль command разбирает строку
через shlex, съедает обратный слэш, kubectl возвращает пустую строку с
кодом 0, и отказ остаётся незамеченным до падения vault write.
Синхронизация репозитория в gitea. Нужное подмножество путей (замыкание
ссылок clusters/aero) едет архивом на хост и коммитится там: gitea не
публикуется дальше самого хоста, контур остаётся замкнутым. flux-bootstrap
вынесен в отдельную волну — до неё Vault получает auth/kubernetes, а
репозиторий наполняется, иначе первая реконсиляция падает на пустом репо.
Инфраструктура: vault-agent-injector (чарт vault-contour в режиме внешнего
Vault), local-path-provisioner взамен встроенного в k3s (--disable=
local-storage; путь данных прежний), rabbitmq и minio с кредами из Vault.
Выход наружу: порты 80/443 k3s-server опубликованы (istio ingressgateway
занимает эти hostPort), общий contour-gateway на wildcard-хост, сертификат
Let's Encrypt через http01. Имена в сертификате перечислены явно —
http01 не выдаёт wildcard, для них нужен dns01.
Разорваны два дедлока Flux: infra-configs больше не зависит от
infra-controllers (издатели не должны зависеть от здоровья чартов, которые
их используют), istio-config получил disableWait.
Модули ядра iptable_nat и смежные грузятся на хосте: ноды k3s —
контейнеры, istio-init правит iptables через ядро хоста, а на RED OS 8
(nf_tables) legacy-модули не загружены, из-за чего любой под с
istio-injection навсегда вставал в Init:Error.
Собственные Gateway/VirtualService/Certificate чартов rabbitmq и dashboard
отключены — маршрутизация описана централизованно. У rabbitmq это сделано
postRenderers, а не values: kustomize нормализует null в {}, а пустую карту
Helm сливает с дефолтами, возвращая их целиком.
|