The popularity of PostgreSQL keeps increasing day by day, newer versions, capabilities and functionalities are constantly being added and incorporated by the community.
Configuring a single PostgreSQL instance in its simplest form is quick and easy but when you desire to incorporate best practices, clusters, additional nodes, security, streaming replication, failover, monitoring and management; the original task becomes much more involved and complicated.
The complexity can range from a single step to multiple steps that constantly require attention to detail; an accidental typo can invalidate what is currently installed and configured on a single node all the way up to the entire cluster.
For these reasons, EDB as a leader in the Postgres community has taken the initiative to contribute the open-source framework “EDB - Postgres Deployment Scripts," which automates the creation of high-availability clusters for PostgreSQL and EDB Postgres Advanced Server infrastructures including database administration and monitoring with alerts.
This blog is the first in a series that will cover this framework contribution to the open source community.
The “EDB - Postgres Deployment Scripts” are the result of collective experiences packaged together to simplify the complexity involved in the deployment of a Postgres cluster. The “EDB - Postgres Deployment Scripts” goal is to provision and configure a Multi-Node Asynchronous Replication Cluster. At a high level the architecture of the “EDB - Postgres Deployment Scripts” is divided into two sequential steps:
1. Provision compute, storage and network
2. Configure and install the software
“Configure and install the software” looks very similar to “Provisioning compute, storage and network”:
Now that we have a better understanding of the two major goals of the “EDB - Postgres Deployment Scripts” it is time to expand on the technologies involved in each step.
Details for the “Provision” step of the “EDB - Postgres Deployment Scripts” are visible below:
Details for “Configure” step of the “EDB - Postgres Deployment Scripts” look like this:
The GitHub repositories for the 2 components of the “EDB - Postgres Deployment Scripts” Framework are:
- Postgres Deployment Scripts developed in Terraform available at: GitHub postgres-deployment
- EDB Ansible Scripts
- GitHub version available at: GitHub edb-ansible repository
- Ansible Galaxy version available at: Galaxy Ansible edb-ansible collection
The “EDB - Postgres-Deployment Scripts” were developed for Terraform version >= 0.13; the goal of this repository is to create the resources in either AWS, Microsoft Azure or Google Cloud Platform. While the goal of the two Ansible repositories that were developed for Ansible >= 2.9 is to configure the resources created in AWS, Microsoft Azure or Google Cloud Platform. These two Ansible repositories achieve the same goal but each repository might attract different audiences.
The GitHub edb-ansible repository might be more suited for those Ansible users that are interested in exploring how the scripts work and how they configure the PostgreSQL or EDB Postgres Advanced Server clusters; while the Galaxy Ansible edb-ansible collection will most likely be of interest to those who just want to get a Postgres deployment completed.
Both Ansible repositories contain the following directories:
- playbook-examples – Containing example playbooks for different scenarios
- roles – For installing dependent packages, installing and initializing Postgres, setting up Postgres or EDB Postgres Advanced Server: Streaming Replication, EDB Postgres Failover Manager (EFM) and EDB Postgres Enterprise Manager (PEM)
Now that we are familiar with the “EDB - Postgres Deployment Scripts,” the biggest question that comes to mind is how long does a complete deployment take? An end-to-end deployment (resource creation and configuration) with the characteristics listed below can take between 30 to 45 minutes to complete:
- 3-node cluster
- EDB Postgres Enterprise Manager (PEM)
- Operating System (CentOS 7 or RHEL 7)
As mentioned previously, the “EDB - Postgres Deployment Scripts” framework is open source. Which means that it is possible to help it evolve and improve. How can that effort happen? It starts with you utilizing, deploying and testing the framework.
What happens if you have ideas or suggestions? Please feel free to add feedback to the issues in the GitHub repository.
Future tentative blog topics to be covered are:
- Provisioning the infrastructure with “EDB - Postgres Deployment Scripts” on AWS
- Setting up EDB Postgres Advanced Server 12, EFM cluster and PEM on AWS
- Destroying the provisioned infrastructure on AWS
- Provisioning the infrastructure with “EDB - Postgres Deployment Scripts” on Azure
- Setting up EDB Postgres Advanced Server 12, EFM cluster and PEM on Azure
- Destroying the provisioned infrastructure on Azure
- Provisioning the infrastructure with “EDB - Postgres Deployment Scripts” on Google Cloud
- Setting up EDB Postgres Advanced Server 12, EFM cluster and PEM on Google Cloud
- Destroying the provisioned infrastructure on Google Cloud