2ndQuadrant is now part of EDB

Bringing together some of the world's top PostgreSQL experts.

2ndQuadrant | PostgreSQL
Mission Critical Databases
  • Contact us
  • EN
    • FR
    • IT
    • ES
    • DE
    • PT
  • Support & Services
  • Products
  • Downloads
    • Installers
      • Postgres Installer
      • 2UDA – Unified Data Analytics
    • Whitepapers
      • Business Case for PostgreSQL Support
      • Security Best Practices for PostgreSQL
    • Case Studies
      • Performance Tuning
        • BenchPrep
        • tastyworks
      • Distributed Clusters
        • ClickUp
        • European Space Agency (ESA)
        • Telefónica del Sur
        • Animal Logic
      • Database Administration
        • Agilis Systems
      • Professional Training
        • Met Office
        • London & Partners
      • Database Upgrades
        • Alfred Wegener Institute (AWI)
      • Database Migration
        • International Game Technology (IGT)
        • Healthcare Software Solutions (HSS)
        • Navionics
  • Postgres Learning Center
    • Webinars
      • Upcoming Webinars
      • Webinar Library
    • Whitepapers
      • Business Case for PostgreSQL Support
      • Security Best Practices for PostgreSQL
    • Blog
    • Training
      • Course Catalogue
    • Case Studies
      • Performance Tuning
        • BenchPrep
        • tastyworks
      • Distributed Clusters
        • ClickUp
        • European Space Agency (ESA)
        • Telefónica del Sur
        • Animal Logic
      • Database Administration
        • Agilis Systems
      • Professional Training
        • Met Office
        • London & Partners
      • Database Upgrades
        • Alfred Wegener Institute (AWI)
      • Database Migration
        • International Game Technology (IGT)
        • Healthcare Software Solutions (HSS)
        • Navionics
    • Books
      • PostgreSQL 11 Administration Cookbook
      • PostgreSQL 10 Administration Cookbook
      • PostgreSQL High Availability Cookbook – 2nd Edition
      • PostgreSQL 9 Administration Cookbook – 3rd Edition
      • PostgreSQL Server Programming Cookbook – 2nd Edition
      • PostgreSQL 9 Cookbook – Chinese Edition
    • Videos
    • Events
    • PostgreSQL
      • PostgreSQL – History
      • Who uses PostgreSQL?
      • PostgreSQL FAQ
      • PostgreSQL vs MySQL
      • The Business Case for PostgreSQL
      • Security Information
      • Documentation
  • About Us
    • About 2ndQuadrant
    • 2ndQuadrant’s Passion for PostgreSQL
    • News
    • Careers
    • Team Profile
  • Blog
  • Menu Menu
You are here: Home1 / Blog2 / 2ndQuadrant3 / PostgreSQL Planet in Ansible Galaxy
Gulcin Yildirim

PostgreSQL Planet in Ansible Galaxy

January 27, 2016/0 Comments/in 2ndQuadrant, Gulcin's PlanetPostgreSQL, PostgreSQL /by Gulcin Yildirim

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!

AnsibleGalaxy

==================== 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:

Roles

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.

PostgresRoles

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.
Tags: Ansible, Ansible modules, Ansible roles, ansible-galaxy, automation, database, devops, main.yml, modules, open source, playbook, postgres, PostgreSQL, Roles, streaming replication, yml
Share this entry
  • Share on Facebook
  • Share on Twitter
  • Share on WhatsApp
  • Share on LinkedIn
0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Search

Get in touch with us!

Recent Posts

  • Random Data December 3, 2020
  • Webinar: COMMIT Without Fear – The Beauty of CAMO [Follow Up] November 13, 2020
  • Full-text search since PostgreSQL 8.3 November 5, 2020
  • Random numbers November 3, 2020
  • Webinar: Best Practices for Bulk Data Loading in PostgreSQL [Follow Up] November 2, 2020

Featured External Blogs

Tomas Vondra's Blog

Our Bloggers

  • Simon Riggs
  • Alvaro Herrera
  • Andrew Dunstan
  • Craig Ringer
  • Francesco Canovai
  • Gabriele Bartolini
  • Giulio Calacoci
  • Ian Barwick
  • Marco Nenciarini
  • Mark Wong
  • Pavan Deolasee
  • Petr Jelinek
  • Shaun Thomas
  • Tomas Vondra
  • Umair Shahid

PostgreSQL Cloud

2QLovesPG 2UDA 9.6 backup Barman BDR Business Continuity community conference database DBA development devops disaster recovery greenplum Hot Standby JSON JSONB logical replication monitoring OmniDB open source Orange performance PG12 pgbarman pglogical PG Phriday postgres Postgres-BDR postgres-xl PostgreSQL PostgreSQL 9.6 PostgreSQL10 PostgreSQL11 PostgreSQL 11 PostgreSQL 11 New Features postgresql repmgr Recovery replication security sql wal webinar webinars

Support & Services

24/7 Production Support

Developer Support

Remote DBA for PostgreSQL

PostgreSQL Database Monitoring

PostgreSQL Health Check

PostgreSQL Performance Tuning

Database Security Audit

Upgrade PostgreSQL

PostgreSQL Migration Assessment

Migrate from Oracle to PostgreSQL

Products

HA Postgres Clusters

Postgres-BDR®

2ndQPostgres

pglogical

repmgr

Barman

Postgres Cloud Manager

SQL Firewall

Postgres-XL

OmniDB

Postgres Installer

2UDA

Postgres Learning Center

Introducing Postgres

Blog

Webinars

Books

Videos

Training

Case Studies

Events

About Us

About 2ndQuadrant

What does 2ndQuadrant Mean?

News

Careers 

Team Profile

© 2ndQuadrant Ltd. All rights reserved. | Privacy Policy
  • Twitter
  • LinkedIn
  • Facebook
  • Youtube
  • Mail
SCALE 14x PgBouncer 1.7 – “Colors Vary After Resurrection”
Scroll to top
×