
Setting up Django + NGinx + Green Unicorn in an Ubuntu EC2 instance - elopinologo
http://adrian.org.ar/python/django-nginx-green-unicorn-in-an-ubuntu-11-10-ec2-instance
======
overshard
Good for starters but there are quite a few bad practices used in this
tutorial such as declaring your apps templates directory when by default
Django searches all apps for a templates directory. Also running nearly
everything as root.

This will get you up and running but just be aware that some of the items may
not be the "correct way" of doing it.

~~~
jared314
What do you suggest is the correct way? Running each app under its own user
with groups for each resource?

~~~
overshard
The correct way on Linux to run services is for each service to have it's own
user. If you are just going to be running a single Django project I recommend
creating a user simply called "django", putting all the projects files in
"/srv/www/" because that's what "srv" is for. And then running your django
project as the django user. If your django project gets hacked and you have
permissions set properly then the most they can do is fiddle with all your
django files. If they have root access they can get your SSL certs, SSH keys,
redirect your Nginx server and all kinds of other bad things.

~~~
latchkey
Sure, trying to mitigate damage with sandboxes is a good goal, but the reality
is that if your server is hacked at all you're screwed. There is enough local
shell exploits that once you are on a box, chances are you can get past user
and group permissions pretty easily. Plus, they've hacked your box! Time to
wipe it and start over. Period.

As for SSL certs, don't you store those on the load balancer? If you are
running a single box and it goes down, pointing the LB at a new backend box is
a lot easier than copying certs around.

As for SSH keys, I'm not quite sure what damage could be done there. The only
thing on there is public keys, right?

As I said below, this is a big reason why I believe in PaaS if your
application can deal with it (and most can). Sysadmin has become so
commoditized that there is no point in wasting your own time/money dealing
with this stuff.

------
brendoncrawford
Just a few notes to keep in mind...

1\. You should use the nginx PPA instead of the default Ubuntu one.

2\. uWSGI is an excellent alternative to Gunicorn, and can be run as a system
startup service using supervisord.

3\. As you get further along in your django project development, you may find
you will need to apply patches to django core. In this case it helps to
install from the git repo instead of pip, then checkout to the latest stable
tag.

4\. Instead of running `sudo /etc/init.d/nginx restart`, the idiomatic Ubuntu
way is `sudo service nginx restart`.

~~~
devmach
Why PPA ? It's maintained by volunteers and there is no connection with "Igor
Sysoev". What i'm missing ?

~~~
brendoncrawford
Probably because the official Nginx docs recommend it:

<http://wiki.nginx.org/Install#Ubuntu_PPA>

~~~
devmach
It's not actually a recommendation, Nginx docs says :

"Look, here is our official release under nginx.org and there is some
wonderful work from volunteers which you can install development, stable and
nightly builds without hassle"

------
mladenkovacevic
There was an article somewhere comparing the performance of various Django
setups and as far as I can remember uWSGI+NGinx won out, although Gunicorn was
a close second

~~~
jethroalias97
Here is an excellent resource which made me a convert to uwsgi:

<http://nichol.as/benchmark-of-python-web-servers>.

Setup is a bit more difficult, but if you are already using nginx it isn't so
bad.

------
snos
Here's another article on setting up Django on EC2 -- but using NGinx and
uWSGI: [http://posterous.adambard.com/start-to-finish-serving-
mysql-...](http://posterous.adambard.com/start-to-finish-serving-mysql-backed-
django-w)

------
megakwood
Anyone know about the performance of this stack vs Apache + mod_wsgi?

~~~
wave
I remember reading from Instagram blog that they found Gunicorn to be less
CPU-intensive:

    
    
      We use http://gunicorn.org/ as our WSGI server; 
      we used to use mod_wsgi and Apache, but found 
      Gunicorn was much easier to configure, and less 
      CPU-intensive. 
    

[http://instagram-
engineering.tumblr.com/post/13649370142/wha...](http://instagram-
engineering.tumblr.com/post/13649370142/what-powers-instagram-hundreds-of-
instances-dozens-of)

------
cardmagic
Why are people still doing this kind of stuff instead of using a PaaS?

~~~
crcsmnky
There's always the ability to tweak specifics for your setup that aren't
available in many platforms.

IMHO, you shouldn't use a PaaS unless you know how to set your stack up.
Essentially, if you don't recognize or have respect for the convenience you're
being given (by going through a platform) then you'll potentially make bad
decisions down the road. Personally, I prefer to learn how to set it up and
scale it myself initially which helps me better understand what to look for in
a platform.

Plus, there's something fun about putting all the pieces together and watching
your apps come up (especially if you don't normally handle this part of the
stack).

~~~
cardmagic
What do you think of Cloud Foundry that is a PaaS which is open source and you
can control all the aspects of if you don't like them?

