The Smart Way to Manage Postgres at Scale: Declarative Deployment

Challenges with Deploying Postgres

Initializing and configuring new Postgres clusters can be a tedious and time consuming activity that requires creative solutions to simplify. There are many ways in which a deployment can have both expected and unexpected challenges.

Even with a single node instance, manually executing the commands required to initialize a cluster in the correct order with the correct permissions all while minimizing exposure of sensitive information, like the IP address of the node, can be a laborious process.

With large scale deployments, this process becomes exponentially more complicated. There could be multiple databases across multiple nodes that all require different commands, yet all need to be done in a specific order. Issues can arise around synchronization across multiple instances, so careful consideration needs to be taken to ensure time and resources are not wasted.

With these challenges in mind, edb-ansible provides a simple solution for deploying Postgres clusters at scale.

edb-ansible

edb-ansible was originally designed to deploy clusters for large-scale benchmarking. Since its inception, more tools have been integrated into the repository and more features have been added to broaden the potential use-cases and enhance the configurability for each specific user.

To learn more about edb-ansible and the deployment options it provides, visit the repository homepage: https://github.com/EnterpriseDB/edb-ansible

A Declarative Way to Deploy

Ansible, and more specifically, edb-ansible, offers a declarative way to deploy Postgres at scale. Within edb-ansible, there exist many roles, each with a unique purpose and intended outcome. These roles are called in a playbook, which with the corresponding inventory file, are all that is needed to deploy a Postgres cluster.

Here is an example of a playbook for deploying a 2-node primary-standby cluster:

--- - hosts: all name: Postgres deployment playbook become: true gather_facts: true any_errors_fatal: true collections: - edb_devops.edb_postgres pre_tasks: - name: Initialize the user defined variables ansible.builtin.set_fact: pg_version: 14 pg_type: "PG" repo_username: "" repo_password: "" pg_instance_name: "my_cluster_name" pg_owner: "my_user" disable_logging: false roles: - role: setup_repo when: "'setup_repo' in lookup('edb_devops.edb_postgres.supported_roles', wantlist=True)" - role: install_dbserver when: "'install_dbserver' in lookup('edb_devops.edb_postgres.supported_roles', wantlist=True)" - role: init_dbserver when: "'init_dbserver' in lookup('edb_devops.edb_postgres.supported_roles', wantlist=True)" - role: setup_replication when: "'setup_replication' in lookup('edb_devops.edb_postgres.supported_roles', wantlist=True)"

More information on the Ansible playbook, calling roles and defining variables can be found here.

The 'set_fact' within the 'pre_tasks' allows users to declare the value of the variables they would like to set. Information about the variables and their definitions is available in the README file of each role. This information is presented in a clear, concise and human-readable manner, making it easy to understand and achieve your intended goal.

In order for Ansible to know where to deploy to, the inventory is required to list the nodes, their IPs, and which group they belong to. An example inventory file for the previous cluster deployment is shown below.

--- all: children: primary: hosts: primary1: ansible_host: xxx.xxx.xxx.xxx private_ip: xxx.xxx.xxx.xxx standby: hosts: standby1: ansible_host: xxx.xxx.xxx.xxx private_ip: xxx.xxx.xxx.xxx replication_type: synchronous upstream_node_private_ip: xxx.xxx.xxx.xxx

More information on the inventory file can be found here.

Using this inventory file along with the playbook, Ansible knows exactly what to execute and when to do so to achieve cluster initialization. To enable a different cluster architecture, additional roles can be called within the playbook and more nodes can be added to the inventory file. This allows for flexibility and scalability during deployment.

Looking for an easier way to deploy?

If you are looking for a declarative and intuitive way to deploy Postgres at scale, look no further than edb-ansible. Features continue to be added and we encourage you to interact with us on GitHub if you have any suggestions, questions, or feedback. We greatly appreciate the positive community engagement and contributions we have received. 

Note: Features expected to be added soon:

• Expanded Linux platform support (SUSE, RHEL9, Debian11, Ubuntu22)
• Postgres Extended support
• Support of upcoming major Postgres version release