PythonでWeb開発をデプロイする方法の紹介

この記事では主に、Python で Web 開発プログラムをデプロイするためのいくつかの方法を紹介します。これは、優れた参考価値があります。エディターで見てみましょう

1. fastcgi は、flup モジュールを通じてサポートされています。nginx では、http で proxy_pass 転送を使用する必要があります。 Python Web フレームワーク

で同時実行性の高い http サーバーを処理するには、次の 4 つのグループ

を含む tornado.3、

uwsgi のみを選択できます。

組み込み Web サーバー サポート プロトコル モジュール アプリケーション サーバー プロトコル サポート モジュール

• プロセス制御プログラム

• nginx には、0.8.4 以降、uwsgi プロトコルのサポートが組み込まれています。uwsgi プロトコルは非常にシンプルです。 4 バイトのヘッダー + 本文で構成され、本文は http、CGI などの多くのプロトコルのパッケージです (ヘッダー内のフィールドでマークされます)。

uwsgi は、C 言語で書かれた独自のプロセス制御プログラムを特徴としており、実際には spawn-fcgi/php-fpm に似ています。したがって、uwsgi は、(python、lua、ruby、erlang、go) などを含むさまざまなアプリケーション フレームワークをサポートできます。

• 4. Apache の組み込みモジュールである mod_python は、使用される Python のバージョンに大きく依存します。 mod_python によるコンパイル用、および apache の使用は推奨されません

5。cgi、これは古すぎるため推奨されません、nginx は cgi モードをサポートしていないため、lighttpd または apache

• 6 のみを使用できます。これは、fastcgi マルチプロセス管理プログラムです。lighttpd をインストールしてください

このパッケージには、flup と同じ効果が付属しています。違いは、flup が Python コード レベルで導入され、spawn-fcgi が外部プログラムであることです。 spawn-fcgi は非常に多用途で、php、python、

perl

など、あらゆる言語で開発されたコードをサポートできます。コードが fastcgi

インターフェース

を実装している限り、プロセス

7、scgi、フルネームの管理に役立ちます。これは、Simple Common Gateway Interface であり、cgi プロトコルは非常に単純ですが、nginx の対応する設定コマンドは scgi_pass です。 Flup もサポートしています。

8. uwsgi に似たツールである Gunicorn は、rails デプロイメント ツール (Unicorn) から移植されています。ただし、使用するプロトコルは WSGI で、正式名は Python Web Server Gateway Interface で、python2.5 で定義された公式標準 (PEP 333) です。これには優れたルーツがあり、導入は比較的簡単です。gunicorn には詳細なチュートリアルがあります。 .org/

9. Apache の モジュールである mod_wsgi は、WSGI プロトコル code.google.com/p/modwsgi/uwsgi

をインストールします

uwsgi の構成

uwsgi では複数の構成が利用可能です:

pip install uwsgi

1，ini 
2，xml 
3，json
4，yaml

構成例

$ 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
$

設定パラメータの詳細な説明:

よく使用されるオプション:

socket: アドレスとポート番号、例:socket = 127.0.0.1:50000

processes: 開始されたプロセスの数

workers: 番号開始されたプロセスの数、プロセスに等しい (公式ネット 引数は、指定された数のワーカー/プロセスを生成することです)

chdir: 実行ディレクトリを指定します (アプリをロードする前に指定されたディレクトリに chdir します)

wsgi- file: Load wsgi-file (load.wsgi file)

stats: 指定されたアドレスの統計サーバーを有効にする (指定されたアドレスの統計サーバーを有効にする)

threads: スレッドを実行する。 GILの存在により、これは本当に駄目だと思います。 (指定されたスレッド数でプリスレッドモードで各

ワーカーを実行します)

master: マスタープロセスの存在を許可します(マスタープロセスを有効にします)

daemonize: プロセスをバックグラウンドで実行させますとログ 指定されたログ ファイルまたは udp サーバー (uWSGI をデーモン化) にヒットします。実際、最も一般的に使用される方法は、実行レコードをローカル ファイルに出力することです。

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

実際には、特定の実装における CGI の亜種です。設計上の考え方は、CGI エージェント プログラムと Web ホスト サービス プログラム間の通信オーバーヘッドを削減することで、Web サービスのパフォーマンスを向上させるという最終目標を達成することです。 FCGI は仕様の点では CGI と変わらないことがわかりますが、具体的な実装方法が改善されています。CGI のアプローチは、HTTP リクエストごとに、Web ホスト サービス プログラムがサーバー スクリプトを呼び出すための新しいプロセスを作成するというものです。これに応じて、FCGI のアプローチは、Web ホスト サービス プログラム プロセスと通信するための独立した FCGI サービス プログラム プロセスを確立し、FCGI サービス プロセスが開始されると、リソースを割り当て、HTTP リクエストに応答するスレッドを作成し、独自の 寿命を決定します。これにより、プロセスを作成するためにシステムによって発生するリソースのオーバーヘッドが大幅に削減されます。 PHP や ASP.Net など、最近の一般的な Web サーバー プログラムは、基本的に FCGI の実装です。

SCGI = Simple CGI

データプロトコルと応答プロセスを合理化した後のFCGIの製品です。その設計目的は、AJAX または REST に基づく HTTP リクエストの増加に適応し、より高速かつ簡潔な応答を行うことです。また、SCGI は、サーバーが HTTP プロトコル要求に対する応答を返すと、HTTP 接続が直ちに閉じられることに同意します。したがって、SCGI が、一般的な意味で SOA が提唱する「リクエスト-フォーゲット」通信モデルにより適していることを理解するのは難しくありません。

WSGI = Web サーバー ゲートウェイ インターフェイス

このプロトコルは、Python 言語によって特許取得されており、Web サービス ホスト プログラムと HTTP 応答ブローカー間の通信に広く適用可能な一連のインターフェイスを定義します。これは、Python プログラマーが、Web フレームワークと Web ホスティング サーバー プログラムの間に深刻な関係があることに気づいたために生まれました。たとえば、一部のフレームワークは Apache の mod_python 用に設計されています。したがって、WSGI は一連の非常に低レベルのインターフェイスを定義します。一般的な Python Web フレームワークは、このプロトコルを実装しています: CherryPy、

Django、web.py、web2py、TurboGears、Tornado、Pylons、BlueBream、Google App Engine [疑わしい - 議論してください]、Trac、Flask、Pyramid など。

以上がPythonでWeb開発をデプロイする方法の紹介の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。