It has never been easier to deploy a database with the tools we have available in 2019: Kubernetes, Helm and its charts, including postgresql, enable the creation of a database with a single command: helm install stable/postgresql. Combined with cloud Kubernetes services from Amazon (EKS), Google (GKE) or similar, this piece of stack streamlines the development process and minimizes infrastructure maintenance.

However, this chart does not offer strategies for automated backups. And this security, dear reader, is essential. After all, infrastructure is like plumbing: you only remember it exists when it breaks.

It was with this in mind that the helm-postgres-google-backup chart was developed. It extends the functions of stable/postgresql with scheduled backups saved to a coldline bucket in Google Storage. Additionally, it sends success or error notifications via email using the SendGrid API. The resulting code can be found at this git address.

Implementation

The following requirements were met in the final solution:

• The Chart must allow Postgres backups to be created at the frequency desired by the operator, following the crontab programming pattern;
• The Chart must upload compressed information (.gz) to a folder in Google Storage as soon as it is completed;
• The Chart must send emails at the end of the steps using the Sendgrid API.

Let's take a look at the main files where the logic that meets these requirements is concentrated.

The script google-account-helper.sh is the utility that takes care of the process of creating a service account and a folder (bucket) to store the files, all in Google. In addition, it manages permissions so that the service account can create and list backups, but nothing more. This script has some parameters to be executed, which are listed if the script is invoked without arguments.

This script must be manually executed by the infrastructure administrator before the chart installation takes place. At the end of its execution, it makes available a json file that is a requirement for the chart to function.

The helm/jobs.yaml file in the chart has the entire backup and upload flow in its initContainers. The first - postgres-backup - connects to the database and generates the base dump in a Kubernetes volume (/backups). The second - backup-uploader - performs checks and uploads to the folder, using the service account configured by the google-account-helper.sh script. Depending on the execution result, this container sends success or error emails.

Finally, all execution (backup, upload, email) is scheduled in bash functions in the helm/files/functions.sh file. Each container uses this file through a configMap, invoking its functions.

Conclusion

Although not simple (who said infrastructure is simple?), the final architecture has some benefits: it allows for upgrading postgresql versions, has dependencies on small and well-maintained containers (postgres:11-alpine and google/cloud-sdk:alpine), and is easy to customize (via functions and initContainers). Furthermore, it can be customized for any other database chart, such as Percona, or expanded with encryption, data integrity check jobs, and routines that simplify the restore process.