Jeff McCormick | CrunchyData Blog

What's New in Crunchy PostgreSQL Operator 4.0

Jeff.McCormick@crunchydata.com (Jeff McCormick) — Tue, 11 Jun 2019 05:00:00 EDT

Crunchy Data is pleased to release PostgreSQL Operator 4.0.

Crunchy PostgreSQL Operator extends Kubernetes to give you the power to easily create, configure and manage PostgreSQL clusters at scale. When combined with the Crunchy PostgreSQL Container Suite, the Crunchy PostgreSQL Operator provides an open source software solution for PostgreSQL scaling, high-availability, disaster recovery, monitoring, and more. All of this capability comes with the repeatability and automation that comes from Operators on Kubernetes.

Crunchy PostgreSQL Operator is open source and developed in close collaboration with users to support enterprise deployments of cloud agnostic PostgreSQL-as-a-Service capability. This release comes after extensive feedback from our customers and the community to ensure the scalability and security that sysadmins, DBAs, and developers have come to rely on.

Key features added to the Crunchy PostgreSQL Operator 4.0. include:

Namespace Deployment Options

Support for deploying the Crunchy PostgreSQL Operator with additional namespace patterns, including the ability to deploy the operator its own namespace but manage PostgreSQL clusters in multiple namespace. The new namespace management features lets users create multi-tenant PostgreSQL environments that add further isolation and security to their deployments. The various deployment patterns are included within the Design documentation.

Further Enhancements to pgBackRest Integration

Crunchy PostgreSQL Operator 4.0. continues the integration of pgBackRest, building on features incorporated within version 3.5. For example, this latest release adds the ability to perform pgBackRest backups to Amazon S3. This allows users to create an automated, geographically distributed, and hybrid cloud disaster recovery strategy: : in addition to the benefits of backing up to a distributed object store, users can move their PostgreSQL data easily between data centers.

Integrated PostgreSQL Benchmarking

Crunchy PostgreSQL Operator 4.0. adds the ability to run pgBench, a simple program for running standard and customizable benchmark tests on PostgreSQL, from the Operator command-line interface. The operator CLI overview documentation provides guidance as to how to use this capability. This provides and simple and easy means for users to compare and investigate performance and scalability under different deployment scenarios.

Ansible Playbook Based Installation

Crunchy PostgreSQL Operator 4.0 provides Ansible playbooks to automate operator installation. The Crunchy PostgreSQL Operator Ansible Installers allow users to install PostgreSQL Operator on Kubernetes and OpenShift from a Linux, Mac or Windows (Ubuntu subsystem) host. In connection with the automated installation, the Ansible playbooks can generate TLS certificates required by the PostgreSQL Operator and configure PostgreSQL Operator settings from a single inventory file.

Operator Lifecycle Management (OLM)

Crunchy PostgreSQL Operator 4.0. supports Operator Lifecycle Management (OLM). The OLM project is a component of the Operator Framework, an open source toolkit to manage Operators, in an effective, automated, and scalable way. OLM concepts were included into Crunchy PostgreSQL Operator to assist in the deployment on Kubernetes using OLM integration.

Documentation Improvements

The latest release includes enhanced user documentation, providing additional information regarding architecture, installation and configuration options. Please take a look and let us know what you think.

How to Get Started

Please give the new release of the operator a try and let us know what you think about these new features.

If you are new to the Crunchy PostgreSQL Operator and interested in installing the Crunchy PostgreSQL Operator in your environment, please start here: Installation via Ansible. Instructions for Installation via Bash are also available.

Interested in a feature you dont see in this release? Please let us know. The project is open source and welcomes issues and pull requests.

We plan to provide a series of posts over the coming weeks to provide additional information about these new features and how they can support enterprise PostgreSQL-as-a-Service requirements.

What's New in Crunchy PostgreSQL Operator 3.5

Jeff.McCormick@crunchydata.com (Jeff McCormick) — Thu, 24 Jan 2019 04:00:00 EST

Crunchy Data is happy to announce the release of the open source PostgreSQL Operator 3.5 for Kubernetes project, which you can find here: https://github.com/CrunchyData/postgres-operator/

This latest release provides further feature enhancements designed to support users intending to deploy large-scale PostgreSQL clusters on Kubernetes, with enterprise high-availability and disaster recovery requirements.

When combined with the Crunchy PostgreSQL Container Suite, the PostgreSQL Operator provides an open source, Kubernetes-native PostgreSQL-as-a-Service capability.

Read on to see what is new in PostgreSQL Operator 3.5.

pgBackRest Architecture Enhancements

In order to reduce disk consumption resulting from backups of large PostgreSQL clusters, the PostgreSQL Operator 3.5 improves on the existing pgBackRest to provide users with a pgBackRest shared repository. This shared pgBackRest repository is used by the primary and each of the replicas of a given PostgreSQL cluster deployed by the Operator. This pgBackRest repository runs within its own Kubernetes Deployment and is dedicated to serving this given single PostgreSQL cluster.

pgBackRest Point-In-Time-Recovery

The PostgreSQL Operator 3.5 provides point-in-time-recovery from this newly introduced pgBackRest shared repository by implementing the pgBackRest restore command.

Users can create a pgBackRest backup using the following pgo CLI command:

pgo backup mycluster --backup-type=pgbackrest

Users can view pgBackRest backups using the following command:

pgo show backup mycluster --backup-type=pgbackrest

Users can perform a point-in-time restore of a given cluster with pgBackRest using the following command:

pgo restore mycluster --backup-opts="--type=time" --pitr-target="2019-01-14 00:02:14.921404+00"

Note: When you restore a cluster, you are putting your PostgreSQL database into a different state (or timeline) and therefore you should exercise caution before doing so!

Fast Failover

A key component of high-availability is ensuring that you are able to quickly fail over from a primary to a replica database in order to limit your downtime. This new release of the PostgreSQL Operator ensures that failovers are fast: a replica can now be promoted to a primary in only a matter of milliseconds!

Archive Storage Configuration

For PostgreSQL Operator users that require and have enabled archiving, but have elected not to use pgBackRest, this release provides a means to specify storage volume sizes specifically for their archive volumes. In this new release, users can now specify configuration setting for your WAL archives in the pgo.yaml configuration file using the XlogStorageConfig setting.

Auto-failover Toggle

Users can now turn off and back on the auto-failover feature for a given cluster. This is helpful for when you need to do maintenance for a PostgreSQL cluster (or perhaps you just want to avoid auto-failover from kicking in).

This is performed using the command line:

pgo update mycluster --label=autofail=false

Preferred Failover Node Label

In PostgreSQL Operator 3.5, we have added a Kubernetes label selector setting within the pgo.yaml configuration file. If set, this selector will be used to determine a list of preferred Kubernetes nodes on which a target would be selected as part of a failover, whether manual or automated. This feature supports a more precise failover target selection and will be expanded in future versions.

pgo-scheduler

In PostgreSQL Operator 3.5, we wrote a dedicated and highly integrated cron scheduler which now runs within the Operator pod. This scheduler is tightly integrated into the Operator and offers users a means to schedule pg_basebackup, pgBackRest, and policy scheduled jobs (or in other words, jobs where you want to run your own SQL). Users interact with the scheduler using the following commands:

pgo create schedule
pgo delete schedule
pgo show schedule

Documentation

Lastly the entire Operator documentation was redesigned and rewritten to better describe the current features of the Operator.

Final Thoughts

Crunchy Data views the PostgreSQL Operator as an enabling component for enterprises interested in deploying Kubernetes native PostgreSQL-as-a-Service. In this 3.5 release, we have targeted specific new functionality that will better enable enterprises to deploy increasingly sophisticated containerized PostgreSQL infrastructure in a highly integrated Kubernetes environment.

While this release represents a major milestone, the rapid innovation demonstrated by the Kubernetes community and the potential for the Operator pattern provides an opportunity for continued improvements in a variety of directions. You can also find more information about running PostgreSQL on Kubernetes on our website.

Please stay tuned, and we welcome any feedback or questions as you get started.

PostgreSQL Operator for Kubernetes

Jeff.McCormick@crunchydata.com (Jeff McCormick) — Tue, 28 Mar 2017 05:00:00 EDT

Crunchy Data is pleased to announce an initial implementation of a PostgreSQL Operator for Kubernetes to build on our work with PostgreSQL Containers. This initial implementation provides a user with the ability to perform certain PostgreSQL functions including creating PostgreSQL clusters, performing database backup and restores and viewing persistent volume claims.

Operators

Last November the team at CoreOS introduced the concept of an “application-specific controller” for Kubernetes called software Operators. In their announcement, CoreOS suggested Operators as a means to more efficiently manage database infrastructure.

Crunchy Data has previously released a suite of containers for deploying, administering and monitoring PostgreSQL and leveraging the Operator concept to further advance the deployment and management of PostgreSQL functions within Kubernetes was a natural extension of our work to date.

To that end, Crunchy Data is pleased to announce an initial implementation of a PostgreSQL Operator.

Initial Scope

For the initial release of a PostgreSQL operator our team has focused on a few basic operations that a user would interact with on a daily basis including:

View existing databases and clusters
Create a single master or master-replica PostgreSQL configuration
Delete a single master or entire PostgreSQL deployment
Perform a database backup and list prior backups
Perform a database restore
Provide visibility into a Persistent Volume Claim

Design Features

The Operator concept makes use of Third Party Resources (TPR) to create a set of domain specific objects that pertain to a specific application. This Operator creates PostgreSQL specific objects, including: pgdatabase, pgcluster, and pgbackup. A few additional notes on the design:

The PostgreSQL Operator runs in a Deployment on the Kubernetes cluster and watches for TPR events
The user interface of the PostgreSQL Operator is a command line utility called pgo
The PostgreSQL Operator allows for a variety of Persistent Volume technologies to be used such as HostPath, NFS, and block storage.
The PostgreSQL Operator allows for different deployment strategies to be defined. A Deployment Strategy in the case is the set of objects that the Operator will create for a new database or PostgreSQL cluster including Pods, Services, Deployments, etc. This is a key feature in that different customers will want to customize exactly how their PostgreSQL databases are deployed.

The following diagram shows the pgo client communicating to the Postgres Operator running within the Kubernetes Cluster and causing the Operator to create or act upon PostgreSQL containers.

Source Code

The PostgreSQL Operator is primarily written in golang and available on GitHub. Instructions on building the code is found under the heading Build-Setup Documentation.

A binary release is provided along with the requisite Docker images on Docker Hub.

Getting Started

In order to get started, a user can build a single master PostgreSQL database using the pgo command line utility as follows:

pgo create database mydatabase

This command creates a database TPR upon which the Operator will act. This command will cause the PostgreSQL Operator to use the default database deployment strategy and create a Pod running the PostgreSQL database along with a Service mapped to the database pod.

A user can then view the database using the following command:

$ pgo show database mydatabase**

database : mydatabase**

├── pod : mydatabase (Running)**

└── service : mydatabase (10.108.0.81)

Once the database is created, a user can perform a database backup using the following command:

pgo create backup mydatabase

This command will create Kubernetes Job that executes a full database backup on the previously created PostgreSQL database named mydatabase.

The following command allows a user to view the backup:

$ pgo show backup mydatabase

pgbackup mydatabase was found PVC_NAME is crunchy-pvc

backup job pods for database mydatabase...

└── backup-mydatabase-63fw1

└── mydatabase

database pod mydatabase is found

├── mydatabase-backups/2017-03-27-13-54-33

├── mydatabase-backups/2017-03-27-13-56-49

└── mydatabase-backups/2017-03-27-14-02-38

Once the backup has been created, it is possible to create a database off of that backup using the following command:

$ pgo create database myrestoredb
--backup-path=mydatabase/2017-03-27-14-02-38 --backup-pvc=mydatabase-pvc

Deploying a PostgreSQL Cluster

Lastly, lets create a more complex PostgreSQL cluster:

pgo create cluster mycluster

This command creates a master database deployment, replica database deployment, a service for the master, and a service for the replicas.

$ pgo show cluster mycluster**

cluster : mycluster

├── deployment : mycluster

├── deployment : mycluster-replica

├── replicaset : mycluster-2460202476

├── replicaset : mycluster-replica-306362430

├── pod : mycluster-2460202476-ndndb (Running)

├── pod : mycluster-replica-306362430-blzvd (Running)

├── pod : mycluster-replica-306362430-s32g7 (Running)

├── service : mycluster (10.107.139.100)

└── service : mycluster-replica (10.100.198.149)

Finally, it is possible to delete of all of the databases created using the following command:

pgo delete database mydatabase

pgo delete cluster mycluster

Conclusion

The Third Party Resource API and golang client projects are both emerging frameworks that let allow application providers like Crunchy Data to build a rich native orchestration layer for Kubernetes In our case, our orchestration is focused on the PostgreSQL database but the pattern and frameworks could certainly be applied to other applications.

In particular, the Operator concept provides an exciting new platform Crunchy Data looks forward to build on and further advances our objective of saving users time in deploying and managing container based PostgreSQL databases infrastructure. This blog provides an discussion of an initial set of PostgreSQL Operator functions. Crunchy Data plans to continue our development to offer more extensive and advanced PostgreSQL automation in future versions of the PostgreSQL Operator, so please stay tuned!

Other Resources

Deploying PostgreSQL Clusters Using StatefulSets

Creating a PostgreSQL Cluster Using Helm

Deploying PostgreSQL Clusters using Kubernetes StatefulSets

Jeff.McCormick@crunchydata.com (Jeff McCormick) — Sun, 26 Feb 2017 04:00:00 EST

This blog provides guidance on how to build a PostgreSQL cluster using the new Kubernetes feature - StatefulSet. Using this StatefulSet capability provides a very simple, Kubernetes native, mechanism to make clustering decisions when deploying a PostgreSQL cluster.

The Crunchy PostgreSQL Container Suite is a set of containers that can be used to deploy, monitor, and administer the open source PostgreSQL database. More details can be found in the crunchy-containers GitHUB repository here In a prior blog, Crunchy Data described how to deploy a similar cluster using Helm.

(This blog cross-posted at the kubernetes.io blog here)

StatefulSets Example

Step 1 - Create Kube Environment

StatefulSets is a new feature and, as a result, running this example will require an environment based on Kubernetes 1.5.

The example in this blog deploys on Centos7 using kubeadm. Some instructions on what kubeadm provides and how to deploy a Kubernetes cluster is located here.

Step 2 - Install NFS

The example in this blog uses NFS for the Persistent Volumes, but any shared file system would also work (ex: ceph, gluster). Reference documentation for Volumes can be found here.

The example script assumes the NFS server is running locally and the hostname resolves to a known IP address.

In summary, the steps used to get NFS working on a Centos 7 host are as follows:

sudo setsebool -P virt_use_nfs 1
sudo yum -y install nfs-utils libnfsidmap
sudo systemctl enable rpcbind nfs-server
sudo systemctl start rpcbind nfs-server rpc-statd nfs-idmapd
sudo mkdir /nfsfileshare
sudo chmod 777 /nfsfileshare/
sudo vi /etc/exports
sudo exportfs -r

The /etc/exports file should contain a line similar to this one except with the applicable IP address specified:

/nfsfileshare 192.168.122.9(rw,sync)

After these steps NFS should be running in the test environment.

Step 3 - Clone the Crunchy Container Repo

The example used in this blog is found at in the Crunchy Containers GitHUB repo here. Clone the Crunchy Containers repository to the applicable test Kubernertes host and go to the example:

cd $HOME
git clone https://github.com/CrunchyData/crunchy-containers.git
cd crunchy-containers/examples/kube/statefulset

Next, pull down the crunchy-postgres container image:

docker pull crunchydata/crunchy-postgres:centos7-9.5-1.2.6

Step 4 - Run the Example

To begin, it is necessary to set a few of the environment variables used in the example:

export BUILDBASE=$HOME/crunchy-containers
export CCP_IMAGE_TAG=centos7-9.5-1.2.6

BUILDBASE is where you cloned the repository and CCP_IMAGE_TAG is the container image version we want to use.

Next, run the example:

./run.sh

That script will create several Kubernetes objects including:

Persistent Volumes (pv1, pv2, pv3)
Persistent Volume Claim (pgset-pvc)
Service Account (pgset-sa)
Services (pgset, pgset-master, pgset-replica)
StatefulSet (pgset)
Pods (pgset-0, pgset-1)

At this point, two pods will be running in the environment:

$ kubectl get pod

NAME      READY   STATUS    RESTARTS   AGE
pgset-0   1/1     Running   0          2m
pgset-1   1/1     Running   1          2m

Immediately after the pods are created, the deployment will be as depicted below:

Step 5 - What Just Happened?

This example will deploy a StatefulSet, which in turn creates two pods.

The containers in those two pods run the database. For a replicating cluster, we need one of the containers to assume the master role and the other containers to assume the replica role.

So, how do the containers determine who will be the master, and who will be the replica?

This is where the new StateSet mechanics come into play. The StateSet mechanics assign a unique ordinal value to each pod in the set.

The StatefulSets provided unique ordinal value always start with 0. During the initialization of the container, each container examines its assigned ordinal value. An ordinal value of 0 causes the container to assume the master role within the database cluster. For all other ordinal values, the container assumes a replica role. This is a very simple form of discovery made possible by the StatefulSet mechanics.

Replicas are configured to connect to the master database via a Service dedicated to the master database. In order to support this replication, the example creates a separate Service for each of the master role and the replica role. Once the replica has connected, the replica will begin replicating state from the master.

During the container initialization, a master container will use a Service Account (pgset-sa) to change it’s container label value to match the master Service selector. Changing the label is important to enable traffic destined to the master database to reach the correct container within the Stateful Set. All other pods in the set assume the replica Service label by default.

Step 6 - Deployment Diagram

The example results in a deployment depicted below:

In this deployment, there is a Service for the master and a separate Service for the replica. The replica is connected to the master and replication of state has started.

The crunchy-postgres container supports other forms of cluster deployment, the style of deployment is dictated by setting the PG_MODE environment variable for the container. In the case of a StatefulSet deployment, that value is set to:

PG_MODE=set

This environment variable is a hint to the container initialization logic as to the style of deployment intended.

Step 7 - Testing the Example

The tests below assume that the psql client has been installed on the test system. If if not, the psql client has been previously installed, it can be installed as follows:

sudo yum -y install postgresql

In addition, the tests below assume that the tested environment DNS resolves to the Kube DNS and that the tested environment DNS search path is specified to match the applicable Kube namespace and domain. The master service is named pgset-master and the replica service is named pgset-replica.

Test the master as follows (the password is password):

psql -h pgset-master -U postgres postgres -c 'table pg_stat_replication'

If things are working, the command above will return output indicating that a single replica is connecting to the master.

Next, test the replica as follows:

psql -h pgset-replica -U postgres postgres -c 'create table foo (id int)'

The command above should fail as the replica is read-only within the cluster.

Next, scale up the set as follows:

kubectl scale statefulset pgset --replicas=3

The command above should successfully create a new replica pod called pgset-2 as depicted below:

Step 8 - Persistence Explained

Take a look at the persisted data files on the resulting NFS mount path:

ls -l /nfsfileshare/

total 12
drwx------ 20 26 26 4096 Jan 17 16:35 pgset-0
drwx------ 20 26 26 4096 Jan 17 16:35 pgset-1
drwx------ 20 26 26 4096 Jan 17 16:48 pgset-2

Each container in the StatefulSet binds to the single NFS Persistent Volume Claim (pgset-pvc) created in the example script.

Since NFS and the PVC can be shared, each pod can write to this NFS path.

The container is designed to create a subdirectory on that path using the pod host name for uniqueness.

Conclusion

StatefulSets is an exciting feature added to Kubernetes for container builders that are implementing clustering. The ordinal values assigned to the set provide a very simple mechanism to make clustering decisions when deploying a PostgreSQL cluster.

To learn more contact Crunchy Data at info@crunchydata.com

Easy PostgreSQL Cluster Recipe Using Docker 1.12 and Swarm

Jeff.McCormick@crunchydata.com (Jeff McCormick) — Thu, 22 Dec 2016 04:00:00 EST

UPDATE

PLEASE READ THE UPDATED VERSION: AN EASY RECIPE FOR CREATING A POSTGRESQL CLUSTER WITH DOCKER SWARM

The below content has been deprecated in favor of An Easy Recipe for Creating a PostgreSQL Cluster with Docker Swarm.

Deprecated Recipe

In this blog I’ll show you how to deploy a PostgreSQL cluster using the latest Docker 1.12 technology. Updates to Docker in their 1.12 release greatly simplify deploying a PostgreSQL cluster. IP addresses and hostnames used in this blog are just examples and not mandated.

Recipe Step 1 - Environment

To start with, provision a Docker cluster. For this example, I have deployed a development cluster that looks like this:

Each host has Docker 1.12 installed and enabled.

Recipe Step 2 - Swarm Setup

Docker 1.12 now includes the Swarm clustering technology directly within the Docker Engine. On your Docker 1.12 cluster, you will need to configure Swarm as documented here:

https://docs.docker.com/engine/swarm/swarm-tutorial/create-swarm

This setup will include initializing Swarm on the Manager designated node using:

docker swarm init --advertise-addr 192.168.10.1

Then on the other Docker worker nodes you would enter this command for them to join the Swarm:

docker swarm join --token SWMTKN-1-65cn5wa1qv76l8l45uvlsbprogyhlprjpn27p1qxjwqmncn37o-015egopg4jhtbmlu04faon82u 192.168.10.1:2377

Recipe Step 3 - Docker Network Setup

Docker 1.12 also includes the ability to define an overlay network to be shared by a set of containers, again this feature is directly built into the Docker Engine. For this PostgreSQL cluster example, we create an overlay network (on the manager node), named crunchynet, as follows:

docker network create --driver overlay crunchynet

This overlay network will provide us a means to perform service discovery between the PostgreSQL replica containers and the PostgreSQL master container. In PostgreSQL streaming replication (clustering), the replica containers need to be able to locate a master database by either IP address or a hostname that will resolve via DNS. The Docker overlay network provides this lookup capability for us if the PostgreSQL containers are all connected to the same overlay network. Within the overlay network, Docker will allow us to resolve the PostgreSQL host using the Docker service name.

Recipe Step 4 - Container Placement

For a highly available PostgreSQL cluster configuration you would want the master database to run on a different host than where the replica databases will be run. Also, you might have a particular host you want the master container to be running on since it will be providing a write capability. Remember, in a PostgreSQL cluster, replica databases are read-only, whereas the master is read-write. So, you might want the master container to be placed on a host with a very fast local disk performance capability.

To allow for container placement, we will add a metadata label to our Swarm nodes as follows:

docker node inspect worker1 | grep IDdocker node update --label-add type=master 18yrb7m650umx738rtevojpqy

In the above example, the worker1 node with ID 18yrb7m650umx738rtevojpqy has a user defined label of “master” added to it. The master service specifies “master” as a constraint when created, this tells Swarm to place the service on that specific node. The replica specifies a constraint of “node.labels.type != master” to have the replica always placed on a node that is not hosting the master service.

Recipe Step 5 - PostgreSQL Cluster Startup

Finally, we have all the wiring and configuration in place to start running our PostgreSQL cluster. Docker 1.12 provides the service abstraction around the underlying deployed containers. This is a powerful abstraction in that it provides a higher-level form of identifying and deploying your application containers across a set of Docker Swarm hosts.

Our PostgreSQL cluster will be comprised of a PostgreSQL master service and a PostgreSQL replica service. Services are created by running the following commands on the Swarm manager node:

docker service create \
  --mount type=volume,src=$MASTER_SERVICE_NAME-volume,dst=/pgdata,volume-driver=local \
  --name $MASTER_SERVICE_NAME \
  --network crunchynet \
  --constraint 'node.labels.type == master' \
  --env PGHOST=/tmp \
  --env PG_USER=testuser \
  --env PG_MODE=master \
  --env PG_MASTER_USER=master \
  --env PG_ROOT_PASSWORD=password \
  --env PG_PASSWORD=password \
  --env PG_DATABASE=userdb \
  --env PG_MASTER_PORT=5432 \
  --env PG_MASTER_PASSWORD=password \
  crunchydata/crunchy-postgres:centos7-9.5-1.2.5

Then create the replica service as follows:

docker service create
  --mount type=volume,src=$VOLUME_NAME,dst=/pgdata,volume-driver=local \
  --name $SERVICE_NAME \
  --network crunchynet \
  --constraint 'node.labels.type != master' \
  --env PGHOST=/tmp \
  --env PG_USER=testuser \
  --env PG_MODE=slave \
  --env PG_MASTER_USER=master \
  --env PG_ROOT_PASSWORD=password \
  --env PG_PASSWORD=password \
  --env PG_DATABASE=userdb \
  --env PG_MASTER_PORT=5432 \
  --env PG_MASTER_PASSWORD=password \
  --env PG_MASTER_HOST=$MASTER_SERVICE_NAME \
  crunchydata/crunchy-postgres:centos7-9.5-1.2.5

After running these commands, you will end up with a deployment of containers as depicted in this diagram:

Note the following lines from the examples above when creating the Docker services:

--constraint 'node.labels.type == master'

This line supplies a constraint to the Swarm manager when choosing what Swarm node to run the container, in this case, we want the master database container to always run on a host with the master label type, in our case this is the worker1 host.

--network crunchynet

This line specifies the network we want the container to use, in our case the network is called crunchynet.

--mount type=volume,src=$VOLUME_NAME,dst=/pgdata,volume-driver=local

This line specifies a dynamically created Docker volume be created using the local driver and which will be mounted to the /pgdata directory within the PostgreSQL container. The /pgdata volume is where PostgreSQL will store it’s data files.

--env PG_MASTER_HOST=$MASTER_SERVICE_NAME

This line specifies the master PostgreSQL database host and in this case is the Docker service name used for the master database service. This name is resolved by means of the overlay network we created, crunchynet.

Recipe Step 6 - Testing the Cluster

Docker 1.12 provides the service abstraction around the underlying deployed containers. You can view the deployed services as follows:

docker service ps master

docker service ps replica

Given the PostgreSQL replica service is named replica, you can scale up the number of replica containers by running this command:

docker service scale replica=2

docker service ls

You can verify you have two replicas within PostgreSQL by viewing the pg_stat_replication table, the password is password, when logged into the kubernetes-node-1 host:

docker exec -it $(docker ps -q) psql -U postgres -c 'table pg_stat_replication' postgres

You should see a row for each replica along with its replication status.

Example Code

The example described above is provided in the Crunchy Containers Suite github in the following location:

https://github.com/CrunchyData/crunchy-containers/tree/master/examples/docker/swarm-service

Conclusion

The update to Docker with the 1.12 release contains an impressive set of new features that greatly simplify enterprises in deploying PostgreSQL to their container environments. I look forward to other enterprise container features being added to the Docker engine including a distributed storage implementation.

Jeff McCormick, the author, works for Crunchy Data, a leading provider of enterprise open source PostgreSQL technology, support and training.