Environment_Infrastructure/roadmap/prod-env/05-apisix-remove-ssl.md
Murat ÖZDEMİR 5ddba7eba4 docs: update production roadmap for HA Vault and shared storage
- Refactor production setup documentation to reflect a 3-node Vault Raft cluster starting from launch.
- Update all paths to use StorageBox mounts for shared state (SWAG config, TLS certs, Monitoring data).
- Switch Nginx configuration convention from proxy-confs to site-confs to align with SWAG's auto-include behavior.
- Standardize TLS private key extensions to .pem.
- Update node failover and recovery facts to include monitoring services.
- Align deployment pipeline instructions with the latest environment variable-driven approach.
2026-05-16 16:18:21 +03:00

50 lines
2.1 KiB
Markdown

# 05 — APISIX: Remove SSL / Configure Trusted Proxy (Prod)
## Context
Identical to `test-env-setup/05-apisix-remove-ssl.md`.
The same `init/apisix-core/init.sh` and custom APISIX image are used for both environments.
Changes made for test already apply to prod.
## Checklist
- [ ] `ssls/1` PUT block removed from `init/apisix-core/init.sh`
- [ ] `dev` SSL block removed or confirmed non-impactful for prod
- [ ] Custom APISIX image (`custom-apisix:3.12.0`) config.yaml contains `real_ip_header`
and `set_real_ip_from` for overlay CIDR (`10.0.0.0/8`)
- [ ] New image built and pushed to Harbor if config.yaml was changed:
```bash
docker build -t registry.tarla.io/iklimco/custom-apisix:3.12.0 .
docker push registry.tarla.io/iklimco/custom-apisix:3.12.0
```
## Prod-specific note
APISIX runs with `replicas: 3` in prod — this value is defined in the `docker-stack-infra.prod.yml` overlay (not in the base `docker-stack-infra.yml`). All replicas read the same configuration from Patroni etcd (`/apisix` prefix) — a single `init` run is sufficient.
```bash
# Prod deploy:
docker stack deploy -c docker-stack-infra.yml -c docker-stack-infra.prod.yml iklimco
```
`init/apisix-core/init.sh` is run once by the pipeline and writes the etcd state that all APISIX instances read.
## SWAG → APISIX load distribution
SWAG connects to APISIX via `proxy_pass http://apisix:9080;` — using the service name directly.
No additional upstream or load balancer configuration is needed on the SWAG side.
**How it works:** Docker Swarm resolves the `apisix` service name to a VIP (Virtual IP).
Swarm's internal IPVS load balancer automatically distributes incoming connections across the 3 replicas
in round-robin. SWAG is unaware of this mechanism; it happens transparently at the overlay network layer.
## Verification
```bash
# From a whitelisted IP, make a request and check real IP in APISIX logs
docker exec $(docker ps -q -f name=iklimco_apisix | head -1) \
tail -5 /usr/local/apisix/logs/access.log
```
Client IP should appear in the log, not SWAG's internal overlay IP.