Managing PostgreSQL with Ansible

Postgres Build 2020 Managing PostgreSQL with Ansible
Andreas Scherbaum
2/122
Agenda
●
What is PostgreSQL
●
What is Ansible
●
Ansible Ad-hoc
●
Ansible Playbooks
●
Bring it all together
●
Run it automated
●
Summary

Andreas Scherbaum
3/122
Andreas Scherbaum
●
Working with databases since 1997, with PostgreSQL since 1998
●
Founding member of the European and German PostgreSQL User Group
●
Board of Directors – European PostgreSQL User Group
●
Organizing pgconf.eu, pgconf.de, FOSDEM PGDay
●
Regional Contact PostgreSQL for Germany
●
Ran my own company for 7+ years – around PostgreSQL
●
Wrote a book about PostgreSQL (in German)
●
Worked for EMC/Pivotal from 2011 – August 2020
●
Joined Adjust in September 2020

Andreas Scherbaum
4/122
Get Social ...
●
Twitter, Instagram & Tumblr: @ascherbaum
●
LinkedIn: https://www.linkedin.com/in/andreas-scherbaum-87b6663/
●
Mastadon: https://mastodon.social/@ascherbaum
●
Diaspora: ads@pluspora.com
●
Blog: https://andreas.scherbaum.la/

Andreas Scherbaum
6/122
Source: unknown

Andreas Scherbaum
8/122
Ansible
●
Ansible is:
– Fictional device for superluminal communication
●
Can send and receive messages without delay, over any
distance
●
From the 1966 novel “Rocannon’s World” by Ursula le
Guin
●
Later adapted by other science fiction, most notably:
“Ender’s Game”

Andreas Scherbaum
9/122
Ansible
●
Ansible is:
– Open Source software for provisioning, configuration management, and application
deployment
– Manages many systems in parallel, by executing tasks over [ssh|Windows Remote
Management|PowerShell]
– Manages Unix-like and Microsoft Windows systems
●
Ansible host has to be Unix/Linux
– Under development since 2012, acquired by Red Hat in 2015
●
Current stable version: 2.10.x
– Python knowledge useful, but not required

Andreas Scherbaum
10/122
Ansible Advantages
●
Code = Documentation
– If done properly
●
Playbooks are idempotent
– Can be re-run any time, only change what’s necessary
●
Can deploy and manage large clusters of machines in parallel
●
Playbooks can be run from multiple locations
– As long as access is handled
– No host agent necessary
●
Extensive and powerful variable and template handling
●
Requirements: Python (v3)
– Some Ansible modules require additional Python modules

Postgres Vision 2020 Managing PostgreSQL with Ansible
Andreas Scherbaum
11/122
Ansible
Ansible
Controller
Host 1
Webserver
Host 2
Webserver
Host 3
Database
Host 4
Load
Balancer
ssh

Andreas Scherbaum
12/122
Ansible Modules
●
Database: PostgreSQL, MongoDB, MS SQL, MySQL,
InfluxDB, …
●
Files: fetch, copy, template, find, file, acl, archive, patch,
archive, xml, xattr, …
●
Network: AWS, GPC, [Switches], [Firewalls], [Loadbalancers]
●
Storage, Notification, Crypto, Cloud, Source Control, ...
●
Expandable!

Andreas Scherbaum
13/122
Ansible
Ansible
Controller
Host 1
Webserver
Host 2
Webserver
Host 3
PostgreSQL
Host 4
Load
Balancer
ssh

Andreas Scherbaum
14/122
Ansible PostgreSQL Modules (as of v2.10)
●
Manage: databases, roles (user), membership, owner, schema,
extensions, languages, privileges, publications, sequences,
tables, indexes, replication slots
●
Information: retrieve information about PG servers, ping servers
●
pg_hba: manage access control
●
Query: run queries against the database, or COPY data
●
Many of the useful modules are available starting with version 2.8

Andreas Scherbaum
16/122
Ad-hoc queries
●
Ansible allows to run ad-hoc commands against any given host
or host group
– Example: ping (check if host is alive, and Ansible can login)

Andreas Scherbaum
17/122
ping
ansible -i 127.0.0.1, -m ping all

Andreas Scherbaum
18/122
ping
Inventory

Andreas Scherbaum
19/122
ping
Inventory Hostlist
(as Python list,
with comma)

Andreas Scherbaum
20/122
ping

Andreas Scherbaum
21/122
ping
Module

Andreas Scherbaum
22/122
ping
Module Module
Name

Andreas Scherbaum
23/122
ping
Module Module
Name
Servers
(all)

Andreas Scherbaum
24/122
ping - pong
127.0.0.1 | SUCCESS => {
"ansible_facts": {
...
},
"changed": false,
"ping": "pong"
}

Andreas Scherbaum
25/122
Password-less login
●
Ansible needs to be able to login without password
– For the regular user
– And the root method (sudo, su), if necessary

Andreas Scherbaum
26/122
Module parameters
ansible -i 127.0.0.1, -m command -a “uptime” all
Additional
Module
Parameters

Andreas Scherbaum
27/122
Module output
127.0.0.1 | CHANGED | rc=0 >>
23:04:34 up 5 days, 5:14, 16 users, load average: 1,82, 1,33, 1,27

Andreas Scherbaum
28/122
Module output
127.0.0.1 | CHANGED | rc=0 >>
Command Output

Andreas Scherbaum
29/122
Module Return Code
127.0.0.1 | CHANGED | rc=0 >>
Command Return Code

Andreas Scherbaum
30/122
Module output
127.0.0.1 | CHANGED | rc=0 >>
“Something” changed

Andreas Scherbaum
31/122
Command output
●
Ansible fetches STDOUT and STDERR from the remote host
●
Shows both to the user, in Ad-hoc mode

Andreas Scherbaum
32/122
Command Result
●
Ansible provides the command return code (RC)
●
Playbooks can act on the RC
– ignore_errors: true
– failed_when: <condition>

Andreas Scherbaum
33/122
Changes
●
Every time Ansible changes something on the host, the status
of the task becomes “changed”
– Can be ignored with “changed_when: false”

Andreas Scherbaum
34/122
“command” versus “shell”
●
Ansible has 2 modules for executing arbitrary commands on the host:
●
command: no variable replacement is done, no filehandle redirects (like:
2> /dev/null) are possible, only one command possible – uses “exec”
●
shell: uses a regular shell to execute the command, can handle all kind
of variables, or multiple shell commands – uses “system”
– cat /etc/passwd | grep root | cut -f3 -d:
●
Both modules (by default) “change” the remote system
– Ansible doesn’t know what the module is executing

Andreas Scherbaum
35/122
“command” / “shell” versus modules
●
Always aim to use Ansible modules over of “shell”/”command”
●
Modules provide idempotence:
– Multiple calls to the same module will not change the remote
system

Andreas Scherbaum
37/122
Playbooks
●
A Playbook is a text file (Yaml format) with tasks
– Can run repeatedly - idempotent
●
Playbooks can become very large, and complex
– Split them up into roles (not topic of this talk)
●
Playbooks can run on parts of the infrastructure
– Example: only database hosts

Andreas Scherbaum
38/122
Hosts list
●
The file “hosts.cfg” in the Playbook directory defines the hosts
●
Variables can be specified
– Per host
– Per host group
– …
– Global

Andreas Scherbaum
39/122
hosts.cfg (Example)
[all-systems:children]
webservers
databases
[all-systems:vars]
ssh_args = -o ServerAliveInterval=30
[databases]
192.168.0.5 hostname=db1
[databases:vars]
db_type=postgresql

Andreas Scherbaum
40/122
hosts.cfg
webservers
databases
[all-systems:vars]
[databases]
[databases:vars]
db_type=postgresql
Specify groups

Andreas Scherbaum
41/122
hosts.cfg
webservers
databases
[all-systems:vars]
[databases]
[databases:vars]
db_type=postgresql
Variables for
all child groups

Andreas Scherbaum
42/122
hosts.cfg
webservers
databases
[all-systems:vars]
[databases]
[databases:vars]
db_type=postgresql
Database group
with one host

Andreas Scherbaum
43/122
hosts.cfg
webservers
databases
[all-systems:vars]
[databases]
[databases:vars]
db_type=postgresql Variables for
database group

Andreas Scherbaum
44/122
Playbook
●
Specifies task groups (Plays)
●
Goal is to group hosts together, and run Plays on them
●
Ansible wants Playbooks to be idempotent:
– Run many times, only change what is necessary
– Ansible modules are idempotent
– shell/command is not

Andreas Scherbaum
45/122
Playbook
---
- hosts: databases
tasks:
- name: uptime
command: uptime
- name: uname
command: uname

Andreas Scherbaum
46/122
Playbook
---
- hosts: databases
tasks:
- name: uptime
command: uptime
- name: uname
command: uname
JSON/YAML marker

Andreas Scherbaum
47/122
Playbook
---
- hosts: databases
tasks:
- name: uptime
command: uptime
- name: uname
command: uname
Host group
(or: all)

Andreas Scherbaum
48/122
Playbook
---
- hosts: databases
tasks:
- name: uptime
command: uptime
- name: uname
command: uname
Task list

Andreas Scherbaum
49/122
Playbook
---
- hosts: databases
tasks:
- name: uptime
command: uptime
- name: uname
command: uname
Task 1
Task 2

Andreas Scherbaum
50/122
Run the Playbook
ansible-playbook -i hosts.cfg playbook.yml
PLAY [all] **********************************************************************************************************
TASK [Gathering Facts] **********************************************************************************************
Ok: [192.168.0.5]
TASK [uptime] TASK [uname] ******************************************************************************************
changed: [192.168.0.5]
TASK [uname] ********************************************************************************************************
changed: [192.168.0.5]
PLAY RECAP **********************************************************************************************************
192.168.0.5 : ok=3 changed=2 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
Playbook run took 0 days, 0 hours, 0 minutes, 1 seconds

Andreas Scherbaum
51/122
Run the Playbook
PLAY [all] **********************************************************************************************************
Ok: [192.168.0.5]
changed: [192.168.0.5]
TASK [uname] ********************************************************************************************************
changed: [192.168.0.5]
PLAY RECAP **********************************************************************************************************
Run the Playbook
(using the “playbook” command

Andreas Scherbaum
52/122
Run the Playbook
PLAY [all] **********************************************************************************************************
Ok: [192.168.0.5]
changed: [192.168.0.5]
TASK [uname] ********************************************************************************************************
changed: [192.168.0.5]
PLAY RECAP **********************************************************************************************************
Task changed something

Andreas Scherbaum
53/122
Run the Playbook
PLAY [all] **********************************************************************************************************
Ok: [192.168.0.5]
changed: [192.168.0.5]
TASK [uname] ********************************************************************************************************
changed: [192.168.0.5]
PLAY RECAP **********************************************************************************************************
Summary

Andreas Scherbaum
54/122
Playbook versus Ad-hoc
●
Ad-hoc is about simple commands
– Output is of interest
●
Playbooks are about idempotence
– Output is not really interesting
– Change is interesting, and so is a failure

Andreas Scherbaum
55/122
Error handling
---
- hosts: all
any_errors_fatal: True
tasks:
- name: non-existent command
command: downtime
- name: uname
command: uname
Abort everything
on first error
Non-existent
command

Andreas Scherbaum
56/122
Failing Playbook
PLAY [all] ****************************************************************************************************************
TASK [non-existent command] ***********************************************************************************************
Fatal: [192.168.0.5]: FAILED! => {"changed": false, "cmd": "downtime", "msg": "[Errno 2] No such file or directory", "rc": 2}
NO MORE HOSTS LEFT ********************************************************************************************************
PLAY RECAP ****************************************************************************************************************

Andreas Scherbaum
58/122
“Demo”
●
The following slides will:
– Install a PostgreSQL database
– Check connectivity
– Create new roles + databases
– Allow access (modify pg_hba.conf)
– Create a table + index
– Run a query

Andreas Scherbaum
60/122
Debian (commandline)
apt-get install postgresql-13 postgresql-client-13
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
libboost-serialization1.71.0 libgmpxx4ldbl libprotobuf-c1 libsfcgal1
Use 'sudo apt autoremove' to remove them.
The following additional packages will be installed:
postgresql-client-common postgresql-common
Suggested packages:
postgresql-doc-13
The following NEW packages will be installed:
postgresql-13 postgresql-client-13 postgresql-client-common postgresql-common
0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Need to get 14,5 MB/14,7 MB of archives.
After this operation, 45,6 MB of additional disk space will be used.

Andreas Scherbaum
61/122
Debian (Ansible Ad-hoc)
ansible -i 192.168.0.5, -b -m apt -a "name=postgresql-13,postgresql-client-13 state=present" all

Andreas Scherbaum
62/122
Ad-hoc
command

Andreas Scherbaum
63/122
Ad-hoc
command
Execute
as “root”

Andreas Scherbaum
64/122
Ad-hoc
command
Execute
as “root”
“apt”
module

Andreas Scherbaum
65/122

Andreas Scherbaum
66/122
List of
packages

Andreas Scherbaum
67/122
List of
packages
Desired
Package
state

Andreas Scherbaum
68/122
127.0.0.1 | CHANGED => {
"ansible_facts": {
...
},
"cache_update_time": 1592052301,
"cache_updated": false,
"changed": true,
"stderr": "",
"stderr_lines": [],
"stdout": "…”
"stdout_lines": […]
]
}
Something
changed
Watch for
errors

Andreas Scherbaum
69/122
Install PostgreSQL with a Playbook
- hosts: all
any_errors_fatal: True
become: yes
tasks:
- name: Install PostgreSQL
apt:
name:
- postgresql-13
- postgresql-client-13
- python3-psycopg2
state: present
Run as “root”
Use Debian
package module “apt”

Andreas Scherbaum
70/122
Install PostgreSQL with a Playbook
ansible-playbook -i 192.168.0.5, playbook.yml
TASK [Install PostgreSQL]
***************************************************************
Changed: [192.168.0.5]
PLAY RECAP ****************************************************
192.168.0.5 : ok=2 changed=1 unreachable=0 failed=0

Andreas Scherbaum
71/122
Re-run the Playbook
ansible-playbook -i 192.168.0.5, playbook.yml
TASK [Install PostgreSQL]
***************************************************************
Changed: [192.168.0.5]
PLAY RECAP ****************************************************
192.168.0.5 : ok=2 changed=0 unreachable=0 failed=0

Andreas Scherbaum
72/122
State
●
Many Ansible modules have a “state” parameter
– Usually defaults to “present”
– “present” will install a package, but not upgrade it
– “latest” will upgrade, if newer package is available
– “absent” will uninstall a package

Andreas Scherbaum
74/122
Next: check if PostgreSQL is running
●
Ansible provides the “postgresql_ping” module
– Login credentials are required (db, username, host)
●
This is useful at the beginning of the Playbook:
– See if the DB is up and running
– Otherwise later commands fail with more obscure errors
●
This module runs on the remote host
– Hence: the db is on “127.0.0.1”
– The Unix Domain Socket is used

Andreas Scherbaum
75/122
Check if PostgreSQL is running
- name: Ping PostgreSQL
postgresql_ping:
db: postgres
login_unix_socket: "/var/run/postgresql"
login_user: postgres
become: yes
become_user: postgres

Andreas Scherbaum
76/122
- name: Ping PostgreSQL
postgresql_ping:
db: postgres
become: yes
Runs on
“local host”
Ansible runs this
as user “postgres”

Andreas Scherbaum
77/122
TASK [Ping PostgreSQL] *******************************************
Ok: [192.168.0.5]
PLAY RECAP *******************************************************
192.168.0.5 : ok=1 changed=0 unreachable=0

Andreas Scherbaum
79/122
Create Roles + Databases
●
Manage roles: postgresql_user
●
Manage databases: postgresql_db

Andreas Scherbaum
80/122
Adding a new role
- name: Create role
postgresql_user:
db: postgres
Name: "{{ demouser }}"
Password: "{{ demopass }}"
become: yes

Andreas Scherbaum
81/122
Adding a new role
- name: Create role
postgresql_user:
db: postgres
Name: "{{ demouser }}"
Password: "{{ demopass }}"
become: yes
Username and password
are stored in variables

Andreas Scherbaum
82/122
Notes on creating roles
●
The password is stored in a variable
– Transmitted in clear text to the remote host
– Ansible will prevent logging the password
●
Consider pre-encrypted passwords
– Creating them is not part of this talk

Andreas Scherbaum
83/122
Example: remove a role
- name: Drop role
postgresql_user:
db: postgres
name: "otheruser"
state: absent
become: yes
State: “absent” to
remove the role

Andreas Scherbaum
84/122
Adding a new database
- name: Create database
postgresql_db:
maintenance_db: postgres
name: "{{ demodb }}"
owner: "{{ demouser }}"
become: yes
Database name is
stored in a variable

Andreas Scherbaum
85/122
Adding a new database
- name: Create database
postgresql_db:
maintenance_db: postgres
name: "{{ demodb }}"
owner: "{{ demouser }}"
become: yes
New db owner
(optional)

Andreas Scherbaum
86/122
Notes on databases
●
“state=dump” allows taking backups
●
“state=restore” allows restoring backups
●
Needs a “target=<filename>” for backup/restore

Andreas Scherbaum
88/122
Modify pg_hba.conf
- name: Allow access for demo user from everywhere
postgresql_pg_hba:
dest: "/etc/postgresql/13/main/pg_hba.conf"
contype: host
users: "demouser"
source: "0/0"
databases: "demodb"
method: "md5"
notify:
- reload postgresql

Andreas Scherbaum
89/122
Notes on modifying pg_hba.conf
●
The “postgresql_pg_hba” module does not allow much control
over the sort order of the entries
– Consider “lineinfile” or “blockinfile” or “template” modules
●
It must be run as root (on Debian)
– The configfiles live in /etc/postgresql

Andreas Scherbaum
90/122
Modify pg_hba.conf
- name: Allow access for demo user from everywhere
postgresql_pg_hba:
dest: "/etc/postgresql/13/main/pg_hba.conf"
contype: host
Users: "{{ demouser }}"
source: "0/0"
Databases: "{{ demodb }}"
method: "md5"
notify:
- reload postgresql Introduces a “notify”,
which requires a “handler”

Andreas Scherbaum
91/122
Handler
- hosts: all
tasks:
handlers:
- name: reload postgresql
service:
name: postgresql
state: reloaded
“handlers” are defined
like “tasks”
The “name” is free-form
Any Ansible module
can be used here

Andreas Scherbaum
92/122
Handler
●
Handler can be called from many places
●
Run when the Playbook ends
– All “notify”s are queued
●
Ideal to reload/restart services at the end
– The notify is only run when the Task changed
– Playbook doesn’t have to check every single Task

Andreas Scherbaum
93/122
pg_hba.conf
cat /etc/postgresql/13/main/pg_hba.conf
…
host demodb demouser 0/0 md5
…

Andreas Scherbaum
95/122
Creates tables + indexes
●
postgresql_table: manage tables
●
postgresql_idx: manage indexes

Andreas Scherbaum
96/122
Create a table
- name: Create table
postgresql_table:
db: "demodb"
name: "demotable"
columns:
- id serial primary key
- data text
owner: "demouser"
become: yes

Andreas Scherbaum
97/122
Create a table
- name: Create table
postgresql_table:
db: "demodb"
name: "demotable"
columns:
- id serial primary key
- data text
owner: "demouser"
become: yes
Table name and
definition

Andreas Scherbaum
98/122
Notes on tables
●
Will not add/remove new columns
– Only the initial set of columns is used when creating the
table
●
Can specify table and storage parameters
●
Can create tables “like” another table
●
Can drop/truncate/rename tables
●
Can create unlogged tables

Andreas Scherbaum
99/122
Create an index
- name: Create index on demo table
postgresql_idx:
db: "demodb"
columns: "data"
idxname: "demotable_data_ixd"
table: "demotable"
become: yes

Andreas Scherbaum
100/122
Create an index
postgresql_idx:
db: "demodb"
table: "demotable"
columns: "data"
become: yes
Index column(s)

Andreas Scherbaum
101/122
Create an index
postgresql_idx:
db: "demodb"
table: "demotable"
columns: "data"
become: yes
Index name

Andreas Scherbaum
102/122
Notes on Indexes
●
The index name is always required (sigh)
●
Index can cover multiple columns
●
Index can have a different type (“idxtype”)
●
Index can be on another tablespace (“tablespace”)

Andreas Scherbaum
105/122
Run queries
●
postgresql_query: run a query against the database

Andreas Scherbaum
106/122
Run queries
- name: Run INSERT
postgresql_query:
db: "demodb"
query: "INSERT INTO demotable (data) VALUES ((SELECT random()::TEXT))"
become: yes
Query to run

Andreas Scherbaum
107/122
Notes on Queries
●
Each call of “postgresql_query” will “change” the database
– Even if it’s a SELECT query
– Use “changed_when: False”
– Not idempotent by default
●
Queries in Ansible can run in a long-running transaction
– Don’t forget to commit/rollback
●
Positional arguments and placeholders (prepared queries) are possible
●
SQL Code can be in a script

Andreas Scherbaum
108/122
Run a SELECT query
- name: Run SELECT
postgresql_query:
db: "demodb"
query: "SELECT COUNT(*) AS count FROM demotable"
become: yes
register: select_result
Store the entire
result in a
variable

Andreas Scherbaum
109/122
Show the result
- name:
debug:
msg: "{{ select_result.query_result[0].count }}"

Andreas Scherbaum
110/122
Show the result
- name:
debug:
Result
variable

Andreas Scherbaum
111/122
Show the result
- name:
debug:
Result
variable
Query
results

Andreas Scherbaum
112/122
Show the result
- name:
debug:
Result
variable
Query
results
The “count”
from the query

Andreas Scherbaum
113/122
Query result
TASK [debug] ************************************
ok: [127.0.0.1] => {
"msg": "8"
}
count(*)

Andreas Scherbaum
115/122
Running Playbooks
●
Playbooks can run from any (Linux) computer
– Every developer can run them
– However: every developer needs access to all credentials

Andreas Scherbaum
116/122
Ansible Tower
●
Ansible Tower provides a central place to run Playbooks
– Runs can be triggered (as example: GitHub commits)
– Runs can be scheduled
– Nice web interface
●
Commercial product by Red Hat

Andreas Scherbaum
117/122
Image copyright: Red Hat

Andreas Scherbaum
118/122
Ansible Tower in Open Source: AWX
●
More frequent releases
– basically: development version for Ansible Tower
●
No support from Red Hat
●
No cross-upgrade possible

Andreas Scherbaum
120/122
Ansible
●
Useful tool to manage a large fleet of servers, VMs, services
and applications
●
Self-documentation
●
Idempotence allows re-running of Playbooks until success

Andreas Scherbaum
121/122
Ansible & PostgreSQL
●
Many useful modules to manage (almost) any aspect of
PostgreSQL databases
●
Quick results & small overhead, compared to “shell scripts”

Managing PostgreSQL with Ansible

Related slideshows

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

More Related Content

What's hot

What's hot (20)

Similar to Managing PostgreSQL with Ansible

Similar to Managing PostgreSQL with Ansible (20)

More from EDB

More from EDB (20)

Recently uploaded

Recently uploaded (20)

Managing PostgreSQL with Ansible