[omaha] Django Talk

Matthew Nuzum newz at bearfruit.org
Wed Feb 6 17:25:17 CET 2008


On Feb 6, 2008 8:52 AM, Mike Hostetler <mike at hostetlerhome.com> wrote:

> I hope everyone can make it to the Django talk tonight.  Going
> through my notes last night helped me to remember how really easy and fun
> it is to build a website with Django.  If you've ever built a site
> with Java or PHP, then you will be amazed by how Django works.
>
> I also have a Django app in production.  Getting it running in a
> production environment wasn't nearly as easy as writing it. :(  So
> I'll be talking a bit about that as well.
>

Hi Mike, unfortunately I won't make it, but I'm eager to hear your
experiences deploying. I too have been developing web applications with
Django.

The company where I work is ultra-ultra cautious with security so even
though I'm the webmaster I don't get root access (they do grant me sudo
access to do apache2ctl graceful though). I am kind of jealous of PHP
applications where you just upload. I'm definitely interested in hearing how
others are deploying.

My team has gone through some trial and error to find something that works
well for us, here's how we're doing it now:

I put my projects in /srv/<projectname>/python-packages/trunk with a symlink
so that you can access the project using either .../trunk or
.../projectname. (The "trunk" is any branch using our vcs, we've just agreed
to use trunk - we use bzr for vcs)

I install django to /srv/<projectname>/python-packages/django and I also put
any other special python packages there in
/srv/<projectname>/python-packages/ (for example, I recently used markdown)

In my project there's of course settings.py but this has been a challenge
since different developers have different configurations so settings.py only
contains things that are valid for everyone. Anything specific to the host
running django gets put in a file called settings_computername.py. The first
line of this file is:
from settings import * Then below that is the host specific stuff (db
settings, paths to media and templates, etc).

The apache vhost looks like this (for mod_python):

<Location "/">
       SetHandler python-program
       PythonPath "['/srv/<projectname>/python-packages'] + sys.path"
       PythonHandler django.core.handlers.modpython
       SetEnv DJANGO_SETTINGS_MODULE trunk.settings_<computername>
       PythonDebug On
</Location>
<Location "/static/">
       SetHandler None
</Location>
<Location "/media/">
       SetHandler None
</Location>
Alias media/ /srv/<projectname>/python-packages/django/contrib/admin/media/
<Location "/files/">
        SetHandler None
</Location>
Alias files/ /srv/<projectname>/www/files/

Also, we're going to implement a new security feature so that admin access
happens via https using a different domain than what you use to you view the
site. That way, in case some kind of xss exploit slips through a malicious
user can't hijack an admin's session since the admin sessions are tied to a
different domain than the site is viewed at. We currently do this with our
PHP applications and even though its a bit cumbersome, I enjoy the extra
safety net it provides.

I worked at a company for a while that developed java applications and they
used the Resin app server. It was kind of interesting because you just had
to upload a war file and resin would detect it, unpack it and install it
automatically. It was kind of nice. I think that a typical java servlet
based app is more difficult to install than a typical django app (but mostly
because of the xml, otherwise they're about the same). It would be exciting
to see functionality similar to this available for us as django developers.
Just upload your app via ftp and django would deploy it. I'll bet the RoR
gang would enjoy this too and it could boost the availability of
mass-hosting options for Rails and Django developers.

-- 
Matthew Nuzum
newz2000 on freenode


More information about the Omaha mailing list