As part of our never ending quest at EDB to simplify and automate processes with PostgreSQL, we are always exploring and researching tools that will help us streamline PostgreSQL. With that in mind, Ansible is one of our most utilized tools not because of its huge popularity in the IT community but mainly because of its capabilities.
In this blog post, we’ll explore two questions: What is Ansible, and why is it used for managing PostgreSQL?
What is Ansible?
Before we discuss the capabilities, advantages and usage of Ansible, let’s take a few steps back and review: What is Ansible? Ansible is a simple, powerful and agentless open-source software platform that is utilized for provisioning resources/software, configuring, and deploying software. Ansible was written by Michael DeHaan and acquired by RedHat in October 2015. Ansible is part of the methodology known as Infrastructure as Code (IaC) practice.
Infrastructure as Code aims to codify and manage IT Infrastructure through code. A few of the benefits of practicing Infrastructure as Code are:
- Speed and efficiency - provided by automating processes instead of keeping them manual along with the ability to fine tune and evolve these processes as they are reused
- Consistent and reliable - because processes are codified they are testable, repeatable and consistent which can be improved and reused
- In-line with DevOps initiatives - code is available for storage in a version control system, testing, and integration into continuous integration/continuous delivery pipelines
Advantages and capabilities of Ansible
With a better understanding of what Ansible is, we can look into its advantages:
Ansible is:
- Straightforward
- Easy to read and understand
- Executed in a specific order
- Powerful
- Can be used to provision/destroy resources, install and configure software
- Easily configured and reused
- Reusable
- Can be executed multiple times
- Code can be reused in other playbooks, roles, and collections
- Agentless
- No need to install any software
- Secure
- Because of no agents to install they are not prone to exploits or updates
Components of Ansible
Ansible is composed of multiple components, where these components provide additional features to Ansible which in turn greatly amplify Ansible as a management tool. A brief description of Ansible’s components and how they tie together are:
- Inventory - A configuration file that lists the IP addresses of the servers to be managed
- Playbooks - File containing configurations, policies, steps and tasks to be applied to the “Inventory”
- Plays - Tasks and/or group of tasks within an Ansible Playbook
- Tasks - Actions that are executed by a Playbook
- Roles - Logical grouping of organizing tasks, some examples: web server, database, application, etc.
- Collections - Logical grouping of roles, akin to a zip file
- Handlers - Tasks that are executed only if a primary action has been called previously
- Templates - Support the use of variables, loops, and conditional expressions which add flexibility when setup occurs
- Variables - How Ansible manages differences between systems
By mixing and matching Ansible’s components as needed, the tedious process of installing, configuring, and setting up becomes not only manageable but fast, testable, repeatable, and schedulable.
Why use Ansible to manage PostgreSQL?
The answer is not one but multiple answers, among them: Installing, configuring, and managing PostgreSQL, implementing best practices, creating/managing users, the list goes on.
Most importantly, the main reason to use Ansible is repeatability: the ability to install, configure, over and over without human errors. This is particularly useful in agile and/or DevOps environments.
It is much easier to get a better understanding with real world examples. Two real-world examples are EDB Ansible Collection and GitHub EDB Ansible, both of these repositories contain Ansible roles that target specific ansible tasks: setup, install a PostgreSQL database server, initialize a database server, setup replication, setup EDB Failover Manager (EFM), setup a Postgres Enterprise Manager (PEM) server, manage the database server, setup PgBouncer, setup PgPool, setup a Barman server for backup, setup Barman, and automate database tuning.
Adding to the previous list, other possible tasks could be:
- Provisioning cloud resources required for an installation of PostgreSQL
- Creating, managing, upgrading, and populating PostgreSQL Databases
- And the list goes on…
By no means have we listed all the possible automation tasks that can be accomplished with Ansible and PostgreSQL, in the end the targeted tasks for automation can be as short, long, simple or complicated as what you are trying to accomplish.
Conclusion
By providing real world examples and possible scenarios/solutions that can be leveraged in automation projects, we hope this blog post has explained Ansible and how it's used to manage PostgreSQL.
This is just the tip of the Ansible iceberg—that said, see you in the next blog post!