python flask nginx

Diferenciar nginx, haproxy, barniz y uWSGI/Gunicorn (3)

Digamos que planea alojar algunos sitios web en su nuevo VPS. Veamos las herramientas que puede necesitar para cada sitio.

Servidores HTTP

El sitio web ''Alpha'' solo consiste en un poco de HTML puro, CSS y Javascript. El contenido es estático

Cuando alguien visita el sitio web Alpha, su navegador emitirá una solicitud HTTP. Usted ha configurado (a través de DNS y la configuración del servidor de nombres) esa solicitud para ser dirigida a la dirección IP de su VPS. Ahora necesita que su VPS pueda aceptar esa solicitud HTTP, decidir qué hacer con ella y emitir una respuesta que el navegador del visitante pueda comprender. Necesita un servidor HTTP, como Apache httpd o NGINX , y digamos que investiga y, finalmente, decide sobre NGINX.

Servidores de aplicaciones

El sitio web ''Beta'' es dinámico y está escrito usando Django Web Framework.

WSGI es un protocolo que describe la interfaz entre una aplicación de Python (la aplicación django) y un servidor de aplicaciones. Entonces, lo que necesita ahora es un servidor de aplicaciones WSGI, que podrá comprender las solicitudes web, hacer ''llamadas'' apropiadas a los diversos objetos de la aplicación y devolver los resultados. Tienes muchas opciones aquí, incluyendo gunicornio y uSSGI . Digamos que investigas y finalmente decides sobre uWSGI.

uWSGI también puede aceptar y gestionar solicitudes HTTPS para contenido estático, por lo que, si lo desea, podría tener el sitio web Alpha servido en su totalidad por NGINX y el sitio web Beta servido en su totalidad por uWSGI. Y eso sería eso.

Servidores proxy inversos

Pero uWSGI tiene un rendimiento bajo al tratar con contenido estático, por lo que preferiría usar NGINX para contenido estático como imágenes, incluso en el sitio web Beta. Pero entonces algo tendría que distinguir entre las solicitudes y enviarlas al lugar correcto. ¿Es eso posible?

Resulta que NGINX no es solo un servidor HTTP sino también un servidor proxy inverso : es capaz de redirigir las solicitudes entrantes a otro lugar, como su servidor de aplicaciones uWSGI, u otros lugares, recopilando las respuestas y enviándolas de nuevo a el solicitante original. ¡Increíble! Entonces configura todas las solicitudes entrantes para ir a NGINX, que servirá contenido estático o, cuando sea necesario, lo redirigirá al servidor de la aplicación.

Equilibrio de carga con múltiples servidores web

También está alojando el sitio web Gamma, que es un blog popular a nivel internacional y que recibe mucho tráfico.

Para Gamma, decide configurar varios servidores web. Todas las solicitudes entrantes van a su VPS original con NGINX, y usted configura NGINX para redirigir la solicitud a uno de varios otros servidores web basados en la modalidad round-robin, y devolver la respuesta al solicitante original.

HAProxy es un servidor web que se especializa en el equilibrio de cargas para sitios de alto tráfico. En este caso, usted pudo usar NGINX para manejar el tráfico del sitio Gamma. En otros escenarios, uno puede optar por configurar un clúster de alta disponibilidad: por ejemplo, enviar todas las solicitudes a un servidor como HAProxy, que redirige de forma inteligente el tráfico a un clúster de servidores nginx similar a su VPS original.

Servidor de caché

El sitio web Gamma excedió la capacidad de su VPS debido al gran volumen de tráfico. Digamos que en su lugar hospedaste el sitio web Delta, y la razón por la cual tu servidor web no puede manejar Delta se debe a una función muy popular que tiene mucho contenido.

Un servidor de caché puede comprender qué contenido multimedia se solicita con frecuencia y almacenar este contenido de forma diferente, de modo que se pueda atender con mayor rapidez. Esto se logra al reducir las operaciones de IO de disco; el contenido popular se puede almacenar en memoria o memoria virtual en su lugar. Puede decidir combinar su pila NGINX existente con una tecnología como Varnish o Memchached para lograr este tipo de optimización y el sitio web del servidor Gamma de manera más efectiva.

Soy realmente nuevo en las cosas de sys admin, y solo aprovisioné un VPS con nginx (sirviendo los archivos estáticos) y gunicornio como el servidor web.

Últimamente he estado leyendo sobre otras cosas diferentes. Llegué a conocer otras herramientas:

nginx : servidor HTTP de alto rendimiento y proxy inverso, así como un servidor proxy IMAP / POP3

haproxy : equilibrador de carga de alto rendimiento

varnish : almacenamiento en caché HTTP reverse proxy

gunicorn : servidor de python WSGI http

uwsgi : otro servidor WSGI de python

He estado leyendo sobre las 5 herramientas anteriores y me he confundido acerca de cuál se usa y para qué sirve. ¿Podría alguien explicarme en términos sencillos qué uso tiene cada herramienta, cuando se usan juntos y qué preocupación específica abordan?

Pondré una descripción muy concisa (muy informal) para cada uno, en el orden en que se verían afectados cuando realizara una solicitud desde su navegador web:

HAProxy equilibra su carga de tráfico, por lo que si su página web recibe 5000 visitas por segundo, no puede manejar eso con un solo servidor web, por lo que HAProxy equilibrará los hits entre los servidores web que tenía detrás.
Varnish es un servidor de caché, se encuentra por delante de sus servidores web y detrás de HAProxy, por lo que si Varnish almacena un recurso en la memoria caché, él mismo atenderá la solicitud, en lugar de pasar la solicitud a los servidores web que están detrás.
ngingx , gunicorn , uwsgi son servidores web, que estarían detrás del barniz y recibirán las solicitudes que el barniz dejará pasar. Estos servidores web usan diseños optimizados para manejar grandes cargas (solicitudes por segundo).

Primero gunicornio y uwsgi son ambos servidores de aplicaciones. En otras palabras, son responsables de ejecutar su código python de una manera estable y eficiente. Usualmente como back-end de un servidor web regular.

El servidor web sería nginx, se destaca en servir a los activos estáticos y pasar las solicitudes de contenido dinámico a los servidores de aplicaciones.

Si lo anterior no proporciona el rendimiento suficiente, agregue barniz entre nginx y el cliente, debería acelerar las solicitudes repetidas para lo mismo.

haproxy es un equilibrador de carga, si tiene varios servidores para el mismo contenido, este software intentará distribuir las solicitudes entre ellos de manera óptima.

así que básicamente:

su código python vive en el servidor de aplicaciones (uwsgi o gunicornio)
sus webassets estáticos viven en nginx
haproxy y barniz son software que le permiten a un servidor mejor cantidades muy grandes de solicitudes