Le 13/01/18 à 13:31, "Ph. Gras" <[email protected]> a écrit : PG> L'objectif du reverse proxy est de faire servir les fichiers statiques PG> (js, jpeg et autres) par l'un des serveurs, et les fichiers dynamiques PG> (php) par l'autre.
Pas forcément, y'a plein d'autres usages pertinents. Ça peut être par ex pour avoir du https (éventuellement en http/2) sur le frontal (reverse proxy), puis tout le reste en http 1.1 sur le lan. Ça peut aussi être pour sécuriser un peu mieux une appli un peu trop laxiste, dont on préfère ne pas modifier les réglages (sinon autant le faire sur le serveur de l'appli directement), par ex interdire l'accès à une partie admin depuis le net (ça ne pourra se faire que depuis le lan). J'utilise depuis longtemps l'archi suivante - frontal nginx en https (http/2) => varnish sur le lan pour mettre en cache le statique => backends divers ayant leur serveur http Ça permet de gérer les certificats sur moins de machines, et changer de backend(s) simplement (ou en démarre un nouveau, lui envoie des requêtes et vérifie que tout va bien, en cas de pb revenir à l'ancien qu'on a pas encore coupé est instantané). Mais c'est pas forcément pertinent dans tous les cas, pour qq applis autant mettre le serveur web des applis directement sur le net (éventuellement avec du nat) plutôt que de maintenir 2 serveurs http. -- Daniel Il est difficile d'attraper un chat noir dans une pièce sombre, surtout lorsqu'il n'y est pas. Proverbe Chinois
