uwsgify for Django¶
uwsgify adds integration with Django Framework.
First add uwsgify into INSTALLED_APPS.
After that nice uwsgi-related staff will be available in your Django
project. For example:
- Manage commands (see below);
- uWSGI summary and statistics in Django Admin interface;
- Automatic DB connections closing after
fork(); - and more.
Settings¶
UWSGIFY_MODULE_INIT¶
uwsgify can import modules from your Django applications automatically
on project startup.
This is useful for background tasks (crons, timers, mules offloading) registration, and other uwsgi stuff. E.g.:
By default uwsgiinit.py modules are imported.
One can change this behavior putting UWSGIFY_MODULE_INIT=mymodule in
Django settings.py. After that uwsgify will search for mymodule.py
instead of uwsgiinit.py.
UWSGIFY_SKIP_TASK_ENV_VAR¶
Cen be used to set an environment variable name to check whether task execution should be skipped. E.g. for temporary maintenance.
Note
See notes on @task and decorator below.
Tools¶
Django cache¶
You can use uWSGI shared cache.
Just configure a backend in Django settings.py.
And don't forget to define mycache cache in uwsgicfg.py:
Decorators¶
@task¶
This decorator is useful to give task functions (e.g. uWSGI cron, timer) superpowers.
Distributed tasks¶
@task decorator can be particularly useful to run scheduled functions exclusively
in one datacenter (first datacenter acquired the lock is the winner).
This implies a distributed cache, such as Redis or Database to store task state, including parameters and last run results.
Consecutive calls of the decorated function, when it is blocked, will be ignored
(the decorated function if called directly will return None).
Pass to the decorator a proper backend object.
Cache backend¶
Let's say we want to use Valkey/Redis to store task locks.
We configure myrediscache cache in Django settings:
After that we pass CacheBackend to the decorator:
Database backend¶
Now let's suppose we need to have more control over our task, we need more context.
For that we use DbBackend. This not only allows exclusive task execution,
but also is able to store task parameters and last run results.
Note
Please note that for performance reasons my_task function needs
to be registered in Database beforehand. For that you can use Django Admin interface,
or from Python (e.g. in migration file).
Reset stale task records¶
Sometimes (e.g. when uWSGI stopped abruptly) task records in your database may "hung up", as if their tasks are still running.
For such occasions it's useful to have a watchdog task resetting stale records:
Management commands¶
uwsgi_run¶
uwsgi_run management command runs uWSGI to serve your Django-based
project.
Now your project is up and running on http://127.0.0.1:8000.
By default the command runs your project using some defaults, but you
can configure it to your needs with the help of uwsgicfg.py
(constructed in a usual for uwsgiconf manner) placed near your
manage.py.
Note
Embedding. if you're using pyuwsgi having uWSGI and your entire
project compiled into a single binary, and your manage.py is the
entrypoint, use --embedded option:
myproject uwsgi_run --embedded.
uwsgi_reload¶
uwsgi_reload management command reloads uWSGI master process, workers.
uwsgi_stop¶
uwsgi_stop management command allows you to shutdown uWSGI instance.
uwsgi_stats¶
uwsgi_stats management command allows you to dump uWSGI configuration
and current stats into the log.
uwsgi_log¶
uwsgi_log management command allows you to manage uWSGI log related
stuff.
uwsgi_sysinit¶
uwsgi_sysinit management command allows you to generate system service
configs (e.g. systemd) to start your Django project on system start.