Review: Ansible shows the beef

At a time when the configuration management market was dominated by Puppet and Chef, an open source project called Ansible emerged with a simpler approach to automating IT environments. An agentless system that was easy to learn, Ansible quickly earned a name for itself. Before long, the developers behind the project formed a company to offer commercial support. That company -- first known as AnsibleWorks, then Ansible -- was acquired by open source leader Red Hat in October 2015.

Originally built as an execution engine, Ansible began by allowing Linux and Unix admins to remotely run arbitrary commands on one or more machines, but it has since evolved into a complete solution for automating and managing your entire IT infrastructure. With version 2.0, Ansible added more than 200 modules to improve and expand support for Amazon Web Services, CloudStack, OpenStack, VMware, Windows, and network infrastructure, among other targets. Version 2.1 improves Docker support, adds a bunch of modules for Microsoft Azure, and removes the beta label from Windows support.

Ansible 2.x also benefits from a major rewrite of the code that parses playbooks. Perhaps the most important new and useful feature here is task blocks, which lets you group related tasks and bring exception handling (think try-catch-finally) to playbooks with ease. But other improvements, such as dynamic include statements (think loops through inventory variables) and better error-checking, help increase the power and flexibility of Ansible playbooks, while preserving their simplicity and ease of use.

Ansible architecture

Instead of an agent that runs on your systems, Ansible pushes modules (scripts) to the remote systems and executes them. By default, modules are pushed to Linux machines via Secure Shell (SSH) and to Windows machines via Windows Remote Management (WinRM). Systems are configured with “playbooks,” which are simple YAML files, and each playbook contains one or more tasks (calls to a module) that will set the system to its desired state. Playbooks are written to be idempotent, which means they can be run repeatedly and will modify the system only when a change needs to be applied. Playbooks are applied to systems based on inventory; the inventory list can be stored in a simple text file or pulled from a dynamic source like a database or a web service.

Now that we've covered playbooks, let's take a quick look at a sample inventory file:

192.168.3.1

[webservers]
doc.ansible.com
blog.ansible.com

[dbservers]
db0.ansible.com
db1.ansible.com

You can use Ansible to manage Windows as well as Unix and Linux systems, but the Ansible control node must run on Unix or Linux. Ansible can be installed on Linux systems using Yum or Apt and on OS X using Pip. The modules, which are written in Python, are divided into two categories: core and extras. Both the core and extras modules ship with Ansible, but the core modules are maintained by the core Ansible team while the extras modules are maintained mostly by the community.

Ansible Tower

In the initial days of Ansible, there was no proper graphical user interface (GUI) for users, many of whom complained the GUI tool that was available showed different results than the command-line interface (CLI). To complicate matters, the GUI tool was capable of performing only a few tasks. Taking this feedback into consideration, Ansible developed Ansible Tower: a web-based user interface that delivers a graphical representation of everything happening within the environment. With Ansible Tower, real-time monitoring of nodes became easy and reliable.

Today, Ansible Tower shows the same results as the CLI except they are in a web UI. Tower also provides separation of duties; for example, a developer can run a play on a development system with a simple click of a button and system administrators can deploy an entire stack as quickly. In a large environment, Ansible is run on a “master” server that can access all of the servers within the infrastructure, and system admins shell into the master server and run their playbooks against the remote systems. Tower basically “webifies” that process while also providing a layer of governance and audit support.

Ansible Tower comes with a useful dashboard that provides a quick summary of the entire infrastructure, and the fully documented REST API enables you to integrate Tower into your existing automation processes. You can easily create teams and users and assign roles to provide role-based access control, and job scheduling can be done with little effort. The portal view simplifies operations for new users and lets you work directly with your managed nodes on Amazon EC2, Rackspace, Azure, and other clouds that Ansible integrates with. At the same time, tasks such as creating playbooks are efficiently done in the CLI.

Playbooks vs. programming

While tools such as Puppet and Chef are popular in the market, Ansible developers considered two important aspects when creating their solution. First, there isn’t a need to learn a programming language. Ansible playbooks are simple YAML files, so no programming knowledge is required to create them. However, you'll need to understand what each module is doing and use them appropriately. In contrast, Puppet and Chef use Ruby, so they require some programming knowledge and can be harder to learn.

Second, whereas Puppet and Chef rely on agents running on managed nodes, Ansible uses the tried-and-tested SSH and WinRM network protocols to deploy modules to nodes, eliminating agent overhead.

Because Ansible uses simple YAML files, it may be easier for administrators to create and work with Ansible modules than the Ruby-based modules that comprise Chef and Puppet. As it turns out, Ansible modules are actually Python modules written in an Ansible-friendly manner. Because Ansible modules are “idempotent,” they can be executed on a node any number of times and will always produce the same result (that is, the desired state of the machine the module describes).

Ansible is designed around a push-based system -- where the control machine pushes a set of instructions or tasks to the managed nodes -- but also supports pull. In either case, an agent is not needed. Ansible pull amounts to fetching playbooks on a schedule -- using Cron, for instance. However, pull mode requires installing Ansible on the remote system, which means having one more package to manage on the node.

In contrast, Puppet and Chef have a pull-based configuration management setup, which means all nodes contact the control system on a regular interval to receive instructions or tasks. When something goes wrong, the node informs the controller and updates itself when it contacts the master.

Let’s take a look at an example. This playbook sets up a simple web server listening on port 80:

- hosts: webservers
  become: yes
  vars:
   - http_port: 80
  tasks:
   - name: Verify web server dependencies are installed
     yum: name = {{ item }} state=present
     with_items:
      - httpd
     tags:
      - application
   - name: Open http port in the firewall for RHEL 6
     lineinfile:
      dest: /etc/sysconfig/iptables
      state: present
      line: "-A INPUT -p udp -m state --state NEW -m tcp --dport {{ http_port }} -j ACCEPT"
      insertafter: '^\:OUTPUT ACCEPT'
      backup: yes
     when: ansible_distribution_major_version == "6"
     tags:
      - base
      - firewall
   - name: Open the http port in the firewall for RHEL 7
     firewalld: port = {{ http_port }}/tcp state=enabled immediate=true permanent=true
     when: ansible_distribution_major_version == "7"
     tags:
      - base
      - firewall

The process of executing Ansible playbooks is slower than executing remote tasks with agent-based tools like Puppet and Chef because Ansible has to make calls out to the clients and work more with the network stack. However, even if you've never seen a playbook before, it’s not difficult to grasp what one is doing. Playbooks are not only easy to set up and execute, but they’re easy to understand when you come back to them weeks or months later.

An Ansible overview

Ansible brings many capabilities to a growing number of management targets. Let’s take a look at some of the core components.

Provisioning. Ansible allows you to quickly provision machines within your infrastructure -- from servers and firewalls and networks to virtual infrastructure and public clouds. By provisioning the operating system with a kick-start script, then relying on playbooks for further configuration, you can automate infrastructure provisioning and manage those configurations in real time using the Ansible Tower.

Configuration management. With Ansible, configuration management becomes straightforward. Using simple YAML files, you can create Ansible playbooks to manage the infrastructure. Hundreds of modules in the core distribution can be used to build automation, and as an agentless system, Ansible is easy to set up and manage. It is simple, consistent, and secure -- relying on a simple password and/or an authentication protocol such as an SSH key or Kerberos. Whether you use an SSH key in a cloud environment or Kerberos within an enterprise environment, you would need SSH to connect and a privileged account to run your plays.

App deployment. Ansible enables businesses to quickly deploy multitier applications from a common framework. All you need to do is describe the desired state of the system in the playbook, and Ansible brings that state to the node -- regardless of the state the system is currently in.

You can easily automate repeatable tasks like installations, upgrades, and other app-related activities using playbooks. You can even deploy and manage a multitier app as a single unit. For example, you could configure a load balancer, a web tier, an app tier, and a database tier -- along with all of their interdependencies -- in a single playbook. In other words, you can have a playbook that contains all of the Ansible roles (remote systems) in your stack. Each system would be classified in an Ansible role (database, web server, load balancer) and have specific playbooks associated with them. For example, the following playbook could be used to provision an entire application environment.

# Common configuration
- hosts: all
  become: yes
  roles:
  - linux_common

# Set up database servers
- hosts: dbservers
  become: yes
  roles:
  - db

# Set up web servers
- hosts: webservers
  become: yes
  roles:
  - webserver

# Set up load balancers
- hosts: loadbalancers
  become: yes
  roles:
  - haproxy

Continuous delivery. Ansible facilitates continuous delivery and allows you to slice thousands of servers into manageable groups, allowing painless updates to hundreds of machines at a time -- all you need is a playbook. To keep it straight, source control is recommended for managing playbooks to ensure an audit trail of the changes. With multitier and multistep orchestration, you gain fine-grained control over operations -- regardless of monitoring systems, load balancers, or web services. Ansible also has a module for managing plugins for the Jenkins continuous integration server.

Security and compliance. Because Ansible uses SSH to connect to nodes, security comes down to the SSH protocol and client configuration. You can connect a single host with multiple nonroot users, and because Ansible supports sudo and other forms of privilege escalation, you can run modules as root. To provide additional security, Ansible has partnered with MindPoint Group so that Ansible roles comply with DISA STIG (the Defense Information Systems Agency’s Security Technical Implementation Guide, a government standard for secure systems). Tools such as STIGMA and OpenSCAP are available for compliance -- allowing you to verify the security configuration and track deviations.

Orchestration. Ansible helps you combine and coordinate different processes, environments, and methodologies by creating a common framework and language. You can easily weave together interlocking services such as network, storage, computing, and identity, or you can describe your multitier production application in a playbook. Ansible will ensure that the right configurations are applied to the right resources in the right order. As it turns out, OpenStack giants like HPE, Cisco, and IBM all use Ansible to orchestrate their OpenStack deployments. This is due in part to the large number of modules that allow Ansible to talk to OpenStack services.

Public cloud deployments. Drawing on 75 modules supporting Amazon Web Services, Ansible allows you to dynamically provision workloads to the AWS cloud, manage and secure those cloud deployments, and easily migrate apps to AWS. You can leverage devops in the cloud to harness the full potential of AWS, and once your AWS environment is described in Ansible, you can scale out your deployment to hundreds or even thousands of machines using the same modules and playbooks.

AWS has the lion’s share of Ansible’s cloud modules, but you’ll also find good support for OpenStack, CloudStack, and Rackspace, as well as rapidly improving support for Azure, with 18 modules and counting.