Ça fait beaucoup de questions d'un coup, mais je vais essayer d'y répondre.
Tout d'abord, je me rends compte que ma dépêche pourrait laisser à penser qu'Unicorn est un concurrent d'apache2 ou de nginx. Ce n'est pas le cas, il est utilisé pour du contenu dynamiques, pas pour servir des ressources statiques.
Les mod_* pour apache, ça existe aussi dans le monde Ruby : ça s'appelle phusion passenger. Il existait auparavant un mod_ruby, mais il n'est plus maintenu et personne ne l'utilisait car il avait des performances désastreuses.
Mais ces solutions ne conviennent pas à tout le monde : certains utilisent d'autres serveurs web comme nginx, d'autres vont faire tourner les applications Rails sur plusieurs serveurs et n'ont pas envie de faire tourner apache sur tous ces serveurs, etc. Ces contraintes se rencontrent généralement sur des sites à fort trafic pour lesquels on cherche à séparer les problématiques pour différentes raisons : meilleures performances, plus facile d'isoler les bugs, maintenance plus aisée, etc. Pour arriver à cela, le serveur applicatif va servir des requêtes HTTP dynamiques très rapidement.
On le place derrière un reverse-proxy pour un tas de raisons (sécurité, bufferiser les uploads, etc.) mais surtout pour éviter qu'il ne serve les fichiers statiques (nginx, ou à défaut apache, fait ça bien mieux).
Maintenant, pourquoi utiliser HTTP plutôt que CGI ou FastCGI pour communiquer entre le reverse-proxy et les processus applicatifs ? J'aurais envie de dire que HTTP est un protocole connu qui convient bien pour ça, alors pourquoi utiliser autre chose ?
Pour WSGI, il n'a pas vraiment sa place avec CGI ou fastCGI, c'est une interface pour les applications Python qui définit quelle fonction appeler (et comment) quand une requête HTTP arrive. Sous le capot, ça peut utiliser un mod_ pour apache, du CGI, du fastcgi, etc.
En bref, nous avons quasiment une équivalence un pour un entre le monde Python et le monde Ruby :
mod_python <-> mod_ruby (tous les 2 RIP)
mod_wsgi <-> phusion passenger
wsgi <-> rack
gunicorn <-> unicorn
PS : j'ai pris exemple sur Python, car en dehors de Ruby, c'est ce que je connais de mieux.
PS2 : on a un bonus quand on arrive à caser 3 liens pertinents vers des dépêches LinuxFr.org que l'on a soi-même rédigé dans les 3 derniers mois ?
[^] # Re: éviter de réinventer la roue
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Les pouvoirs magiques d'Unicorn 1.0.0. Évalué à 10.
Tout d'abord, je me rends compte que ma dépêche pourrait laisser à penser qu'Unicorn est un concurrent d'apache2 ou de nginx. Ce n'est pas le cas, il est utilisé pour du contenu dynamiques, pas pour servir des ressources statiques.
Les mod_* pour apache, ça existe aussi dans le monde Ruby : ça s'appelle phusion passenger. Il existait auparavant un mod_ruby, mais il n'est plus maintenu et personne ne l'utilisait car il avait des performances désastreuses.
Mais ces solutions ne conviennent pas à tout le monde : certains utilisent d'autres serveurs web comme nginx, d'autres vont faire tourner les applications Rails sur plusieurs serveurs et n'ont pas envie de faire tourner apache sur tous ces serveurs, etc. Ces contraintes se rencontrent généralement sur des sites à fort trafic pour lesquels on cherche à séparer les problématiques pour différentes raisons : meilleures performances, plus facile d'isoler les bugs, maintenance plus aisée, etc. Pour arriver à cela, le serveur applicatif va servir des requêtes HTTP dynamiques très rapidement.
On le place derrière un reverse-proxy pour un tas de raisons (sécurité, bufferiser les uploads, etc.) mais surtout pour éviter qu'il ne serve les fichiers statiques (nginx, ou à défaut apache, fait ça bien mieux).
Maintenant, pourquoi utiliser HTTP plutôt que CGI ou FastCGI pour communiquer entre le reverse-proxy et les processus applicatifs ? J'aurais envie de dire que HTTP est un protocole connu qui convient bien pour ça, alors pourquoi utiliser autre chose ?
Pour WSGI, il n'a pas vraiment sa place avec CGI ou fastCGI, c'est une interface pour les applications Python qui définit quelle fonction appeler (et comment) quand une requête HTTP arrive. Sous le capot, ça peut utiliser un mod_ pour apache, du CGI, du fastcgi, etc.
En bref, nous avons quasiment une équivalence un pour un entre le monde Python et le monde Ruby :
mod_python <-> mod_ruby (tous les 2 RIP)
mod_wsgi <-> phusion passenger
wsgi <-> rack
gunicorn <-> unicorn
PS : j'ai pris exemple sur Python, car en dehors de Ruby, c'est ce que je connais de mieux.
PS2 : on a un bonus quand on arrive à caser 3 liens pertinents vers des dépêches LinuxFr.org que l'on a soi-même rédigé dans les 3 derniers mois ?