Ansible Galaxy is simply the easiest way of finding already written Ansible roles, creating and sharing your roles and jump into the galaxy of Ansible content!

==================== Prime time announcement ! ====================

FOSDEM PGDay 2016 will be on 29th of January before FOSDEM which is Europe’s biggest open source event and PostgreSQL Devroom will be on 31st of January at FOSDEM in Brussels.

If you’re interested in configuration management, server orchestration, automated deployment (that’s why you’re reading this blog post, right?) and you like working with PostgreSQL (for sure) on AWS (optionally), then you might want to join my talk “Managing PostgreSQL with Ansible” on 29th Jan, 12:30-13:20.

Please check the amazing schedule for both of the events! Hope to see you in Brussels this week!

==================== Prime time announcement ! ====================

Hello Ansible Galaxy!

Ansible has a powerful community which makes them even more powerful. Developers who contribute to Ansible are happy to contribute and users who use Ansible for their own systems are happy to use it.

Ansible Galaxy is your hub for finding, reusing and sharing the best Ansible content.

The Ansible content they referred to on their webpage is basically Ansible roles. Let’s continue with roles in this blog post and try to understand what Ansible role means, and what are differences between roles, playbooks and tasks.

What is an Ansible Role?

You absolutely should be using roles. Roles are great. Use roles. Roles! Did we say that enough? Roles are great.

Before talking about roles, let’s remember the definition of task and playbook in Ansible terminology.

Task

Tasks are responsible for calling a module with a specific set of parameters.

Modules (also referred to as “task plugins” or “library plugins”) are the ones that do the actual work in ansible, they are what gets executed in each playbook task. But you can also run a single one using the ‘ansible’ command.

You can read my previous blog post for learning about Ansible modules and check Ansible Postgres modules with examples.

Each Ansible task contains a name, a module to be called upon, module parameters, and optionally pre/post-conditions. They allow us to call Ansible modules and pass information to consecutive tasks.

Task below invokes the file module by providing 4 parameters.

- name: Ensure the data folder has right ownership
  file: path="/var/lib/postgresql" state=directory owner=postgres group=postgres

It ensures 3 conditions are true:

• /var/lib/postgresql exists as a directory
• owner of /var/lib/postgresql is “postgres”
• group of /var/lib/postgresql is “postgres”

If it doesn’t exist, Ansible creates the directory and assigns owner & group. If only the owner is different, Ansible makes it “postgres”.

Playbook

Playbooks contain plays and plays contain tasks. Tasks call modules and may (optionally) trigger handlers (run once, run at the end).

If Ansible modules are the tools in your workshop, playbooks are your design plans. Ansible playbooks are written using the YAML syntax. Playbooks may contain more than one play. Each play contains name of host groups to connect to and tasks it needs to perform. A play may also contain variables/roles/handlers, if defined.

Now we can check out a very simple playbook example below:

- name: Ensure all virtual machines are ready
  hosts: 127.0.0.1
  connection: local
  vars_files: # load default variables from YAML files below
    - 'defaults/postgresql.yml'
    - 'defaults/aws.yml'
  tasks:
    - include: 'tasks/provision.yml' # load infrastructure setup tasks

- name: Ensure all required PostgreSQL dependencies ready
  hosts: postgresql-all # manage all PostgreSQL servers
  sudo: yes
  sudo_user: root
  vars_files:
    - 'defaults/postgresql.yml'
    - 'defaults/aws.yml'
  tasks:
    - include: 'tasks/postgresql.yml' # load PostgreSQL setup tasks

In this playbook we have two plays:

First play ensures all virtual machines are ready and operates on localhost. It loads default variables from YAML files named postgresql.yml and aws.yml. You can think of these files as configuration files for PostgreSQL and AWS (in our example) roles and playbooks, as you can see both of the plays use these files for default variables. This play calls provision.yml task which contains infrastructure setup tasks.

Second play ensures all required PostgreSQL dependencies ready and operates on postgres servers which are defined in the inventory file. This play calls postgresql.yml task which contains PostgreSQL setup tasks.

If you would like to see full playbook you are welcomed to check my repository and contribute it to make it better.

For grasping the playbook concept better, you can look at example playbooks that is suggested at Ansible docs.

Let’s turn back to talking about roles. In Ansible;

• Playbooks organize tasks
• Roles organize playbooks

Imagine that we have lots of independent resources to manage (e.g., web servers, PostgreSQL servers, logging, monitoring, AWS). Putting everything in a single playbook may result in an unmaintainable solution.

To reduce such complexity, roles help us with:

Splitting tasks into much smaller playbooks

This allows us to focus on resources, independently. That makes it simpler to maintain and debug. Also it will be much easier to understand the structure.

Reusing configs, files, templates, tasks

This way we can easily share those components between playbooks, without rewriting over and over.

Handling playbook dependencies

When we execute a role, we can be sure that all of the preconditions are satisfied for that role.

Here you can see a dependency graph and the corresponding role directory structure:

PostgreSQL Roles in Ansible Galaxy

While I was writing this blog post there were 146 roles which turns as an output of postgresql and postgres filter search.

I personally suggest checking a couple of these roles and use them in your architectures if they are good enough, and meets your needs; if they are not, sign up to Ansible Galaxy and create your own roles.

Happy hacking!

For more information about Ansible:

• Check out their well-written docs.
• Watch Ansible quick start video which is a really helpful tutorial.
• Follow their webinar schedule, there are some cool upcoming webinars on the list.