Python에서 웹 개발을 배포하는 방법 소개
- Y2J원래의
- 2017-05-13 14:03:291504검색
이 글에서는 참고할만한 가치가 있는 Python으로 웹 개발 프로그램을 배포하는 여러 가지 방법을 주로 소개합니다. 아래 편집기로 살펴보겠습니다
1. fastcgi는 flup 모듈을 통해 지원됩니다. nginx의 해당 구성 명령은 fastcgi_pass
2입니다. nginx는 이를 전달하기 위해 Proxy_pass를 사용합니다. 백엔드 애플리케이션에는 높은 동시성을 처리할 수 있는 http 서버가 내장되어 있어야 합니다. Python의 웹프레임워크에서는 tornado만 선택할 수 있습니다.
uwsgi 프로토콜
웹 서버 내장 지원 프로토콜 모듈
애플리케이션 서버 프로토콜 지원 모듈
프로세스 제어 프로그램
nginx가 내장- uwsgi 프로토콜 및 0.8.4부터 시작하는 uwsgi 프로토콜 지원 매우 간단합니다. 4바이트 헤더 + 본문 본문은 http, cgi 등과 같은 많은 프로토콜의 패키지일 수 있습니다(헤더의 필드로 표시됨). ).
uwsgi의 특징은 자체 프로세스 제어 프로그램이며 C 언어로 작성되었으며 실제로spawn-fcgi/php-fpm과 유사합니다. 따라서 uwsgi는 (python, lua, ruby, erlang, go) 등을 포함한 다양한 애플리케이션 프레임워크를 지원할 수 있습니다.
4. mod_python, 이는 Apache의 내장 모듈이며 크게 의존합니다. mod_python으로 컴파일된 Python 버전, apache와 함께 사용, 권장하지 않음
5. cgi, 이는 너무 오래되어 권장되지 않으며 nginx는 cgi 모드를 지원하지 않으므로 lighttpd 또는 apache만 사용할 수 있습니다
6.spawn-fcgi, 이것은 lighttpd 설치 패키지와 함께 제공되는 fastcgi 다중 프로세스 관리 프로그램입니다. flup과 동일한 효과가 있습니다. Python 코드 수준이고 generate-fcgi는 외부 프로그램입니다. spawn-fcgi는 매우 다재다능하며 php, python, perl 등 모든 언어로 개발된 코드를 지원할 수 있습니다. 코드가 fastcgi 인터페이스를 구현하는 한 관리에 도움이 될 수 있습니다.
7. 전체 이름은 Simple Common Gateway Interface이며, scgi 프로토콜은 fastcgi와 매우 유사하다고 생각합니다. nginx의 해당 구성 명령은 scgi_pass입니다. 원하는 경우 사용할 수 있으며 flup도 이를 지원합니다.
8. uwsgi와 유사한 도구인 Gunicorn은 레일 배포 도구(Unicorn)에서 이식되었습니다. 그러나 그것이 사용하는 프로토콜은 WSGI이고, 전체 이름은 python2.5에 정의된 공식 표준(PEP 333)인 Python 웹 서버 게이트웨이 인터페이스입니다. 이는 뿌리가 좋고 배포가 비교적 간단합니다. .org/
9. Apache의 모듈인 mod_wsgi는 WSGI 프로토콜(code.google.com/p/modwsgi/
uwsgi
uwsgi 설치
pip install uwsgi
uwsgi 구성
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 $
구성 매개변수에 대한 자세한 설명:
공통 옵션 :
소켓: 주소 및 포트 번호, 예: 소켓 = 127.0.0.1:50000
프로세스: 시작된 프로세스 수
작업자: 시작된 프로세스 수는 프로세스와 동일합니다(공식 웹사이트). 지정된 수의 작업자/프로세스를 생성한다고 말합니다)
chdir: 실행 디렉터리를 지정합니다(앱을 로드하기 전에 지정된 디렉터리에 대한 chdir)
wsgi-file: Load wsgi-file(.wsgi 파일 로드)
stats: 지정된 주소에서, 상태서비스를 켭니다(지정된 주소에서 통계 서버를 활성화합니다)
스레드: 실행 중인 스레드. GIL의 존재로 인해 이것은 정말 쓸모가 없다고 생각합니다. (지정된 스레드 수를 사용하여 사전 스레드 모드에서 각 작업자 실행)
마스터: 마스터 프로세스 존재 허용(마스터 프로세스 활성화)
daemonize: 프로세스가 백그라운드에서 실행되고 지정된 로그 파일 또는 UDP 서버에 기록됩니다(uWSGI를 daemonize). 실제로 가장 일반적으로 사용되는 방법은 실행 중인 기록을 로컬 파일로 출력하는 것입니다.
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 에이전트 프로그램과 웹 호스트 서비스 프로그램 간의 통신 오버헤드를 줄여 웹 서비스 성능 향상이라는 궁극적인 목표를 달성하는 것이 디자인 아이디어이다. FCGI는 사양 측면에서 CGI와 다르지 않지만 구체적인 구현 방법에는 개선이 있음을 알 수 있습니다. CGI의 접근 방식은 각 HTTP 요청에 대해 웹 호스트 서비스 프로그램이 서버 스크립트를 호출하기 위해 새로운 프로세스를 생성한다는 것입니다. 이에 따라 FCGI의 접근 방식은 웹 호스트 서비스 프로그램 프로세스와 통신하기 위해 독립적인 FCGI 서비스 프로그램 프로세스를 구축하는 것입니다. FCGI 서비스 프로세스가 시작되면 리소스를 할당하고 HTTP 요청에 응답하기 위한 스레드를 생성하며 자체 라이프 사이클 을 통해 프로세스를 생성하기 위해 시스템에서 발생하는 리소스 오버헤드를 크게 줄입니다. PHP 및 ASP.Net과 같은 최신 인기 웹 서버 프로그램은 기본적으로 FCGI를 구현한 것입니다.
SCGI = Simple CGI
데이터 프로토콜과 응답 프로세스를 간소화한 FCGI의 산물입니다. 설계 목적은 AJAX 또는 REST 기반으로 증가하는 HTTP 요청 수에 적응하고 더 빠르고 간결한 응답을 제공하는 것입니다. 그리고 SCGI는 서버가 HTTP 프로토콜 요청에 대한 응답을 반환하면 HTTP 연결이 즉시 종료된다는 데 동의합니다. 따라서 SCGI가 일반적인 의미에서 SOA가 주창하는 "요청-망각(request-forget)" 통신 모델에 더 적합하다고 보는 것은 어렵지 않습니다.
WSGI = 웹 서버 게이트웨이 인터페이스
이 프로토콜은 Python 언어로 특허를 받았습니다. 이는 웹 서비스 호스트 프로그램과 HTTP 응답 브로커 간의 통신을 위해 보편적으로 적용 가능한 인터페이스 집합을 정의합니다. 이는 Python 프로그래머가 웹 프레임워크와 웹 호스팅 서버 프로그램 사이에 심각한 결합이 있음을 발견했기 때문에 발생했습니다. 예를 들어 일부 프레임워크는 Apache의 mod_python용으로 설계되었습니다. 따라서 WSGI는 매우 낮은 수준의 인터페이스 세트를 정의합니다. 일반적인 Python 웹 프레임워크에서는 CherryPy, Django, web.py, web2py, TurboGears, Tornado, Pylons, BlueBream, Google App Engine [모호함 – 논의], Trac, Flask, Pyramid 등 이 프로토콜을 구현했습니다. 등등
위 내용은 Python에서 웹 개발을 배포하는 방법 소개의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!