What is Ansible

Ansible allows you to manage the configuration of remote linux server instances — whether config files, installed software.

Additionally Ansible can create hosts in EC2 (and other clouds or VPS providers such as digitalocean), in Vagrant, through cobbler, etc.

Ansible is open source

Why Ansible?

• No special privileges required — does not run as root
• Runs tasks under ssh — no new daemon required
• Runs under python — so runs on most standard linux installs
• Usable orchestration platform — it can coordinate the application of configuration management
• Improvements to Ansible are accepted upstream

Fundamentals of Ansible

Key concepts of Ansible include:

• Playbooks
• Inventory
• Templates
• Roles

Playbooks

Playbooks specify a list of tasks* that are run in sequence across one or more hosts. Each task can also run multiple times with a variable taking a different value

- hosts: localhost
  connection: local
  tasks:
  — name: create ex1, ex2 directories in current directory
    action: file state=directory dest={{item}}
    with_items: [ex1, ex2]

* Also: roles, handlers, variables. But mostly tasks!

Inventory

Inventory is the representation of information about hosts — what groups a host belongs to, the properties those groups and hosts have. A hierarchy of groups often results

Inventory

Inventory

• You can configure your inventory using the -i flag or set it in your Ansible config file, and it can point to a static file (typically called hosts) or a dynamic inventory script (e.g. ec2.py).
• Ansible will pick up group_vars and host_vars directories that live in the same location as the inventory file, and look for group and host variables there.
• So if the hosts file lives in ~/inventory/hosts, then the information about the exampleapp group would live in ~/inventory/group_vars/exampleapp.yml

Templates

Templates allow you to generate configuration files from values set in various inventory properties. This means that you can store one template in source control that applies to many different environments.

An example might be a file specifying database connection information that would have the same structure but different values for dev, test and prod environments

db.settings={{dbhost}}:{{dbport}}/{{dbuser}}:{{dbpass}}@{{dbschema}}

Roles

Roles are a way to encapsulate common tasks and properties for reuse. One example is to install java, a very common task!

- role: ../../../common/roles/java7/0.3.0
  minor_version: 45
  dest: /opt/java

If you find yourself writing the same tasks in multiple playbooks, turn them into roles.

Getting started with Ansible

You will need:

• A host on which to run Ansible
• A sensible ssh setup to talk to target hosts
• Some playbooks
• A config file
• Some inventory

Best Practices

Code reuse: sharing common code

• Check out Ansible Galaxy for existing implementations of roles
• Use common roles, and create new common roles.

Versioning

• Use versioning for common roles so that older playbooks can keep linking to older roles.
• You should ensure that when you use git or hg in your playbooks, you refer to a specific commit so that later runs of the same playbook do not have a different effect

Avoid command/shell

Ansible modules are designed to be safely repeatable

Use the file module rather than command with rm, mkdir, rmdir etc.

Other modules that replace shell commands include synchronize, unarchive, git, hg, svn

You'll need to merge in patch #5123 for this to work in your environment

Checks, commits

As with any software development, make the most of the tools of your environment. Agree coding standards with your teams, and enforce them with pre- or post-commit scripts.

You can use e.g. ansible-playbook --syntax-check to ensure that the playbook is syntactically valid, for example

Managing AWS

This is not specifically Ansible related — there are some things you just have to do to manage AWS. But this is how the two go together

The basics

Ansible relies on boto. With a suitable ~/.boto config file, the playbook that creates an instance looks a bit like:

  - name: create instance
    ec2:
      user_data: "{{ lookup('template', '../templates/userdata.tmpl') }}"
      region: "{{region}}"
      image: "{{rhel6ami}}"
      instance_type: "{{instance_type}}"
      vpc_subnet_id: "{{vpc_subnet}}"
      group_id: "{{security_group}}"
    register: ec2

What else?

• ELBs
• EBS volumes and snapshots
• Autoscaling groups, policies etc
• RDS
• …