I also use boto in my fabfile, so that I can run a single command to launch an EC2 instance, install & configure software on it, save an AMI and terminate the instance. It's a like having a Makefile that compiles machine images:
> fab build:<role> <region>
I wouldn't go as far as Fowler's "disable the shell" idea, but it doesn't take much discipline to do all significant changes by building new AMIs.If you prefer some other IaaS, fine. The point is that fabric can drive both the virtualization API and the actual set up of servers over SSH. I have a fake region called "dev" that runs the build against a vmware image on my local machine. It could work with Softlayer or Joyent or Rackspace or CloudFoundry or whatever.
Fabric and an IaaS provider is a really nice way to implement the PheonixServer pattern.
However, it took me days to complete the script and make it moderately reusable (and completely idempotent and able to handle different configurations), and it still doesn't do as much as I want it to. For example, I just noticed that Ansible[1] can tell whether a change needs to restart a service (e.g. if a config file changed) and only then do it.
That's pretty useful, but my script can't really handle it.
Not a particularly searchable term.
Seems to be down right now though.
Also, you need this too: https://github.com/sebastien/cuisine/
Edit:
The primary weakness of my approach is that for convenience's sake, I rely heavily on apt-get. So hypothetically I'm tied to the debian family. (we use Ubuntu LTS of a couple different versions)
Strictly speaking this disadvantage is unnecessary, you could do all from-source builds using fabric if you wanted. Didn't seem like a constructive use of my time though.
Sample task in my fabfile:
https://gist.github.com/3086836
I'll let you guess from the function name what it does.
The magic word of devops is "idempotence".
While that page has a long list of things they do, the important bits relevant to your comment are
1. a tighter focus on idempotence than Fabric 2. an easy-ish way to integrate package management so you could potentially use the same script to kick off either yum or apt depending on the box
Why the hell would I store anything about deploying one of my projects in /etc/?
Why would I make the same mistake twice? My only real dissatisfaction with Flask is that it cannot handle dispatching its work in parallel. Not a big deal though.
I like knowing exactly how things get done.
For a number of reasons, Debian (or faithful derivatives) comes closest to this of any platform I've encountered.
That said: fabric appears to be little more than a multi-system aware task runner. Somewhat like dsh (distributed ssh / dancer's shell): http://www.netfort.gr.jp/~dancer/software/dsh.html
... or like Capistrano, as the Debian package description suggests (modulo installing Rails).
There's a bad pimp joke around "idempotence" waiting to be made.
Your task here would seem to install Oracle's Java 7 HostSpot JVM.
How do you get around the licensing question(s) (or is that what the "-y" is for)?
> fabric appears to be little more than a multi-system aware task runner.
And C is little more than a portable assembler ;)
I just start writing code to provision/configure the machine for the role in question and don't stop until I have something that can reliably take a blank-slate server and have it rolling by the end of the function.
Easiest way to do devops I've seen yet. I didn't care for chef/puppet/cfengine.
Particularly since I can cherry-pick servers for testing pretty easily with fabric before I run the code against the rest of the machines.