NGINX et Angular

Comme vous avez appris cette semaine, Ezo s’apprête à mettre en production une application qui, espérons-le, finira par changer le monde de la psychologie. Lors de la préparation du déploiement, nous avons rencontré plusieurs problèmes d’architecture quand nous sommes passés d’une application Angular tournant sur Webpack à une ferme de serveurs dans un cloud. Aujourd’hui, je vous présente comment on configure nginx comme proxy inversé devant plusieurs applications Angular et un backend.

La problématique

Angular et les SPAs (single page applications ou applications monopages) favorisent l’architecture en services. Peu importe l’implémentation (micro, avec bus de services, etc.), nous nous retrouvons avec des frontends de plus en plus lourds. Il n’est donc pas rare de voir des applications séparées en modules déployés comme des applications indépendantes, comme par exemple :

Module d’authentification
Module client
Module d’administration ou pilotage
APIs
etc.

Lorsque ce genre de système distribué est déployé dans une architecture infonuagique avec un orchestrateur comme Kubernetes ou celui de la plateforme cloud de Google, chacune de ces applications doit être clonable, donc gagne à être de la plus petite taille possible.

Pour faire en sorte que ce soit le plus transparent possible pour l’utilisateur, on utilise généralement un proxy inversé pour rediriger les requêtes vers des instances de serveurs différentes en se basant sur un contexte dans l’URL (ex. : myapp/context/page ). nginx fait ça pour nous :Là où ça se complique, c’est lorsqu’on est en développement sur nos machines, en localhost, et qu’on utilise Angular. Webpack ne sera pas utilisé en production, mais plutôt un serveur statique comme Apache ou superstatic derrière un proxy inverse. Essayons…

La solution

Une solution parmi tant d’autres est d’installer nginx localement, puis de démarrer les différentes instances sur des ports différents. Ensuite, nginx doit être configuré pour rediriger les requêtes vers le bon port selon de contexte d’application dans l’URL, ce qu’on appelle proxy pass.

location /auth/ {
    proxy_pass http://127.0.0.1:4200/;
}

location /app/ {
    proxy_pass http://127.0.0.1:4001/;
}

location /api {
    proxy_pass http://127.0.0.1:3000;
}

location /auth/ {

proxy_pass http://127.0.0.1:4200/;

}

location /app/ {

proxy_pass http://127.0.0.1:4001/;

}

location /api {

proxy_pass http://127.0.0.1:3000;

}

(le fichier de configuration se trouve dans le dossier de nginx, sous conf/nginx.conf)

J’attire votre attention sur cette subtilité. Dans l’exemple ci-dessus, /auth/ et /app/ pointent vers le port des instances, mais remarquez la barre oblique à la fin de l’URL du proxy_pass . Ceci va faire en sorte que /auth/ ou /app/ ne seront pas transmis vers l’instance. Par exemple :

https://myapp/auth/section/page -> http://127.0.0.1:4200/section/page

https://myapp/api/section/action -> http://127.0.0.1:3000/api/section/action

Puis, au niveau d’Angular, ils faut configurer le contexte afin qu’il soit ignoré par le routage. Angular nous permet de faire ceci grâce à la balise html <base> dans le <head> .

<base href="/auth/">

1	<base href="/auth/">

Vous pouvez aussi définir cette balise à la compilation avec Angular cli en exécutant :

ng build --prod --base-href /auth/

1	ng build --prod --base-href /auth/

Pourquoi

Plusieurs raisons font en sorte qu’on pourrait vouloir un proxy inverse devant ses différentes instances, mais la principale réside dans le fait que le numéro de port est considéré comme faisant partie intégrante du domaine. Donc, si vous utilisez des cookies, ils ne seront valides que pour une seule instance. Le même problème arrive avec le session storage du navigateur.

Par contre, vous perdrez le rafraîchissement automatique du navigateur de SockJS intégré à webpack. Il est possible de configurer nginx pour laisser passer ce genre de requête.

Conclusion

Aujourd’hui, vous avez appris à configurer un proxy inversé localement pour router les requêtes vers plusieurs instances différentes constituant un système distribué. Vous avez aussi appris configurer Angular pour lui définir un contexte d’application dans l’URL afin de permettre aux différentes applications de partager de l’information via les cookies ou le session storage du navigateur.

N’hésitez pas à partager nos articles avec vos collègues et amis! Je vous invite aussi à lire cet article pour en savoir un peu plus sur angular cli. De plus, si vous vous sentez généreux, vous pouvez faire un don à Ezo afin de nous encourager à continuer à produire du contenu gratuit et sans publicité pour notre merveilleuse communauté de développeurs québécois 🙂

Cheers 🍺

Partager sur Facebook

Partager sur Twitter

60

SHARES

Écrit par

Sylvain Cloutier

Tags

Laisser un commentaire

Annuler la réponse.

Catégories

Suivez-nous par courriel!

Publications récentes

Ce qu’on dit sur Twitter