Key information for automating your data center with Ansible.

Get the newsletter

Ansible
is an open source automation tool used to configure servers, install
software, and perform a wide variety of IT tasks from one central
location. It is a one-to-many agentless mechanism where all instructions
are run from a control machine that communicates with remote clients
over SSH, although other protocols are also supported.
While targeted for system administrators with privileged access who
routinely perform tasks such as installing and configuring applications,
Ansible can also be used by non-privileged users. For example, a
database administrator using the mysql login ID could use Ansible to create databases, add users, and define access-level controls.
Let's go over a very simple example where a system administrator
provisions 100 servers each day and must run a series of Bash commands
on each one before handing it off to users.

This is a simple example, but should illustrate how easily commands
can be specified in yaml files and executed on remote servers. In a
heterogeneous environment, conditional statements can be added so that
certain commands are only executed in certain servers (e.g., "only
execute yum commands in systems that are not Ubuntu or Debian").
One important feature in Ansible is that a playbook describes a desired
state in a computer system, so a playbook can be run multiple times
against a server without impacting its state. If a certain task has
already been implemented (e.g., "user sysman already exists"), then Ansible simply ignores it and moves on.

Definitions

Tasks:A task is the smallest unit of
work. It can be an action like "Install a database," "Install a web
server," "Create a firewall rule," or "Copy this configuration file to
that server."

Plays:A play is made up of tasks. For
example, the play: "Prepare a database to be used by a web server" is
made up of tasks: 1) Install the database package; 2) Set a password for
the database administrator; 3) Create a database; and 4) Set access to
the database.

Playbook:A playbook is made up of
plays. A playbook could be: "Prepare my website with a database
backend," and the plays would be 1) Set up the database server; and 2)
Set up the web server.

Roles:Roles are used to save and
organize playbooks and allow sharing and reuse of playbooks. Following
the previous examples, if you need to fully configure a web server, you
can use a role that others have written and shared to do just that.
Since roles are highly configurable (if written correctly), they can be
easily reused to suit any given deployment requirements.

Ansible Galaxy:Ansible Galaxy
is an online repository where roles are uploaded so they can be shared
with others. It is integrated with GitHub, so roles can be organized
into Git repositories and then shared via Ansible Galaxy.

Please note this is just one way to organize the tasks that need to
be executed. We could have split up the installation of the database and
the web server into separate playbooks and into different roles. Most
roles in Ansible Galaxy install and configure individual applications.
You can see examples for installing mysql and installing httpd.

Tips for writing playbooks

The best source for learning Ansible is the official documentation
site. And, as usual, online search is your friend. I recommend starting
with simple tasks, like installing applications or creating users. Once
you are ready, follow these guidelines:

When testing, use a small subset of servers so that your plays
execute faster. If they are successful in one server, they will be
successful in others.

Always do a dry run to make sure all commands are working (run with --check-mode flag).

Test as often as you need to without fear of breaking things. Tasks
describe a desired state, so if a desired state is already achieved, it
will simply be ignored.

Be sure all host names defined in /etc/ansible/hosts are resolvable.

Because communication to remote hosts is done using SSH, keys have
to be accepted by the control machine, so either 1) exchange keys with
remote hosts prior to starting; or 2) be ready to type in "Yes" to
accept SSH key exchange requests for each remote host you want to
manage.

Although you can combine tasks for different Linux distributions in
one playbook, it's cleaner to write a separate playbook for each distro.

In the final analysis

Ansible is a great choice for implementing automation in your data center:

It's agentless, so it is simpler to install than other automation tools.

Instructions are in YAML (though JSON is also supported) so it's easier than writing shell scripts.

It's open source software, so contribute back to it and make it even better!

How have you used Ansible to automate your data center? Share your experience in the comments.