TP 5 : Reverse proxy#

1. Conception#

1.1. Cahier des charges#

Nous allons reprendre une fois de plus l’architecture de l’application Groupomania, que vous avez déjà pratiquée aux TPs précédents.

Les objectifs sont les suivants :

  • Un seul port forwarding : le port 80 de la machine est bind sur le port 80 de nginx

  • Trois noms de domaine :

    • grp.lan → Permet d’accéder au frontend

    • api.grp.lan → Permet d’accéder au backend

    • db.grp.lan → Permet d’accéder au panneau de contrôle de la base de données

1.2. Prérequis#

  • Modifier le Dockerfile du frontend, de manière à ce qu’il pointe sur l’API au travers du domaine

  • Modifier le fichier /etc/hosts de l’hôte en lui ajoutant ces lignes :

127.0.0.1 grp.lan
127.0.0.1 api.grp.lan
127.0.0.1 db.grp.lan

1.3. Nginx#

Nginx est un puissant serveur web, mais c’est également un excellent reverse-proxy.

Indication

Un proxy inverse (reverse proxy) ou serveur mandataire inverse est un type de serveur, habituellement placé en [amont] de serveurs web. Contrairement au serveur proxy qui permet à un utilisateur d’accéder au réseau Internet, le proxy inverse permet à un utilisateur d’Internet d’accéder à des serveurs internes. Une des applications courantes du proxy inverse est la répartition de charge (load-balancing).

D’après Wikipédia

Nous allons ici chercher à l’exploiter de manière à aiguiller les requêtes arrivant dans notre réseau.

Le répertoire de fonctionnement de nginx est /etc/nginx.

Un fichier de configuration nginx a cette forme :

server {
  listen 80;                # Port d'écoute IPv4
  listen [::]:80;           # Port d'écoute IPv6
  server_name example.com;  # Domaine concerné par la règle
  
  # On renvoie tout le traffic en example.com/* sur 192.168.0.1, port 8080
  location / {
    proxy_pass http://192.168.0.1:8080;
  }
  
  # On renvoie seulement le traffic en example.com/media/* sur 192.168.0.2, port 8978
  location /media/ {
    proxy_pass http://192.168.0.2:8978;
  }
}

On enregistre cette configuration dans un fichier example.conf1, que l’on place ensuite dans le répertoire /etc/nginx/conf.d. Nginx le charge alors automatiquement, et s’occupera de rediriger les paquets conformément à la configuration[^2].

Astuce

En pratique, on ajoute quelques headers au moment de faire une redirection, pour la stabiliser et la documenter. Par exemple, l’exemple ici concerné deviendrait :

  location / {
    proxy_pass http://192.168.0.1:8080;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-NginX-Proxy true;
  }

1.4. Architecture#

Nous allons reprendre l’architecture des TP 3 et 4, en leur adjoignant un conteneur nginx qui devra router les requêtes HTTP ainsi :

2. Exercices#

  1. Reprendre la configuration docker-compose du TP 4 et la mettre en conformité avec le cahier des charges

  2. Écrire les configurations nginx pour arriver à un comportement identique au schéma

  3. Monter les configurations dans un conteneur grp_nginx et les tester.

2.1. BONUS#

  1. Que pourrait-on modifier pour améliorer la sécurité de ce déploiement ?

  2. Implémenter ces modifications

1

Par convention, on nomme les fichiers de configuration nginx en fonction du domaine qu’ils concernent, en remplaçant le domaine de premier niveau par l’extension du fichier, .conf. Ainsi, une règle concernant le domaine gitlab.sakiut.fr serait enregistrée dans un fichier gitlab.sakiut.conf.