centosflask + uWSGI + nginx deployment

centosflask + uWSGI + nginx deployment

 

1. Concept

Flask own webserver - Werkzeug, you can build a service that runs the site. However, in the development, generally with a professional --uWSGI.

In addition, there often with the nginx.

 

1.1. uWSGI

uWSGI is a full-stop hosting service, which implements the application server (supports multiple programming languages), agents, process manager, monitor. UWSGI named because it was first realized that WSGI Python language.

WSGI: common interface / protocol for implementing parsing python, is a universal interface standard interface protocol, or to achieve a commonality between pythonweb interaction with the server program.

Use it, web.py or bottle or django etc. pythonweb development framework that can easily be deployed on a different webserver;

uwsgi: Like WSGI is a communication protocol

uwsgi uWSGI server protocol is a proprietary protocol, which defines the type of information transmission, it is compared with WSGI are two things.

uWSGI: one kind or pythonwebserver called Server / Gateway

uWSGI similar tornadoweb or flup, a pythonwebserver, uWSGI is to achieve a Web server and WSGI uwsgi two protocols, python responsible for responding to web requests.

Because apache, nginx, etc., they themselves do not resolve dynamic languages ​​like php function, but assigned to other modules to do, such as apache can say built-in php module, it feels like apache support php same.

uWSGI realized wsgi agreement, uwsgi protocol, http and other protocols. Nginx role in HttpUwsgiModule uWSGI is exchanged with the server.

uWSGI is written in C language, performance is relatively high. uWSGI comprises four parts:

 

1.2.    Nginx

 

Nginx efficient Web server and a reverse proxy server, load balancing can be used (when n users access the server, the shunt can be achieved, relieve the pressure on the server), it may be security filtering, anti-DDOS attacks. Compared with Apache, Nginx supports high concurrency, can support TCP connections of one million, one hundred thousand level of concurrent connections, simple to deploy, less memory consumption, low cost, but Nginx Apache module is not rich.

Nginx support uWSGI of uwsgi agreement, so we can uWSGI combined with Nginx, Nginx by uwsgi_pass dynamic content to uWSGI process.

 

1.3. Why use nginx

Since uWSGI can act as a Web server, then why have uWSGI Nginx need it?

The most common argument is that Nginx advantage, better performance for static files. In fact, if the site is small, there is no need to deal with static files, only uWSGI is also possible, but with Nginx this layer, the advantage can be very specific:

For operation and maintenance is more convenient, if the server is an IP spoofing, add the IP to the blacklist in the Nginx configuration file, if only uWSGI, then you need to modify the code.

On the other hand, Nginx Web server is a veteran, uWSGI appear to be more professional in the performance, for example uWSGI in earlier versions do not support https, you can say Nginx safer.

Nginx feature is the ability to do load balancing and HTTP caching, if more than one server, Nginx basic is mandatory, and by Nginx, resources can be allocated to different server nodes, only one server, can well improve performance because Nginx can handle static resources through headers of ExpiresorE-Tag, gzip compression, etc. well, after all, is written in C language, a function call is native, optimized for I / O, for a dynamic resource, the Nginx can also implement caching functionality, with CDN optimization (uWSGI this is impossible). Nginx support epoll / kqueue network library, such as efficient, works well with the short connection request concurrent high performance ratio uWSGI not know where to go high.

If you run multiple applications PHP, Python and other languages ​​written on the server host, you need to listen on port 80, this time Nginx is a necessary option. Because we need a forwarding service.

So, Nginx is basically mandatory. So although uWSGI itself is a web service, here again it is to put the introduction of Nginx Nginx as a reverse proxy so, some pictures, js and other static resources can provide the service with Nginx, while others are forwarded to the uWSGI, which is why we the ultimate goal of this deployment architecture.

 

2. Deploy

2.1. System Environment

centos6.5

python3.6.5

nginxn 1.10.3

uwsgi 2.0.18

 

2.2. uWSGI

uWSGI is implemented by a python web containers, better compatibility can publish pythonweb application framework Django, Flask and so on. Because essentially uwsgi python is a module, it can be used directly pipinstalluwsgi install it.

Uwsgi can create a server configuration file in an appropriate directory after installation is complete. For example, I choose the root directory of the project creates a file of uwsgiconfig.ini. Incidentally, in addition to the configuration ini format, to uwsgi JSON supports, and other wide variety of configurations XML format. Here, for example to ini format.

 

2.2.1. Configuration

Directly uwsgi running configuration file as follows:

[Uwsgi]

http= 0.0.0.0:9000

chdir = /home/web_server/flask/website

wsgi-file= run.py

callable= app

processes=4

threads=2

pidfile = /home/web_server/flask/uwsgi.pid

daemonize = /home/web_server/flask/server.log

 

The parameters are:

After you specify a port designated by the uwsgi no longer need to run the port flask, actually given callable after variables, perform run by the uwsgi ()

socket: socket communication port, the interface to the outside world the equivalent of leaving a uWSGI server, Nginx is responsible for communicating with, but note socket can not be directly accessed via http request was successful.

pythonpath: project directory.

callable: Enable variable names in the application program, in general are app = Flask (__ name__) So here is the app.

processes: the number of processors.

threads: the number of threads.

After the processes and threads pointed out uwsgi start the server, the server will open several parallel processes, each process will open a few threads to handle requests waiting, obviously this number should be reasonable, not too small and too much will make the processing performance It will bring too much burden on the server itself.

stats: obtaining statistical information service address uwsgi

daemonize: uWSGI the process running in the background, and log hit the specified log file or udp server.

 

 

 

2.2.2. Start / Stop

uWSGI will generate a xxx.pid in the same directory by the xxx.ini startup file, there is only a single line is the process ID of the main process of uWSGI.

uWSGI start:

uwsgi --ini xxx.ini

 

uwsgi reboot:

uwsgi --reload xxx.pid

 

uwsgi stop:

uwsgi --stop xxx.pid

 

pid file to be generated manually specify

 

2.2.3. Issues

 

Close Problem

After manually specify the pid file, the actual process began four, but only one pid pid, using -stop turned off only close a process pid file recorded in the remaining three can only kill

Batch kill the process:

pkill uwsgi

pkill -f uwsgi -9 # generally less than

 

 

2.3.    nginx

2.3.1. Installation

yum install nginx

 

View version

nginx version: nginx/1.10.3

 

2.3.2. Configuration

Path of the profile varies, when installed on a CentOS yum, the general profile /etc/nginx/nginx.conf

Nginx.conf modify the configuration file, but this does not directly modify, and use another way (recommended)

 

Nginx the default installation configuration file follows the tail /etc/nginx/nginx.conf

              include /etc/nginx/conf.d/*.conf;

That is, from external directory /etc/nginx/conf.d/ folder also introduced other configuration files.

So, do not modify the default configuration file, add a new webapp.conf in /etc/nginx/conf.d/ directory, thereby increasing the profile system robustness.

 

webapp.conf reads as follows:

server {

    listen 9002; // web access port

    server_name localhost; // server name

    charset     utf-8;

    access_log /var/www/webapp/access.log; // server receives the request log, logs directory if there needs to be created, otherwise nginx error

    error_log /var/www/webapp/error.log; // error log

    client_max_body_size 100M;

    location / {

       include          uwsgi_params;

       uwsgi_pass 127.0.0.1:9000; // uwsgi needs and profiles of the same item in the address socket, or can not make uwsgi receiving the request.

       #uwsgi_param UWSGI_PYHOME / var / www / webapp / Venv;

       uwsgi_param UWSGI_CHDIR / home / web_server / flask / web_test; // root directory project

       #uwsgi_param UWSGI_SCRIPT run: app; // start the project of the main program (running on a local

                                 // The main program can be built into the flask of

                                 // access to your project on the server), in fact, can be specified in uwsgi

       }

 

    error_page 404 /404.html;

        location = /40x.html {

        }

   

    error_page 500 502 503 504 /50x.html;

        location = /50x.html {

        }

}

 

problem:

unknown directive "listen " in

The configuration file tab spaces, can be replaced with a normal space.

 

2.3.3. Start / Stop

Start: nginx -c /usr/local/nginx/conf/nginx.conf

 

stop:

Close nginx approach:

(1) command

When nginx starts, you can use the "-s" parameter to control the nginx nginx management process (ie master process) sends a signal: nginx -s signal

Which, signal can be the following values:

  [1] stop: Fast Close

  [2] quit: safety shutdown

  [3] reload: reload the configuration file

  [4] reopen: Reopen a log file, mainly used to cut logs

quit signal, wait for notification nginx worker processes finishes with the current request after the exit, this command can only be performed by nginx start of linux accounts.

reload signal to inform the nginx reload configuration file nginx.conf. In addition to using reload outside, nginx will only load a configuration file at startup, after changes to the configuration file is not real-time process is already running on nginx take effect.

When you run this command, master process attempts to read the configuration file, if the profile is no problem (configuration file in question see below how to verify it?):

master process starts a new worker process to run the new configuration file and processes the request, and will notify the old worker process does not process new requests and exits after processing the current task.

If the configuration file there is a problem can not be executed, master process rolls back the old configuration files continue to work, the whole process will not lead to nginx abnormal exit.

linux kill command can also achieve the same effect, assuming nginx's master process ID (pid) is 123456, then kill -s QUIT 123456 and kill -s HUP 123456 and in front of these two commands quit, reload the same effect.

Close nginx Command 1:

nginx -s quit

 

[3] reload configuration

Reload the configuration file

(1) command

nginx -s reload

 

2.4. UWSGI reconfigured

uwsgi configuration is not the same as when the independent operation and use nginx

Profile: uwsgi_nginx.ini

[Uwsgi]

socket = :9000

chdir = /home/web_server/flask/website

wsgi-file= run.py

callable= app

processes=4

threads=2

pidfile = /home/web_server/flask/uwsgi.pid

daemonize = /home/web_server/flask/server.log

 

3. Test Results

3.1. uWSGI

Do not use nginx, run directly uWSGI

uwsgi uwsgi_independent.ini

 

3.1.1. The results show

Visit http: // ip: 9000 / success.

 

3.2.    uWSGI+ nginx

First start uwsgi, if you do not write the absolute path needs to be performed in the ini files in the current path

[root@soft flask]# uwsgi uwsgi_nginx.ini

 

Start nginx

nginx -c /etc/nginx/nginx.conf

 

3.2.1. The results show

Visit http: // ip: 9002 / success.

Note: Specify when configuring nginx.

 

 

4. Appendix

4.1. Common command

ps -ef | grep uwsgi

uwsgi uwsgi.ini

uwsgi --stop uwsgi.pid

kill -9