Every services.<svc>.deployment.resources.requests.{cpu,memory} across the
36 uralkal apps (69 HelmRelease/service entries total) is now nulled via a
kustomize patch, so Helm never renders a requests block for these pods on
uralkal — Kubernetes won't reserve CPU/memory for them there.
Where a uralkal patch already existed for that service (13 cases:
documentations api/filestream/pdf-markings-amqp, django backend, flows
backend/celery, pm backend/celery, transmittal backend/worker, bi,
document-link, stamp-verification, message-hub), the null block was added
into that same file. Where no uralkal patch existed yet (55 cases,
including all 13 cde workers and every plain frontend), a new minimal
patch file was added and wired into that app's kustomization.yaml.
vad and the other clusters are untouched — only apps/*/uralkal/* changed.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
apps/<app>/uralkal mirrors apps/<app>/vad for all 36 apps from
clusters/vad/kustomization.yaml, with domains remapped (not a suffix swap —
vad's sarex-login.vadroad.ru etc. use a different host scheme than uralkal's
login.sarex.local.uralkali.com). Two things are left as explicit
placeholders pending real infra: the Zitadel client_id/org_id
(TBD_URALKAL_ZITADEL_CLIENT_ID, since uralkal's Zitadel has no application
registered yet) and the Kafka CA cert in pm/issues/message-hub/flows
(copied from vad, will need swapping once uralkal's Kafka actually
generates its own CA, same as vad's history).
infrastructure/s3-proxy/uralkal: new component, nginx upstream points at
the single uralkal minio endpoint (10.133.0.245:9000) from terraform,
unlike vad's 4-node list.
clusters/uralkal/kustomization.yaml: wires in s3-proxy + all 36 apps.
infrastructure/istio-config/uralkal/istio-config.yaml: adds the 28
path-routed virtualServices under sarex.local.uralkali.com (mirroring
vad's sarex.vadroad.ru routing, incl. the documentations-api CORS policy)
plus stamp-verification/document-link/s3 on their already-declared hosts.
Pre-existing zitadel/superset/camunda-operate blocks are untouched.
apps/django/vad/backend.yaml: drop a stale explanatory comment (also
removed from the uralkal copy before this commit).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
django's nginx-configmap is patched for vad: pm and processing aren't
deployed there yet (kept commented out), documentations is enabled
since it's going in alongside django this time.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
По просьбе: неподнятые в контуре сервисы (pm, documentations,
processing) остаются в конфиге закомментированными, а не вырезанными —
видно, что временно выключено, легко раскомментировать когда появятся.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
nginx падал в CrashLoopBackOff: "host not found in upstream
backend-svc.pm.svc.cluster.local" — proxy_pass резолвится один раз при
старте, приложений pm/documentations/processing в sarex-contour нет.
Убраны location-блоки /api/pm/, /api/v1/documents/, /workflows/;
django и workspaces (оба раскатаны) — оставлены.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
apps/django/sarex-contour — чистое наследование base (backend, celery,
frontend, srx-admin, s3-proxy, redis, конфигмапы). Все vault-пути
(apps/django/postgres, rabbitmq/apps/django, minio/apps/django,
kafka/apps/django, vault/common/{rsa_keys,django_auth}) заведены через
terraform в infra/terraform. S3-эндпоинт в манифестах base захардкожен
на несуществующий домен — деплою как есть, патчить по факту если
помешает подняться (как с rabbitmq/zitadel).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The standalone rebuild in the previous commit reconstructed several
services from base/wb reference values and missed re-applying the
cr.yandex -> 10.4.10.187 registry swap for: checklists, issues/frontend,
contracts, drawings, flows (backend/celery/frontend),
documentations/pdf-markings, django/s3-proxy, django/srx-admin,
inspections. All 32 previously wb-synced images now verified back on
10.4.10.187:80/library.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Root cause: apps/*/ugok extended ../base via kustomize patches, but base
is vault-native (Vault Agent Injector annotations + serviceAccount +
command/args wrapper sourcing /vault/secrets/*). The Vault Agent Injector
webhook IS deployed cluster-wide in ugok (infrastructure/vault/ugok), so
it actually intercepted these pods — but no per-app Vault roles/secrets
were ever provisioned there, so every pod hung in Init.
Fix, mirrored from apps/*/wb (which never extends base for these apps):
rebuild every affected app as a standalone HelmRelease per service, with
no serviceAccount/podAnnotations override and no vault-sourcing wrapper
in command/args (dropped entirely, or replaced with the real functional
command where base's wrapper did double duty — e.g. celery invocations,
pm's `python manage.py migrate`, pdf-markings-amqp's `start-amqp-worker`).
Also recreates ConfigMaps that were referenced by name in volumes but
never actually captured into the repo (eav, subscriptions, pm, issues,
django) — copied verbatim from the cluster dump and verified byte-for-byte
against it.
Incidental bugs found and fixed along the way:
- message-hub was still extending base (missed in an earlier pass).
- system-log's patches targeted services.api/services.worker while base
uses services.backend for both — would have produced duplicate
Deployments per release, one of them permanently vault-broken.
- contracts' real container port is 8080, not base's default 8000.
- drawings' Service.targetPort (8000) didn't match the real containerPort
(8080), breaking routing.
- inspections/ugok was missing entirely from this pass.
apps/documentations: intentionally left without a redis Deployment even
though VALKEY_ADDR now points at one — the cluster dump has no redis in
that namespace, so provisioning one is a scope decision, not a bug fix.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Adds apps/<app>/ugok overlays for 31 applications, derived strictly from
a live cluster dump (kubectl get deployment/service/configmap/secret),
following the wb overlay pattern (standalone HelmRelease patches on
universal-chart, plain k8s Secret + secretKeyRef instead of Vault Agent
since the ugok cluster has zero Vault usage cluster-wide).
- processing (workflow namespace) does not extend base: base is
vault-native, ugok is not, so it's four standalone HelmReleases
modeled on apps/processing/wb/*.
- issues/redis and django/redis are raw Deployments patched via JSON6902.
- documentations/pdf-markings and django/auth-flow-frontend,
export-project are copied in as standalone files (base has no
HelmRelease for them, and kustomize forbids cross-overlay references
outside a directory's own tree).
- Images and images-with-registry updated to match wb where the same
build lineage applies; left as-is where the wb tag carries a distinct
client/cluster name (donstroi1, brusnika_*, dev4, UGOK_*, ugok1_*) or
points at a different image repository entirely.
- Missing backend envs backfilled from wb where safe (internal
svc.cluster.local refs, feature flags, already-established ugok
domains); skipped where wb-specific (external DB/Kafka hosts, TLS CA
content, features not deployed in ugok like gatekeeper/Superset).
- message-hub patch was missing its entire env block from the original
bootstrap; rebuilt from the raw dump (not wb, whose Kafka/DB config is
incompatible) plus a handful of small env gaps found while
cross-checking every ugok app's rendered envs against the raw dump.
clusters/ugok/kustomization.yaml keeps the apps section commented out —
not wired into the Flux Kustomization yet, pending review.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Образы подтянуты под теги wb там, где это один и тот же сервис.
В backend-файлах добавлены недостающие env-переменные — с адаптацией
доменов под конвенцию brusnika-stage (test.sarex.brusnika.tech), без
слепого копирования wb-специфичных значений (доменов/секретов).
Не тронуты apps/comparisons/brusnika-stage/backend.yaml,
apps/faas/brusnika-stage/backend.yaml, apps/notes/brusnika-stage/backend.yaml —
по содержимому принадлежат другим приложениям/клиенту, требуют отдельного
разбора.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Проставлены requests и limits в apps/*/wb на основе p95/max
потребления CPU и памяти за 14 дней (scripts/wb-resource-utilization.sh).
request ~ p95*1.2, limit ~ max*1.5-2, с полом 10m/20m CPU и 32Mi/48Mi
памяти. documentations/pdf-markings: request урезан до пола (10m/32Mi),
limit оставлен на исходном уровне (2 CPU/8Gi) — редко используется, но
при вызове может понадобиться весь объём.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
