Una aplicación web que genera contenido dinámico requiere dos componentes:
Ejemplos de software
Los servidores web y los servidores de aplicaciones funcionan juntos como componentes en aplicaciones web típicas.
Correr rieles en producción
Cuando se ejecuta una aplicación de Rails en producción usando Passenger, algunas opciones incluyen:
Correr rieles en desarrollo
Cuando se ejecuta una aplicación de Rails en desarrollo, está configurada para usar Puma de forma predeterminada; consulte Ruby Docs . Puma es un servidor de aplicaciones. ¿Cómo es que por defecto, en Rails, Puma puede ejecutar por sí solo toda la aplicación web? No se menciona un servidor web como Nginx o Apache en la pila de aplicaciones.
No entiendo cómo esto es posible. ¿Puede alguien por favor explicar esto? Puma siempre ha sido un servidor de aplicaciones, no un servidor web...
Gracias por adelantado.
La distinción entre un "servidor web" y un "servidor de aplicaciones" es bastante confusa y tiene mucho bagaje implícito (y en su mayoría histórico).
Generalmente, un servidor web se entiende como un software que se comunica a través de HTTP (o HTTPS) con los clientes y envía archivos estáticos como respuesta a las solicitudes.
Un servidor de aplicaciones, por otro lado, a menudo no se comunica directamente con los clientes (sino con los sistemas de servidores intermedios frente a él, como los equilibradores de carga, los servidores proxy o, bueno, los servidores web) y su función principal es responder a las solicitudes con generado dinámicamente. contenido. Los servidores de aplicaciones a veces se comunican con esos servidores intermedios mediante protocolos distintos de HTTP, como FCGI o AJP.
A menudo, veremos servidores web clásicos (como nginx, Apache, lighttpd) utilizados junto con un servidor de aplicaciones como Puma, Unicorn, Thin o Passenger. La razón de esto es que esos servidores web son más eficientes en el servicio de archivos estáticos que los servidores de aplicaciones, que están más orientados a ayudar a la aplicación a generar respuestas dinámicas. Además, los servidores web pueden ser más adecuados que los servidores de aplicaciones para almacenar en búfer las solicitudes y respuestas de los clientes sin usar muchos recursos.
Dicho esto, en las últimas dos décadas, se volvió cada vez más común usar HTTP en todas partes en lugar de usar, por ejemplo, FCGI internamente. Por lo tanto, los servidores de aplicaciones generalmente pueden hablar con los clientes HTTP por sí mismos sin requerir estrictamente un servidor web adicional. A menudo, estos servidores de aplicaciones también pueden servir archivos estáticos directamente y, por lo tanto, también pueden asumir la mayoría de las funciones de un servidor web.
Sin embargo, como se escribió anteriormente, la mayoría de los servidores web son mucho más rápidos y escalables cuando sirven archivos estáticos. Además, algunos servidores de aplicaciones, como Unicorn, no están destinados a estar expuestos a los clientes directamente, ya que Unicorn no almacena en búfer las solicitudes y las respuestas de manera eficiente. En cambio, confían en un servidor frontend como nginx para eso.
Por lo tanto, como conclusión: la mayoría de los servidores de aplicaciones Ruby se pueden usar directamente sin un servidor web. Con, por ejemplo, Puma, esto funcionará bastante bien. Para brindar un servicio más eficiente a los activos estáticos, o para equilibrar la carga o proteger su aplicación, también puede introducir un servidor web/proxy frente a su servidor de aplicaciones, como nginx o Apache.