[CentralOH] Django Application Deployment and Production Delivery

Fri Jul 19 04:14:10 CEST 2013

I was doing something similar, and I ran into this documentation.

http://code.google.com/p/modwsgi/wiki/VirtualEnvironments

Essentially, you build one baseline virtualenv with just the python
interpreter.  Then, you can build different wsgi-driven sites under their
own virtualenv's
 and deploy the virtualenv file structure under wsgi.

Here's a practical example.  Since I'm using CentOS, I'm building rpm's for
some Django-based sites.  I have one rpm, ve-baseline, that provides the
following structure:

/srv/ve-baseline
/srv/ve-baseline/lib
/srv/ve-baseline/lib/python2.6
..(files typical of a virtualenv, under /srv/ve-baseline)..
/etc/httpd/conf.d/00_security.conf
/etc/httpd/conf.d/01_ve-baseline.conf

So what's the story on the conf files?  I begin their filenames with 00 and
01 because I want them to be read first when Apache boots up.  The
security.conf contains a smattering of miscellaneous security settings, not
necessarily related to Python or WSGI.  The ve_baseline looks like this:

WSGIPythonHome /srv/ve-baseline
WSGISocketPrefix run/wsgi

These are lines you'd traditionally find in a site configuration for a
WSGI-based site.  It basically configures the WSGI home environment to the
ve-baseline, and it sets the prefix for the Unix socket that WSGI uses to
communicate with Apache.  (This last one is needed because you'll have
SELinux headaches if the Unix socket is in the wrong place.)

The rpm package for the website provides a similar structure: a conf file
under /etc/httpd/conf.d, and a virtualenv file structure under
/srv/website.  The conf file, in this case 10_Vinova-WS.conf, looks like
this:

<VirtualHost 192.168.2.223:80>

ServerName vindev.mydomain.as

WSGIDaemonProcess vinova_org_website processes=2 threads=16
display-name=%{GROUP}
WSGIProcessGroup vinova_org_website
WSGIScriptAlias / /srv/vinova/www/vinova/deploy/wsgi.py

Alias /static /srv/vinova/www/vinova/static

<Directory /srv/vinova>
    WSGIApplicationGroup %{GLOBAL}
    Order deny,allow
    Allow from all
</Directory>
</VirtualHost>

As you can see, this is a config file that is typical for a WSGI-based
site; there isn't anything out of the ordinary here.

It might be possible to specify different PythonHomes while doing this, but
I'm not sure.

On Thu, Jul 18, 2013 at 3:40 PM, Joe Shaw <joe at joeshaw.org> wrote:

> Hi,
>
> We built Woven (woventheapp.com) as a Flask app that serves an API to
> native mobile client apps. Our setup is:
>
> * An SSL-terminating Rackspace load balancer
> * 2 web servers running nginx
> * The same 2 servers running our Flask app in uwsgi, proxying using the
> nginx uwsgi binary protocol over a unix domain socket
>
> I highly recommend the combination of nginx + uwsgi.  It has never caused
> us any problems, and while the docs around configuring uwsgi aren't great,
> once it's running you basically never have to touch it.  With these two
> servers we can easily handle hundreds of requests per second and the
> bottleneck becomes the database, not the web server or our app.
>
> Hudson is now called Jenkins, and we use it with nose to ensure 100% code
> coverage.  We also use it to run periodic integration tests.  It works well
> enough, and we recently moved from self-hosting the whole environment to
> only partially hosting it, with Cloudbees hosting the rest.  I wouldn't say
> I love Jenkins, though.
>
> If you use GitHub for development, I also wrote a little tool called
> Leeroy (http://github.com/litl/leeroy) to integrate GH pull requests with
> Jenkins.  We have a rule that you can't push code until the Jenkins build
> passes without test failures.
>
> Hope this is helpful,
> Joe
>
>
> On Thu, Jul 18, 2013 at 3:17 PM, Mark Aufdencamp <mark at aufdencamp.com>wrote:
>
>> Hi All,
>>
>> While many of you here are busy planning the upcoming PyOhio, I've been
>> engaged in learning to coherently converse on TDD and Django this year.
>> I've been following O'Reilly's "Test Driven Development in Python" which
>> is still sparse on chapters.  I've managed to complete the first three
>> chapters of building an application.   In preparation of deploying to a
>> server, I stepped back into some virtualenv/pythonbrew learning and
>> discovered the magic of PythonPath and the site_packages directory.
>> I've learned a bit and can successfully configure a venv and utilize it
>> for development.
>>
>> I'd now like to propagate that to a production environment.  I've ruled
>> out mod_python as an option to run django apps.  That leaves wsgi and
>> gunicorn.
>>
>> So, I guess I'm looking for someone with some experience utilizing
>> apache/wsgi/venv/django to give me some sage advice on how they do it
>> and the gotchas?
>>
>> Alternatively, if your running NGinx in front of gunicorn with BSD
>> sockets, I'd be really interested in hearing of your experiences. (I
>> like the performance and no TCP port requirement)
>>
>> In conjunction with selecting and building a production platform, I'm
>> curious as to the differing deployment methodologies utilized in the
>> group.  I'm spoiled by capistrano in the ruby world.  Any great
>> equivalent in the django world?  Utilizing scp/sftp?  Pulling with
>> git/svn directly from a repository?
>>
>> How about dealing with database migrations in django?  Anyone utilizing
>> South?
>>
>> Last question, anyone utilizing Hudson with django/venv as a testing
>> platform?
>>
>>
>> Hoping to elicit some responses, and looking forward to this years
>> PyOhio.
>>
>> Mark Aufdencamp
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> CentralOH mailing list
>> CentralOH at python.org
>> http://mail.python.org/mailman/listinfo/centraloh
>>
>
>
> _______________________________________________
> CentralOH mailing list
> CentralOH at python.org
> http://mail.python.org/mailman/listinfo/centraloh
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/centraloh/attachments/20130718/25f43853/attachment.html>