Opened 11 years ago

Closed 11 years ago

#20406 closed New feature (wontfix)

manage.py generate nginx/apache/uWSGI/gunicorn sample config

Reported by: est Owned by: nobody
Component: Core (Management commands) Version: 1.4
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Hello,

This is just an idea, if this issue is inappropriet please ignore.

I see a lot of people having troulbe setting up django for production because the hassle of setup and config process.

For lower the barriers to entry of Django, I suggest we implement scaffolding some sample config based on current dir and settings.

For example:

$ python manage.py getconfig uwsgi+nginx

The utility will ask the user to input the domain for the project: example.com

The command output two files, uwsgi.ini and example.com.nginx.conf

uwsgi.ini:

[uwsgi]
chdir = LAST_COMMAND_CWD
module = wsgi:application
workers = 2 # number of cores
master = true
socket = LAST_COMMAND_CWD/django.sock

example.com.nginx.conf should be automatically placed under nginx sites-available, and prompt the user to ln -s to the sites-enabled dir.

server {

server_name example.com
location /static/ {

# generated using settings.py MEDIA_PATH and STATIC_PATH.

}
location / {

include uwsgi_params;
uwsgi_pass LAST_COMMAND_CWD/django.sock;

}

}

In the above example LAST_COMMAND_CWD is the abspath where user executed manage.py command.

This is just a rough example. The goal is to give an official standard reference deploy structure and process.

Later we can even add some parameters that allows SA to automatically genreate the correct config for seamless infrastructure migration.

Change History (1)

comment:1 by Claude Paroz, 11 years ago

Component: UncategorizedCore (Management commands)
Resolution: wontfix
Status: newclosed
Type: UncategorizedNew feature

Deployment is hard to standardize, because you have so many different parameters to take into account.

I don't say that we should not do it, but nothing prevent you from creating a package outside of core Django to achieve this, and when/if it is popular and recognized as a very useful addition, we can then conceive integrating it in Django.

Note: See TracTickets for help on using tickets.
Back to Top