Bob Pacheco: CI/CD with Crunchy Postgres for Kubernetes and Argo

Continuous Integration / Continuous Delivery (CI/CD) is an automated approach in which incremental code changes are made, built, tested and delivered. Organizations want to get their software solutions to market as quickly as possible without sacrificing quality or stability. While CI/CD is often associated with application code, it can also be beneficial for managing changes to PostgreSQL database clusters. GitOps plays an important part in enabling CI/CD. If you are unfamiliar with GitOps, I recommend starting with my previous post on Postgres GitOps with Argo and Kubernetes. Today I have a working sample to walk through for implementing basic CI/CD using Crunchy Postgres for Kubernetes, ArgoCD, and a self test container. In the following steps we will: Deploy a Postgres cluster to a developer namespace Run a series of tests on the deployed cluster Once the tests pass we will automatically deploy the same postgres cluster to a QA namespace. Prerequisites Crunchy Postgres for Kubernetes v5.3 or later. The sidecar functionality should be enabled. To enable the sidecar functionality you will need to add the following to the Deployment.spec.template.spec.containers.env section of the manager.yaml file located in the postgres-operator-examples/kustomize/install/manager directory. - name: PGO_FEATURE_GATES value: 'InstanceSidecars=true' ArgoCD v 2.6 or later deployed in the Kubernetes cluster. A private container registry containing the images you want to deploy. Most organizations will pull images, tag them and then upload them into their private registries. For this blog I am using a private registry for all images except the self test. That image is in a public repo in my docker registry. A git repository containing the Crunchy Postgres for Kubernetes manifest to be deployed. Here's a sample manifest you can use or you can fork my git repository. - kustomization.yaml resources: # - argocd-token.yaml - hippo-self-test-config.yaml [...]