Deploy Django with Helm

This is a follow up post to Deploy Django with helm to Kubernetes which focused on the CI pipeline. This post will highlight a generic Django Helm Chart I made for GlitchTip, an open source alternative to Sentry issue tracking.

Note that Kubernetes and Helm are very complex systems that a simple Django app does not need. GlitchTip, for example, can run on DigitalOcean App Platform.

Django + Celery + Redis Helm Chart

Django Helm Chart can act as a starter Helm Chart for any Django project. While you could use the chart directly, I recommend forking it instead so that you can include your own customizations.

Let’s start with some language definitions and assumptions

• A django app is made of several “components” – often the web server, Celery worker queue, Celery Beat, DB migration job, and databases including Postgres and Redis.
• In addition, we need Helm specific infrastructure such as a Service, Load Balancer, and/or Ingress.
• Environment variables will be stored as Helm values. This is a method that can easily be done with Helm alone. You may want a more complex solution for secrets such as Hashicorp Vault.
• I highly recommend installing Helm Diff. I wouldn’t suggest using Helm without it. One small typo in Helm can delete your entire app.
• This chart supports Helm based Postgres and Redis, however I strongly recommend using a managed service for any persistent data.

Forking the Helm Chart

Start by forking the Django Helm Chart. If you’d like to keep your own secrets in a values.yaml file – ensure this repo is private.

• Edit Chart.yaml and set the name to your project. You may want to edit appVersion, but I find it a little burdensome to increment this. Unless you plan to host a helm chart for many users, it’s not necessary.
• Carefully review values.yaml
  • Notice the tree structure reflects our web and worker components.
  • For new kubernetes users, leave autoscaling off and set replicas manually.
  • Defaults for resources are a guess. Adjust them based on your app’s real world usage.
  • The default web affinity attempts to implement the business rule “Do not run all app pods on the same node”
    • This will only work if you have at least one more node than you need. If one node becomes unhealthy, Kubernetes may be forced to do “bad” things like schedule all pods on one Node. I recommend at least three Nodes for even a smaller production deployment.
  • If your app needs to live on the internet, enable the Ingress. You’ll also need one Load Balancer for your Kubernetes cluster. Technically you can make just a Load Balancer and ignore the Ingress, but I don’t recommend this. Most service providers charge for Load Balancers and it may get expensive running them for staging/testing instances of your app.
  • Consider if you need to enable Postgres and Redis. Personally, I always use a managed, non-kubernetes, Postgres server like RDS or DigitalOcean’s managed databases. If my Redis instance doesn’t need to persist, for example it’s used only for cache or a task queue, I enable it in Kubernetes.
  • Any key-value under environmentVariables will map to environment variables that can be read manually or by django-environ.

Health checks assume a endpoint at /_health/. I suggest adding this to your Django admin, although you could change it in templates/web/deployment.yaml. It isn’t desired to run, for example, your homepage if it involves database lookups. Don’t test your entire app infrastructure, only test that Django is responding.

def health(request):
    return HttpResponse("ok", content_type="text/plain")

path("_health/", health),

Now install your app. Something like

helm install your-chart -f your-values.yaml

What’s next?

Consider contributing any improvements. Here’s a few ideas:

• Better budget, affinity, autoscaling, and resource defaults.
• Ideas for secrets management.
• Enable/Disable features like Celery and more. Done
• Is it worth publishing this chart instead of only forking it?

If you found this chart useful, consider donating time or money to GlitchTip. Donations let me spend more time on various open source projects. GlitchTip is an open source error tracking platform that is compatible with the open source Sentry SDKs. It’s a free software alternative to proprietary platforms like DataDog and Sentry. We also offer a paid hosted service.