31–39 of 39 posts
You really should use nginx to serve static files and route everything else to apache. The setup is dead simple.
Know of any tutorials appropriate for a Linux server noob (I'm comfortable with the Linux command line but haven't done much web deployment other than basic one-click xampp stuff)?
I recommend nginx in front of gunicorn. This way nginx can sit up front and do what it does best: serve static media files and buffer requests and responses. Set up gunicorn under some kind of process manager. I use daemontools, but runit, upstart, monit, and others can work very well too. For updating code on the server, I'm a big fan of keeping it simple, and to me that means writing a small shell script that ssh's…
Here's what I've found that helps tremendously: -Keep your software in a DVCS of some sort. I find Git and Mercurial to be great. -Use virtualenv to abstract away from your current environment's Python distribution. Start clean and download the packages you need. -Create a requirements file listing the packages that you need for you program. Put it in the same format that the 'pip freeze' command outputs, so that ins…
> -Set up a local configuration file (not managed by version control) and a base configuration file with all the settings that are immutable. Import the local config file within settings.py so as to avoid local setting conflicts. Have you tried keeping your settings in a package rather than in a module? Most introductions to django use settings.py to keep things simple (works out of the box using manage.py), however…
I recommend nginx in front of gunicorn. This way nginx can sit up front and do what it does best: serve static media files and buffer requests and responses. Set up gunicorn under some kind of process manager. I use daemontools, but runit, upstart, monit, and others can work very well too. For updating code on the server, I'm a big fan of keeping it simple, and to me that means writing a small shell script that ssh's…
Beautiful summary of a nice setup indeed. Although, I would run in a virtual environment, don't you think that's a good idea? By the way, Eventlet workers sounds nice - how does that compare to using Twisted for aIO?
Earlier quoted context omitted.
These are some excellent points, the only things we do differently are: - We keep a local settings file for each environment, and those /are/ versioned. We have a /settings_local directory which contains each of the variants (localdev/dev/staging/df/live). The appropriate one is sym linked to /settings_local.py, which in turn is imported into settings.py. - We bypass Apache entirely and just plug Nginx FCGI into Djan…
I use fabric for deployment, testing, log maintenance, database backups. For almost everything on remote machines. Learning curve is rather not steep.
If you haven't used fabric, give it a try. It's an extremely simple API for performing remote management, deployment, etc.
I've tried numerous tools but nothing compares to fabric. It is just so easy and it always works. I can't imagine not seeing a fabfile.py in my project's deploy/ dir anymore, it just wouldn't be right.
I recommend nginx in front of gunicorn. This way nginx can sit up front and do what it does best: serve static media files and buffer requests and responses. Set up gunicorn under some kind of process manager. I use daemontools, but runit, upstart, monit, and others can work very well too. For updating code on the server, I'm a big fan of keeping it simple, and to me that means writing a small shell script that ssh's…
I recommend nginx in front of gunicorn. This way nginx can sit up front and do what it does best: serve static media files and buffer requests and responses. Set up gunicorn under some kind of process manager. I use daemontools, but runit, upstart, monit, and others can work very well too. For updating code on the server, I'm a big fan of keeping it simple, and to me that means writing a small shell script that ssh's…