Адрес вида /workflows/<uuid> — это путь ВНУТРИ SPA платформы, который
должна обработать она сама, отдав index.html. Маршрут /workflows/ на
frontend-svc.processing уводил его в nginx микрофронтенда, где такого файла
нет, и браузер получал
404 Not Found — nginx/1.19.6
Статика микрофронтенда доезжает и без этого маршрута: nginx платформы сам
проксирует /workflows/*.js в processing (apps/django/aero/nginx-configmap).
Это уже проверялось — 200, 282339 байт.
Маршрут /workflows/api/ оставлен: его nginx платформы не обслуживает, а
бандл ходит по нему относительным путём.
Продолжение разбора: после появления bimapidb оба пода упали на
psycopg2.ProgrammingError: ltree type not found in the database
а миграция api — на
type "ltree" does not exist
LINE 2: ALTER TABLE bimelement ADD hierarchy ltree null;
models/database.py при инициализации зовёт register_ltree(conn), без
расширения приложение не стартует. Роль bim не суперпользователь и
CREATE EXTENSION сама не сделает — расширение обязан завести бутстрап,
как у sarex_db и workflow_db. Добавлено в contour.databases.
--- Почему понадобилась отдельная задача ansible ---
Базы и расширения описаны декларативно, но заводит их скрипт бутстрапа
ТОЛЬКО при старте пода postgresql. На живом кластере правка списка
доезжает до Kubernetes и не делает ничего: спецификация пода не меняется,
пересоздания нет. Flux при этом полностью зелёный, а приложение падает с
"database does not exist" — связь между причиной и симптомом неочевидна.
Альтернатива — перезапуск postgresql-0, но это обрыв коннектов django,
processing и workspaces ради одной базы.
Добавлены tasks/databases.yml, список sarex_databases в defaults и задача
`uv run poe dbsync`. Делает ровно то же, что бутстрап, но без простоя, и
идемпотентно: существующие базы пропускаются, расширения создаются через
IF NOT EXISTS. Расширения обрабатываются отдельным шагом и всегда, а не
только для новых баз, — расширение может появиться в списке позже самой
базы, ровно так и вышло с ltree.
Проверено на живом контуре: bim-api 2/2 (uWSGI поднял воркеров),
bim-worker 2/2 (celery подключился к брокеру, 8 задач зарегистрировано).
Оба пода уходили в рестарты, причины разные и обе — мои.
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 и лечиться это будет только пересборкой образа.
Аннотации Flux force, prune и ssa принимают enabled/disabled, а не
булево. Написанное "true" Flux молча игнорировал.
Пока Job'а не существовало, это ничем себя не проявляло: обычный apply
проходил, бакеты заводились, всё выглядело рабочим. Сломалось на первой
же правке скрипта — spec.template у Job неизменяем, и слой
infra-controllers встал целиком:
Job/minio/minio-buckets dry-run failed (Invalid):
Job.batch "minio-buckets" is invalid: spec.template: ... field is immutable
а вместе с ним встал зависящий от него слой apps: измерения не получили
новый бакет не потому, что правка неверна, а потому что до них не дошла
очередь.
--- Бакет ---
В base у measurements имя бакета ЗАШИТО в самом vault-шаблоне:
"buckets":["measurements"]
Из-за этого он складывал файлы в собственный бакет, тогда как
медиахранилище контура одно — sarex-media-storage: туда пишет django и
оттуда же раздаёт s3-proxy на маршруте /media/. Ссылка на файл
измерения, отданная через django, вела бы в пустоту.
Шаблон переопределён в apps/measurements/aero так, чтобы имя бакета
читалось из секрета — как уже читается endpoint. Значение задаётся в
одном месте, vault_app_secrets, и совпадает с sarex_django_s3_bucket.
Заменить пришлось аннотацию целиком: значение внутри шаблона, через
values его не перекрыть.
Из Job'а бакетов убран measurements. Это не удаление: Job умеет только
mc mb --ignore-existing, ранее созданный бакет остаётся на месте — мы
лишь перестаём его заводить.
Порядок применения безопасен: в platform.yml vault-k8s.yml идёт до
gitea-sync.yml, то есть секрет получит ключ bucket раньше, чем Flux
пересоздаст под. Иначе vault-agent-init не отрендерил бы шаблон с
несуществующим ключом и под ушёл бы в Init:Error.
--- Перекат нагрузок ---
Единственное действие, которое до сих пор делалось руками мимо роли, —
rollout restart после правки ConfigMap. Оно понадобилось дважды (порядок
set/rewrite в nginx и auth_type) и оба раза выглядело как «правка не
поехала»: Flux рапортует Applied revision, а поведение старое.
Причина в том, что у релизов universal-chart в шаблоне пода нет
контрольной суммы конфига: ConfigMap меняется, спецификация пода — нет,
Kubernetes не видит причин пересоздавать под. Декларативно это здесь не
лечится — имя ConfigMap передаётся чарту строкой, монтирует он его сам, а
configMapGenerator переименовал бы ресурс, не поправив ссылку внутри
чарта, который рендерится уже в кластере.
Добавлены tasks/reload.yml, список sarex_reload_workloads в defaults и
задача `uv run poe reload`. По умолчанию выключено: перезапуск подов
посреди обычного деплоя происходить сам не должен.
Чарт дашборда своего пользователя не создаёт — он лишь показывает форму
ввода токена и ходит в API от имени того, чей токен введён. До сих пор
дашборд открывался, но войти в него было нечем.
Добавлены ServiceAccount dashboard-admin, привязка к встроенной роли
cluster-admin и Secret типа kubernetes.io/service-account-token.
Secret нужен именно ради бессрочности: с Kubernetes 1.24 ServiceAccount
не получает вечный токен автоматически, а kubectl create token выдаёт
короткоживущий. Secret с аннотацией kubernetes.io/service-account.name —
единственный штатный способ получить токен без срока действия: поле
token заполняет контроллер, в репозиторий оно не попадает.
Права взяты максимальные осознанно: дашборд задуман как инструмент
оператора — логи, exec, перезапуск нагрузок, — и с меньшими правами
половина экранов отдаёт ошибки доступа. Для закрытого тестового контура
это приемлемо; сузить до read-only можно заменой roleRef на встроенную
view, отозвать доступ — удалением Secret.
Envoy перехватывает исходящий трафик через iptables-правила, которые
ставит init-контейнер istio-init. Правила появляются раньше, чем envoy
начинает слушать, поэтому приложение, дёрнувшее сеть в первые секунды,
получает не таймаут, а connection refused — пакет уже завёрнут на порт
envoy, а там ещё никого нет.
Так падал workflows-api: контейнер стартовал и умирал в ту же секунду,
INFO Starting workflows migrations
INFO init database connection...
FATAL [dial tcp 10.43.195.4:5432: connect: connection refused]
при restartCount=0 у istio-proxy. Со второй попытки envoy успевал, и
дальше всё работало — то есть симптомом был ровно один рестарт на
старте, который легко списать на случайность.
Настройка сделана на уровне mesh, а не аннотацией на поде: уязвимы все,
кто ходит в БД или брокер сразу при запуске, а это почти каждый бэкенд
контура — django катит migrate первым делом, celery подключается к
rabbitmq, workspaces-api и engine-low к postgres. Они не падали не
потому, что устроены иначе, а потому что успевали.
Цена — каждый под стартует на время готовности envoy дольше, обычно
секунду-две: istio добавляет в sidecar postStart-хук, блокирующий запуск
остальных контейнеров. На Job'ы не влияет, у них инжекция отключена.
Действует в момент инжекции, поэтому на уже запущенные поды не
распространяется — хук появится при следующем пересоздании.
Фронтенд был исключён из-за адресов, вшитых в бандл на этапе сборки через
константу __BUILD_ENV__. Опасение не подтвердилось: сборка обращается к тому
же origin относительными путями — иначе в yc-k8s-test и d8-ugmk-prod не
понадобился бы отдельный маршрут /workflows/api/ перед /workflows/.
Маршруты добавлены на домен платформы, а не на отдельный поддомен: поддомен
потребовал бы пересборки образа с другим __BUILD_ENV__.
/workflows/api/ -> rewrite /api/ -> backend-svc.processing
/workflows/ -> rewrite / -> frontend-svc.processing
Порядок внутри пары значим: /workflows/api/ обязан идти перед /workflows/,
иначе запросы к API уйдут в раздачу статики. Оба стоят перед /api/ и / —
правила django их бы перехватили.
Маршруты положены в существующий VirtualService platform, а не в отдельный:
Istio не сливает несколько VirtualService на одной паре хост+gateway, и часть
правил молча потерялась бы.
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.
Celery не поднимался: worker падал в CrashLoopBackOff на
amqp.exceptions.AccessRefused (403) при подключении к брокеру.
Диагностика уводила в сторону — 403 читается как несовпадение пароля, но
пароль был верный: хеши значения в Vault, в файле, смонтированном в под
брокера, и в собранном BROKER_URL совпадали, а rabbitmqctl authenticate_user
с ним проходил. Настоящая причина нашлась в логе брокера:
PLAIN login refused: user 'rabbit' can only connect via localhost
Пользователю разрешён вход только с localhost, поэтому отбивалось любое
подключение из кластера — и по той же причине в management UI нельзя было
войти снаружи.
Лечится так же, как в d8-ugmk-prod: флагом auth.enableLoopbackUser и
дублирующим advancedConfiguration. Дубль не избыточен — флаг лишь пишет в
rabbitmq.conf строку "loopback_users.<user> = false", которую брокер не
применяет: в рантайме loopback_users всё равно оставался [<<"rabbit">>].
Значение задаёт именно advanced.config.
Первый прикладной сервис переехал из 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.
PostgreSQL разворачивается пустым инстансом, состав баз повторяет то, что
сейчас провижинит postgres-init в compose:
sarex_db -> django (ltree)
workflow_db -> processing (uuid-ossp, ltree, hstore)
bim_db -> bim
workspace_db -> workspace
Пароли администратора и владельцев берутся из Vault через
vault-agent-injector, в репозитории их нет. Расширения создаёт бутстрап
заранее: роли не суперпользователи и CREATE EXTENSION в миграциях им
недоступен. timescaledb включён в shared_preload_libraries сразу, хотя этим
базам не нужен, — параметр читается только при старте, и добавить его позже
означает перезапуск СУБД.
nodeSelector снимается postRenderers'ом. Чарт по умолчанию ставит
dedicated: sts в расчёте на выделенный пул нод; в контуре таких нет, и под
навсегда повисал в Pending, а следом застревал PVC, потому что у local-path
режим WaitForFirstConsumer. Через values это недостижимо: Helm сливает карты
по ключам, поэтому ни {}, ни другая метка dedicated: sts не убирают.
Цикл реконсиляции сокращён с 10 до 2 минут у всех Kustomization и
HelmRelease контура. Корневая Kustomization патчится из clusters/aero:
её файл генерирует flux bootstrap с пометкой DO NOT EDIT, а флаг --interval
задаёт периодичность только GitRepository. Таймаут установки postgresql
снижен с 20 до 10 минут — он определяет цену одной неудачной итерации.
Отключение собственных Gateway/VirtualService/Certificate чарта rabbitmq
переведено с JSON6902 на postRenderers: kustomize нормализует null в {}, а
пустую карту Helm сливает с дефолтами, поэтому настоящий null до Helm не
доходит ни одним путём.
Топология 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 сливает с дефолтами, возвращая их целиком.
