edb postgres containers and integration with openshift · 1 introduction ... (advanced server) in a...

EDB™ Postgres Containers and Integration with OpenShift

Version 2.0

March 8, 2018

Copyright © 2018 EnterpriseDB Corporation. All rights reserved.

2

EDB Postgres Containers and Integration with OpenShift, Version 2.0 by EnterpriseDB® Corporation


EnterpriseDB Corporation, 34 Crosby Drive, Suite 201, Bedford, MA 01730, USA

T +1 781 357 3390 F +1 978 467 1307 E [email protected] www.enterprisedb.com



Table of Contents

1 Introduction ................................................................................................................. 2

1.1 What’s New ........................................................................................................ 3

1.2 Typographical Conventions Used in this Guide ................................................. 4

2 Preparing to Deploy an Advanced Server Container .................................................. 5

2.1 Deployment Prerequisites ................................................................................... 5

2.1.1 Step One - Create Directories for the Persistent Volumes .............................. 5

2.1.2 Step Two - Create an OpenShift Project ......................................................... 6

2.1.3 Step Three - Configure the Volume Resources .............................................. 6

2.1.4 Step Four - Create a Registry Secret ............................................................. 10

2.1.5 Step Five - Grant Administrative Access...................................................... 11

2.2 Creating a Template .......................................................................................... 12

2.3 Creating a Local Repository ............................................................................. 12

3 Using the OpenShift Console.................................................................................... 13

3.1 Scaling an Advanced Server Deployment ........................................................ 21

3.2 Connecting with the psql Client ........................................................................ 22

3.3 Using a ConfigMap Object to Customize a Configuration ............................... 25

3.4 Performing a Rolling Update ............................................................................ 27

3.5 Performing a Manual Backup ........................................................................... 28

3.5.1 Restoring a Backup into a Pod ...................................................................... 29

3.6 Removing a Project ........................................................................................... 30

3.6.1 Retaining a Project with No Pods ................................................................. 30

3.7 Upgrading from Containers 1.0 ........................................................................ 31

4 Reference .................................................................................................................. 32

4.1 Sample Template File - EDB Postgres Advanced Server, Failover Manager,

pgPool, and BART ........................................................................................................ 32

4.2 Sample Template File - EDB Postgres Advanced Server, Failover Manager,

pgPool, and BART with Custom Features .................................................................... 47

4.3 Sample Template File - BART ......................................................................... 58

4.4 Sample Template File - BART, Managing Backups for Multiple Databases ... 64


Copyright © 2018 EnterpriseDB Corporation. All rights reserved. 2

1 Introduction

EDB™ Postgres Platform for Containers allows you to use a Docker-formatted container

to deploy and manage EDB Postgres Advanced Server (Advanced Server) in a Red Hat

OpenShift environment. OpenShift automation provides an environment in which you

can easily:

Deploy or disable Advanced Server instances as needed.

Automatically scale an Advanced Server instance to meet application

requirements.

Easily ensure Failover Manager protection for your data.

Utilize load balancing to distribute read/write requests across available servers.

Manage Advanced Server instances with custom configurations in a container

environment.

The EDB Postgres Platform for Containers automates the deployment of containers that

include Advanced Server and the following supporting components:

EDB Failover Manager

pgPool (connection pooling for Postgres databases)

The EDB Postgres Platform for Containers also automates the deployment of Docker

containers that install the EDB Postgres Backup and Recovery Tool (BART). BART

provides simplified backup and recovery management for Advanced Server.

For detailed information and documentation for each component, please visit the

EnterpriseDB website at:

http://www.enterprisedb.com/products-services-training/products/documentation

http://www.enterprisedb.com/products-services-training/products/documentation



1.1 What’s New

The following changes have been made to EDB Postgres Containers and Integration with

OpenShift 1.0 to create version 2.0:

You can deploy Advanced Server and supporting components on local volumes or

shared volumes.

EDB containers allow you can provide custom database configurations at startup.

You can use an initialization script to create a custom schema, or pre-load data.

Backup volumes (BART) are stored on shared volumes (for example, glusterFS or

NFS).

A single BART pod can manage backups for multiple database clusters.

pgPool now resides in a separate container (one per node) to route and balance

queries across all of the pods.

You can use OpenShift ConfigMap or Secret objects to help configure and

manage your deployments.



1.2 Typographical Conventions Used in this Guide

Certain typographical conventions are used in this manual to clarify the meaning and

usage of various commands, statements, programs, examples, etc. This section provides a

summary of these conventions.

In the following descriptions a term refers to any word or group of words that are

language keywords, user-supplied values, literals, etc. A term’s exact meaning depends

upon the context in which it is used.

Italic font introduces a new term, typically, in the sentence that defines it for the

first time.

Fixed-width (mono-spaced) font is used for terms that must be given

literally such as SQL commands, specific table and column names used in the

examples, programming language keywords, etc. For example, SELECT * FROM emp;

Italic fixed-width font is used for terms for which the user must

substitute values in actual usage. For example, DELETE FROM table_name;

A vertical pipe | denotes a choice between the terms on either side of the pipe. A

vertical pipe is used to separate two or more alternative terms within square

brackets (optional choices) or braces (one mandatory choice).

Square brackets [ ] denote that one or none of the enclosed term(s) may be

substituted. For example, [ a | b ], means choose one of “a” or “b” or neither

of the two.

Braces {} denote that exactly one of the enclosed alternatives must be specified.

For example, { a | b }, means exactly one of “a” or “b” must be specified.

Ellipses ... denote that the proceeding term may be repeated. For example, [ a |

b ] ... means that you may have the sequence, “b a a b a”.



2 Preparing to Deploy an Advanced Server Container

Advanced Server containers are supported on OpenShift version 3.6 or later. For

information about obtaining and installing OpenShift, please visit:

https://www.openshift.com/

2.1 Deployment Prerequisites

Some prerequisite steps and advanced management tasks are performed at the OpenShift

command line. For detailed information about using the OpenShift command line, see

the project documentation at:

https://docs.openshift.com/container-platform/3.6/cli_reference/get_started_cli.html

Before deploying an EDB Postgres Advanced Server (EPAS) or EDB Postgres Backup

and Recovery Tool (BART) container, you must:

1. Create a directory that will contain the project files.

2. Create an OpenShift project that will describe the resource allocations and

template information for the container.

3. Configure the volume resources that the container will use.

4. Create a registry secret that contains connection information for the container

repository.

5. Grant administrative privileges to the project.

The following sections provide detailed information about each step listed above.

2.1.1 Step One - Create Directories for the Persistent Volumes

Before deploying a container, an administrative user must create the directories in which

the volumes will reside. After creating the directory, the administrator must ensure that

the permissions on the directory allow write access and that the security context of the

directory specifies svirt_sandbox_file_t.

https://www.openshift.com/

https://docs.openshift.com/container-platform/3.6/cli_reference/get_started_cli.html



For example (if you are using local volumes), the following commands create a directory

named edbas; after creating the directory and setting access permissions for the

directory, the chcon command sets the security context of the directory to

svirt_sandbox_file_t:

mkdir /volumes/edbas/edbas96

chmod -R 777 /volumes/edbas/edbas96

chcon -Rt svirt_sandbox_file_t /volumes/edbas/edbas96

Please note: the directory must be created on each OpenShift node, and necessary

privileges granted in OpenShift to use the local (hostPath) volumes.

2.1.2 Step Two - Create an OpenShift Project

After creating the directory in which the project will reside, use the OpenShift command

line utility to login and create a project. Include the -u flag and specify a user name when

connecting:

oc login -u user_name

Then, create a project:

oc new-project project_name

Where project_name specifies the name of the new project.

2.1.3 Step Three - Configure the Volume Resources

After creating a directory (with read/write access) that will be used to store the data files,

log files, and supporting files for your deployments, you must provide the location in the

persistent volume file. You must also provide a corresponding persistent volume claim

file, and if applicable, a glusterfs endpoints file.

The persistent volume and persistent volume claim files contain information that will be

passed to the OpenShift PersistentVolume API and the OpenShift

PersistentVolumeClaim API when deploying your project.

The volume on which Advanced Server resides may be either local or shared, but BART

must reside on a non-local volume. The example that follows uses glusterfs as the shared

volume for BART; you can also use a NFS volume.



To create a volume and a volume claim, login as the system user, and connect to the

project:

oc login -u system

oc project project_name

After creating the supporting files that define the volume and the volume claim, navigate

into the directory in which the files reside, and use the oc create command to register

each file. Include the -f flag, and specify the file name:

oc create -f file_name.yaml

The following sample .yaml files create a persistent volume and volume claim for local

volumes.

The local persistent-volume.yaml File

Include the following content when defining a local persistent volume; customize the

content for your host(s):

apiVersion: v1

kind: PersistentVolume

metadata:

name: persistent_volume_name

spec:

capacity:

storage: 10Gi

accessModes:

- ReadWriteOnce

hostPath:

path: complete_path_to_volume_directory

persistentVolumeReclaimPolicy: Retain

Where:

persistent_volume_name is the name of the persistent volume.

complete_path_to_volume_directory is the directory in which the volume

will reside

The local persistent-volume-claim.yaml File

Include the following content when defining a local persistent volume claim:

apiVersion: v1

kind: PersistentVolumeClaim

metadata:



name: persistent_volume_claim_name

spec:

accessModes:

- ReadWriteOnce

resources:

requests:

storage: 2Gi

volumeName: persistent_volume_name

Where:

persistent_volume_claim_name is the name of the persistent volume claim.

persistent_volume_name is the name of the associated persistent volume.

To use a glusterfs-based shared volumes, use the following the yaml files to create the

endpoint, persistent volume and volume claim.

The glusterfs-endpoint.yaml File

apiVersion: v1

kind: Endpoints

metadata:

name: glusterfs_cluster_name

subsets:

- addresses:

- ip: 192.168.1.147 # node1 IP

ports:

- port: 1

- addresses:

- ip: 192.168.1.148 # node2 IP

ports:

- port: 1 # ignored

The shared persistent-volume.yaml File

Include the following content when defining a shared persistent volume; customize the

content for your host(s):

apiVersion: v1

kind: PersistentVolume

metadata:

name: persistent_volume_name

spec:

capacity:



storage: 4Gi

accessModes:

- ReadWriteMany

glusterfs:

endpoints: glusterfs_cluster_name

path: gv0

readOnly: false

persistentVolumeReclaimPolicy: Retain

Where:

persistent_volume_name is the name of the persistent volume.

glusterfs_cluster_name is the name of the gluster endpoint's .yaml file.

The shared persistent-volume-claim.yaml File

Include the following content when defining a shared persistent volume claim:

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

name: persistent_volume_claim_name

spec:

accessModes:

- ReadWriteMany

resources:

requests:

storage: 2Gi

volumeName: persistent_volume_name

Where:

persistent_volume_claim_name is the name of the persistent volume claim.

persistent_volume_name is the name of the associated persistent volume.

For more information about OpenShift volumes, please see the OpenShift documentation

at:

https://docs.openshift.com/enterprise/3.0/dev_guide/persistent_volumes.html

https://docs.openshift.com/enterprise/3.0/dev_guide/persistent_volumes.html



2.1.4 Step Four - Create a Registry Secret

Use the oc secrets command to create an OpenShift Secret object that contains

connection information for the EnterpriseDB repository:

oc secrets new-dockercfg secret_name \

--docker-server=containers.enterprisedb.com \

--docker-username=repo_user_name \

--docker-password=repo_user_password \

[email protected]

Where:

secret_name specifies the name of the secret.

repo_user_name specifies the name of the EnterpriseDB repository user.

repo_user_password specifies the password associated with the specified user name.

[email protected] specifies the email address of the user.

You must add the secret to your service account; include the default keyword to use

the default service account:

oc secrets add serviceaccount/default secrets/secret_name --

for=pull

The following command creates a secret that can be mounted in a pod:

oc secrets add serviceaccount/builder secrets/ secret_name

You can also use OpenShift Secret objects to manage sensitive information such as

passwords. For more information about using OpenShift Secret objects, see the

OpenShift documentation at:

https://docs.openshift.com/enterprise/3.6/dev_guide/secrets.html

https://docs.openshift.com/enterprise/3.6/dev_guide/secrets.html



2.1.5 Step Five - Grant Administrative Access

The cluster must have administrative rights; use the following commands to bind policies

to the project:

oadm policy add-cluster-role-to-user edit

system:serviceaccount:project_name:default

oc policy add-role-to-user view system:serviceaccount:

project_name:default

Where project_name specifies the name of the project.



2.2 Creating a Template

A template is a .yaml file that describes a set of objects that can be parameterized and

processed to produce a list of objects for creation by OpenShift Container Platform. To

create and upload a template to your current project’s template library, use the command:

oc create -f template-yaml-file

After creating the template, you can customize parameter values during deployment.

Section 4 includes a number of sample template files that you can use as a starting point.

2.3 Creating a Local Repository

To create a local repository that contains EDB Postgres images, you must create a local

Docker registry. For example, the following command creates and start a registry on localhost:5000

docker run -d -p 5000:5000 --restart=always --name registry

registry:2

The following commands will push the Advanced Server image from the EnterpriseDB

repository to a local repository (localhost:5000):

docker pull containers.enterprisedb.com/edb/edb-as:9.6

docker tag containers.enterprisedb.com/edb/edb-as:9.6

localhost:5000/edb/edb-as:9.6

docker push localhost:5000/edb/edb-as:9.6

Use similar steps to create pgPool (edb-pgpool:3.5) and BART (edb-bart:2.0)

repositories.

For information about creating a local Docker registry, please see the Docker

documentation at:

https://docs.docker.com/registry/deploying/#storage-customization

https://docs.docker.com/registry/deploying/#storage-customization



3 Using the OpenShift Console

After creating a project and any required templates (the prerequisite steps outlined in

Section 2), you can use the OpenShift console to create and manage Advanced Server

projects. To create a project, open your web browser, and navigate to the connection

address of your OpenShift console (by default, https://10.1.2.2:8443/console).

Provide your OpenShift credentials and click the Log In button to connect. When you've

successfully authenticated with OpenShift, the console displays the My Projects page

(see Figure 3.1).

Figure 3.1 – The OpenShift console Projects page.

Select your project (for example, edbas96) from the Projects list; the OpenShift

console will navigate to the project management page (see Figure 3.2).

Figure 3.2 – The OpenShift console project management page.

Click the Add to Project button to open the Select Image or Template page (see

Figure 3.3).



Figure 3.3 – The OpenShift console Select Image or Template page.

Select the button that is labeled with the name of the Advanced Server template. The

OpenShift console opens a page that allows you to specify details for your Advanced

Server deployment (see Figure 3.4).

Figure 3.4 – The OpenShift Parameters page.



Use the fields displayed under the Parameters heading to provide installation details

for the deployment. The details provided will be used during pod initialization; it is

important to note that password changes are not allowed after a pod has been initialized.

Use the Database Name field to provide the name of the database that will be

created when the cluster is initialized.

Use the Default database user field to specify the name of a database

superuser that will be created when the database is initialized; by default, the

database superuser is named enterprisedb.

If you accept the default (enterprisedb), the user will be associated with the

password provided by an OpenShift Secret created for the enterprisedb

password.

If you specify an alternate name for the database superuser, the user will be

associated with the password provided via an OpenShift Secret created for the

alternate user password. Optionally, you can provide the name of an alternate

user with a ConfigMap.

Use the Repl user field to specify the name of the replication user; the default

name is repl. Optionally, you can use a ConfigMap to provide the name of a

replication user.

The replication user will be associated with a password provided in a OpenShift

Secret created for the replication user password.

Use the Database Port field to specify the port that the database will monitor

for connections.

Use the Locale field to specify the locale that will be used by the cluster; by

default, the locale used is the system locale.

Use the Host Cleanup Schedule to specify the execution schedule for a

cleanup script. The cleanup script will review the data directories, and mark any

directory for deletion that has not been used in the last 24 hours. If you do not

provide a value in this field, the cleanup script will not execute.

Use the Yum Repository username field to specify the user name that will be

used when authenticating with the EnterpriseDB yum repository. You can

optionally provide this information with a ConfigMap object. Use an OpenShift

Secret to provide the yum repository password.

Use the Email field to provide the email address that will receive any

notifications sent by Failover Manager.



Use the Name Server for Email parameter to provide the identity of a name

server that will be used for notifications from Failover Manager.

Use the Persistent Volume field to specify the name of the persistent volume

definition file.

Use the Persistent Volume Claim to specify the name of the persistent

volume claim definition file.

Use the Backup Volume field to provide the name of the volume claim for

BART.

Use the Backup Volume Claim field to provide the name of the persistent

volume claim for BART.

Use the BART Host Address field to provide the address of the BART server

host.

Use the Database Host field to provide the name of the database server that

BART is backing up.

Use the Automate backup operation field to indicate if backups should be

taken automatically; if you specify No, the BART Backup Schedule field and the

BART Number of Backups to Keep fields will not apply, and you must

manually take backups and manage backup retention.

Use the BART Backup Schedule field to provide cron formatted schedule on

which backups will be performed.

Use the BART Number of Backups to Keep field to specify the number of

database backups that will be stored.

Use the Compress backup files field to specify if backup files should be

stored in compressed format.

Use the Restore File field to specify the name and location of a backup file

that will be restored during the deployment.

Provide a value in the Accept end-user license agreement field; valid

options are Yes or No.

You can use the Labels section of the Parameters dialog to specify one or more tags

that will be applied to the container. For more information about using labels, see the

OpenShift documentation.



When you've completed the Parameters dialog, click the Create button to deploy an

Advanced Server project.

Figure 3.5 – Continue to the project overview.

When the OpenShift console acknowledges that the application has been created; click

the Continue to overview banner (see Figure 3.5).

Figure 3.6 – The template objects have been created successfully.

OpenShift confirms that all of the items described in the template have been created

before deploying Advanced Server pods (see Figure 3.6).

By default, an Advanced Server deployment will consist of four pods, with EDB Failover

Manager protection enabled. To disable failover protection and spin up a pod with a

single replica, you can modify the.yaml file, setting the value for replicas to 1.



Figure 3.7 – The pods are being deployed.

As OpenShift spins up the pod, the progress indicator displayed on the Overview will

change from light blue to darker blue (see Figure 3.7).

Figure 3.8 – The cluster is ready for use.

When the progress indicator is solid blue and indicates that 4 pods have been created,

Advanced Server is ready for use (see Figure 3.8).



Failover Manager will send email notifications to the address specified when you

configured your project, keeping you informed of the state of your pods (see Figure 3.9).

Figure 3.9 – Email notifications from Failover Manager.

Failover Manager notifications make it easy to identify the Master node of your

replication scenario. The Subject line identifies each node in the cluster as a Master or

Standby. Locate the Master agent, and then compare the address shown in the From

column of your email to the names in the Pods list (accessed via the Applications

menu) in the OpenShift console to identify the Master node (see Figure 3.10).

Figure 3.10 – A list of pods, displaying the pod names.



You can also use the oc get pods command to review a list of deployed pods, and

review the status of each node within a cluster:

oc get pods -o wide -L role -L cluster-l cluster=cluster_name

Where:

-o wide includes node information in the (wide) output

-L includes fields that would otherwise not be shown (in our example, the role

and cluster fields)

-l includes the labels in the display

To check the log files for a pod, use the command:

oc rsh pod_name cat startup.log

Where pod_name specifies the name of a specific pod.



3.1 Scaling an Advanced Server Deployment

The default configuration of EDB Postgres Advanced Server for OpenShift uses EDB

Postgres Failover Manager to ensure high-availability for your deployment. If a pod

fails, Failover Manager detects the failure, and replaces the pod with a running node. If

the failed node is the master in your replication scenario, Failover Manager promotes a

standby node to the role of master before adding a replacement standby to the scenario.

To prevent disruptions in Failover Manager monitoring, an Advanced Server deployment

must have at least four pods; by default, each new Advanced Server project will have

four pods.

Figure 3.11 – Use the arrows to the right of the blue circle to scale a deployment.

Please note: by default, the container environment will support up to 9 pods; to support

10 or more pods, you must modify the server configuration.

Manually Scaling a Pod

You can use the up arrow (to the right of the blue circle) to add new pods to your

deployment when processing requirements are higher, or use the down arrow to remove

unneeded pods from the deployment when processing requirements are light (see Figure

3.11). Please note that when removing a pod from your deployment, OpenShift may

remove the master node in your replication scenario. If Failover Manager is enabled, and

the master node is removed during scaling, a standby node will be promoted to the role of

master.

If you plan to remove multiple pods from a deployment, you should allow time for each

pod to be completely removed before removing each additional pod to avoid interfering

with Failover Manager protection.



3.2 Connecting with the psql Client

Connections to Advanced Server and supporting components are managed by OpenShift;

for more information about managing and connecting to an OpenShift pod, refer to the


https://docs.openshift.com/enterprise/3.0/welcome/index.html

OpenShift documentation is also easily accessed through the Documentation link in the

upper-right corner of the OpenShift console.

You can use the OpenShift console Terminal to open a psql client to connect to

Advanced Server and query the server directly. To connect with psql, select Pods from

the Applications menu.

Figure 3.12 – The list of available pods.

When the Pods dialog opens (see Figure 3.12), click the name of a pod to access detailed

information about the selected pod.

https://docs.openshift.com/enterprise/3.0/welcome/index.html



Figure 3.13 – Detailed information about a pod

To open the psql client, select the Terminal tab (see Figure 3.13).



Figure 3.14 – Connecting with the psql client on the Terminal tab

When the Terminal tab opens (as shown in Figure 3.14), use the psql command to

open the client. A psql command takes the following form:

psql –d database_name –U user_name

Where:

database_name specifies the name of the database to which you wish to

connect.

user_name specifies the name of the connecting user.

For detailed information about using the psql client, see the PostgreSQL online

documentation at:

https://www.postgresql.org/docs/9.6/static/app-psql.html

https://www.postgresql.org/docs/9.6/static/app-psql.html



3.3 Using a ConfigMap Object to Customize a Configuration

You can use an OpenShift ConfigMap object to create a template that specifies a custom

configuration, executes SQL commands, or specifies the name of the database superuser.

When specifying a custom parameter value for the postgresql.conf file,

provide the modified parameter=value pair(s) in a file named

postgresql.conf.in.

When specifying a custom entry for the pg_hba.conf file, provide the entry in a

file named pg_hba.conf.in.

When using a ConfigMap to execute SQL commands at deployment, provide the

SQL commands in a file named dbload.

After creating custom files, copy the files into a directory that can be accessed when

deploying the container. Then, create a ConfigMap with the command:

oc create configmap map_name --from-file=directory_name

Where:

map_name is the name of the ConfigMap.

directory_name specifies the directory that contains the custom configuration

files.

After creating the ConfigMap, you must modify the template file, specifying the location

of the files in the volumes section:

- name: mount_name

configMap:

name: map_name

You must also modify the volumeMounts section:

volumeMounts:

- name: mount_name

mountPath: /target_directory

Where:

mount_name is the name used within the template file to link the ConfigMap

name with the target directory on the deployment.

map_name is the name of the ConfigMap.



target_directory is the name of the directory on the deployment to which the

files will be copied.

Any containers deployed using the template will use the customized configuration files.

To create a ConfigMap that specifies the (non-default) name of the database superuser or

replication user, include the --from-literal type, followed by the associated

keyword, and the name of the user.

When specifying the name of a database superuser, include the database.user

keywords.

When specifying the name of a replication user, include the repl.user

keywords.

Use the following command to create the ConfigMap:

oc create configmap --from-literal=user_type=user_name

Where:

user_type is either database.user or repl.user.

user_name is the name of the user.

You do not need to update the template file when using a ConfigMap to specify a non-

default user name.

For detailed information about customizing the postgresql.conf file, please refer to

the Postgres core documentation, available at:

https://www.postgresql.org/docs/10/static/config-setting.html#CONFIG-SETTING-

CONFIGURATION-FILE

For detailed information about customizing the pg_hba.conf file, please refer to the

Postgres core documentation, available at:

https://www.postgresql.org/docs/10/static/auth-pg-hba-conf.html

For more information about using an OpenShift ConfigMap object, please see the


https://docs.openshift.com/enterprise/3.2/dev_guide/configmaps.html

https://www.postgresql.org/docs/10/static/config-setting.html#CONFIG-SETTING-CONFIGURATION-FILE

https://www.postgresql.org/docs/10/static/config-setting.html#CONFIG-SETTING-CONFIGURATION-FILE

https://www.postgresql.org/docs/10/static/auth-pg-hba-conf.html

https://docs.openshift.com/enterprise/3.2/dev_guide/configmaps.html



3.4 Performing a Rolling Update

When an updated version of Advanced Server becomes available, you can use a rolling

update technique to upgrade your cluster. EnterpriseDB's Docker repository will always

make available the most recent version of the server; to update the server version used in

your deployment, you can simply:

1. When an updated version of Advanced Server becomes available, use the

OpenShift console to add new pods to the cluster; as each new pod is added, the

new pod will use the updated server version.

2. Remove pods that were instantiated using the old server version (including the

original master node of the replication scenario).

Please note: To preserve the integrity of your Failover Manager scenario, you should not

let the total pod count of the deployment drop below four when performing a rolling

update.



3.5 Performing a Manual Backup

To perform a manual backup, use the OpenShift command line to identify the BART

container:

oc get pods -o wide -L role -L cluster -l role=backuptool

-l cluster=cluster_name

Then, use the OpenShift command line to log in to the BART container

oc rsh pod_name

Where pod_name is the value displayed for the backuptool in the list of pods.

Then, use BART to perform a backup:

bart -d backup -s edb -Ft -z

For example:

$ bart -d backup -s edb -Ft -z

INFO: creating backup for server 'edb2'

INFO: backup identifier: '1519156132207'

INFO: backup completed successfully

INFO: backup checksum: 8598e84807251bdbcd0903e0dd68b1fd of

base.tar.gz

INFO:

BACKUP DETAILS:

BACKUP STATUS: active

BACKUP IDENTIFIER: 1519156132207

BACKUP NAME: none

BACKUP PARENT: none

BACKUP LOCATION:

/edbbackup/edbas96/edb-bart-1-

363h0/pgbackup/edb/1519156132207

BACKUP SIZE: 7.94 MB

BACKUP FORMAT: tar.gz

BACKUP TIMEZONE: UTC

XLOG METHOD: fetch

BACKUP CHECKSUM(s): 1

ChkSum File 8598e84807251bdbcd0903e0dd68b1fd

base.tar.gz

TABLESPACE(s): 0

START WAL LOCATION: 00000002000000000000000D

BACKUP METHOD: streamed

BACKUP FROM: master

START TIME: 2018-02-20 19:48:52 UTC



STOP TIME: 2018-02-20 19:48:54 UTC

TOTAL DURATION: 2 sec(s)

3.5.1 Restoring a Backup into a Pod

To restore the cluster into a pod, use the Add to Project button to deploy a new

container. Provide the BACKUP LOCATION in the Restore File field on the

Parameters dialog for the deployment:

BART will restore the backup into the container when the deployment completes.



3.6 Removing a Project

Use the following set of commands to remove a project:

oc project project-name

For example, to remove a project named ppas-96:

oc project ppas-96

3.6.1 Retaining a Project with No Pods

You can delete all pods in the project but retain the project for later use; use the

commands:

oc delete dc/database_name-as96

dc/ database_name -pgpool

dc/ database_name -bart

oc delete svc database_name -service

You can reuse the Secret and ConfigMap objects created earlier.



3.7 Upgrading from Containers 1.0

To upgrade from Containers version 1.0 to Containers 2.0, you must upgrade the edb-as

container, and restart the pgPool and BART containers. The following steps detail the

upgrade process.

1. Use pg_dump to perform a logical backup of the edb-as database from your

Containers 1.0 installation. You can optionally take a filesystem backup; this is a

good precautionary step.

2. Delete the Containers 1.0 edb-as pod.

3. Mount the backup volume of Container 1.0 to a Container 2.0 edb-as pod, and

start it as a single pod.

4. Restore the database from the Containers1.0 backup; when the restore completes,

scale the Container 2.0 pod to create standbys.

For detailed information about using pg_dump, see the PostgreSQL online

documentation at:

https://www.postgresql.org/docs/10/static/app-pgdump.html

https://www.postgresql.org/docs/10/static/app-pgdump.html



4 Reference

The following reference sections provide sample template files.

4.1 Sample Template File - EDB Postgres Advanced Server, Failover Manager, pgPool, and BART

The following sample template file deploys Advanced Server, pgPool, Failover Manager,

and BART. The template uses OpenShift Secret objects to provide passwords for the

database user and the EDB yum repository user. After creating the template, you can use

the OpenShift console to provide installation details for your deployment.

apiVersion: v1

kind: Template

metadata:

name: edbas96-persistent

annotations:

description: "Standard EDB Postgres Advanced Server 9.6

Deployment Config"

tags: "database,epas,postgres,postgresql"

iconClass: "icon-postgresql"

objects:

- apiVersion: v1

kind: Service

metadata:

name: ${DATABASE_NAME}-service

labels:

role: loadbalancer

cluster: ${DATABASE_NAME}



spec:

selector:

lb: ${DATABASE_NAME}-pgpool

ports:

- name: lb

port: ${PGPORT}

targetPort: 9999

sessionAffinity: None

type: LoadBalancer

- apiVersion: v1

kind: DeploymentConfig

metadata:

name: ${DATABASE_NAME}-pgpool

spec:

replicas: 2

selector:


strategy:

resources: {}

rollingParams:

intervalSeconds: 1

maxSurge: 25%

maxUnavailable: 25%

timeoutSeconds: 600

updatePeriodSeconds: 1



type: Rolling

template:

metadata:

labels:


role: queryrouter


spec:

containers:

- name: edb-pgpool

env:

- name: DATABASE_NAME

value: ${DATABASE_NAME}

- name: PGPORT

value: ${PGPORT}

- name: REPL_USER

value: ${REPL_USER}

- name: ENTERPRISEDB_PASSWORD

valueFrom:

secretKeyRef:

name: ${DATABASE_NAME}-enterprisedb-passwd

key: password

- name: REPL_PASSWORD

valueFrom:

secretKeyRef:



name: ${DATABASE_NAME}-repl-user-passwd

key: password

- name: ACCEPT_EULA

value: ${ACCEPT_EULA}

image: containers.enterprisedb.com/edb/edb-pgpool:3.5

imagePullPolicy: Always

readinessProbe:

exec:

command:

- /var/lib/edb/testIsReady.sh

initialDelaySeconds: 60

timeoutSeconds: 5

triggers:

- type: ConfigChange

- apiVersion: v1


metadata:

name: ${DATABASE_NAME}-as96

spec:

replicas: 4

selector:

db: ${DATABASE_NAME}-as96

strategy:

resources: {}

rollingParams:



intervalSeconds: 1

maxSurge: 25%

maxUnavailable: 25%

timeoutSeconds: 600


type: Rolling

template:

metadata:

creationTimestamp: null

labels:



spec:

containers:

- name: edb-as96

env:



- name: DATABASE_USER

value: ${DATABASE_USER}

- name: DATABASE_USER_PASSWORD

valueFrom:

secretKeyRef:

name: ${DATABASE_NAME}-database-user-passwd

key: password




valueFrom:

secretKeyRef:


key: password

- name: REPL_USER

value: ${REPL_USER}


valueFrom:

secretKeyRef:


key: password

- name: PGPORT

value: ${PGPORT}

- name: RESTORE_FILE

value: ${RESTORE_FILE}

- name: LOCALEPARAMETER

value: ${LOCALEPARAMETER}

- name: CLEANUP_SCHEDULE

value: ${CLEANUP_SCHEDULE}

- name: EDB_YUM_USERNAME

value: ${EDB_YUM_USERNAME}

- name: EDB_YUM_PASSWORD

valueFrom:

secretKeyRef:



name: edb-yum-repo-password

key: password

- name: EFM_EMAIL

value: ${EFM_EMAIL}

- name: NAMESERVER

value: ${NAMESERVER}

- name: POD_NAMESPACE

valueFrom:

fieldRef:

fieldPath: metadata.namespace

- name: POD_NODE

valueFrom:

fieldRef:

fieldPath: spec.nodeName

- name: POD_IP

valueFrom:

fieldRef:

fieldPath: status.podIP

- name: ACCEPT_EULA


image: containers.enterprisedb.com/edb/edb-as:9.6


readinessProbe:

exec:

command:





timeoutSeconds: 5

livenessProbe:

exec:

command:

- /var/lib/edb/testIsHealthy.sh


timeoutSeconds: 60

ports:

- containerPort: ${PGPORT}

volumeMounts:

- name: ${PERSISTENT_VOLUME}

mountPath: /edbvolume

- name: ${BACKUP_VOLUME}

mountPath: /edbbackup

dnsPolicy: ClusterFirst

restartPolicy: Always

volumes:


persistentVolumeClaim:

claimName: ${PERSISTENT_VOLUME_CLAIM}



claimName: ${BACKUP_VOLUME_CLAIM}



triggers:


- apiVersion: v1


metadata:

name: ${DATABASE_NAME}-bart

spec:

replicas: 1

selector:


strategy:

resources: {}

rollingParams:

intervalSeconds: 1

maxSurge: 25%

maxUnavailable: 25%

timeoutSeconds: 600


type: Rolling

template:

metadata:

labels:


role: backuptool




spec:

containers:

- env:

- name: BART_HOST_ADDRESS

value: ${BART_HOST_ADDRESS}

- name: PGHOST

value: "${DATABASE_NAME}-service"

- name: PGPORT

value: ${PGPORT}



- name: REPL_USER

value: ${REPL_USER}


valueFrom:

secretKeyRef:


key: password

- name: BART_AUTOMATE_BACKUP

value: ${BART_AUTOMATE_BACKUP}

- name: BART_BACKUP_SCHEDULE

value: ${BART_BACKUP_SCHEDULE}

- name: BART_NUM_BACKUPS_TO_KEEP

value: ${BART_NUM_BACKUPS_TO_KEEP}

- name: BART_COMPRESS_BACKUP



value: ${BART_COMPRESS_BACKUP}


value: ${EDB_YUM_USERNAME}


valueFrom:

secretKeyRef:


key: password

- name: ACCEPT_EULA


volumeMounts:



image: containers.enterprisedb.com/edb/edb-bart:2.0


name: edb-bart

volumes:




triggers:


parameters:


displayName: Database Name



description: Name of Postgres database (leave edb for default)

value: 'edb'


displayName: Default database user (leave enterprisedb for

default)

description: Default database user

value: 'enterprisedb'

- name: REPL_USER

displayName: Repl user

description: repl database user

value: 'repl'

- name: PGPORT

displayName: Database Port

description: Database Port (leave 5444 for default)

value: "5444"


displayName: Locale

description: Locale of database

value: 'en_US.UTF-8'


displayName: Host Cleanup Schedule

description: Standard cron schedule - min (0 - 59), hour (0 -

23), day of month (1 - 31), month (1 - 12), day of week (0 - 6)

(0 to 6 are Sunday to Saturday, or use names; 7 is Sunday, the

same as 0). Leave it empty if you dont want to cleanup.

value: '0:0:*:*:*'




displayName: Yum Repository username

description: Yum repository username

value: ''

- name: EFM_EMAIL

displayName: Email

description: Email for EFM

value: '[email protected]'

- name: NAMESERVER

displayName: Name Server for Email

description: Name Server for Email

value: 'nameserver 8.8.8.8'

- name: PERSISTENT_VOLUME

displayName: Persistent Volume

description: Persistent volume name

value: 'edb-edbas96-local-pv'

required: true

- name: PERSISTENT_VOLUME_CLAIM

displayName: Persistent Volume Claim

description: Persistent volume claim name

value: 'edb-edbas96-local-pvc'

required: true

- name: BACKUP_VOLUME

displayName: Backup Volume

description: Backup volume name

value: 'edb-edbas96-shared-pv'



- name: BACKUP_VOLUME_CLAIM

displayName: Backup Volume Claim

description: Backup volume claim name

value: 'edb-edbas96-shared-pvc'


displayName: BART Host Address

description: BART host address (leave localhost for default)

value: 'localhost'

required: true

- name: PGHOST

displayName: Database Host

description: Database Host (leave ${DATABASE_NAME}-service for

default)

value: ${DATABASE_NAME}-service

required: true


displayName: Automate backup operation (leave 'Yes' for

default)

description: Indicates whether backups should be done

automatically

value: 'Yes'

required: true


displayName: BART Backup Schedule




same as 0)



value: '0:0:*:*:*'

required: true


displayName: BART Number of Backups to Keep

description: How many backups to keep, older backups will be

removed as newer backups are added

value: '2'

required: true


displayName: Compress backup files (leave 'Yes' for default)

description: Indicates whether backup files should be

compressed

value: 'Yes'


displayName: Restore File

description: Restore file location

value: ''

- name: ACCEPT_EULA

displayName: Accept end-user license agreement (leave 'Yes' for

default)

description: Indicates whether user accepts the end-user

license agreement

value: 'Yes'

required: true



4.2 Sample Template File - EDB Postgres Advanced Server, Failover Manager, pgPool, and BART with Custom Features

The following sample template deploys Advanced Server, pgPool, Failover Manager, and

BART with additional features. In addition to using OpenShift Secret objects to provide

passwords for the database users and the EDB yum repository user, the template uses

OpenShift ConfigMap objects to provide usernames, custom database configuration files

(postgresql.conf, pg_hba.conf), and an initialization script.

Please Note: This example assumes that a ConfigMap volume and edb-initconf-vol

volume (where edb is the name of the database), have been created to store:

custom server configurations in postgresql.conf.in and pg_hba.conf.in

an initialization script named dbload

apiVersion: v1

kind: Template

metadata:

name: edbas96-persistent2

annotations:

description: "Standard EDB Postgres Advanced Server 9.6

Deployment Config"

tags: "database,epas,postgres,postgresql"


objects:

- apiVersion: v1

kind: Service

metadata:

name: ${DATABASE_NAME}-service

labels:

role: loadbalancer




spec:

selector:


ports:

- name: lb

port: ${PGPORT}

targetPort: 9999

sessionAffinity: None

type: LoadBalancer

- apiVersion: v1


metadata:

name: ${DATABASE_NAME}-pgpool

spec:

replicas: 2

selector:


strategy:

resources: {}

rollingParams:

intervalSeconds: 1

maxSurge: 25%

maxUnavailable: 25%

timeoutSeconds: 600




type: Rolling

template:

metadata:

labels:


role: queryrouter


spec:

containers:

- name: edb-pgpool

env:



- name: PGPORT

value: ${PGPORT}

- name: REPL_USER

valueFrom:

configMapKeyRef:

name: ${DATABASE_NAME}-config

key: repl.user


valueFrom:

secretKeyRef:




key: password


valueFrom:

secretKeyRef:


key: password

- name: ACCEPT_EULA


image: containers.enterprisedb.com/edb/edb-pgpool:3.5


readinessProbe:

exec:

command:



timeoutSeconds: 5

triggers:


- apiVersion: v1


metadata:

name: ${DATABASE_NAME}-as96

spec:

replicas: 4

selector:




strategy:

resources: {}

rollingParams:

intervalSeconds: 1

maxSurge: 25%

maxUnavailable: 25%

timeoutSeconds: 600


type: Rolling

template:

metadata:

creationTimestamp: null

labels:



spec:

containers:

- name: edb-as96

env:




valueFrom:

configMapKeyRef:




key: database.user

- name: DATABASE_USER_PASSWORD

valueFrom:

secretKeyRef:

name: ${DATABASE_NAME}-database-user-passwd

key: password


valueFrom:

secretKeyRef:


key: password

- name: REPL_USER

valueFrom:

configMapKeyRef:


key: repl.user


valueFrom:

secretKeyRef:


key: password

- name: PGPORT

value: ${PGPORT}




value: ${RESTORE_FILE}


value: ${LOCALEPARAMETER}


value: ${CLEANUP_SCHEDULE}


valueFrom:

configMapKeyRef:

name: edb-config

key: yum.repo.user


valueFrom:

secretKeyRef:


key: password

- name: EFM_EMAIL

value: ${EFM_EMAIL}

- name: NAMESERVER

value: ${NAMESERVER}


valueFrom:

fieldRef:


- name: POD_NODE

valueFrom:



fieldRef:

fieldPath: spec.nodeName

- name: POD_IP

valueFrom:

fieldRef:

fieldPath: status.podIP

- name: ACCEPT_EULA


image: containers.enterprisedb.com/edb/edb-as:9.6


readinessProbe:

exec:

command:



timeoutSeconds: 5

livenessProbe:

exec:

command:

- /var/lib/edb/testIsHealthy.sh


timeoutSeconds: 30

ports:

- containerPort: ${PGPORT}

volumeMounts:




mountPath: /edbvolume



- name: edb-initconf

mountPath: /initconf

dnsPolicy: ClusterFirst

restartPolicy: Always

volumes:



claimName: ${PERSISTENT_VOLUME_CLAIM}




- name: edb-initconf

configMap:

name: ${DATABASE_NAME}-initconf-vol

triggers:


parameters:




value: 'edb'



- name: PGPORT



value: "5444"


displayName: Locale

description: Locale of database

value: 'en_US.UTF-8'


displayName: Host Cleanup Schedule




same as 0). Leave it empty if you dont want to cleanup.

value: '0:0:*:*:*'

- name: EFM_EMAIL

displayName: Email

description: Email for EFM

value: '[email protected]'

- name: NAMESERVER

displayName: Name Server for Email

description: Name Server for Email

value: 'nameserver 8.8.8.8'

- name: PERSISTENT_VOLUME

displayName: Persistent Volume

description: Persistent volume name



value: 'edb-edbas96-local-pv'

required: true

- name: PERSISTENT_VOLUME_CLAIM

displayName: Persistent Volume Claim

description: Persistent volume claim name

value: 'edb-edbas96-local-pvc'

required: true










displayName: Restore File

description: Restore file location

value: ''

- name: ACCEPT_EULA


default)


license agreement

value: 'Yes'

required: true



4.3 Sample Template File - BART

Use the following template to deploy a BART container:

apiVersion: v1

kind: Template

metadata:

name: edb-bart

annotations:

description: "Standard EDB Backup And Recovery Tool

Deployment Config"

tags: "database,edbas,postgres,postgresql"


labels:

template: edb-bart

objects:

- apiVersion: v1


metadata:


spec:

replicas: 1

selector:


strategy:

resources: {}

rollingParams:



intervalSeconds: 1

maxSurge: 25%

maxUnavailable: 25%

timeoutSeconds: 600


type: Rolling

template:

metadata:

labels:


role: backuptool


spec:

containers:

- env:





- name: PGHOST


- name: PGPORT

value: ${PGPORT}

- name: REPL_USER

valueFrom:



configMapKeyRef:


key: repl.user


valueFrom:

secretKeyRef:


key: password




value: "${BART_BACKUP_SCHEDULE}"


value: "${BART_NUM_BACKUPS_TO_KEEP}"




valueFrom:

configMapKeyRef:

name: edb-config

key: yum.repo.user


valueFrom:

secretKeyRef:




key: password


valueFrom:

fieldRef:


- name: ACCEPT_EULA


volumeMounts:



image: containers.enterprisedb.com/test/edb-bart:2.0


name: edb-bart

volumes:




triggers:


parameters:




value: 'localhost'

required: true






value: 'edb'

required: true

- name: PGHOST



default)


required: true

- name: PGPORT



value: '5444'

required: true













default)


automatically

value: 'Yes'

required: true






same as 0)

value: '0:0:*:*:*'

required: true





value: '2'

required: true




compressed

value: 'Yes'

required: true

- name: ACCEPT_EULA


default)




license agreement

value: 'Yes'

required: true

4.4 Sample Template File - BART, Managing Backups for Multiple Databases

The following sample template deploys a BART container that can support multiple

databases.

Please Note: This example assumes that a ConfigMap volume and edb-bart-vol

volume (where edb is the name of the database), have been created to store custom

configurations in bart.cfg.in.

The following is an example of a bart.cfg.in entry for an additional database

named edb2:

[edb2]

host=edb2-service

port=5444

user=repl

cluster_owner=enterprisedb

apiVersion: v1

kind: Template

metadata:

name: edb-bart

annotations:

description: "Standard EDB Backup And Recovery Tool

Deployment Config"

tags: "database,edbas,postgres,postgresql"




labels:

template: edb-bart

objects:

- apiVersion: v1


metadata:


spec:

replicas: 1

selector:


strategy:

resources: {}

rollingParams:

intervalSeconds: 1

maxSurge: 25%

maxUnavailable: 25%

timeoutSeconds: 600


type: Rolling

template:

metadata:

labels:


role: backuptool




spec:

containers:

- env:





- name: PGHOST


- name: PGPORT

value: ${PGPORT}

- name: REPL_USER

valueFrom:

configMapKeyRef:


key: repl.user


valueFrom:

secretKeyRef:


key: password






value: "${BART_BACKUP_SCHEDULE}"


value: "${BART_NUM_BACKUPS_TO_KEEP}"




valueFrom:

configMapKeyRef:

name: edb-config

key: yum.repo.user


valueFrom:

secretKeyRef:


key: password


valueFrom:

fieldRef:


- name: ACCEPT_EULA


volumeMounts:



- name: edb-bartconf



mountPath: /bartconf

image: containers.enterprisedb.com/test/edb-bart:2.0


name: edb-bart

volumes:




- name: edb-bartconf

configMap:

name: ${DATABASE_NAME}-bartconf-vol

triggers:


parameters:




value: 'localhost'

required: true




value: 'edb'

required: true

- name: PGHOST





default)


required: true

- name: PGPORT



value: '5444'

required: true











default)


automatically

value: 'Yes'

required: true








same as 0)

value: '0:0:*:*:*'

required: true





value: '2'

required: true




compressed

value: 'Yes'

required: true

- name: ACCEPT_EULA


default)


license agreement

value: 'Yes'

required: true

edb postgres containers and integration with openshift · 1 introduction ... (advanced server) in a...

Documents