Une explication de la stack web nginx / starman / dancer

J’ai passé le dernier jour à lire les différentes composantes et je pense avoir assez de compréhension pour répondre à ma propre question. La plupart de mes réponses se trouvent à divers endroits sur le Web, mais nous espérons qu’il sera utile de mettre toutes les pièces en un seul endroit:

• Nginx: Le premier et le plus évident de la stack à comprendre est nginx. Nginx est un serveur Web léger qui peut remplacer le serveur Web Apache omniprésent. Nginx peut également agir en tant que serveur proxy. Son utilisation s’est rapidement développée et dessert actuellement environ 10% de tous les domaines Web. L’un des principaux avantages de nginx est qu’il est asynchrone et axé sur les événements au lieu de créer un thread de processus pour gérer chaque connexion. En théorie, cela signifie que nginx est capable de gérer un grand nombre de connexions sans utiliser beaucoup de ressources système.
• PSGI: PSGI est un protocole (pour le distinguer d’une implémentation particulière du protocole, tel que Plack). La principale motivation pour la création de PSGI, pour autant que je sache, est que lorsque Apache a été créé pour la première fois, il n’y avait pas de support natif pour gérer les requêtes avec des scripts écrits, par exemple, Perl. La possibilité de faire cela a été ajoutée à Apache en utilisant mod_cgi. Pour tester votre application Perl, vous devez exécuter l’intégralité du serveur Web, car l’application est exécutée dans le serveur Web. En revanche, PSGI fournit un protocole avec lequel un serveur Web peut communiquer avec un serveur écrit, par exemple, dans Perl. L’un des avantages est qu’il est beaucoup plus facile de tester le serveur Perl indépendamment du serveur Web. Un autre avantage est qu’une fois qu’un serveur d’applications est construit, il est très facile de basculer dans différents serveurs Web compatibles PSGI pour tester les meilleures performances.
• Plack: Il s’agit d’une implémentation particulière du protocole PSGI qui fournit le lien entre un serveur Web compatible PSGI et un serveur d’application perl. Plack est l’équivalent de Perl de Ruby’s Rack.
• Starman: un serveur Web basé sur Perl compatible avec le protocole PSGI. Une des confusions que j’ai eue était la raison pour laquelle je voudrais utiliser les deux Starman et Nginx en même temps, mais heureusement, cette question a été très bien traitée ici sur Stackoverflow. L’essentiel est qu’il serait préférable de laisser nginx servir des fichiers statiques sans avoir besoin d’un processus de perl pour cela, tout en permettant également au serveur d’application perl de s’exécuter sur un port supérieur.

• Dancer : Un framework d’application web pour Perl. Genre d’équivalent de Ruby on Rails. Ou plus précisément, un équivalent de Sinatra pour Ruby (la différence est que Sinatra est un framework minimaliste, alors que Ruby on Rails est un framework Web plus complet). En tant que personne qui traitait avec PHP et n’avait pas vraiment utilisé de framework Web auparavant, j’étais un peu confus quant à la manière dont cela se rapportait à la stack de serveurs. Le but des frameworks Web est de faire abstraction des tâches courantes très fréquemment effectuées dans les applications Web, telles que la conversion de requêtes de firebase database en objects / structures de données dans l’application Web.

• Installation (sur Ubuntu):

     sudo apt-get install nginx
     sudo apt-get install build-essential curl
     sudo cpan App :: cpanminus
     sudo cpanm Starman
     sudo cpanm Task :: Plack
     sudo apt-get install libdancer-perl

• Le faire fonctionner:

 CD
 danseuse -a mywebapp
 sudo plackup -s Starman -p 5001 -E deployment --workers = 10 -a mywebapp / bin / app.pl

Maintenant, vous aurez un serveur starman exécutant votre application Dancer sur le port 5001. Pour que nginx envoie du trafic vers le serveur, vous devez modifier

  /etc/nginx/nginx.conf 

et append une règle quelque chose comme ceci à la section http:

         serveur {
                nom_serveur permanentinvesting.com
                écouter 80;

                 location / css / {
                   alias / home / ubuntu / mywebapp / public / css /;
                   expire 30d;
                   access_log off;
                 }



                emplacement / {
                   proxy_pass http: // localhost: 5001;
                   proxy_set_header X-Real-IP $ remote_addr;
                 }

         }

La première règle de localisation spécifie que nginx doit gérer le contenu statique du répertoire / css en le récupérant

  / home / ubuntu / mywebapp / public / css / 

. La seconde règle d’emplacement indique que le trafic vers le serveur Web sur le port 80 doit être envoyé au serveur Starman pour qu’il le gère. Maintenant, il suffit de lancer nginx:

 sudo service nginx start

Votre réponse est correcte jusqu’à présent, mais il serait préférable de configurer nginx de la manière suivante:

server { listen 80; server_name foo.example.com; location / { # Serve static files directly: if (-f $request_filename) { expires 30d; break; } # Pass on other requests to Dancer app proxy_pass_header Server; proxy_pass http://localhost:5001/; } } 

Ceci permet à nginx de servir tous les fichiers statiques (JavaScript et images) et pas seulement le css.

Cet exemple est tiré de 2011 Perl Dancer Advent 🙂

Depuis le wiki nginx:
“IfIsEvil … Directive si a des problèmes lorsqu’elle est utilisée dans un contexte de localisation, dans certains cas, elle ne fait pas ce que vous attendez mais quelque chose de complètement différent. … ”

Une meilleure configuration est la suivante:

 server { listen 80; server_name foo.example.com; location / { # Checks the existence of files and uses the first match try_files $uri $uri/ @dancer; } location @dancer { # Pass on other requests to Dancer app proxy_pass_header Server; proxy_pass http://localhost:5001/; } } 

Correction pour la réponse de s.magri :

 location @dancer { # Pass on other requests to Dancer app proxy_pass_header Server; proxy_pass http://localhost:5001; } 

J’ai dû supprimer la barre oblique finale dans la dernière directive proxy_pass. Ma version de nginx (1.10.3) ne démarrera pas avec la barre oblique finale.