From alex at grep.ro Mon Sep 10 18:27:00 2012 From: alex at grep.ro (Alex Morega) Date: Mon, 10 Sep 2012 19:27:00 +0300 Subject: [Web-SIG] Sarge - progress update Message-ID: <6FDA653E-A3A5-4E9F-BE61-F94B0B233523@grep.ro> Hello! Here's a progress update on "sarge", the deployment tool. Turns out I was trying to address too many concerns at once, so I focussed on the core problem: managing the lifecycle of a version of the application. http://mgax.github.com/sarge/ Sarge acts as container for "instances". An instance can be *created*, then you install code and configure stuff; you can then *start* and *stop* it, and when a new version is ready, *destroy* the old one. There's also a *run* command to bring up a REPL or execute custom commands. Some documentation exists: http://mgax.github.com/sarge/ Instances are independent, so you can run them simultaneously; this allows for different instances for different jobs (web, worker, cron script) and also things like rolling back a failed deployment or zero-downtime upgrade. I'm using this, for a couple of projects, in production, today. There's an example fabfile in the repo (deploy/complex_fabfile.py), but it's way more complex than it should be. Much of that logic should probably be handled by sarge itself. Thoughts, ideas? Cheers, -- Alex From dholth at gmail.com Wed Sep 12 15:08:32 2012 From: dholth at gmail.com (Daniel Holth) Date: Wed, 12 Sep 2012 06:08:32 -0700 (PDT) Subject: [Web-SIG] Sarge - progress update In-Reply-To: <6FDA653E-A3A5-4E9F-BE61-F94B0B233523@grep.ro> References: <6FDA653E-A3A5-4E9F-BE61-F94B0B233523@grep.ro> Message-ID: <829a28ff-6567-43fb-9efe-556f4e5953e1@googlegroups.com> On Monday, September 10, 2012 12:33:31 PM UTC-4, Alex Morega wrote: > > Hello! > > Here's a progress update on "sarge", the deployment tool. Turns out I > was trying to address too many concerns at once, so I focussed on the > core problem: managing the lifecycle of a version of the application. > > http://mgax.github.com/sarge/ > > Sarge acts as container for "instances". An instance can be *created*, > then you install code and configure stuff; you can then *start* and > *stop* it, and when a new version is ready, *destroy* the old one. > There's also a *run* command to bring up a REPL or execute custom > commands. Some documentation exists: http://mgax.github.com/sarge/ > > Instances are independent, so you can run them simultaneously; this > allows for different instances for different jobs (web, worker, cron > script) and also things like rolling back a failed deployment or > zero-downtime upgrade. I'm using this, for a couple of projects, in > production, today. > I am using a system that installs each revision of a web application into a new virtualenv in a directory hostname/random-number (uuid), echoes the random number into a file hostname/active and creates a symlink hostname/current -> random-number. A uwsgi config file hosname/config.ini links to the currently active environment by loading its name from the file 'active': [uwsgi] virtualenv = %d/@(%d/active) When you touch the .ini file, uwsgi reloads the application. Another file 'history' has all the old 'active' lines in order with timestamps so you can revert. uwsgi's many features allow background workers and so on. -------------- next part -------------- An HTML attachment was scrubbed... URL: