Video of the presentation:
[originally published in ShuttleCloud’s blog]
It’s no secret that ShuttleCloud uses Ansible for managing its infrastructure, thus we think it would be useful to explain on how we use it.
At ShuttleCloud, we take automation as a first order component of Software Engineering. We aim to have everything automated in production: application deployment, monitoring, provisioning, etc. Ansible is a key component in this process.
Our infrastructure is almost entirely in Amazon Web Services (AWS), although we are in the process of moving to Google Compute Engine (GCE). The stack is distributed across several regions in US and Europe. Due to the fact that we have SLAs up to 99.7%, we need to have every component, service and database operating in a High Availability manner.
Excerpt from a message I sent to tmux-users mailing list:
I just began to use the recently added zoom feature and came across an anoying thing.
You have panes A and B. A is zoomed, if you switch to pane B, then A is forcibly unzoomed. This is expected, of course, otherwise B would remain invisible.
If you switch back to pane A I expect to get A zoomed again because it wasn’t me who unzoomed it.
Ansible 1.2 is out of the door. Go and check the changelog to see how many
new features and fixes this version brings, my favorites being the new
syntax for variable substitution and support for roles. This version also
includes a patch I submitted for adding encryption support to password
Just fixing a build error, but anyway I’m proud of it.
with ignore(OSError): os.remove(somefile)
Prebuilt OS images are usually available for virtualization environments, for example see lists for OpenVZ, Vagrant, EC2, VirtualBox (also here) or Proxmox. As you can guess, some machinery is needed for building and maintaining them all. There is veewee for Vagrant, template creation guides for OpenVZ, dab for Proxmox, and so on.