There's also a file called "hosts". This is the Ansible Inventory file, and it stores the hosts, and their mappings to the host groups.

The hosts file looks like this:

[example_servers]192.168.100.1 set_hostname=vm-ex01# example of setting a host inventory by IP address.# also demonstrates how to set per-host variables.

[repository_servers]example-repository#example of setting a host by hostname. Requires local lookup in /etc/hosts# or DNS.[webservers]web01[dbservers]db01

It's standard INI-like file format, hostgroups are defined in [square brackets], one host per line. Per-host variables can follow the hostname or IP address. If you declare a host in the inventory by hostname, it must be resolvable either in your /etc/hosts file, or by a DNS lookup.

The playbook definitions are in the .yml files. There's 3 in the Parallax example. Two which are separate YAML files, and one that's a kind of, catchall in 'site.yml'.

site.yml is the default name for a playbook, and you'll likely see it crop up when you look at other ansible examples (https://github.com/ansible/ansible-examples/).

You'll also see lots of files called 'main.yml'. This is the default filename for a file containing Ansible Tasks, or Handlers. More on that later.

So, site.yml, consists of 3 named blocks. If you look closely, you'll see that the blocks all have a name, they all have a hosts: line, and they all have roles.

The hosts: line sets which host group (from the Inventory file 'hosts') to apply the following roles to.

The roles: line, and subsequent role entries define the roles to apply to that hostgroup. The roles currently defined in parallax can be seen in the above tree structure.

You can either put multiple named blocks in one site.yml file, or split them up, in the manner of 'example_servers.yml' and 'repository_server.yml'

Other stuff in 'site.yml':

'user:' - This sets the name of the user to connect to the target as. Sometimes shown as remote_user in newer ansible configurations.

'sudo:' - This tells Ansible whether it should run sudo on the target when it connects. You'll probably want to set this as "sudo: yes" most often, unless you plan to connect as root. In which case, this (ಠ.ಠ) is for you.

Roles

=====

A role should encapsulate all the things that have to happen to make a thing work. If that sounds vague, it's because it is.

The parallax example has a role called common, which installs and configures the things that I've found are useful as prerequisites for other things. You should go through and decide which bits you want to put into your 'common' role, if you decide to have one.

Roles can have dependencies, which will require that another role be applied first. This is good for things like handling the dependencies before you deploy code.

meta/ contains YAML files containing role dependencies. Usually just meta/main.yml

tasks/ contains YAML files containing a list of named steps which Ansible will execute in order on a target. Usually tasks/main.yml

templates/ contains Jinja2 template files, which can be used in a task with the template: module to interpolate variables in the template, then copy the template to a location on the target. Files in this directory often end .j2 by convention.

Example Role: Redis

-------------------

Path: parallax/playbooks/example/roles/redis

Structure:

.├── files├── handlers├── meta├── tasks│ └── main.yml└── templates

All there is in this one, is a task file, unsurprisingly called 'main.yml' - Told you that name would crop up again. - Actually, there's a .empty file under files, handlers, meta, and templates. This is just so that if you commit it to git, the empty directories won't vanish.

apt_repository: module configures a new apt repository for the system. It can take a ppa name, or a URL for a repository. update_cache tells ansible to run apt-get update after it's added the new repository.

apt: module tells Ansible to run apt-get install $pkg using whatever value has been defined for pkg.

service: tells Ansible to execute "sudo service $name start" on the target.

I recommend you have a trawl through the roles as configured in Parallax, and see if you can make sense of how they work. If you open the Ansible Module Index, you'll be able to use that as a quick reference guide for the modules in the roles.

One of the most useful features of Ansible, in my opinion is the "with_items:" action that some modules support. If you want to install multiple packages with apt at the same time, the easiest way to do it is like this:

I'm going to run ansible-playbook -i hosts site.yml and see what happens.

For the first run, we'll need to tell ansible the SSH and Sudo passwords, because one of the thing that the common role does is to configure passwordless sudo, and deploy a SSH key.

In order to use Ansible with SSH passwords (pretty much required for the first run of normal machines (unless you deploy keys with something far lower level, like kickstart), you'll need the sshpass program.

On ubuntu, you can install that as follows:

sudo apt-get install sshpass

When you use Parallax as a starting point, one thing you'll want to do is edit

roles/common/files/authorized_keys

and put your keys in it.

So, for a first run, it's:

ansible-playbook -i hosts -k -K site.yml

You'll get the following prompts for the ssh password, and the sudo password:

SSH password:sudo password [defaults to SSH password]:

Enter whatever password you gave Ubuntu at install time.

Once the following tasks have completed, you can remove -k -K from the ansible command line