How Ansible Simplifies DevOps Implementations

Ansible is a relatively new player in the software Configuration Management space. Its initial entry into the space was as an open source software creation managed by the team at Ansible in 2012. The name Ansible is derived from the 1980s novel Ender's Game and was selected by Ansible creator, Michael DeHaan. The main effort behind the solution was to provide a simple-to-use and human-readable implementation of a Configuration Management solution.

The initial implementation of Ansible was derived in 2012 and aimed to fit the following principles:

• Minimal development required: Configuration Management systems should be lightweight and simplistic in nature.
• Consistent in execution: Ansible aims to provide a consistent set of rules and expectations in its core implementation.
• Secure: The Ansible platform was developed using SSH as its recommended protocol, which provides a secure transport method for remote execution of Configuration Management code.
• Scalable: Whether it's targeting one server or 1,000, the system needs to be able to scale effectively. Ansible has been built with this in mind.
• Highly reliable in nature: Providing a consistent execution model is the aim of Ansible—a very reliable execution platform with minimal bugs.
• Easy to learn: Eschewing on the complexity of CFEngine and others, Ansible aims to be the easiest-to-learn Configuration Management tool in the industry.

Now that we know the principles Ansible was built upon, let's take a look at how it enhances a DevOps implementation specifically.

Ansible (as we mentioned earlier) was designed to be consistent, easy to manage, scalable, secure, and minimal. With these principles in mind, let's take a quick look at a simple DevOps environment diagram and see how Ansible fits in:

In the diagram, we can see four unique environments (Dev, Test, Stage, and Production). These environments are fairly common across DevOps implementations and cloud computing software organizations. Some organizations may have more, some fewer. In a DevOps environment, there may be one or multiple servers or devices that need to be consistently provisioned and deployed to. The consistency across these environments is critical for the eventual release of a software system to production.

Ansible in many ways helps maintain consistency across environments as it provides an easy-to-use automation solution that can be executed in the following manner:

• Simultaneously across environments
• Consistently across environments
• In an idempotent manner that provides a level of congruency across environments

Given the diagram, we can see that each environment would be pushed to symmetrically use a Configuration Management tool such as Ansible. This tool would sit on a central location with access to each of the aforementioned environments. As such, it would be in many ways the governor of the systems. The diagram provided next shows the basic architecture of the push-model architecture that Ansible provides:

From this diagram, we can see a few things that fit into our Configuration Management best practices list we talked about earlier:

• The Configuration Management resources are stored in a VCS (version control system).
• The Ansible provisioning machine has access to both the VCS and the deployment servers. In some cases, this is good, but in some cases it may be useful to bundle your Ansible resources in with your artifacts (we will talk more about that later).
• Ansible has the ability to target specific server types and configure and deploy to each in a unique way. No matter whether it is the company's web, application, or main database server, Ansible automates otherwise tedious configurations so that we can concentrate on more valuable tasks. This process is done through the development of playbooks, or prewritten configuration setups, which save both time and money, as will be discussed later.