Runs the Centreon web container behind a TLS-terminating reverse proxy
(external HTTPS, internal HTTP). A reusable building block to test connection
scenarios the standard e2e/API stack cannot cover: X-Forwarded-Proto handling,
auth/cookies behind a proxy, redirections.
browser --HTTPS--> web-proxy (nginx, TLS) --HTTP + X-Forwarded-Proto: https--> web (apache :80)
apache-forwarded-proto.conf makes apache trust X-Forwarded-Proto, so php-fpm
sees REQUEST_SCHEME=https while the real connection stays HTTP.
cd .github/docker
# 1. one-time: self-signed cert for the proxy (git-ignored)
reverse-proxy/create-certs.sh
# 2. start (web image defaults to centreon-web-alma9:develop, override with WEB_IMAGE=…)
docker compose -f docker-compose.yml -f docker-compose.proxy.yml --profile proxy up -d
# 3. verify the wiring (expects https via proxy, http direct)
reverse-proxy/verify.shExpected output of step 3:
» Through the proxy (HTTPS) — expect https
PASS proxy → X-Effective-Scheme: https
» Direct to web (HTTP) — expect http
PASS direct → X-Effective-Scheme: http
Then use Centreon through either entry point:
- Through the proxy: https://localhost:4443/centreon —
admin/Centreon!2021 - Direct to
web(HTTP, for comparison): http://localhost:4000/centreon
Per-scenario config goes through env, e.g. CENTREON_INTERNAL_API_BASE_URL=http://127.0.0.1:80.
# stop when done
docker compose -f docker-compose.yml -f docker-compose.proxy.yml --profile proxy down -v../docker-compose.proxy.yml— overlay:weboverride +nginx-proxy(profileproxy)nginx.conf— proxy vhost (TLS 443 →web:80, setsX-Forwarded-Proto: https)apache-forwarded-proto.conf— apache trustsX-Forwarded-Protocreate-certs.sh— generates the self-signed proxy certificateapache-debug-scheme.conf+verify.sh— diagnosticX-Effective-Schemeheader and its bash check (helpers)
Fait tourner le conteneur web de Centreon derrière un reverse proxy qui termine
le TLS (HTTPS externe, HTTP interne). Un socle réutilisable pour tester des
scénarios de connexion que la stack e2e/API standard ne couvre pas : gestion de
X-Forwarded-Proto, authentification/cookies derrière un proxy, redirections.
navigateur --HTTPS--> web-proxy (nginx, TLS) --HTTP + X-Forwarded-Proto: https--> web (apache :80)
apache-forwarded-proto.conf fait confiance à X-Forwarded-Proto côté apache,
si bien que php-fpm voit REQUEST_SCHEME=https alors que la connexion réelle
reste en HTTP.
cd .github/docker
# 1. une fois : certificat auto-signé pour le proxy (non commité)
reverse-proxy/create-certs.sh
# 2. démarrer (image web par défaut : centreon-web-alma9:develop, surcharge via WEB_IMAGE=…)
docker compose -f docker-compose.yml -f docker-compose.proxy.yml --profile proxy up -d
# 3. vérifier le câblage (attendu : https via le proxy, http en direct)
reverse-proxy/verify.shSortie attendue de l'étape 3 :
» Through the proxy (HTTPS) — expect https
PASS proxy → X-Effective-Scheme: https
» Direct to web (HTTP) — expect http
PASS direct → X-Effective-Scheme: http
Ensuite, exploiter Centreon par l'une ou l'autre porte d'entrée :
- Via le proxy : https://localhost:4443/centreon —
admin/Centreon!2021 - En direct sur
web(HTTP, pour comparer) : http://localhost:4000/centreon
La config par scénario passe par l'environnement, ex. CENTREON_INTERNAL_API_BASE_URL=http://127.0.0.1:80.
# arrêter une fois terminé
docker compose -f docker-compose.yml -f docker-compose.proxy.yml --profile proxy down -v../docker-compose.proxy.yml— overlay : surchargeweb+ servicenginx-proxy(profilproxy)nginx.conf— vhost du proxy (TLS 443 →web:80, poseX-Forwarded-Proto: https)apache-forwarded-proto.conf— apache fait confiance àX-Forwarded-Protocreate-certs.sh— génère le certificat auto-signé du proxyapache-debug-scheme.conf+verify.sh— en-tête diagnosticX-Effective-Schemeet sa vérification bash (helpers)
