Una explicación de la pila web nginx/starman/dancer

plack

Question

He estado haciendo programación web desde hace un tiempo y estoy bastante familiarizado con la pila LAMP. He decidido intentar jugar con la pila nginx / starman / dancer y estoy un poco confundido acerca de cómo entender, desde un alto nivel, cómo se relacionan todas las piezas entre sí. Configurar la pila no parece tan sencillo como configurar la pila LAMP, pero eso es probablemente porque realmente no entiendo cómo se relacionan las piezas.

Entiendo el papel que está jugando nginx, un servidor web liviano / proxy, pero estoy confundido acerca de cómo starman se relaciona con pgsi, plack y dancer.

Apreciaría un desglose de alto nivel de cómo estas piezas se relacionan entre sí y por qué cada una es necesaria (o no necesaria) para obtener la configuración de la pila. ¡Gracias!

Answer 1

Corrección para la respuesta de :

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

Tuve que eliminar la barra final en la última directiva proxy_pass. Mi versión de nginx (1.10.3) no se iniciará con la barra inclinada.

Answer 2

Desde la wiki de nginx:
"IfIsEvil ... Directivo si tiene problemas cuando se usa en contexto de ubicación, en algunos casos no hace lo que esperas sino que es completamente diferente en su lugar. En algunos casos incluso falla. Generalmente es una buena idea evitarlo si es posible. ... "

Una mejor configuración es:

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/;
}
}

Answer 3

Pasé el último día leyendo sobre los diversos componentes y creo que tengo suficiente comprensión para responder a mi propia pregunta. La mayoría de mi respuesta se puede encontrar en varios lugares de la web, pero espero que tenga algún valor colocar todas las piezas en un solo lugar:

• Nginx: La primera y más obvia pieza de la pila para entender es nginx. Nginx es un servidor web ligero que puede actuar como un reemplazo para el omnipresente servidor web Apache. Nginx también puede actuar como un servidor proxy. Ha estado creciendo rápidamente en su uso y actualmente sirve alrededor del 10% de todos los dominios web. Una ventaja crucial de nginx es que es asíncrono y está orientado a eventos en lugar de crear un subproceso de proceso para manejar cada conexión. En teoría, esto significa que nginx puede manejar una gran cantidad de conexiones sin utilizar muchos recursos del sistema.
• PSGI: PSGI es un protocolo (para distinguirlo de una implementación particular del protocolo, como Plack). La motivación principal para crear PSGI, por lo que puedo deducir, es que cuando Apache se creó por primera vez no había soporte nativo para manejar solicitudes con guiones escritos en, por ejemplo, Perl. La capacidad de hacer esto se agregó a Apache usando mod_cgi. Para probar su aplicación Perl, debería ejecutar todo el servidor web, ya que la aplicación se ejecutó dentro del servidor web. Por el contrario, PSGI proporciona un protocolo con el que un servidor web puede comunicarse con un servidor escrito, por ejemplo, Perl. Una de las ventajas de esto es que es mucho más fácil probar el servidor de Perl independientemente del servidor web. Otra ventaja es que una vez que se crea un servidor de aplicaciones, es muy fácil cambiar en diferentes servidores web compatibles con PSGI para probar cuál proporciona el mejor rendimiento.
• Plack: esta es una implementación particular del protocolo PSGI que proporciona el pegamento entre un servidor web compatible con PSGI y un servidor de aplicaciones perl. Plack es el equivalente de Perl de Ruby''s Rack.
• Starman: un servidor web basado en perl que es compatible con el protocolo PSGI. Una confusión que tuve fue por qué querría usar Starman y Nginx al mismo tiempo, pero afortunadamente esa pregunta fue respondida bastante bien aquí en . La esencia es que podría ser mejor dejar que nginx sirva archivos estáticos sin requerir un proceso de perl para hacerlo, mientras que también permite que el servidor de aplicaciones Perl se ejecute en un puerto más alto.

• Dancer : un marco de aplicación web para Perl. Tipo de un equivalente de Ruby on Rails. O para ser más precisos, un equivalente de Sinatra para Ruby (la diferencia es que Sinatra es un marco minimalista, mientras que Ruby on Rails es un marco web más completo). Como alguien que se ocupó de PHP y no había usado realmente un framework web antes, estaba un poco confundido acerca de cómo esto se relacionaba con la pila de publicación. El objetivo de los marcos web es que resuelvan tareas comunes que se realizan con frecuencia en aplicaciones web, como la conversión de consultas de bases de datos en objetos / estructuras de datos en la aplicación web.

• Instalación (en 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

• Poniéndolo en funcionamiento:

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

Ahora tendrá un servidor Starman ejecutando su aplicación Dancer en el puerto 5001. Para hacer que nginx envíe tráfico al servidor, debe modificar

/etc/nginx/nginx.conf y agrega una regla como esta a la sección http:

server { server_name permanentinvesting.com listen 80; location /css/ { alias /home/ubuntu/mywebapp/public/css/; expires 30d; access_log off; } location / { proxy_pass http://localhost:5001; proxy_set_header X-Real-IP $remote_addr; } }

La primera regla de ubicación especifica que nginx debe manejar el contenido estático en el directorio / css obteniéndolo de

/home/ubuntu/mywebapp/public/css/ . La segunda regla de ubicación dice que el tráfico al servidor web en el puerto 80 se debe enviar al servidor Starman para que lo maneje. Ahora solo tenemos que iniciar nginx:

sudo service nginx start

Answer 4

Su respuesta es correcta hasta ahora, pero sería mejor configurar nginx de la siguiente manera:

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/;
}
}

Esto hace que nginx sirva todos los archivos estáticos (JavaScript e imágenes) y no solo el css.

Este ejemplo está tomado del 2011 Perl Dancer Advent :)