This will be Part 1 out of 2 of the Ansible primer series.

We love Ansible at AltoStack. The learning curve is very gradual and you can get value for it after a few minutes playing with it.

Ansible allows your whole infrastructure to be defined as code, so it can be version controlled, easily replicated and tested.

Basic Concepts

  • Ansible and it’s module are written in Python but you don’t need to know Python to use it
  • Ansible is Agentless
  • Ansible connects to remote servers and nodes using SSH

Terminology

Some words you’ll come across in the Ansible world.

Playbook

This is the entry point for configuration management in Ansible. A playbook is a YAML file that instructs Ansible on what to do. Below is a peak at what a playbook looks like

---
 - name: ansible playground
   hosts: all
   connection: local
   tasks:
     - debug: msg="Hello World!"
Task

Tasks define an operation to be performed on the destination host. From installing a package to staring a service and much more.

Inventory

This is an INI file that lists and groups our hosts which Ansible uses to know the destination hosts to apply configuration to. Hosts entries usually include the hostname and few variables you can pass to Playbooks.

Roles

Put simply, Roles are a collection of Tasks. For example, getting Apache up and running usually involves various tasks. To improve efficiency and reduce code duplication, we can group this task into an Apache Role that we can then reuse in multiple Playbooks.

Setting up

Ansible is can be setup in multiple ways but by far the easiest is by using the Python package manager PIP.

  • Install PIP
# Debian/Ubuntu:
apt-get install python-pip

# RedHat/CentOS/Fedora:
yum install python-pip

# MacOSX (more info):
sudo easy_install pip
  • Install Ansible
pip install ansible
  • Confirm installation
ansible --help

Inventory

By default, Ansible on Linux will look for the file /etc/ansible/hosts. A simple way to startup is to create this file with the below contents;

[localhost]
127.0.0.1

Configuration

To define a different location for your inventory file or where are Roles are located, we update the ansible.cfg file.

Ansible will look this file in the current directory, or in your home directory (named .ansible.cfg) and finally in /etc/ansible/ansible.cfg.

[defaults]
inventory = hosts
remote_user = ubuntu
host_key_checking = False

Run Playbook

We’re now setup and ready to run our first Playbook. Using the example Playbook above, save it as hello.yml

We have set our hosts to all which means Ansible will target all hosts in our inventory file which at the moment is just 127.0.0.1. We also specified connection is local to tell Ansible ro run without SSH.

This should be the structure of our ansible101 folder;

+-- ansible101
    +-- hosts.ini
    +-- ansible.cfg
    +-- hello.yml

Time to run our playbook;

ansible-playbook hello.yml

playbook_run

Anatomy of a Playbook run

  • PLAY [ ansible playground ] : The start of the Playbook run
  • TASK [ setup ] : Ansible is collecting information from the host and setting up to run the Task
  • TASK [ debug ] : Ansible is running the Task
  • PLAY RECAP : For each host, the number of tasks resulting in ok, changed, unreachable and failed

Next Steps

Hope you enjoyed the first installment of our Ansible primer series.

Next up in Part 2, now that we’ve setup, configured and run a playbook locally, we can move forward with targeting remote hosts and some more advance configuration, tips and tricks.

At AltoStack, our experts can maintain your DevOps platform and be responsible for day-to-day operational issues, allowing you to develop and ship your product without the need for internal DevOps hires.