For several years, LCSEE Systems has used Debian packaging to automate the installation of software on servers and desktop computers, reducing the amount of time and effort required versus manual configuration by hand. While Debian packaging has fulfilled its role as an automation tool, numerous facets of its behavior are non-ideal for Systems configuration management. The package author is limited to actions which are amenable given the features of Debian packaging. For example, the primary means to automatically execute commands during package installation is a singleBASH script denoted as the post-install script. Implementing the post-install script for non-trivial software requires deciding which installation steps to include in the script and which to perform by hand following package installation. In an effort to include every required task, many complex packages have rather intricate post install steps, to reduce the number of steps which must be performed by hand. Additionally, intricate packages can become a serious maintenance burden, as passing the responsibility of package maintenance to a second author following the departure of the original is time-consuming and tedious. Clearly, this provisioning system has left much to be desired.
"I wrote Ansible because none of the existing tools fit my brain. I wanted a tool I could not use for six months, come back later, and still remember how it worked."
–Michael DeHaan, Ansible project founder
Ansible is an open-source software that provides a platform enabling administrators to automate tasks in an intuitive manner, owing greatly to simple, straightforward syntax. One of the most attractive features of Ansible is that it only requires an SSH server running on the target machine for operation. A consequence is that unlike other automation tools, there’s no need to preseed an image with everything needed before hand, such as custom agents.
Automating tasks via Ansible is performed via playbooks. The administrator writes the playbook in a YAML file that makes use of various Ansible modules to define a set of tasks. Once the playbook is complete, it can be applied to a target machine. At least one machine is designated as the control machine, requiring the Ansible software, which requires a Linux operating system and the Python programming language. This brings up another great feature of Ansible – a central server is not required for deploying playbooks. This kind of system can be setup if desired, but the ability to provision machines from a plethora of locations is convenient for administrators that need the flexibility.
An example Ansible Playbook to configure the squid service.
The primary motivation for LCSEE Systems migrating configuration management to Ansible is to support the recent creation of a new Systems infrastructure in the cloud using Amazon Web Services (AWS). This new set of server instances could been provisioned using Debian packaging as was done previously, but it was clearly an opportune time to deploy an improved provisioning system. The new configuration management process is straightforward. First an individual writes a Ansible playbook in a test environment. Once the playbook has been developed it is stored in a git repository. A new AWS instance is created. Once the new instance is up and running, the administrator then fetches the playbook from the git repository and executes it, initiating installation on the new instance.
Unlike Debian packages, Ansible simplifies automation of every part of the software installation process. This is primarily due to their vast set of modules that are specifically designed to perform common tasks. This set of modules also has hooks to make use of Amazon software such as EC2, S3, Route53, and even has modules for other technologies like Redis, Docker and Digital Ocean.
In this brief introduction to LCSEE Systems Ansible deployment I’ve barely scratched the surface of Ansible’s capabilities. It has a plethora of security features such as the Vault for encrypting sensitive data. Once you become accustomed to writing playbooks, you can learn how to use them to call other playbooks, eventually reaching the point of being able to set up an entire infrastructure with a “single” playbook all of which that inherits parts of itself from other playbooks.. Ansible itself has a great set of tutorials and I highly advise you take the time to look through them if you are interested. They can be found here.
To recap, Why Ansible? First, it’s simple. It requires basically little more than SSHrunning on the target machine. The playbooks themselves make use of a very simple set of syntax in YAML, all of which can easily be learned by non-programmers. When you are ready to deploy the playbook, you can do so from anywhere that has the Ansible package installed, no need for a central server. In the words of Ansible, it “makes deploying software fun again”.
Contributors: Barry Martin, Terry Ferrett, Marc Seery, David Krovich