# Kong — migrat pe cluster shared (2026-04-28)

> **TL;DR**: containerul local `didi-kong` nu mai rulează. Tot traficul public DIDI trece prin clusterul Kong shared extern: `HAProxy 10.11.10.175` → `Kong DP1/DP2 (10.11.10.177/178)`. Configurația DIDI declarativă e în `declarative/kong-cluster.yml`.

---

## Ce era aici (înainte de 2026-04-28)

`didi-kong` — un container Kong 3.4.2 standalone (`image: didi-kong:latest`) definit în `backend/production/docker-compose.yml`. Mod Postgres (DB pe clusterul Patroni). Servea singur tot traficul `didi365.eu`. Avea 16 servicii + 35 rute + 5 plugin-uri globale + 1 consumer JWT.

## Ce e acum

Tot traficul DIDI a fost migrat pe **Kong cluster extern** (același folosit de `lege365`, `rafai`, `biddie`, `notify`, `firme`).

| Component cluster | IP:Port | Rol |
|---|---|---|
| HAProxy LB | `10.11.10.175:443` | edge → DP, terminare TLS pentru DIDI |
| Kong CP (Control Plane) | `10.11.10.176:8001` | configurare via Admin API (DB-attached) |
| Kong DP1 | `10.11.10.177:8000/8443` | proxy trafic |
| Kong DP2 | `10.11.10.178:8000/8443` | proxy trafic |

Cluster Kong rulează versiunea 3.14.0.1 în mod Hybrid CP/DP, cu DB Postgres pe clusterul Patroni.

## Servicii DIDI consolidate pe cluster (4)

| Service cluster | Tag | Upstream | Routes |
|---|---|---|---|
| `didi-agent-v3` | `product:didi,env:prod,kind:api` | `10.11.10.12:24803` | 16 (15 API + 1 prefix /agent-v3) |
| `didi-framework` | `product:didi,env:prod,kind:api` | `10.11.10.12:3005` | 6 |
| `didi-keycloak` | `product:didi,env:prod,kind:auth` | `10.11.10.12:28000` | 2 |

> `didi-admin` NU e migrat — accesibil intern via VPN, păstrează Docker network DNS.

Toate rutele matchează pe `Host: didi365.eu, www.didi365.eu, <host-local>`.

## Servicii droppate complet

- `analysis-api`, `orchestrator-api` (legacy, 0 routes)
- `agent-v3`, `keycloak` (alias-uri orfane)
- `minio-storage` (deja în cluster MinIO 4-node, vezi `didiStorage/MIGRATION.md`)
- `pgadmin`, `redis-commander`, `rabbitmq-management`, `minio-console` (tooling în dispariție)

## Configurația declarativă

```
declarative/
├── kong-cluster.yml      ← config-ul curent al DIDI pe cluster (sursa de adevăr)
├── kong-local-backup.yml ← snapshot complet al Kong-ului local înainte de migrare
└── kong.yml              ← config-ul declarativ legacy (DB-less staging)
```

Apply / sync:
```bash
docker run --rm --network host -v $(pwd)/declarative:/cfg kong/deck:latest \
  gateway sync /cfg/kong-cluster.yml --kong-addr http://10.11.10.176:8001
```

Validare fără modificări:
```bash
docker run --rm --network host -v $(pwd)/declarative:/cfg kong/deck:latest \
  gateway diff /cfg/kong-cluster.yml --kong-addr http://10.11.10.176:8001
```

## Edge nginx (Contabo)

Edge nginx pe Contabo (`213.136.83.198`, `/srv/edge-nginx/conf.d/didi365.conf`) a fost actualizat să trimită `/auth/`, `/api/`, `/agent-v3/` la `https://10.11.10.175` (în loc de `https://<host-local>` care era kong local). Backup: `didi365.conf.bak.pre-kong-cluster-20260428`.

## Admin nginx

`backend/admin-dashboard/nginx-ssl.conf` — `location /api/` proxy_pass schimbat de la `https://kong:8443` (Docker DNS local) la `https://10.11.10.175` cu `Host: didi365.eu` overridden. Restul (`/auth/`, `/agent-v3/`, `/framework/`) bypass-ează Kong, merg direct la backend.

## Cum verifici că merge prin cluster

Răspunsurile prin cluster Kong au header-ul `X-Gateway: DIDI-Kong-Cluster`. Răspunsurile (vechile) prin Kong local aveau `X-Gateway: DIDI-Kong-Staging`.

```bash
curl -sI https://didi365.eu/auth/realms/didi-clients | grep -i x-gateway
# expect: x-gateway: DIDI-Kong-Cluster
```

## Rollback (dacă apar probleme)

Kong local nu mai există ca container, dar imaginea `didi-kong:latest` e intactă local. Pași rollback:

1. **Restore docker-compose**: revert commitul care a scos `kong:` din `production/docker-compose.yml`
2. **Repornește kong**: `cd backend/production && docker compose up -d kong`
3. **Rollback edge Contabo**: 
   ```
   cp /srv/edge-nginx/conf.d/didi365.conf.bak.pre-kong-cluster-20260428 \
      /srv/edge-nginx/conf.d/didi365.conf
   nginx -s reload
   ```
4. **Rollback admin nginx**: revert commit-ul nginx-ssl.conf, rebuild `didi-admin:latest`

DB-ul Kong-ului local (`KONG_PG_DATABASE`) era pe clusterul Patroni — datele sunt încă acolo (nu s-au șters).

## Lecții importante (capcane confirmate)

1. **decK default `protocols: [https]` rupe HAProxy passthrough.** Cluster Kong returna `426 Please use HTTPS` deși edge termina TLS. HAProxy LB forwardează HTTP intern la DP — Kong vede HTTP. Fix: `_info.defaults.route.protocols: [http, https]`.

2. **Port binding upstream.** Original `didi-agent-v3` era `127.0.0.1:24803` și `didi-framework` deloc expus. Modificat în docker-compose la `10.11.10.12:24803`/`3005` ca DPs cluster să ajungă (LAN VLAN 10).

3. **strip_path nu e uniform.** Match local: `/agent/health`, `/auth`, `/framework`, `/agent-v3` au `strip_path: true`. Restul `false`. Verifică înainte să copiezi.

4. **Host header obligatoriu.** Cluster shared filtrează rute pe Host. Edge nginx și admin nginx fac `proxy_set_header Host didi365.eu`. Fără asta — 404.

5. **JWT plugin per-rută.** Cluster shared, alți tenanți nu vor JWT didi-clients. Plugin aplicat explicit pe 13 rute.

## Linkuri rapide

- Cluster Admin API: `http://10.11.10.176:8001`
- Cluster ghid onboarding: `landingzone/kong-api/README.md` (repo `git.finesynergy.eu/lucian/landingzone`)
- Documentație decK: <https://docs.konghq.com/deck/>

## Status

- ✅ Migrare aplicată: 2026-04-28
- ✅ Kong local oprit și șters din docker-compose
- ✅ Edge nginx Contabo actualizat
- ✅ Admin nginx actualizat
- ⏳ Soak 24-48h în desfășurare; eliminarea volumelor Kong după validare