Skip to content

Latest commit

 

History

History
184 lines (141 loc) · 6.52 KB

build.asciidoc

File metadata and controls

184 lines (141 loc) · 6.52 KB

PostgreSQL Operator Build Instructions

Table of Contents

Overview

This document describes how to build from source code the Postgres Operator, mostly this is for developers or people wanting to hack on the operator.

This document assumes you have already followed the Install instructions and have a working Kube environment.

Requirements

The operator is developed with the Golang versions great than or equal to version 1.8 See Golang website for details on installing golang.

The Operator project builds and operates with the following containers:

This Operator is developed and tested on the following operating systems but is known to run on other operating systems:

  • CentOS 7

  • RHEL 7

Kubernetes Environment

To test the postgres-operator, it is required to have a Kubernetes cluster environment. The Operator is tested on Kubeadm Kubernetes installed clusters. Other Kubernetes installation methods have been known to work as well.

Build from Source

Install a golang compiler, this can be done with either your package manager or by following directions from https://golang.org/dl/. The operator is currently built using golang version 1.8.X but also runs using golang version 1.9.X

Then install the project library dependencies, the godep dependency manager is used as follows:

cd $COROOT
make setup

Compiling the PostgreSQL Operator

cd $COROOT
make all
which pgo

Create Namespace

This example is based on a kubeadm installation with the admin user being already created. The example below assumes the cluster name is kubernetes and the cluster default user is kubernetes-admin.

kubectl create -f $COROOT/examples/demo-namespace.json
kubectl get namespaces

then set your context to the new demo namespace

sudo chmod o+w /etc/kubernetes
sudo chmod o+w /etc/kubernetes/admin.conf
kubectl config set-context demo --namespace=demo --cluster=kubernetes --user=kubernetes-admin
kubectl config use-context demo
kubectl config current-context

Permissions are granted to the Operator by means of a Service Account called postgres-operator. That service account is added to the Operator deployment.

The postgres-operator service account is granted cluster-admin priviledges using a cluster role binding postgres-operator-cluster-role-binding.

See here for more details on how to enable RBAC roles and modify the scope of the permissions to suit your needs.

The sample service account and cluster role bindings specify the demo namespace. Edit the yaml definitions of these to match the namespace you are deploying the operator into.

If you are not using the demo namespace, you will edit the following:

  • $COROOT/deploy/service-account.yaml

  • $COROOT/deploy/cluster-role-binding.yaml

Deploy the PostgreSQL Operator

NOTE: This will create and use /data on your local system as the persistent store for the operator to use for its persistent volume.

cd $COROOT
make deployoperator
kubectl get pod -l 'name=postgres-operator'

You should see output similar to:

NAME                                 READY     STATUS    RESTARTS   AGE
postgres-operator-7f8db87c7b-4tk52   2/2       Running   0          8s

This output shows that both the apiserver and postgres-operator containers are in ready state and the pod is running.

You can find the operator service IP address as follows:

kubectl get service postgres-operator
NAME                TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
postgres-operator   ClusterIP   10.105.56.167   <none>        8080/TCP,8443/TCP   1m

In this example, the apiserver is reachable at https://10.105.56.167:8443.

When you first run the operator, it will create the required CustomResourceDefinitions. You can view these as follows:

kubectl get crd

Instead of using the bash script you can also deploy the operator using the provided Helm chart:

cd $COROOT/chart
helm install ./postgres-operator
helm ls

Verify Installation

When you first run the operator, it will look for the presence of the predefined custom resource definitions, and create them if not found. The best way to verify a successful deployment of the Operator is by viewing these custom resource definitions:

kubectl get crd
kubectl get pgclusters
kubectl get pgreplicas
kubectl get pgbackups
kubectl get pgupgrades
kubectl get pgpolicies
kubectl get pgingests
kubectl get pgtasks

At this point, you should be ready to start using the pgo client! Be sure to set the environment variable CO_APISERVER_URL to the DNS name of the postgres-operator service or to the IP address of the postgres-operator service IP address. For example:

export CO_APISERVER_URL=https://10.105.56.167:8443

Or if you have DNS configured on your client host:

export CO_APISERVER_URL=https://postgres-operator.demo.svc.cluster.local:8443

Makefile Targets

The following table describes the Makefile targets: .Makefile Targets

Target Description

all

compile all binaries and build all images

setup

fetch the dependent packages required to build with

deployoperator

deploy the Operator (apiserver and postgers-operator) to Kubernetes

main

compile the postgres-operator

runmain

locally execute the postgres-operator

pgo

build the pgo binary

runpgo

run the pgo binary

runapiserver

run the apiserver binary outside of Kube

clean

remove binaries and compiled packages, restore dependencies

operatorimage

compile and build the postgres-operator Docker image

apiserverimage

compile and build the apiserver Docker image

lsimage

build the lspvc Docker image

loadimage

build the file load Docker image

rmdataimage

build the data deletion Docker image

release

build the postgres-operator release