Revoir les images nginx de client et nginx-strangler

[StephaneTrebel]

Elles sont actuellement basées sur bitnamylegacy, et comme son nom l'indique, c'est pas fait pour durer, d'autant qu'elles ne sont plus maintenues à jour par Bitnami

Une tentative de basculer sur nginx:1.27-alpine s'est soldée par un échec cuisant lors de la validation sur l'environnement d'Intégration MI, car le securityContext côté Openshift associe un uid aléatoire au conteneur, ce qui fait planter joyeusement l'entrypoint qui attend plutôt un uid fixe (101). C'est ce qui a provoqué la création du hotfix v9.16.2

Il faut donc revoir tout ça:

• Utiliser une image nginx maintenue, officielle, et qui permette le chargement d'une configuration dynamique (variables d'environnement qui vont changer la configuration au démarrage)
• On peut faire notre propre image si on s'en sent le courage, plutôt que de se reposer sur des images qu'on ne maîtrise pas
• Envisager éventuellement de faire en sorte que la configuration soit rechargeable (lié au sujet de Feature Toggling) pour activer/désactiver des pans de configuration si besoin. Ça pourrait être intéressant pour nginx-strangler et les tests de bascule de route entre server et server-nestjs

[franko-c]

nginxinc/nginx-unprivileged couvre exactement le cas OpenShift random-uid — image nginx officielle, maintenue, qui tourne en non-root et écoute sur 8080 (port non-privilégié) avec un uid arbitraire. c'est l'image que la communauté OpenShift utilise pour contourner précisément la policy securityContext qui a fait planter nginx:1.27-alpine sur l'env d'Intégration MI.

FROM nginxinc/nginx-unprivileged:1.27-alpine
COPY default.conf.template /etc/nginx/templates/

la substitution dynamique est déjà câblée dans l'entrypoint upstream — /docker-entrypoint.d/20-envsubst-on-templates.sh lit /etc/nginx/templates/*.template, fait un envsubst au boot, et écrit le résultat dans /etc/nginx/conf.d/. tous les ${VAR} du template sont remplacés par les variables d'environnement au démarrage du conteneur, donc pas besoin de fabriquer une image custom pour ça.

pour le rechargement à chaud (sujet Feature Toggling sur nginx-strangler), nginx -s reload sur SIGHUP fonctionne sans redémarrer le pod — un pattern sidecar qui watch un ConfigMap et déclenche un reload via kubectl exec est viable. pas creusé si nginx-strangler a déjà une notion de feature flag dans sa config actuelle ou si le routage server ↔ server-nestjs se fait ailleurs.