Skip navigation.

Notes to self

Whatever I feel like writing

Posts tagged with "fabric"

Someone did a talk on Fabric?!?

Apparently so. Turns out a guy named Aaron VanDerlip did a "lightning talk" at the 2008 Plone Conference. I didn't even know Plone had a conference.

And there's proof that Aaron really did a talk; day 3, near the bottom, at Standby 1.

Fabric 0.0.9 released.

,

Just booted out Fabric 0.0.9 hot off the press.

Here are the changes:
  • when in 'fab shell', failing commands no longer terminates your session - they print a warning instead.
  • fix a bug where local_per_host() did nothing if Fabric was not connected to any hosts.
  • fix a regression in sudo with pre-specified passwords.
  • and a typo was fixed.
It's immediately available from the cheese shop.

About Fabric:

Fabric is a remote automation tool written in Python. It is typically used for deploying web applications in a homogeneous cluster environment, but can be used for other automation tasks as well.

To learn more about Fabric, go to the web site: http://www.nongnu.org/fab/

Fabric 0.0.4 Released

As promised yesterday, version 0.0.4 of Fabric has been released.

Here's a direct link to the news item:
https://savannah.nongnu.org/forum/forum.php?forum_id=5233

Fabric 0.0.4 this Weekend.

I was ill last weekend, plus we're preparing to push a new release of one of our major platforms at work, so I've overall been quit busy for the past three weeks.

This means that very little have been done on fabric, but don't worry; I haven't abandoned the project.

I'm also starting to recieve user feedback on fabric, so I'm happy to declare that I will push a 0.0.4 release this weekend based on that feedback!

Some of the changes will include no longer requireing a fabfile in the current directory to operate. This means that "fab list" and "fab help" will work even if you don't have a fabfile in your working directory. Also, doc-strings that start with a newline will no longer look empty when viewed with a "fab list"-ish command.

I hope you'll like that version.

After 0.0.4, I hope to have a major restructuring of fabric. In fact, I've already started working on this (in a git branch). The goal of the restructuring is to make it possible to extend fabrics runtime with plugins.

I really want to have the core of fabric stay small and simple, but I'de also like to help people who want direct support for various SCM systems and application servers. Plugins are the way to do this, I believe.

Other features I hope to support with the restructuring, will be built-in docs for variables, triggers (that fire when a variable changes or some operation/command gets run), a much better non-blocking IO subsystem for console output and finally a much improved terminal emulator.

But that won't all happen in one version, just so ou know :wink: Still, It's what I'de like to accomplish with fabric in the near-term future.

Fabric 0.0.2 Released.

, ,

Here's a sorry-for-previous-release-not-working-release; It's Fabric 0.0.2.

Hopefully it won't crash and burn as much...

Here's what's new:
  • lots of minor tweaks to the innards to make it a little less hacky (still plenty to do in that regard).
  • added a new download() operation; like put, but the other way around.
  • local() and local_per_host() operations now halt fabric if whatever they happen to be executing terminates with an exit_code != 0.
  • load() shoul now print a nicer message if no fabfile is found.
Appart from that, I've done work on a new and improved (!) shell command, but it's not ready for this version (maybe next). Also worked a little on unittesting this baby, but I haven't got much to show for that, either.

Fabric 0.0.1 Released!

, ,

Last Sunday, after little more than two weeks of work, Fabric version 0.0.1 was been released. The main goal of this the very first release was to just get something out the door, and I must admit that some pretty horroble bugs made it through the cracks.

Fabric had most of its core functionality in place after just three days. Then came a period of polishing and bug squashing, and finally a lot of work on the help system and the distribution tool-chain these past four days.

I'll be celebrating this first release by transitioning Fabric from Pre-Alpha to Alpha. Also, I'de like to state my intend on release the cycles; that if anything at all has happened on Fabric since last release, then push a new version out the door every two weeks. The big idea is, that if I can just maintain this rythm, then the project is bound to move forward and not die out, regardless of how fast or slow the work progresses.

I'de like to make clear what version-numbering scheme I intend to use:
Before 1.0:
0.0.1 = First release
0.-.X = Backwards compatible update
0.X.0 = Backwards incompatible update

After 1.0:
-.-.X = Update without interface changes
-.X.0 = Update with backwards compatible interface additions
X.0.0 = Backwards incompatible update

And that's it for now. See you in two weeks, if not sooner.

ANN: Fabric - Simple pythonic remote deployment tool.

, , ,

Deployment woes.

I code in Java at work, and all of my projects can be divided into two camps:
  1. Those that build to .jar files and deploy to our maven2 repo.
  2. And those that build to .war files and are deployed to some application server.


Once configured, maven itself is pretty good at making case #1 run smoothly - "mvn deploy" is all it really takes. But do I have anything similar for case #2?

Well, not quite. I tried banging something together with Capistrano, but that didn't work. For one thing, Capistrano expects you to be deploying a Rails application and these are typically all deployed in the same way, which is very different from deploying a .war file. Secondly, I had a build/compile step in my process that I needed to do locally (because compiling on the server is troublesome and a bad idea), this meant that I had to use the put function to upload my .war file. Put worked nicely for small text files (ie. my project.properties file), but failed miserably when the payload war a near 20 MB heavy .war file.
Googling and tweaking the flags on the File object didn't work. It simply refused to upload that damn .war file.

Itch-scratchers mentality.

I suppose I could have written a shell script and leveraged the existing scp and ssh tool chain. And I did throw a pebble down this route to see how it felt, but eventually rejected the idea. The reason is that I'm deploying to multiple hosts simultaneously. I tried looking at clusterssh to see if it would help me in this regard, but it turned out to be odd, klonky and basicly not designed for such a task. I also took a look at Dancer's Shell, dsh, which was a lot closer to home, but my username contains a backslash and dsh meticulously stripped it out prior to logging in, foiling any and all of my attempts at tricking it into taking it at face value.

What was I suppose to do? I had pretty much given up on automating the process and started to accept defeat, when I happened upon the paramiko module for python. Paramiko is a pure python implementation of the SSH 2 protocol, and lets you log into servers, execute commands and upload files. It prompted me to the idea to write my own pythonic version of a Capistrano like tool, and then use that for deployment. It could be made open source and a perfect oppotunity try out Git on a real project.

Birth of Fabric.

So I swiftly went to work. In two days, I had written the first prototype. It supported the most basic operations such as running remote shell commands, sudo'ing and uploading files. Then I registered my project on nongnu.org (chosen because of their Git support). And ba-da-bim, Fabric became an open source project: https://savannah.nongnu.org/projects/fab/

Fabric looks, on the surface at least (or for those who've only spent a short while with either), a lot like Capistrano. You have a fabfile (as oppose to a capfile) in you project directory, and that file describes all of your deployment tasks (or commands, in Fabric speak).

Commands are really just regular python functions (and you're allowed to call it fabfile.py if you like) that simply makes calls to some other, more magical, functions called operations. Operations are magical because they just sort of exist; you don't import them from a module and don't find them in an object - you just call them.

So, to get the feet wet, here's a hello-world'ish simple fabfile:
set(
    fab_user = 'joe.shmoe',
    fab_mode = 'rolling', # run stuff on one host at a time
    fab_hosts = ['node1.servers.com', 'node2.servers.com'],
)

def deploy():
    "Build and deploy a war file to our app. servers."
    local("mvn clean package")
    put("target/myapp.war", "myapp.war")
    run("mkdir /rollback/$(fab_timestamp)")
    run("cp /$(fab_host)/deply/myapp.war /rollback/$(fab_timestamp)/myapp.war")
    sudo("cp myapp.war /$(fab_host)/deploy/myapp.war")
    sudo("$(fab_host) restart")


Then, all it takes to deploy is a "fab deploy" in the directory where the above file is found. It's still pretty basic, low-level and imparative, but it's a good start.

Fabric also has a built in help system that is powered by your doc-strings; try typing "fab help:deploy" for instance. If you want to see what other commands are availble to you, then simply type "fab list". You can also get a list of operations (the local(), put(), run(), sudo() kind of things) by typing "fab help:ops" and get more details about the individual operation with, for instance, "fab help:put".

And that's basically it for today.