Getting Started with Ansible

Exclusive offer: get 50% off this eBook here
Ansible Configuration Management

Ansible Configuration Management — Save 50%

Leverage the power of Ansible to quickly configure your Linux infrastructure with ease

$20.99    $10.50
by Daniel Hall | November 2013 | Open Source

The article by Daniel Hall the author of Ansible Configuration Management, teaches you the basics of Ansible, how to build an inventory, how to use modules, and, most importantly, how to get help. Ansible is profoundly different from other configuration management tools available today. It has been designed to make configuration easy in almost every way, from its simple English configuration syntax to its ease of set up. You'll find that Ansible allows you to stop writing custom configuration and deployment scripts and lets you simply get on with your job.

(For more resources related to this topic, see here.)

First steps with Ansible

Ansible modules take arguments in key value pairs that look similar to key=value, perform a job on the remote server, and return information about the job as JSON. The key value pairs allow the module to know what to do when requested. The data returned from the module lets Ansible know if anything changed or if any variables should be changed or set afterwards.

Modules are usually run within playbooks as this lets you chain many together, but they can also be used on the command line. Previously, we used the ping command to check that Ansible had been correctly setup and was able to access the configured node. The ping module only checks that the core of Ansible is able to run on the remote machine but effectively does nothing.

A slightly more useful module is called setup. This module connects to the configured node, gathers data about the system, and then returns those values. This isn't particularly handy for us while running from the command line, however, in a playbook you can use the gathered values later in other modules.

To run Ansible from the command line, you need to pass two things, though usually three. First is a host pattern to match the machine that you want to apply the module to. Second you need to provide the name of the module that you wish to run and optionally any arguments that you wish to give to the module. For the host pattern, you can use a group name, a machine name, a glob, and a tilde (~), followed by a regular expression matching hostnames, or to symbolize all of these, you can either use the word all or simply *.

To run the setup module on one of your nodes, you need the following command line:

$ ansible machinename -u root -k -m setup

The setup module will then connect to the machine and give you a number of useful facts back. All the facts provided by the setup module itself are prepended with ansible_ to differentiate them from variables. The following is a table of the most common values you will use, example values, and a short description of the fields:

Field

Example

Description

ansible_architecture

x86_64

The architecture of the managed machine

ansible_distribution

CentOS

The Linux or Unix Distribution on the managed machine

ansible_distribution_version

6.3

The version of the preceding distribution

ansible_domain

example.com

The domain name part of the server's hostname

ansible_fqdn

machinename.example.com

This is the fully qualified domain name of the managed machine.

ansible_interfaces

["lo", "eth0"]

A list of all the interfaces the machine has, including the loopback interface

ansible_kernel

2.6.32-279.el6.x86_64

The kernel version installed on the managed machine

ansible_memtotal_mb

996

The total memory in megabytes available on the managed machine

ansible_processor_count

1

The total CPUs available on the managed machine

ansible_virtualization_role

guest

Whether the machine is a guest or a host machine

ansible_virtualization_type

kvm

The type of virtualization setup on the managed machine

These variables are gathered using Python from the host system; if you have facter or ohai installed on the remote node, the setup module will execute them and return their data as well. As with other facts, ohai facts are prepended with ohai_ and facter facts with facter_. While the setup module doesn't appear to be too useful on the command line, once you start writing playbooks, it will come into its own.

If all the modules in Ansible do as little as the setup and the ping module, we will not be able to change anything on the remote machine. Almost all of the other modules that Ansible provides, such as the file module, allow us to actually configure the remote machine.

The file module can be called with a single path argument; this will cause it to return information about the file in question. If you give it more arguments, it will try and alter the file's attributes and tell you if it has changed anything. Ansible modules will almost always tell you if they have changed anything, which becomes more important when you are writing playbooks.

You can call the file module, as shown in the following command, to see details about /etc/fstab:

$ ansible machinename -u root -k -m file -a 'path=/etc/fstab'

The preceding command should elicit a response like the following code:

machinename | success >> { "changed": false, "group": "root", "mode": "0644", "owner": "root", "path": "/etc/fstab", "size": 779, "state": "file" }

Or like the following command to create a new test directory in /tmp:

$ ansible machinename -u root -k -m file -a 'path=/tmp/test state=directory mode=0700 owner=root'

The preceding command should return something like the following code:

machinename | success >> { "changed": true, "group": "root", "mode": "0700", "owner": "root", "path": "/tmp/test", "size": 4096, "state": "directory" }

The second command will have the changed variable set to true, if the directory doesn't exist or has different attributes. When run a second time, the value of changed should be false indicating that no changes were required.

There are several modules that accept similar arguments to the file module, and one such example is the copy module. The copy module takes a file on the controller machine, copies it to the managed machine, and sets the attributes as required. For example, to copy the /etc/fstabfile to /tmp on the managed machine, you will use the following command:

$ ansible machinename -m copy -a 'path=/tmp/fstab mode=0700 owner=root'

The preceding command, when run the first time, should return something like the following code:

machinename | success >> { "changed": true, "dest": "/tmp/fstab", "group": "root", "md5sum": "fe9304aa7b683f58609ec7d3ee9eea2f", "mode": "0700", "owner": "root", "size": 637, "src": "/root/.ansible/tmp/ansible-1374060150.96- 77605185106940/source", "state": "file" }

There is also a module called command that will run any arbitrary command on the managed machine. This lets you configure it with any arbitrary command, such as a preprovided installer or a self-written script; it is also useful for rebooting machines. Please note that this module does not run the command within the shell, so you cannot perform redirection, use pipes, and expand shell variables or background commands.

Ansible modules strive to prevent changes being made when they are not required. This is referred to as idempotency and can make running commands against multiple servers much faster. Unfortunately, Ansible cannot know if your command has changed anything or not, so to help it be more idempotent you have to give it some help. It can do this either via the creates or the removes argument. If you give a creates argument, the command will not be run if the filename argument exists. The opposite is true of the removes argument; if the filename exists, the command will be run.

You run the command as follows:

$ ansible machinename -m command -a 'rm -rf /tmp/testing removes=/tmp/testing'

If there is no file or directory named /tmp/testing, the command output will indicate that it was skipped, as follows:

machinename | skipped

Otherwise, if the file did exist, it will look as follows:

ansibletest | success | rc=0 >>

Often it is better to use another module in place of the command module. Other modules offer more options and can better capture the problem domain they work in. For example, it would be much less work for Ansible and also the person writing the configurations to use the file module in this instance, since the file module will recursively delete something if the state is set to absent. So, this command would be equivalent to the following command:

$ ansible machinename -m file -a 'path=/tmp/testing state=absent'

If you need to use features usually available in a shell while running your command, you will need the shell module. This way you can use redirection, pipes, or job backgrounding. You can pick which shell to use with the executable argument. However, when you write the code, it also supports the creates argument but does not support the removes argument. You can use the shell module as follows:

$ ansible machinename -m shell -a '/opt/fancyapp/bin/installer.sh > /var/log/fancyappinstall.log creates=/var/log/fancyappinstall.log'

Summary

In this article, we have covered which installation type to choose, installing Ansible, and how to build an inventory file to reflect your environment. After this, we saw how to use Ansible modules in an ad hoc style for simple tasks. Finally, we discussed how to learn which modules are available on your system and how to use the command line to get instructions for using a module.

Resources for Article:


Further resources on this subject:


Ansible Configuration Management Leverage the power of Ansible to quickly configure your Linux infrastructure with ease
Published: November 2013
eBook Price: $20.99
Book Price: $34.99
See more
Select your format and quantity:

About the Author :


Daniel Hall

Daniel Hall started as a Systems Administrator at RMIT University after completing his Bachelor of Computer Science degree there in 2009. More recently, he has been working to improve the deployment processes at realestate.com.au. Like many System Administrators, he is constantly trying to make his job easier and easier, and has been using Ansible to this effect.

Books From Packt


Microsoft System Center 2012 Configuration Manager: Administration Cookbook
Microsoft System Center 2012 Configuration Manager: Administration Cookbook

Puppet 3 Beginner’s Guide
Puppet 3 Beginner’s Guide

Arch Linux Environment Setup How-to
Arch Linux Environment Setup How-to

Visual SourceSafe 2005 Software Configuration Management in Practice
Visual SourceSafe 2005 Software Configuration Management in Practice

Instant Puppet 3 Starter
Instant Puppet 3 Starter

Linux Utilities Cookbook
Linux Utilities Cookbook

JBoss AS 7 Configuration, Deployment and Administration
JBoss AS 7 Configuration, Deployment and Administration

Puppet 3 Cookbook
Puppet 3 Cookbook


No votes yet

Post new comment

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
w
5
5
U
r
k
Enter the code without spaces and pay attention to upper/lower case.
Code Download and Errata
Packt Anytime, Anywhere
Register Books
Print Upgrades
eBook Downloads
Video Support
Contact Us
Awards Voting Nominations Previous Winners
Judges Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software
Resources
Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software