I was invited to the first DevOps Gathering edition to talk about the lessons learned after one year of monitoring ShuttleCloud with Prometheus.
Video of the presentation:
Category: Sysadmin
[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.
Infrastructure
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.
I’m just another user who loves GNOME and suffers the blessing of its developers.
I’ve had the Close Button in the left since it was set by default in Ubuntu 10.04 and I liked it, and the button stayed in the left until GNOME 3.8.
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
lookup plugin.
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.
Ansible is a relatively new kid in the town of Configuration Management. If you don’t know it already go see this introductory video: System Provisioning with Ansible.
When using bridging for Xen Networking and your guests machines (domUs in Xen parlance) are fully managed by third parties, some sort of isolation is specially needed. A rogue admin can change the IP and/or MAC address(es) assigned to its domU and potentially cause an IP address conflict.