2016 Update: If you are using Windows 10 or later, check out my newer instructions for Using Ansible through Windows 10's Subsystem for Linux.
Ansible is a simple and powerful infrastructure and configuration management tool that Server Check.in uses to manage it's infrastructure. Installing and using Ansible on Mac OS X or Linux workstations is incredibly easy, and takes all of 30 seconds to set up.
Server Check.in's entire infrastructure is managed via Ansible, which has helped tremendously as the service has grown from one to many servers.
cowsay and Ansible were made for each other.
One pain point with running Apache servers that host more than one website (using name-based virtual hosts) is that the virtual host configuration files quickly get unwieldy, as you have to define the entire <VirtualHost /> for every domain you have on the server, and besides Apache's mod_macro, there's no easy way to define a simple structured array of information and have the vhost definitions built from that.
While getting a local VM managed by Vagrant to work with Ansible for provisioning, I kept getting errors like the following:
fatal: [solr] => SSH encountered an unknown error during the connection. We recommend you re-run the command using -vvvv, which will enable SSH debugging output to help diagnose the issue
[vm-name-here] : ok=0 changed=0 unreachable=1 failed=0
FATAL: no hosts matched or all hosts have already failed -- aborting
Ansible failed to complete successfully. Any error output should be
visible above. Please fix these errors and try again.
It seems that Ansible is unable to connect to the VirtualBox host via SSH because the entry for 127.0.0.1 in my ~/.ssh/known-hosts file is set for my local computer, and not for any VMs. To work around this limitation, I created a new file, ~/.ssh/config, with the contents:
Host 127.0.0.1
StrictHostKeyChecking no
UserKnownHostsFile=/dev/null
Now, when Ansible tries connecting during provisioning, it doesn't check the host key for localhost, and provisioning succeeds.
For the past few years, as the number of servers I manage has increased from a few to many, and the services I operate have required more flexibility in terms of adding and removing similarly-configured servers for different purposes, I've been testing different deployment and configuration management tools.
Many developers who are also sysadmins have progressed much the same way as I have, beginning by building everything by hand without documenting the process, then documenting the build with text files, and ultimately scripting builds with bash scripts. However, none of these techniques allow fast provisioning, continuous configuration management, or the flexibility required to make constantly-evolving applications adapt to the requirements of the day.
In recent years, 'DevOps' (better integration of development and operations) has become a hot buzzword and mantra of companies espousing agile development methodologies.
Source: DevOps.com
Servers, like instances of applications, should be managed via version-controlled configuration, and should be disposable (a common war cry: Trash Your Servers and Burn Your Code. If a server blows up, or if another few application servers are needed, they should be able to be provisioned or decommissioned in minutes, not hours (much less days or weeks!), and should be able to be provisioned and decommissioned automatically, without human intervention.