[SE-5518] Initial helm chart for Django applications

Description

This merge request implements the basics for packaging our internal applications using Helm Charts and Helm Libraries. The MR contains two charts and one library:

• libdjango - Helm library that contains templates for django applications
• example - An example chart that can be copy-pasted to save time
• crafty-bot - Helm chart for Crafty Bot, this is the prototype application as it uses every feature

Although values.yaml is not parsed for libraries, it serves as a reference file in the library to see what the library supports. The library provides templates for the following features:

• Django application
• Static file collection job for collecting static files
• Database migrations run job for executing database migrations
• Optional application autoscaling based on RAM/CPU usage
• Optional service account creation
• Celery worker setup (per queue) for async tasks
• Celery beat setup for scheduled tasks
• Celery flower setup for monitoring queues
• Redis integration for caching
• Liveness and Readiness probes for the application and flower to ensure the pods are running

The helm charts are packaged and pushed using the helm plugin, helm-push by chartmuseum. The charts are pushed to GitLab's helm repository for the current (https://gitlab.com/opencraft/ops/helm-charts) repository, which is used by the infrastructure repository's terraform scripts to pull charts.

The values in the values.yaml are intentionally not containing secrets or config map values based on computation. Those values are set by terraform directly, as that's what manages the mentioned resources.

Supporting information

• https://gitlab.com/opencraft/ops/infrastructure/-/merge_requests/21
• https://docs.google.com/document/d/1XpPGMQ_CMbn8Gx1lAZlKJapWEI2s3xFwFBaLxSlWHvo
• https://tasks.opencraft.com/browse/SE-5518

Testing instructions

Steps to test the changes:

1. Proofread changes
2. Clone the repo and checkout changes
3. Install prerequisites
4. Run helm repo add --username <username> --password <access_token> opencraft-helm-charts https://gitlab.com/api/v4/projects/36348812/packages/helm/stable, where <username> and <password> are your GitLab credentials, to add the opencraft-helm-charts Helm repository`
5. Run heml search repo and validate craftybot chart is listed
6. Run helm dependency update crafty-bot
7. Run helm dependency update example
8. Run helm template crafty-bot > rendered.yaml and review the rendered Kubernetes resources
9. Run helm template example > rendered.yaml and review the rendered Kubernetes resources

Dependencies

N/A

Screenshots

The following images are showing the deployed version of the helm crafty-bot chart.

Pods running in the crafty-bot namespace

Kubernetes resources

Port-forwarded flower integration

Exposed application

Checklist

• Documentation is added/updated

Additional context

Why not exposing flower? It is rarely used. Not exposing it does not mean we cannot connect to it. We can use port-forwarding (kubectl --namespace crafty-bot port-forward --address 0.0.0.0 deployments/crafty-bot-flower 8001:5555) and connect to http://localhost:8001 to access it. Also, we would have to assign a basic auth for the ingress controller of the flower service to secure it which makes the debugging slower.