On Apr 4, 3:59 pm, Kristaps Kūlis <kristaps.ku...@gmail.com> wrote: > I believe that running manage.py for production deployments is "not > way to go", as it has been noted by django devs previously. > What purpose would runuwsgi command serve ?
I'm unsure. Roberto's proposal is interresting: i could configure uwsgi in settings.py and then just run runuwsgi. Although that looks a little to much for django itself, it would be great in a pluggable django app. That said i'd love to *not* have to put a 3 liners module in my project directory anymore. A runuwsgi command might not be the only way to solve this need. On Apr 2, 4:44 pm, Łukasz Rekucki <lreku...@gmail.com> wrote: > > +1. More docs didn't hurt anybody. At least while there is someone to > maintain them. > You can count on me (until death). > > > What do you think ? > > My first impression is that you're focusing too much on all those > switches. That section got me totally lost. That should be simplified. > Also, do I really need to type all that stuff? I probably won't be > doing that on production, so showing how to place it in a > configuration file would be better. > > I would also drop the whole "advantages" section. The purpose of the > page is to show how to deploy a Django app onuWSGI, not compare it > against other solutions. You also mention some features, but never > show how to enable/use them which is confusing. Thanks for your feedback, I did my best to take it in consideration while rewriting most of the documentation this week. (Some examples are still missing but most of it is there. Feedback is always appreciated) ============================ How to use Django with uWSGI ============================ .. highlight:: bash uWSGI_ is a fast, self-healing and developer/sysadmin-friendly application container server coded in pure C. .. _uWSGI: http://projects.unbit.it/uwsgi/ Prerequisite: uWSGI =================== `uWSGI wiki<http://projects.unbit.it/uwsgi/wiki/Install>`_ describes several installation procedures. Using pip, the python package manager, installing any uWSGI_ version can be done with one command line. For example:: # install current stable version pip install uwsgi # or install LTS (long term support) pip install http://projects.unbit.it/downloads/uwsgi-lts.tar.gz Prerequisite: general concept ============================= uWSGI model ----------- uWSGI_ operates on a client-server model. Your Web server (ie. Nginx, Apache) communicates with a django-uwsgi "worker" process 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_, * or 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. .. admonition:: Choosing the socket The easiest is to set the socket to a high level (>1024) local port like 127.0.0.1:3000. 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: * command line switches * ini files * xml files Managing the uWSGI server ------------------------- The system administrator controls the worker process pool by sending signals to the master process. For example, the unix kill command sends such signals. uWSGI_ can write the master process id to a "pidfile". A "pidfile" is a plain text file containing just a process id. Starting the server ------------------- Starting an uWSGI_ server is the role of the system administrator, like starting the Web server. It is *not* the role of the Web server to start the uWSGI_ server. This means: * the uWSGI_ server can be restarted or reloaded independently from the Web server, * it is the role of the system administrator to make uWSGI_ to start on boot or reboot: either through tools like supervisor or daemontools, either directly at init level in a file like /etc/rc.local or /etc/conf.d/ local Managing uWSGI ============== Configuring the project ----------------------- Starting a process with uWSGI takes an additional python script. The script can be in the project directory, named 'youruwsgi.py':: from django.core.handlers.wsgi import WSGIHandler # set application for WSGI processing application = WSGIHandler() Starting the server ------------------- Example command line for a Web server that understand the uWSGI_ protocol:: uwsgi --home=/path/to/your/project --module=youruwsgi \ --master --pidfile=/tmp/project-master.pid \ --socket=127.0.0.1:3000 \ # can also be a file --processes=5 \ # number of worker processes --uid=1000 --gid=2000 \ # if root, uwsgi can drop privileges --harakiri=20 \ # respawn processes taking more than 20 seconds --limit-as=128 \ # limit the project to 128 Megabytes --max-requests=5000 \ # respawn processes after serving 5000 requests --daemonize=/var/log/uwsgi/yourproject.log # background the process Django specific options are: * home: should be the path to your project * module: should be the name of your uwsgi module, ie. youruwsgi * pythonpath: optionnal path to your project virtualenv Example ini configuration:: Example ini configuration usage:: Example xml configuration:: Example xml configuration usage:: Reloading the daemon -------------------- As mentioned above, the uWSGI_ master process is one of the core component of the uWSGI_ stack. The signal to brutally reload all the workers and the master process is SIGTERM. Example command to brutally reload the uWSGI_ processes:: kill -TERM `cat /tmp/project-master.pid` Patching the daemon ------------------- One of the great advantages of uWSGI_ is its ability to gradually restart each worker without loosing any request. For example, uWSGI_ can be signaled that worker should reload the code after handling their current request (if any):: kill -HUP `cat /tmp/project-master.pid` Stopping the daemon ------------------- If you have the process running in the foreground, it's easy enough to stop it: Simply hitting ``Ctrl-C`` will stop and quit the uWSGI server. However, when you're dealing with background processes, you'll need to resort to the Unix ``kill`` command. The ``kill`` is used to send a signal to the uWSGI_ master process. The `uWSGI_ signals are documented online <http://projects.unbit.it/uwsgi/wiki/uWSGISignals>`_. Example command to completely stop the uWSGI_ stack:: kill -INT `cat /tmp/project-master.pid` HTTP server configuration ========================= Nginx setup ----------- Nginx provides the uwsgi module by default these days. Configuring Nginx to use an uWSGI server is as simple as setting it up to proxy requests:: location / { uwsgi_pass 127.0.0.1:3000; # in case of a socket file: # uwsgi_pass unix:/tmp/yourproject.sock; } Note that default uwsgi parameters should be included somewhere in your Nginx configuration. For example:: http { include uwsgi_params; # [...] normal nginx configuration here } Cherokee setup -------------- Lighttpd setup -------------- Apache setup ------------ Troubbleshoting =============== As usual, the first things to do is to check the logs. This implies: * the Web server log, which will indicate if it couldn't connect to the uWSGI_ process * the uWSGI_ log, which will indicate if an exception was thrown Tipical gotchas: * if the socket is a file: the Web server process should have read, write and execute permissions on the socket file * uWSGI_ won't remove the socket and pidfile when it is interrupted, it is safe to remove them manually and to start uWSGI_ again in that case * uWSGI_ can start the process on the foreground, this will make errors easily visible to the system administrator -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
