En el artículo anterior, algunos estudiantes sintieron que era difícil entenderlo sin ser lo suficientemente detallado, así que permítanme explicarles brevemente.
En el caso de nuestro desarrollo:
solicitud del navegador → python manage.py runserver (como 8000) → al código de la aplicación (Django, Flask, etc.)
Implementado en línea:
solicitud de nombre de dominio → resolución DNS → IP del servidor → Nginx (puerto 80) → reenvío de proxy 127.0.0.1: 8000 (IP no es necesariamente 127.0.0.1) → lógica de código de aplicación para el proyecto.
Durante todo el proceso de implementación, agregamos una capa de Docker para implementación aislada, que no solo resolvió la inconsistencia de múltiples entornos en desarrollo (dev) prueba (prueba) en línea (prod), sino que también logró el propósito de empaquetar una vez y ejecutar en todas partes. , No necesitamos usar virtualenv para el aislamiento del entorno de paquetes de Python todos los días, lo cual es muy conveniente en el modo de desarrollo multijugador.
De hecho, ya he hablado sobre la práctica de implementación en contenedores de Docker en el capítulo de introducción de Docker: comenzar . En cuanto al principiante, si cree que no es fácil comenzar desde el principio, puede considerar eliminar el enlace intermedio de la ventana acoplable y ejecutar el servicio directamente en la máquina Linux.
Después de explicar lo anterior, pasemos al tema de hoy:
implementación de Django + Nginx + Gunicorn
Gunicorn
Gunicorn es "Green Unicorn". Proviene originalmente de Unicorn en la comunidad Ruby. Es un servidor HTTP Python WSGI para Unix. Gunicorn es ampliamente compatible con varios frameworks web y es simple y liviano.
La razón por la que usamos uWSGI o Gunicorn es Flask. El rendimiento del servicio WSGI integrado de Django no es lo suficientemente bueno. Generalmente se usa en entornos de prueba y desarrollo, y el servicio WSGI de mayor rendimiento se usa principalmente en línea.
Como introducción, cito un ejemplo oficial:
$ pip install gunicorn
$ cat myapp.py
def app (environment, start_response):
data = b "¡Hola, mundo! \ n"
start_response ("200 OK", [
("Content-Type", "text / plain"),
("Content-Length", str (len (datos)))
])
return iter ([datos])
$ gunicorn -w 4 myapp: app
[2014-09-10 10:22:28 +0000] [30869] [ INFO] Escuchando en: http://127.0.0.1:8000 (30869)
[2014-09-10 10:22:28 +0000] [30869] [INFO] Usando worker: sync
[2014-09-10 10:22 : 28 +0000] [30874] [INFO] Trabajador de arranque con pid: 30874
[10-09-2014 10:22:28 +0000] [30875] [INFO] Trabajador de arranque con pid: 30875
[10-09-2014 10:22:28 +0000] [30876] [INFO] Trabajador de arranque con pid: 30876
[2014-09-10 10:22:28 +0000] [30877] [INFO] Trabajador de arranque con pid: 30877
Después de instalar gunicorn, podemos gunicorn -h ver la configuración. Normalmente, por conveniencia, siempre ponemos gunicorn en el archivo de configuración.
Una cosa para mencionar aquí es que hay uno --statsd-host en gunicorn que hace posible rastrear las solicitudes de otra manera. Mencioné statsd en el artículo de monitoreo antes. Puedes consultar mi blog anterior "Construyendo un sistema de monitoreo web usando Statsd + Graphite + Grafana" , Haga clic para leer el texto original.
Como uWSGI, doy un ejemplo simple de supervisor:
# gunicorn.conf.py import multiprocessing import socket bind = '0.0.0.0:9527' workers = multiprocessing.cpu_count () * 2 + 1 worker_class = 'gevent' # 搭配 gevent 运行 daemon = False proc_name = 'yourproject' pidfile = ' /data/run/gunicorn.pid ' loglevel =' error ' accesslog =' /data/yourproject/supervisor/gunicorn.access.log ' errorlog =' /data/yourproject/supervisor/gunicorn.error.log ' max_requests = 200000 # Integración de StatsD # El host de StatsD se omite aquí, agregue `--statsd-host` a gunicorn # statsd_host = 'localhost: 8125' statsd_prefix = socket.gethostname ()
Lo mencionado anteriormente por qué el número de trabajadores es el número de núcleos de CPU * 2 + 1. No hay mucha base científica para esto. Se basa principalmente en las operaciones de lectura y escritura de un trabajo y el procesamiento de solicitudes por parte del otro trabajo. Puedes configurarlo de acuerdo a tu propia situación. Para configuraciones más especiales, puede consultar los documentos usted mismo.
supervisor & nginx & docker-compose
El supervisor es el mismo que la implementación de la aplicación Django usando la práctica de implementación en contenedor de Docker (1) en el artículo anterior . El único cambio es que nuestro comando ha sido cambiado de uUWSGI a gunicorn. No enumeraré la configuración completa del supervisor aquí.
[programa: gunicorn] comando = / ruta / a / gunicorn principal: aplicación -c /ruta/a/gunicorn.conf.py directorio = / ruta / a / proyecto usuario = nadie autostart = true autorestart = true redirect_stderr = true
Nginx es el mismo que en el artículo anterior. Aquí hay un ejemplo simple:
servidor {
escuchar 80;
nombre_servidor example.org;
access_log /var/log/nginx/example.log;
ubicación / {
proxy_pass http://127.0.0.1:8000;
proxy_set_header Host $ host;
proxy_set_header X-Fordered-For $ proxy_add_x_fordered_for;
}
}
La configuración de docker-compose es la misma que la del artículo anterior, con más contenido, por lo que no la enumeraré. Puede consultar el artículo anterior para la configuración de la implementación de la aplicación Django (1) utilizando las prácticas de implementación en contenedores de Docker .
Al final
Hoy explicamos principalmente el segundo método de implementación de Django. De hecho, este proceso es casi el mismo que sin la ventana acoplable. Puede despegar la ventana acoplable, lo que no tendrá mucho impacto en todo el proceso.
De la misma manera, todo el proceso de mi proceso de implementación es relativamente simple, pero la situación real será algo diferente, ¿no comprendes? Bienvenidos todos a dejarme un mensaje y lo discutiremos juntos.
La implementación en contenedores de Docker está relacionada con nuestro próximo artículo, hablaremos sobre el gran asesino de Kubernets.