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

2.1 KiB

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.

# 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

# 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.