The Smart Way to Manage Postgres at Scale: Declarative Deployment

July 24, 2023

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
Share this

Relevant Blogs

What is pgvector and How Can It Help You?

There are a thousand ways (likely more) you can accelerate Postgres workloads. It all comes down to the way you store data, query data, how big your data is and...
November 03, 2023

More Blogs

pgAdmin CI/CD

Almost exactly three years ago I wrote a blog on my personal page entitled Testing pgAdmin which went into great detail discussing how we test pgAdmin prior to releases. Back...
August 24, 2023