Nunca foi tão fácil subir uma base de dados com o ferramental que temos disponível em 2019: Kubernetes, Helm e seus charts, entre eles o postgresql permitem a criação de uma base de dados com um único comando: helm install stable/postgresql. Aliado ao serviço de Kubernetes em nuvem da Amazon (EKS), Google (GKE) ou similar, esse pedaço de stack agiliza o processo de desenvolvimento e minimiza a manutenção da infraestrutura.

Mas esse chart não oferece estratégias para backups automatizados. E este seguro, caro(a) leitor(a), é essencial. Afinal, infraestrutura é igual a encanamento: você só lembra que existe quando quebra.

Foi pensando nesta linha que o chart helm-postgres-google-backup foi desenvolvido. Ele amplia as funções do stable/postgresql com backups agendados, salvos em um bucket coldline do Google Storage. Ainda, envia notificações de sucesso ou erro por e-mail utilizando a API da SendGrid. O código resultante pode ser visto neste endereço git.

Implementação

Os seguintes requisitos foram atendidos na solução final:

• O Chart deve permitir que backups Postgres sejam criados com a frequência desejada pelo operador, seguindo o padrão de programação crontab;
• O Chart deve realizar o upload das informações compactadas (.gz) para uma pasta do Google Storage assim que ele for concluído;
• O Chart deve enviar e-mails ao final das etapas usando a API da Sendgrid.

Vamos analisar os principais arquivos onde se concentra a lógica que atende a estes requisitos.

O script google-account-helper.sh é o utilitário que cuida do processo de criação de uma conta de serviço e de uma pasta (bucket) para armazenar os arquivos, todos na Google. Além disso, ele faz a gestão das permissões para que a conta de serviço possa criar e listar backups, mas nada além disso. Este script possui alguns parâmetros para ser executado, que são listados se o script é invocado sem argumentos.

Este script deve ser executado manualmente pelo administrador da infraestrutura antes da instalação do chart acontecer. Ao final de sua execução ele disponibiliza um arquivo json que é requisito para o funcionamento do chart.

O arquivo helm/jobs.yaml do chart possui todo o fluxo de backup e upload em seus initContainers. O primeiro - postgres-backup - conecta ao banco e gera o dump da base em um volume kubernetes (/backups). O segundo - backup-uploader - faz checagens e upload para a pasta, usando a conta de serviço configurada pelo script google-account-helper.sh. A depender do resultado da execução, este container envia e-mails de sucesso ou erro.

Por fim, toda execução (backup, upload, email) é programada em funções bash no arquivo helm/files/functions.sh. Cada container utiliza este arquivo por meio de um configMap, invocando suas funções.

Conclusão

Apesar de não ser simples (quem disse que infraestrutura é simples?) a arquitetura final possui alguns benefícios: permite o upgrade das versões do postgresql, tem dependências de containers pequenos e bem mantidos (postgres:11-alpine e google/cloud-sdk:alpine) e é de fácil customização (via functions e initContainers). Além disso, pode ser customizada para qualquer outro chart de base de dados, como o Percona, ou ampliada com criptografia, jobs que verifiquem integridade de dados e rotinas que simplifiquem o processo de restore.