Maison > Article > développement back-end > Introduction à la méthode de déploiement du développement web en Python
Cet article présente principalement plusieurs méthodes de déploiement de programmes de développement web en Python, qui ont une bonne valeur de référence. Jetons un coup d'œil avec l'éditeur ci-dessous
1. fastcgi est pris en charge via le module flup. L'instruction de configuration correspondante dans nginx est fastcgi_pass
2 http, nginx utilise proxy_pass pour transmettre cela. Il est nécessaire que l'application back-end dispose d'un serveur http intégré capable de gérer une concurrence élevée. Dans le framework web de Python, vous ne pouvez choisir que tornado.
3, uwsgi, comprenant 4 partiesRegrouper en :
protocole uwsgi
support intégré du serveur Web module de protocole
Module de prise en charge du protocole du serveur d'applications
Programme de contrôle de processus
nginx a construit- en support du protocole uwsgi et du protocole uwsgi à partir de 0.8.4 Très simple, un en-tête de 4 octets + un corps Le corps peut être un package de nombreux protocoles, tels que http, cgi, etc. (marqué par des champs dans l'en-tête. ).
La caractéristique de uwsgi est son propre programme de contrôle de processus. Il est écrit en langage C et utilise la fonction natvie. Il est en fait similaire à spawn-fcgi/php-fpm. Par conséquent, uwsgi peut prendre en charge une variété de frameworks d'application, notamment (python, lua, ruby, erlang, go), etc.
4. mod_python, il s'agit d'un module intégré d'Apache, et il s'appuie fortement sur le python compilé par mod_python, utilisé avec apache, déconseillé
5. cgi, c'est trop ancien, déconseillé, et nginx ne supporte pas le mode cgi, vous ne pouvez utiliser que lighttpd ou apache
6. spawn-fcgi , il s'agit d'un programme de gestion multi-processus fastcgi, fourni avec le package lighttpd installation Il a le même effet que flup. le niveau de code Python, et spawn-fcgi est un programme externe. spawn-fcgi est très polyvalent et peut prendre en charge le code développé dans n'importe quel langage, tel que php, python, perl Tant que votre code implémente l'interface fastcgi, il peut vous aider à gérer. votre processus.
7. scgi, le nom complet est Simple Common Gateway Interface, est également une version alternative de cgi est très simple, je pense qu'il est similaire à fastcgi, mais ce n'est pas le cas. largement promu. La commande de configuration correspondante de nginx est scgi_pass Vous pouvez l'utiliser si vous le souhaitez, flup la prend également en charge.
8. Gunicorn, un outil similaire à uwsgi, est transplanté à partir de l'outil de déploiement de rails (Unicorn). Mais le protocole qu'il utilise est WSGI, le nom complet est Python Web Server Gateway Interface, qui est la norme officielle (PEP 333) définie dans python2.5. Il a de bonnes racines et est relativement simple à déployer. Il existe des tutoriels détaillés sur gunicorn. .org/
9. mod_wsgi, un module d'Apache, prend également en charge le protocole WSGI, code.google.com/p/modwsgi/
uwsgi
Installer uwsgi
pip install uwsgi
Configurer uwsgi
uwsgi a plusieurs configurations disponibles :
1,ini 2,xml 3,json 4,yaml
Exemple de configuration
$ cat etc/uwsgi.ini [uwsgi] socket = 127.0.0.1:9005 chdir = /Users/suoning/python_project/trunk/ wsgi-file = main.py processes = 4 stats = 127.0.0.1:9000 daemonize = /tmp/uwsgiServer.log pidfile = /tmp/uwsgi.pid vacuum = true log-maxsize = 50000000 disable-logging = true callable = app $
Explication détaillée des paramètres de configuration :
Options communes :
socket : adresse et numéro de port, par exemple : socket = 127.0.0.1:50000
processus : Le nombre de processus démarrés
travailleurs : Le nombre de processus démarrés est égal aux processus (le site officiel indique de générer le nombre spécifié de travailleurs/processus)
chdir : Spécifiez le répertoire en cours d'exécution (chdir vers le répertoire spécifié avant le chargement des applications)
fichier wsgi : Charger le fichier wsgi (charger le fichier .wsgi)
statistiques : À l'adresse spécifiée, ouvrez StatusService (activez le serveur de statistiques sur l'adresse spécifiée)
threads : Threads en cours d'exécution. En raison de l'existence de GIL, je pense que c'est vraiment inutile. (exécutez chaque travailleur en mode préthread avec le nombre de threads spécifié)
maître : Autoriser le processus maître à exister (activer le processus maître)
daemonize : provoque l'exécution du processus en arrière-plan et se connecte au fichier journal ou au serveur udp spécifié (démoniser uWSGI). En fait, la méthode la plus couramment utilisée consiste à exporter les enregistrements en cours dans un fichier local.
log-maxsize :以固定的文件大小(单位KB),切割日志文件。 例如:log-maxsize = 50000000 就是50M一个日志文件。
pidfile : 指定pid文件的位置,记录主进程的pid号。
vacuum : 当服务器退出的时候自动清理环境,删除unix socket文件和pid文件(try to remove all of the generated file/sockets)
disable-logging : 不记录请求信息的日志。只记录错误以及uWSGI内部消息到日志中。如果不开启这项,那么你的日志中会大量出现这种记录:
[pid: 347|app: 0|req: 106/367] 117.116.122.172 () {52 vars in 961 bytes} [Thu Jul 7 19:20:56 2016] POST /post => generated 65 bytes in 6 msecs (HTTP/1.1 200) 2 headers in 88 bytes (1 switches on core 0)
配置nginx
$ cat etc/nginx/servers/tongbupan.conf server { listen 80; server_name localhost; location / { include uwsgi_params; uwsgi_pass 127.0.0.1:9005; } location /webstatic/ { expires 7d; add_header Cache-Control public; alias /Users/suoning/probject/python_project/webstatic/trunk/; } } $ $ nginx -t nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok nginx: configuration file /usr/local/etc/nginx/nginx.conf test is successful $ $ nginx -s reload $
配置application
flask 示例
... app = Flask('pan') ... if name == 'main': # app.run(host='0.0.0.0', port=5000) app.run() # 注意:变量app对应uwsgi配置文件uwsgi.ini中 callable = app
启动uwsgi
$ $ uwsgi --ini /usr/local/etc/uwsgi.ini [uWSGI] getting INI configuration from /usr/local/etc/uwsgi.ini $ $ ps -ef|grep uwsgi 11428 1 0 11:40下午 ?? 0:01.23 uwsgi --ini /usr/local/etc/uwsgi.ini 11432 11428 0 11:40下午 ?? 0:00.00 uwsgi --ini /usr/local/etc/uwsgi.ini 11433 11428 0 11:40下午 ?? 0:00.00 uwsgi --ini /usr/local/etc/uwsgi.ini 11434 11428 0 11:40下午 ?? 0:00.00 uwsgi --ini /usr/local/etc/uwsgi.ini 11435 11428 0 11:40下午 ?? 0:00.00 uwsgi --ini /usr/local/etc/uwsgi.ini 11440 69240 0 11:40下午 ttys000 0:00.00 grep uwsgi $ $ lsof -i tcp:9000 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME uwsgi 11428 suoning 28u IPv4 0x5583e11534d24e73 0t0 TCP localhost:cslistener (LISTEN) $ $ lsof -i tcp:9005 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME uwsgi 11428 suoning 6u IPv4 0x5583e11535699e73 0t0 TCP localhost:9005 (LISTEN) uwsgi 11432 suoning 6u IPv4 0x5583e11535699e73 0t0 TCP localhost:9005 (LISTEN) uwsgi 11433 suoning 6u IPv4 0x5583e11535699e73 0t0 TCP localhost:9005 (LISTEN) uwsgi 11434 suoning 6u IPv4 0x5583e11535699e73 0t0 TCP localhost:9005 (LISTEN) uwsgi 11435 suoning 6u IPv4 0x5583e11535699e73 0t0 TCP localhost:9005 (LISTEN) $
FCGI
参考:webpy.org/cookbook/fastcgi-nginx
配置Nginx
$ cat etc/nginx/servers/pan.conf server { listen 80; server_name localhost; error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } location / { fastcgi_param REQUEST_METHOD $request_method; fastcgi_param QUERY_STRING $query_string; fastcgi_param CONTENT_TYPE $content_type; fastcgi_param CONTENT_LENGTH $content_length; fastcgi_param GATEWAY_INTERFACE CGI/1.1; fastcgi_param SERVER_SOFTWARE nginx/$nginx_version; fastcgi_param REMOTE_ADDR $remote_addr; fastcgi_param REMOTE_PORT $remote_port; fastcgi_param SERVER_ADDR $server_addr; fastcgi_param SERVER_PORT $server_port; fastcgi_param SERVER_NAME $server_name; fastcgi_param SERVER_PROTOCOL $server_protocol; fastcgi_param SCRIPT_FILENAME $fastcgi_script_name; fastcgi_param PATH_INFO $fastcgi_script_name; fastcgi_pass 127.0.0.1:9005; } location /webstatic/ { expires 7d; add_header Cache-Control public; alias /Users/suoning/probject/python_project/webstatic/trunk/; } } $
配置application
简单示例
from flup.server.fcgi import WSGIServer from pan import app WSGIServer( app, bindAddress=(host, port), maxThreads=threads ).run()
生产环境示例
#!/usr/bin/env python # -*- coding: utf-8 -*- author = 'suoning' import sys import argparse from flup.server.fcgi import WSGIServer from lib.daemon import Daemon from pan import app APP_NAME = 'pan_platform' APP_INST_NAME = '20170501' parser = argparse.ArgumentParser(description=u'Run an pan FastCGI server') parser.add_argument('command', type=str, help=u'command [start|stop|restart]', choices=['start', 'stop', 'restart']) parser.add_argument('-p', '--port', type=int, help=u'port of this server', required=True) parser.add_argument('-t', '--threads', type=int, default=50, help=u'max number of threads') parser.add_argument('-host', '--host', default='0.0.0.0', help=u'Listen to the main clause') class panPlatformDaemon(Daemon): def run(self): # 运行服务 try: WSGIServer( app, bindAddress=(args.host, args.port), maxThreads=args.threads, umask=0111 ).run() except: sys.stderr.write('oops') def gen_pidfile(port): return '/var/run/%s_%s_%d.pid' % (APP_NAME, APP_INST_NAME, port) if name == 'main': args = parser.parse_args() daemon = panPlatformDaemon(gen_pidfile(args.port)) if 'start' == args.command: daemon.start() elif 'stop' == args.command: daemon.stop() elif 'restart' == args.command: daemon.restart() else: print "Unknown command" sys.exit(2) sys.exit(0)
fastcgi协议和http协议在代码部署中的的优劣对比
fastcgi虽然是二进制协议,相对于http协议,并不节省资源。二进制协议,只能节省数字的表达,比如 1234567,用字符串表示需要7个Byte,用数字就是4个Byte,而字符串到哪里都一样
fastcgi在传输数据的时候,为了兼容cgi协议,还要带上一堆cgi的环境变量,所以和http协议相比,用fastcgi传输数据并不省,反而多一些
fastcgi 唯一的优点是,它是长连接的,用户并发1000个request,fastcgi可能就用10个 链接转发给后端的appplication,如果用http协议,那来多少给多少,会向后端appplication 发起1000个请求
http代理转发方式,在面对超高并发的情况下会出问题,因为,tcp协议栈当中,port是int16整型 你本地新建一个connect,需要消耗一个端口,最多能到65536。外部并发几十万个请求,port池耗干,你的服务器只能拒绝响应了
CGI, FCGI, SCGI, WSGI 区别
WIKI Links:
CGI - en.wikipedia.org/wiki/Common_Gateway_Interface
FCGI - en.wikipedia.org/wiki/Fcgi
SCGI - en.wikipedia.org/wiki/SCGI
WSGI - en.wikipedia.org/wiki/Wsgi
Other reference:
helpful.knobs-dials.com/index.php/CGI%2C_FastCGI%2C_SCGI%2C_WSGI%2C_servlets_and_such#FastCGI_and_SCGI
CGI = Common Gateway Interface
顾名思义,它是一种接口规范。该规范详细定义了Web服务器中运行的服务器代理程序,怎样获取及返回网页生成过程中,服务器环境上下文和HTTP协议中的参数名称,如大家所熟知的:REQUEST_METHOD,QUERY_STRING,CONTENT_TYPE等等。绝大部分的Web服务器程序,是以脚本的形式代理接受并处理HTTP请求,返回HTTP页面或响应。这些脚本程序,就是大家所熟知的PHP、ASP、JSP等等。
FCGI = Fast CGI
Il s'agit en fait d'une variante de CGI en implémentation spécifique. L'idée de conception est d'atteindre l'objectif ultime d'améliorer les performances du service Web en réduisant la surcharge de communication entre le programme d'agent CGI et le programme de service d'hébergement Web. On peut voir que FCGI n'est pas différent de CGI en termes de spécifications, mais il y a des améliorations dans la méthode de mise en œuvre spécifique : l'approche de CGI est que pour chaque requête HTTP, le programme du service hôte Web crée un nouveau processus pour appeler le script du serveur, en conséquence, l'approche de FCGI consiste à établir un processus de programme de service FCGI indépendant pour communiquer avec le processus de programme de service d'hébergement Web. Une fois le processus de service FCGI démarré, il alloue des ressources, crée des threads pour répondre aux requêtes HTTP et détermine son propre cycle de vie , réduisant ainsi considérablement la surcharge de ressources générée par le système pour créer des processus. Les programmes de serveur Web populaires modernes, tels que PHP et ASP.Net, sont essentiellement des implémentations de FCGI.
SCGI = Simple CGIC'est le produit de FCGI après avoir rationalisé le protocole de données et le processus de réponse. Son objectif de conception est de s'adapter au nombre croissant de requêtes HTTP basées sur AJAX ou REST et d'apporter des réponses plus rapides et plus concises. Et SCGI convient que lorsque le serveur renvoie une réponse à une requête du protocole HTTP, la connexion HTTP est immédiatement fermée. Par conséquent, il n'est pas difficile de voir que SCGI est plus adapté au modèle de communication « demande-oubli » préconisé par SOA au sens général. WSGI = Web Server Gateway InterfaceCe protocole est breveté par le langage Python. Il définit un ensemble d'interfaces universellement applicables pour la communication entre les programmes hôtes de services Web et les courtiers de réponses HTTP. Cela est dû au fait que les programmeurs Python ont remarqué qu'il existait un couplage sérieux entre les frameworks Web et les programmes de serveur d'hébergement Web. Par exemple, certains frameworks ont été conçus pour le mod_python d'Apache. Par conséquent, WSGI définit un ensemble d'interfaces de très bas niveau. Les frameworks Web Python courants implémentent ce protocole : tels que CherryPy,Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!