Quelle est la responsabilité de l’application ngnix ou apache in rails?

Comment fonctionnent les applications de rails? Disons que nous avons nginx + passenger + Ubuntu, donc mes questions sont:

  • Qu’est-ce que nginx fait réellement?
  • Comment transfère-t-il les demandes à l’application rails?
  • Quelle est la responsabilité du passager?
  • Et qu’est ce que le rack?
  • Comment l’application rails peut-elle fonctionner sur webrick sans apache?

S’il vous plaît ne me donne pas des réponses comme ” nginx traite les demandes “; J’ai besoin de quelque chose de plus, ou peut-être connaissez-vous la source où je peux lire à ce sujet.

Phusion Passenger author here. Je pense que ces deux documents expliquent la plupart de vos questions en détail.

  • Options de serveur Ruby on Rails – Comment sont liés Rails, Apache / Nginx, Passenger, Capistrano et autres?
  • Aperçu architectural de Phusion Passenger

Comme pour Rack: c’est une interface standardisée. Différents serveurs Web ont tendance à avoir des API différentes pour les applications dynamics. Afin d’éviter d’avoir à chaque framework Ruby à écrire un adaptateur pour chaque serveur, tous les frameworks Ruby implémentent tous l’interface Rack. Tous les serveurs, à leur tour, parlent également Rack. Cela vous permet de basculer entre les différents serveurs sans avoir besoin de la structure pour avoir un support spécial pour ce serveur, et vous permet de basculer entre les différentes infrastructures sans que le serveur ait besoin d’un support spécial pour cette infrastructure.

Comment WEBRick sert-il Rails? Lorsque vous démarrez WEBrick, il ouvre un socket TCP sur un port et écoute les connexions. Lorsqu’une nouvelle connexion arrive, elle parsing les données en tant que HTTP, crée des structures de données internes et transmet ces structures de données à Rails en appelant l’object Rails Rack. L’object Rails Rack est le principal point d’entrée dans Rails et est créé lors du démarrage du programme. Lorsque l’object Rack est renvoyé, WEBrick convertit les structures de données renvoyées en données HTTP et les écrit sur le socket.

Cette description de haut niveau décrit à peu près comment fonctionne chaque serveur Ruby. Phusion Passenger fonctionne également à un niveau élevé, mais la gestion des processus, l’équilibrage de la charge, la vérification de la sécurité, etc. bibliothèque en cours de processus. Le document de synthèse sur l’architecture de Phusion Passenger l’explique.

Cela aidera à comprendre l’histoire de cette façon:

Il y a longtemps, lorsque le Web était nouveau, il n’y avait que des pages statiques – juste des pages .html . Ainsi, un logiciel de serveur Web lirait efficacement un fichier et enverrait le contenu du fichier au demandeur (un navigateur).

Puis vint le web dynamic. Ici, le contenu de la page devait être généré dynamicment à la volée, en réponse à la demande. Cela signifiait qu’il devait y avoir un programme en cours d’exécution sur le serveur, qui comprenait ce qui était demandé et ce qui devrait être utilisé comme réponse. Cela a entraîné la naissance de CGI (Common Gateway Interface) . Au lieu de lire un fichier .html et d’envoyer son contenu au client, vous exécutez maintenant un programme CGI sur le serveur qui va extraire le fichier html qui peut être envoyé au demandeur. Ces scripts CGI peuvent être écrits dans différents langages de programmation.

Compte tenu de la complexité croissante des scripts CGI, il était nécessaire de disposer d’applications d’assistance spécialisées qui éliminent toute la logique commune (et mécanique). Cela simplifierait l’écriture de la logique métier. Ces assistants spécialisés sont généralement appelés application servers ou containers .

Ces conteneurs aident également à garder le serveur Web simple et léger, car la complexité de l’exécution d’un script cgi (quel que soit le langage de programmation dans lequel il a été écrit) est maintenant déléguée du serveur Web. Tout ce que le serveur Web doit savoir, c’est que si l’url de requête se termine par un .php , il devrait alors déléguer la demande à FASTCGI , ou si l’URI commence par /javaapp/ alors /javaapp/ le à tomcat etc. comme APP SERVERS ou Container

Passenger, est un tel conteneur, conçu pour exécuter une application RACK.

Qu’est-ce que Rack: vous pouvez dire que Rack est une interface standardisée pour que le conteneur charge une application (telle qu’une application Rails), tout comme CGI est une interface standardisée permettant au serveur Web d’exécuter un programme externe.

Rack définit une interface standard pour les frameworks d’application (rails, merb, sinatra etc.). Si une infrastructure d’application est conforme à l’interface de rack, le container sait comment le charger et l’exécuter.

Remarque:

J’ai essayé de simplifier les concepts pour vous. Ce n’est pas plus proche d’être une explication complète. J’espère que c’est assez bon pour vous initier à l’auto-apprentissage.