Switched to Python Fabric
by Stii
We’ve been using Capistrano to deploy Afrigator to our various servers for a while now. I can seriously not complain or say anything bad about Capistrano. Thing is, I’m more familiar with Python than I am with Ruby, thus for me it just makes more sense for me to use Fabric.
Here is a small example of how to write a typical deploy script with Python Fabric:
First, define your various servers which you need to deploy to. Ideally, you’ll have a test, staging and live server. Thus you’ll set them up as follows.
def test():
config.fab_user = 'test_user_name'
config.fab_hosts = ['test.yourserver.com']
def staging():
config.fab_user = 'staging_user_name'
config.fab_hosts = ['staging.yourserver.com']
def live():
config.fab_user = 'live_user_name'
config.fab_hosts = ['www1.yourserver.com', \
'www2.yourserver.com', 'www3.yourserver.com']
This allows you to deploy your code to the various servers. Please note, you need to setup automatic login for your different servers. See here how to do automatic logins.
Next, write the steps you would take to deploy your site manually:
def deploy():
"Deploy code to servers"
msg = "deploying"
require('fab_hosts', provided_by = [test,staging,live])
local('svn ci -m "$(msg)"')
run('svn export repos /path/to/repository/export/')
run('cp -R /path/to/repository/export/* /path/to/your/site/')
To deploy to the staging server you can run the following command:
$ fab staging let:msg="Reason for check in" deploy
To deploy to the 3 live servers, all you do is:
$ fab live let:msg="Reason for check in" deploy
The command works as follows: fab is the command. live/stating/test are the environments you would like to load. If you said staging, it will do the commands in deploy for the staging server. The last part is the command you want to run. In this instance, deploy.
The let:msg=”Reason for check in” is the coolest bit! It basically allow you to override Fabric variables. If you look closely, in my deploy script I’ve set a variable msg to just say “deploy”. Now that is a stupid SVN message for a commit. In order to commit with meaningful messages, I override the msg variable with my own message. Simple, yet very effective!
You may want to write a number of different functions in a single fabfile. If you have 100 commands and you’re not one hundred percent sure, just do a:
$ fab list
and all the commands available to you will be printed with their description. Fabric rocks! Seriously.
Good stuff, Stii! I’m going to have to give Fabric a closer look. Capistrano is nice but this appears to be an elegant alternative.
Check it out! It is very cool. I’ve just scratched the surface and already it does anything i need. I’ll write up as i find new cool features.
Great post, thanks
Also possible to set username, password, port, etc. in fabfile
def test():
config.fab_user = ‘username’
config.fab_password = ‘mypassword’
config.fab_port = 30000
config.fab_hosts = ['test.server.com']
[...] Switched to Python Fabric | Es Tea Double Eye [...]
For simpler things I think Fabric would be enough. Capistrano has several Strategy classes for every major SCM, many deployment strategies (copy, scm, etc), gateway support, etc.
For simpler things in Ruby, there is also Vlad, the Deployer http://rubyhitsquad.com/Vlad_the_Deployer.html from the RubySquad.
so here’s what I’m curious about… since fab is GPL and fabfiles are mostly a bunch of “dynamically linked calls” to fab’s methods, does that mean you must release your fabfiles? :)
http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL
A consequence is that if you choose to use GPL’d Perl modules or Java classes in your program, you must release the program in a GPL-compatible way, regardless of the license used in the Perl or Java interpreter that the combined Perl or Java program will run on.
perl and java is just an example.
@Alex G
That’s an interesting question. I don’t think people normally release fabfiles in a way that would otherwise be covered by the GPL, but the answer is no; fabfiles are not covered by the GPL that covers Fabric itself. I consider it an implementation detail that Fabric loads the fabfile into the same interpretor instance.
That is what I intended when I licensed Fabric under the GPL.
If someone more knowledgeable on the legal details insists that Fabric is incompatible with its intended use, then I will handle it by fixing the license, rather than the program.
Christian, thats the way to do it! Thanx
@Alex – you have misinterpreted the interpretation of the GPL – the link you posted refers directly to the JNI or java native interface, a way of binding with machine code libraries through java. That is linking, not running bytecode on an interepter.
For the record – as far as I know Fabric uses paramiko, which is pure python. :)
Hi, I think I’m right in saying this is for the 0.1 version of Fabric not the 0.9 whose release is fairly imminent? Looking for more examples of fabfiles written with the new API! :)
Thanks for the article. I have to tell you that “hab list” doesn’t work for me, it should be “fab –list”.
The article was written for the 0.1 series of Fabric. What you have installed is a 0.9 series version, which has an overhauled command line interface.
[...] References: SSH Without Password Fabic 0.9.0 Documentation Switched-To-Python-Fabric/ [...]
What would the possibility be of using fabric for router config changes using ssh or telnet access ?
Yuo can use it just fine for the SSH case, I suppose. But I’m not sure that telnet is a supported protocol – it would be a coincidence if it were.
Fabric is really just a tool to automate the execution of commands over SSH. Note that this article was written in 2009 and that Fabric has moved forward a fair bit since then.