Pourquoi Unicorn doit-il être déployé avec Nginx?


138

J'aimerais connaître la différence entre Nginx et Unicorn. Pour autant que je sache, Nginx est un serveur Web tandis que Unicorn est un serveur HTTP Ruby.

Étant donné que Nginx et Unicorn peuvent gérer les requêtes HTTP, quel est le besoin d'utiliser la combinaison de Nginx et Unicorn pour les applications RoR?


3
Bonne question ! Je pense que le titre de cette question devrait être: "Pourquoi nous avons besoin de la combinaison de nginx et de licorne.;) Les réponses ont été très utiles pour moi.
servatj

1
@servatj J'ai ajouté une réponse qui explique plus en détail pourquoi Unicorn a besoin d'un proxy inverse comme Nginx devant lui. Vous voudrez peut-être vérifier;)
Agis

Réponses:


62

Nginx
entrez la description de l'image ici
Unicorn
entrez la description de l'image ici
Référez-vous à unicorn sur github pour plus d'informations.


1
Pratik, Ma question est que le serveur licorne peut servir à la fois un processus statique et dynamique, alors pourquoi nous utilisons NGinx ou Apache ceux-ci peuvent traiter le seul contenu statique, en combinaison avec le passager ou la licorne ou mod_php?
loganathan

17
@loganathan, Apache et Nginx sont beaucoup plus rapides à servir du contenu statique que ruby ​​ou l'un des serveurs d'applications. Ils savent également comment gérer la mise en cache et sont capables d'autoriser les téléchargements de fichiers simultanés tout en continuant à absorber le trafic et à le transmettre aux serveurs d'applications.
Pratik

4
De plus, si vous avez de grandes quantités de données à venir, nginx les mettra en mémoire tampon (et alimentera) le client. Sans nginx, l'une de vos licornes sera bloquée lors des chargements / téléchargements.
BraveNewCurrency

10
Cela ne répond pas du tout à la question de savoir pourquoi nginx est nécessaire. Il le met simplement dans les deux images sans aucun commentaire. La réponse de Nick est bien meilleure.
gorn

1
Je suis d'accord avec @gorn. Cela ne signifiait rien pour moi, par exemple.
BalinKingOfMoria réintègre les CM

94

Nginx est un serveur Web pur destiné à servir du contenu statique et / ou à rediriger la demande vers un autre socket pour gérer la demande.

Unicorn est un serveur Web Rack et est uniquement destiné à héberger une «Application Rack» qui génère généralement du contenu dynamique. Les applications en rack peuvent également servir du contenu statique, mais il est moins efficace que la plupart des autres serveurs Web traditionnels.

La plupart des configurations RoR utilisent une combinaison de serveurs Web traditionnels et de serveurs rack pour appliquer le meilleur de leurs deux capacités. Nginx est incroyablement rapide à la redirection de demande via l'équilibrage de proxy et la diffusion de contenu statique. Unicorn est tout à fait capable de traiter les en-têtes HTTP et d'équilibrer les requêtes entrantes vers Ruby pour le traitement.


73

Cette réponse est complémentaire des autres et explique pourquoi Unicorn a besoin de nginx devant elle .

TL; DR La raison pour laquelle Unicorn est généralement déployé avec un proxy inverse comme nginx est que ses créateurs l'ont délibérément conçu ainsi, faisant un compromis pour la simplicité.

Tout d'abord, rien ne vous empêche de déployer Unicorn sans proxy inverse. Cependant, ce ne serait pas une très bonne idée; voyons pourquoi.

Unicorn suit la philosophie Unix qui est de faire une chose et de bien la faire , à savoir servir des clients rapides et à faible latence (nous verrons ce que cela signifie plus tard). Le fait que Unicorn soit conçu pour les clients rapides et à faible latence implique également que ce n'est pas très bon avec les clients lents et à latence élevée , ce qui est en effet vrai. C'est l'un des points faibles de Unicorn et c'est là qu'un proxy inverse entre en jeu: il se trouve devant Unicorn et s'occupe de ces clients lents (nous verrons comment plus tard).

Heureusement, un tel proxy inverse existe déjà et s'appelle nginx .

La décision de ne gérer que les clients rapides, simplifie grandement la conception de Unicorn et permet une base de code beaucoup plus simple et plus petite, au prix d'une complexité supplémentaire sur le département de déploiement (c'est-à-dire que vous devez également déployer nginx en plus de Unicorn).

Une autre décision pourrait être de concevoir Unicorn de manière à ne pas avoir besoin d'un proxy inverse. Cependant, cela signifie qu'il devrait implémenter des fonctionnalités supplémentaires pour faire tout ce que fait maintenant nginx, ce qui entraîne une base de code plus complexe et plus d'efforts d'ingénierie.

Au lieu de cela, ses créateurs ont pris la décision de tirer parti des logiciels existants qui sont testés au combat et très bien conçus et d'éviter de perdre du temps et de l'énergie sur des problèmes déjà résolus par d'autres logiciels.

Mais soyons techniques et répondons à votre question:

Pourquoi Unicorn doit-il être déployé avec nginx?

Voici quelques-unes des principales raisons:

Unicorn utilise des E / S bloquantes pour les clients

S'appuyer sur un proxy inverse signifie que Unicorn n'a pas besoin d'utiliser des E / S non bloquantes. Au lieu de cela, il peut utiliser des E / S de blocage, ce qui est par nature plus simple et plus facile à suivre pour le programmeur.

Également comme l' indique le document DESIGN :

[Utiliser des E / S bloquantes] permet de suivre un chemin de code plus simple dans l'interpréteur Ruby et moins d'appels système.

Cependant, cela a également des conséquences:

Point clé n ° 1: Unicorn n'est pas efficace avec les clients lents

(Par souci de simplicité, nous supposons une configuration avec 1 ouvrier Licorne)

Étant donné que le blocage des E / S est utilisé, un worker Unicorn ne peut servir qu'un client à la fois , donc un client lent (c'est-à-dire un avec une connexion lente) garderait effectivement le travailleur occupé plus longtemps (qu'un client rapide le ferait) ). En attendant, les autres clients attendraient simplement que le travailleur soit à nouveau libre (c'est-à-dire que les demandes s'accumulaient dans la file d'attente).

Pour contourner ce problème, un proxy inverse est déployé devant Unicorn, qui met complètement en mémoire tampon les demandes entrantes et  les réponses de l'application, puis envoie chacune d'elles  à la fois (c'est-à-dire les nourrit à la cuillère) à Unicorn et aux clients, respectivement. À cet égard, on pourrait dire que le proxy inverse «protège» Unicorn des clients réseau lents.

Heureusement, Nginx est un excellent candidat pour ce rôle, car il est conçu pour gérer efficacement des milliers de centaines de clients simultanés.

Il est d'une importance cruciale que le proxy inverse se trouve dans le même réseau local que Unicorn (généralement dans la même machine physique communiquant avec Unicorn via un socket de domaine Unix), afin que la latence du réseau soit réduite au minimum.

Ainsi, un tel proxy joue efficacement le rôle d'un client rapide  qu'Unicorn est conçu pour servir en premier lieu, car il transmet rapidement les demandes à Unicorn et maintient les travailleurs occupés pendant le laps de temps le plus court possible (par rapport au temps passé par un client. avec une connexion lente ferait).

Point clé n ° 2: Unicorn ne prend pas en charge HTTP / 1.1 keep-alive

Étant donné que Unicorn utilise des E / S bloquantes, cela signifie également qu'il ne peut pas prendre en charge la fonction de maintien en vie HTTP / 1.1, car les connexions persistantes des clients lents occuperaient rapidement tous les travailleurs Unicorn disponibles.

Par conséquent, pour tirer parti de HTTP keep-alive, devinez quoi: un proxy inverse est utilisé.

nginx, d'autre part, peut gérer des milliers de connexions simultanées en utilisant seulement quelques threads. Par conséquent, il n'a pas les limites de concurrence qu'un serveur comme Unicorn a (qui se limite essentiellement à la quantité de processus de travail), ce qui signifie qu'il peut très bien gérer les connexions persistantes. Vous trouverez plus d'informations sur la façon dont cela fonctionne réellement ici .

C'est pourquoi nginx accepte les connexions persistantes des clients et les met en proxy à Unicorn via des connexions simples via généralement un socket Unix.

Point n ° 3: Unicorn n'est pas très bon pour servir des fichiers statiques

Encore une fois, servir des fichiers statiques est une chose que Unicorn peut faire mais n'est pas conçue pour le faire efficacement.

D'un autre côté, les proxys inverses comme nginx sont bien plus performants (c'est-à-dire sendfile(2)et la mise en cache).

Plus

Il y a d'autres points qui sont décrits dans le document PHILOSOPHY (voir «Amélioration des performances grâce au proxy inverse» ).

Voir également certaines des fonctionnalités de base de nginx .

Nous voyons qu'en tirant parti des logiciels existants (c.-à-d. Nginx) et en suivant la philosophie Unix de «faire une chose et bien le faire», Unicorn est capable de suivre une conception et une implémentation plus simples tout en restant efficace pour servir les applications Rack (par exemple. votre application Rails).

Pour plus d'informations, reportez-vous à la philosophie et aux documents de conception de Unicorn qui expliquent plus en détail les choix derrière la conception de Unicorn et pourquoi nginx est considéré comme un bon proxy inverse pour Unicorn.


Mais pourquoi ne pas simplement utiliser Nginx, je pense qu'il demandait, pas «pourquoi la licorne a-t-elle besoin de nginx». Que fournit Unicorn que Nginx ne fournit pas, par exemple?
omikes

3
@oMiKeY Si tel est le cas, je pense que les autres réponses répondent assez bien à cette question. Je pense toujours que ma réponse fournit des informations utiles pour quiconque essaie de comprendre la combinaison de nginx et de licorne.
Agis

2
C'est de l'or pur. Je vous remercie!
Magne

14

Nginx peut être utilisé pour servir des clients lents sur un serveur licorne, car les clients lents étrangleraient le serveur licorne. Nginx est utilisé comme une sorte de proxy mettant en mémoire tampon toutes les demandes et réponses aux clients lents.

Voir http://unicorn.bogomips.org/

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.