Discours sur le proxy inverse et HTTPS

J’ai fait fonctionner Apache2 « sans problème » dans un environnement de test, avec Apache2 agissant comme proxy inverse vers un socket Unix dans le conteneur :

La seule différence que j’ai constatée (note : seulement quelques heures de tests, rien de complet) était :

  • Apache2 ne fonctionne pas avec un lien symbolique pointant vers le socket Unix dans le volume partagé du conteneur ;
  • Apache2 était légèrement plus lent lors d’un test approximatif, mais pas de beaucoup.

Personnellement, je ne suis pas fan des guerres religieuses autour des technologies ; je ne partage donc pas l’avis selon lequel « Apache2 vous causera beaucoup de problèmes ». Je n’ai rencontré aucun problème négatif avec Apache2 lors de mes tests.

Voici la configuration de base que j’ai utilisée avec Apache2 (HTTP, qui fonctionnait parfaitement avec LETSENCRYPT, au passage) :

# cat discourse.example.conf
<VirtualHost *:80>
  ServerAdmin webmaster@localhost
  ServerName  discourse.example.com
  DocumentRoot /website/discourse

  RewriteEngine On
  ProxyPreserveHost On
  ProxyRequests Off
  ProxyPass / unix:/var/discourse/shared/socket-only/nginx.http.sock|http://localhost/
  ProxyPassReverse  / unix:/var/discourse/shared/socket-only/nginx.http.sock|http://localhost/
  ErrorLog /var/log/apache2/discourse.error.log
  LogLevel warn
  CustomLog /var/log/apache2/discourse.access.log combined

  RewriteCond %{SERVER_NAME} =discourse.example.com
  RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>

Note : La seule fois où nous avons rencontré des problèmes avec la diffusion de contenu HTTP même lorsque force_https était activé, c’était lorsque des fichiers manquaient dans le répertoire /uploads, mais cela (bien sûr) n’a aucun lien avec le choix entre Apache2 et nginx en tant que proxy inverse.