El paso a paso o código que encontrarás en este post es la resolución más eficiente y efectiva que encontramos a tu duda o problema.
Solución:
Nginx es un servidor web puro diseñado para servir static contenido y / o redirigir la solicitud a otro socket para manejar la solicitud.
Unicorn es un servidor web de Rack y solo está destinado a alojar una ‘Aplicación de Rack’ que generalmente genera contenido dinámico. Las aplicaciones de rack también pueden servir static contenido, pero es menos eficiente que la mayoría de los otros servidores web tradicionales.
La mayoría de las configuraciones de RoR utilizan una combinación de servidores web tradicionales y servidores Rack para aplicar lo mejor de ambas capacidades. Nginx es increíblemente rápido en la redirección de solicitudes a través del equilibrio de proxy y la prestación de servicios static contenido. Unicorn es bastante capaz de procesar encabezados HTTP y equilibrar las solicitudes entrantes a Ruby para su procesamiento.
Esta respuesta es complementaria a las demás y explica por qué Unicorn necesita nginx frente a él.
TL; DR La razón por la que Unicorn generalmente se implementa junto con un proxy inverso como nginx es porque sus creadores lo diseñaron deliberadamente así, haciendo una compensación por la simplicidad.
En primer lugar, no hay nada que le impida implementar Unicorn sin un proxy inverso. Sin embargo, eso no sería una muy buena idea; veamos por qué.
Unicorn sigue la filosofía de Unix que es Haz una cosa y hazla bien, y eso es servir clientes rápidos y de baja latencia (veremos qué significa esto más adelante). El hecho de que Unicorn está diseñado para clientes rápidos y de baja latencia también implica que no es muy bueno con clientes lentos y de alta latencia, que es de hecho true. Este es uno de los puntos débiles de Unicorn y es donde entra en juego un proxy inverso: se sienta frente a Unicorn y se encarga de esos clientes lentos (ya veremos cómo mas tarde).
Afortunadamente, ese proxy inverso ya existe y se llama nginx.
La decisión de manejar solo clientes rápidos simplifica enormemente el diseño de Unicorn y permite una base de código mucho más simple y pequeña, a costa de una complejidad adicional en el departamento de implementación (es decir, también debe implementar nginx además de Unicorn).
Una decisión alternativa podría ser diseñar Unicorn de tal manera que no necesite un proxy inverso. Sin embargo, esto significa que tendría que implementar una funcionalidad adicional para hacer todas las cosas que hace ahora nginx, lo que da como resultado una base de código más compleja y más esfuerzos de ingeniería.
En cambio, sus creadores tomaron la decisión de aprovechar el software existente que está probado en batalla y muy bien diseñado y para evitar perder tiempo y energía en problemas ya resueltos por otro software.
Pero seamos técnicos y respondamos tu pregunta:
¿Por qué es necesario implementar Unicorn junto con nginx?
Éstos son algunos de los key razones:
Unicorn usa bloqueo de E / S para clientes
Depender de un proxy inverso significa que Unicorn no necesitar para utilizar E / S sin bloqueo. En su lugar, puede usar el bloqueo de E / S, que es inherentemente más simple y más fácil de seguir para el programador.
También como dice el documento de DISEÑO:
[Using blocking I/O] permite seguir una ruta de código más simple dentro del intérprete de Ruby y menos llamadas al sistema.
Sin embargo, esto también tiene algunas consecuencias:
Punto clave n. ° 1: Unicorn no es eficiente con clientes lentos
(En aras de la simplicidad, asumimos una configuración con 1 trabajador Unicornio)
Dado que se utiliza el bloqueo de E / S, un trabajador Unicornio solo puede atender a un cliente a la vez, por lo que un cliente lento (es decir, uno con una conexión lenta) mantendría al trabajador ocupado durante más tiempo (de lo que lo haría un cliente rápido). Mientras tanto, los otros clientes simplemente esperarían hasta que el trabajador esté libre nuevamente (es decir, las solicitudes se acumularían en la cola).
Para solucionar este problema, se implementa un proxy inverso frente a Unicorn, que amortigua completamente solicitudes entrantes y las respuestas de la aplicación, y luego envía cada una de ellas En seguida (también conocido como los alimenta con cuchara) a Unicorn y a los clientes, respectivamente. En ese sentido, se podría decir que el proxy inverso “protege” a Unicorn de los clientes lentos de la red.
Afortunadamente, Nginx es un gran candidato para este rol, ya que está diseñado para manejar miles de cientos de clientes concurrentes de manera eficiente.
Es de crucial importancia que el proxy inverso esté dentro de la misma red local que Unicorn (normalmente en la misma máquina física que se comunica con Unicorn a través de un socket de dominio Unix), para que la latencia de la red se mantenga al mínimo.
De modo que tal proxy desempeña efectivamente el papel de un cliente rapido que Unicorn está diseñado para servir en primer lugar, ya que envía solicitudes a Unicorn rápido y mantiene ocupados a los trabajadores durante el menor tiempo posible (en comparación con el tiempo que tardaría un cliente con una conexión lenta).
Punto clave n. ° 2: Unicorn no admite HTTP / 1.1 Keep-Alive
Dado que Unicorn usa bloqueo de E / S, también significa que no puede admitir la función de mantener vivo HTTP / 1.1, ya que las conexiones persistentes de clientes lentos ocuparían rápidamente a todos los trabajadores de Unicorn disponibles.
Por lo tanto, para aprovechar HTTP Keep-Alive, adivine qué: se usa un proxy inverso.
nginx, por otro lado, puede manejar miles de conexiones concurrentes usando solo unos pocos subprocesos. Por lo tanto, no tiene los límites de simultaneidad que tiene un servidor como Unicorn (que esencialmente se limita a la cantidad de procesos de trabajo), lo que significa que puede manejar conexiones persistentes sin problemas. Puede encontrar más información sobre cómo funciona esto aquí.
Es por eso que nginx acepta conexiones de mantenimiento de la vida de los clientes y las envía a Unicorn a través de conexiones simples a través de un socket Unix.
Punto # 3: El unicornio no es muy bueno para servir. static archivos
De nuevo, sirviendo static archivos es una cosa que Unicornio pueden hacer, pero no está diseñado para hacerlo de manera eficiente.
Por otro lado, los proxies inversos como nginx son mucho mejores en eso (es decir. sendfile(2) y almacenamiento en caché).
Más
Hay otros puntos que se describen en el documento FILOSOFÍA (ver “Rendimiento mejorado a través del proxy inverso”).
Consulte también algunas de las funciones básicas de nginx.
Vemos que al aprovechar el software existente (es decir, nginx) y seguir la filosofía de Unix de “hacer una cosa y hacerlo bien”, Unicorn puede seguir un diseño e implementación más simples mientras se mantiene eficiente en el servicio de aplicaciones Rack (p. Ej. tu aplicación Rails).
Para obtener más información, consulte los documentos de diseño y filosofía de Unicorn que explican con más detalle las opciones detrás del diseño de Unicorn y por qué nginx se considera un buen proxy inverso para Unicorn.
Nginx
Unicornio
Consulte unicornio en github para obtener más información.
Reseñas y calificaciones de la guía
Si guardas alguna indecisión y disposición de aclararse nuestro ensayo eres capaz de escribir una interpretación y con placer lo estudiaremos.