One nice way of having a reproducible development or test environment is to "program" a virtual machine to do the job. If you have a powerful machine at hand you might use Vagrant in combination with VirtualBox. But if you have an OpenStack setup at hand (which is our case), you might want to setup and destroy your virtual machines on such a private cloud (or public cloud if you want or can). Sure, Vagrant has some plugins that should add OpenStack as a provider, but, here at Logilab, we have a clear preference for python over ruby. So this is where cloudenvy comes into play.
Setup your authentication in ~/.cloudenvy.yml :
cloudenvy: clouds: cloud01: os_username: username os_password: password os_tenant_name: tenant_name os_auth_url: http://keystone.example.com:5000/v2.0/
Then create an Envyfile.yml at the root of your project
project_config: name: foo image: debian-wheezy-x64 # Optional #remote_user: ec2-user #flavor_name: m1.small #auto_provision: False #provision_scripts: #- provision_script.sh #files: # files copied from your host to the VM #local_file : destination
Now simply type envy up. Cloudenvy does the rest. It "simply" creates your machine, copies the files, runs your provision script and gives you it's IP address. You can then run envy ssh if you don't want to be bothered with IP addresses and such nonsense (forget about copy and paste from the OpenStack web interface, or your nova show commands).
Little added bonus : you know your machine will run a web server on port 8080 at some point, set it up in your environment by defining in the same Envyfile.yml your access rules
sec_groups: [ 'tcp, 22, 22, 0.0.0.0/0', 'tcp, 80, 80, 0.0.0.0/0', 'tcp, 8080, 8080, 0.0.0.0/0', ]
As you might know (or I'll just recommend it), you should be able to scratch and restart your environment without loosing anything, so once in a while you'll just do envy destroy to do so. You might want to have multiples VM with the same specs, then go for envy up -n second-machine.
Only downside right now : cloudenvy isn't packaged for debian (which is usually a prerequisite for the tools we use), but let's hope it gets some packaging soon (or maybe we'll end up doing it).
Don't forget to include this configuration in your project's version control so that a colleague starting on the project can just type envy up and have a working setup.
In the same order of ideas, we've been trying out salt-cloud <https://github.com/saltstack/salt-cloud> because provisioning machines with SaltStack is the way forward. A blog about this is next.