July 1, 2010 |
pro tip |
Only one comment so far.
We love pip and Fabric for Django deployment. You can see our boilerplate fabfile.py here. Pip, however, isn’t safe to run in an automated fashion. If you attempt to switch branches or repos for one of your editable requirements, you’ll be presented with this input:
What to do? (s)witch, (i)gnore, (w)ipe, (b)ackup
At this time, there is an open bug to solve this problem, but thanks to the trusty *nix toolkit, we have an easy workaround. Enter yes. From its manpage:
NAME
yes - output a string repeatedly until killed
SYNOPSIS
yes [STRING]...
yes OPTION
DESCRIPTION
Repeatedly output a line with all specified STRING(s), or `y'.
...
I have the most success with the “wipe” option for pip, so now we can simply run:
yes w | pip install -r requirements.pip
This answers w to any prompt that pip displays, making it much more ...
View full post
June 24, 2010 |
pro tip |
3 comments
I really like supervisord for long-running process management. It is Python, so it is easy to install and it is easy to script with tools like Fabric. Lately I’ve been deploying smaller Django/WSGI sites with Green Unicorn behind Nginx proxied over a Unix socket which makes for a nice little setup on shared hosting and RAM starved VPSes.
After installing supervisord with something like sudo easy_install supervisor, you’ll want to make sure it runs after you reboot your machine (and gets restarted in case it crashes). If you are on a Linux system with upstart (and have root access), you can bypass the ugly init scripts and use this simple file placed in /etc/init/supervisord.conf to manage your supervisord process:
description "supervisord"
start on runlevel [2345]
stop on runlevel [!2345]
respawn
exec /usr/local/bin/supervisord --nodaemon --configuration /etc/supervisord.conf
Now that it is ...
View full post
February 12, 2010 |
pro tip |
Only one comment so far.
Here’s one I struggled with a bit while upgrading lincolnloop.com yesterday.
Scenario: You need to take your site offline and want to redirect all its traffic to a “down for maintenance” page. For search engine friendliness, that page should return a 503: Service Unavailable status code. Here’s the (not entirely intuitive) way to do that in Nginx:
server {
listen 80;
server_name mysite.com;
root /var/www/mysite.com/;
location / {
if (-f $document_root/maintenance.html) {
return 503;
}
... # the rest of your config goes here
}
error_page 503 @maintenance;
location @maintenance {
rewrite ^(.*)$ /maintenance.html break;
}
}
Now whenever you need to take your site offline, simply create the file maintenance.html in the $document_root (in our case, /var/www/mysite.com). If the file exists, Nginx will serve it with a 503 status code, if not, it will proceed as usual.
View full post
