Une brève description de la différence entre WSGI, uwsgi et uWSGI et le déploiement du web python basé sur uWSGI et gunicorn

introduction

Récemment, je développe un projet back-end basé sur le framework Flask Web. Lors de l'interaction entre les applications Web Server et Flask, je rencontrerai toujours les concepts de WSGI, uwsgi et uWSGI mentionnés dans le sujet de cet article, qui sont organisés comme suit.

WSGI

Nom complet anglais: Interface de passerelle de serveur Web, interface de gestion de réseau de service Web, en termes simples, il s'agit d'une spécification de communication entre le serveur Web et l'application.

uwsgi

uwsgi est un protocole de communication, mais il appartient à deux choses avec WSGI, qui est plus rapide avec ce protocole.

uWSGI

uWSGI est un serveur Web et un protocole uwsgi exclusif, mais prend également en charge le protocole WSGI, le protocole HTTP, etc., sa fonction est de convertir le protocole HTTP en un protocole réseau pris en charge par le langage pour l'utilisation de python.

Bien que Flask soit très facile à utiliser et que son app.run(host="0.0.0.0", port=7001)débogage intégré soit très pratique, il est utilisé dans l'environnement de production, qu'il s'agisse d'une concurrence élevée ou d'une robustesse élevée. Il fait généralement défaut dans le conteneur WGSI. [Déploiement dans l'environnement de production]

Utilisation de uWSGI

Lorsque nous travaillons sur un projet Django, nous utilisons généralement le serveur Web intégré de Django directement pour le test et le développement. Cependant, si le projet doit être utilisé dans un environnement de production et compte tenu de la concurrence et d'autres performances, nous pouvons avoir besoin de uwsgi et nginx. Ce qui suit uniquement explique l'utilisation courante de uwsgi.En ce qui concerne la configuration de nginx, je vais écrire un article de blog spécifiquement pour le suivi.

1. Installation

pip install uwsgi

2. Configuration

Il existe généralement deux façons d'exécuter uwsgi: la ligne de commande et la configuration de fichier, mais la ligne de commande peut avoir besoin de se souvenir de nombreux paramètres, la configuration de fichier est donc une approche plus générale. Le format de fichier prend en charge de nombreux types tels que ini, xml, yaml, etc. L'auteur recommande d'utiliser le mode ini de forme clé-valeur relativement simple, un exemple de configuration uwsgi ini simple est donné ci-dessous:

[uwsgi]
socket = 127.0.0.1:8001
master = false
chdir = /var/www/cmpvirtmgr/
module = cmpvirtmgr.wsgi
home = /var/www/env
workers = 2
reload-mercy = 10
vacuum = true
max-requests = 1000
limit-as = 512
buffer-size = 30000
pidfile = /etc/uwsgi/uwsgi.pid

Exécution: uwsgi --ini /path/to/uwsgi.ini

Explication des paramètres:

socket: fichier socket, il peut également s'agir d'adresse + port;
master: s'il faut démarrer le processus principal pour gérer d'autres processus;
chdir: le répertoire racine du projet;
module: chemin relatif du fichier wsgi;
home: répertoire d'environnement virtuel;
travailleurs: le nombre de processus ouverts;
reload-mercy: Définissez le nombre maximum de secondes pour attendre la fin du travail dans un sous-processus de travail dans un redémarrage en douceur (redémarrage jusqu'à ce que la demande reçue soit traitée);
vide: supprimez le socket et les fichiers pid correspondants à la fin du service;
max_requests: limite supérieure de requêtes définie par chaque processus de travail;
limit_as: limite le nombre de mémoire virtuelle occupée par chaque processus uwsgi;
buffer_size: définit la taille de la zone tampon interne utilisée pour l'analyse du paquet uwsgi;
pid_file: spécifiez le fichier pid;
harakiri: le délai d'expiration de la demande;
daemonize: le processus s'exécute en arrière-plan et enregistre le journal dans un chemin spécifique, si le processus uwsgi est géré par le superviseur, ce paramètre ne peut pas être défini;

Pour plus de paramètres uwsgi, veuillez vous référer au document officiel: https://uwsgi-docs.readthedocs.io/en/latest/

Utilisez gunicorn pour déployer le projet de flacon

1. Protocole WSGI

Le framework Web est dédié à la façon de générer du code HTML ou de générer des données d'interface API basées sur Restful, et le serveur Web est utilisé pour traiter et répondre aux requêtes HTTP. La communication entre le framework Web et le serveur Web nécessite un ensemble de protocoles d'interface que les deux parties respectent. Le protocole WSGI est utilisé pour unifier les deux interfaces.

2, conteneur WSGI

Les conteneurs WSGI couramment utilisés sont Gunicorn et uWSGI, mais Gunicorn est démarré directement avec des commandes sans écrire de fichiers de configuration, ce qui est beaucoup plus facile que uWSGI, donc ici, je choisis également d'utiliser Gunicorn comme conteneur.

3. Introduction au gunicorn

Gunicorn est un serveur http python Wsgi, qui ne prend en charge que l'exécution sur les systèmes Unix, dérivé du projet unicorn de Ruby. Gunicorn utilise le modèle préfork maître-ouvrier (dans gunicorn, le maître s'appelle arbitre), qui peut fonctionner avec divers frameworks Web wsgi.

4. Installation de Gunicorn

L'installation de gunicorn est très simple, il suffit d'utiliser la commande pip install gunicorn. Utilisez-le généralement, principalement pour utiliser son modèle de travail asynchrone, mais vous devez également installer le module asynchrone correspondant.

$ pip install gunicorn 
$ pip install greenlet # 使用异步必须安装
$ pip install eventlet # 使用eventlet workers
$ pip install gevent   # 使用gevent workers

5. Utilisation de gunicorn

Voici un exemple d'utilisation de gunicorn pour déployer un projet flask. L'utilisation du framework flask ici n'est pas trop compliquée, et ce n'est pas l'objet de cet article.

L'exemple suivant, enregistrez sous app.py

from flask import Flask
app = Flask(__name__)

@app.route("/")
def hello():
    return "Hello World!"

Les paramètres habituellement utilisés par gunicorn sont les suivants:

-c CONFIG, --config=CONFIG
# 设定配置文件。
-b BIND, --bind=BIND
# 设定服务需要绑定的端口。建议使用HOST:PORT。
-w WORKERS, --workers=WORKERS
# 设置工作进程数。建议服务器每一个核心可以设置2-4个。
-k MODULE
# 选定异步工作方式使用的模块。

Entrez votre configuration de démarrage dans le shell, par exemple:

$ gunicorn -w 3 -b 127.0.0.1:8080 app:app
# 此处app:app中，第一个app为flask项目实例所在的启动模块，第二个app为生成的flask项目实例

Le serveur peut être démarré lorsqu'il fonctionne normalement.

6. Ports de liaison

Linux interdit généralement l'utilisation de ports inférieurs à 1024, à moins qu'il ne s'agisse de l'autorité de l'utilisateur root. De nombreuses personnes ont essayé de le lier au port 80 ou 443 lors de l'utilisation de gunicorn et l'ont trouvé invalide. Si vous souhaitez vous lier à ces ports, il existe plusieurs méthodes courantes comme suit:

Utilisez le transfert de proxy Nginx.
sudo démarre gunicorn.
Installez des programmes supplémentaires.

7. Terminez le processus de service gunicorn

Utilisez la commande ps -ef | grep gunicorn pour découvrir tous les processus de gunicorn.

[root@VM_0_12_centos ~]# ps -ef | grep gunicorn
root     16843 23035  0 Oct14 ?        00:00:02 /root/Envs/myflask/bin/python3.6 /root/Envs/myflask/bin/gunicorn -w 3 -b 172.17.0.12:80 app:app
root     22445 23035  0 Oct04 ?        00:00:15 /root/Envs/myflask/bin/python3.6 /root/Envs/myflask/bin/gunicorn -w 3 -b 172.17.0.12:80 app:app
root     22581 23035  0 Oct11 ?        00:00:05 /root/Envs/myflask/bin/python3.6 /root/Envs/myflask/bin/gunicorn -w 3 -b 172.17.0.12:80 app:app
root     23035     1  0 Sep27 ?        00:04:11 /root/Envs/myflask/bin/python3.6 /root/Envs/myflask/bin/gunicorn -w 3 -b 172.17.0.12:80 app:app

Ensuite, utilisez la commande kill -9 process ID pour tuer le processus. Notez que nous pouvons trouver le processus principal et le tuer, et le processus enfant se terminera. Dans l'exemple ci-dessus, l'ID de processus principal est 23035.

[root@VM_0_12_centos ~]# kill -9 23035
[root@VM_0_12_centos ~]# ps -ef | grep gunicorn

Après avoir tué le processus, attendez quelques secondes, puis utilisez ps -ef | grep gunicorn pour vérifier et trouver que tous les processus de service gunicorn ont été tués.