Nginx reverse proxy faisant de la racine webapp dans un chemin personnalisé

J'essaie d'installer plusieurs conteneurs docker avec la même image sur une seule machine et d'héberger toute l'application sur le même domaine séparé par chemin d'accès. L'objectif est d'isoler chaque client dans son propre conteneur. C'est-à-dire mydomain.com/aaa , mydomain.com/bbb … etc.

J'utilise nginx comme proxy inverse et j'ai suivi différents exemples en ligne. Ma configuration nginx ressemble à:

 server { listen ...; ... location / { proxy_pass http://127.0.0.1:8080; } location /aaa { proxy_pass http://127.0.0.1:8181; } location /bbb { proxy_pass http://127.0.0.1:8282; } ... } 

J'ai remarqué que l'application s'attendait à être hébergée sur la racine / qui se termine actuellement en 404. Existe-t-il un moyen intelligent de réécrire celles-ci dans son propre chemin en fonction de l'origine de la requête sans modifier l'application elle-même?

Je suis conscient qu'il pourrait être plus facile d'utiliser le sous-domaine, mais je veux éviter d'ajouter et de supprimer le sous-domaine lorsque les clients vont et viennent.

La réponse simple est non.

Vous devez considérer au moins trois aspects de forcer une application à vivre loin de la racine.

  • Mapping des URL basées sur la racine dans le nouvel emplacement – ce qui est facile avec proxy_pass ou une rewrite
  • Mapping des réponses de redirection (301, 302, etc.) – ce qui est facile avec proxy_redirect
  • Mappage d'URL de ressources et liens hypertextes intégrés

Le dernier point n'est pas facile. Les applications qui s'attendent à vivre dans la racine, ont généralement accès à leurs ressources par rapport à la racine, ce qui signifie qu'ils atteignent le mauvais emplacement dans le proxy inverse.

Apache a un module qui peut réécrire les URL intégrées dans le document HTML, mais cela me semble plutôt inefficace.

La solution préférée est de changer l'application pour rendre ses URL de ressources et de liens hypertextes soit le chemin relatif ou préfixé avec le même chemin personnalisé.

J'essaie de faire la même configuration, alors j'ai rencontré le même problème. Il me semble qu'il faut changer les applications de backend comme Richard Smith le décrit. L'utilisation de différents ports «extérieurs» pour nginx est une solution de contournement, mais ce n'est pas élégant.