The uWSGI model (taken from the original Django docs)
uWSGI operates on a client-server model. Your Web server (ie. nginx, Apache) communicates with one or more uwsgi "workers" processes to serve dynamic contents. The Web server can communicate with the uWSGI process either:
- directly by the uwsgi protocol through a socket created by uWSGI,
- via plain-old-ugly fastcgi protocol
- by proxying HTTP requests to the minimalist HTTP server built in uWSGI.
In the first case: the Web server can do uwsgi protocol (often with a module). It can then use either a Unix domain socket (a "named pipe" on Win32 systems), or it can use a TCP socket. What you choose is a matterr of preference. Usually, a TCP socket is easier because connecting to a port doesn't require special permissions.
In the second case, the Web server doesn't need to do uwsgi protocol. It just needs to be able to proxy HTTP requests to the HTTP server built-in uWSGI. The procedure is the same than proxying any HTTP server. Note that the Web server is a "reverse proxy" in this case.
Configuring the uWSGI server
In any case, when you set up your Web server, you'll just need to point its uwsgi or proxy module to the host/port or socket you specified when starting the uWSGI server.
Choosing the socket
The easiest is to set the socket to a high level (>49152) local port like 127.0.0.1:49152. If the socket is a file, the system administrator must ensure that the Web server process has read, write and execute privileges on that file.
uWSGI is highly configurable and thus there are many ways to start the process. For example, uwsgi version 0.9.6.8 provides a hundred switches. This guide demonstrates the most important of them, but does not intent to substitute the official manual and online documentation.
uWSGI supports configuration through:
- environment variables
- command line switches
- ini files
- xml files
- yaml files