Scalable and resilient Django with Kubernetes

This repository contains code and notes to get a sample Django application running on a Kubernetes cluster. It is meant to go along with a related blog post that provides more context and explains some of the theory behind the steps that follow.

Preliminary steps

1. Fetch the source code for this example.

   git clone https://github.com/hnarayanan/kubernetes-django.git
   

2. Install Docker.

3. Take a look at and get a feel for the example Django application used in this repository. It is a simple blog that’s built following the excellent Django Girls Tutorial.

4. Setup a cluster managed by Kubernetes. The effort required to do this can be substantial, so one easy way to get started is to sign up (for free) on Google Cloud Platform and use a managed version of Kubernetes called Google Container Engine (GKE).

   1. Create an account on Google Cloud Platform and update your billing information.

   2. Install the command line interface.

   3. Create a project (that we'll refer to henceforth as $GCP_PROJECT) using the web interface.

   4. Now, we're ready to set some basic configuration.

      gcloud config set project $GCP_PROJECT
      gcloud config set compute/zone europe-west1-d
      

   5. Then we create the cluster itself.

      gcloud container clusters create demo
      gcloud container clusters list
      

   6. Finally, we configure kubectl to talk to the cluster.

      gcloud container clusters get-credentials demo
      kubectl get nodes
      

Create and publish Docker containers

For this example, we'll be using Docker Hub to host and deliver our containers. And since we're not working with any sensitive information, we'll expose these containers to the public.

PostgreSQL

Build the container, remembering to use your own username on Docker Hub instead of hnarayanan:

cd containers/database
docker build -t hnarayanan/postgresql:9.5 .

You can check it out locally if you want:

docker run --name database -e POSTGRES_DB=app_db -e POSTGRES_PASSWORD=app_db_pw -e POSTGRES_USER=app_db_user -d hnarayanan/postgresql:9.5
# Echoes $PROCESS_ID to the screen
docker exec -i -t $PROCESS_ID bash

Push it to a repository:

docker login
docker push hnarayanan/postgresql:9.5

Django app running within Gunicorn

Build the container:

cd containers/app
docker build -t hnarayanan/djangogirls-app:1.2-orange .

Push it to a repository:

docker push hnarayanan/djangogirls-app:1.2-orange

We're going to see how to perform rolling updates later in this example. For this, let's create an alternative version of our app that simply has a different header colour, build a new container app and push that too to the container repository.

cd containers/app
emacs blog/templates/blog/base.html

# Add the following just before the closing </head> tag
    <style>
      .page-header {
        background-color: #ac4142;
      }
    </style>

docker build -t hnarayanan/djangogirls-app:1.2-maroon .
docker push hnarayanan/djangogirls-app:1.2-maroon

Deploy these containers to the Kubernetes cluster

PostgreSQL

Even though our application only requires a single PostgreSQL instance running, we still run it under a (pod) replication controller. This way, we have a service that monitors our database pod and ensures that one instance is running even if something weird happens, such as the underlying node fails.

cd  kubernetes/database
kubectl create -f replication-controller.yaml

kubectl get rc
kubectl get pods

kubectl describe pod <pod-id>
kubectl logs <pod-id>

Now we start a service to point to the pod.

cd  kubernetes/database
kubectl create -f service.yaml

kubectl get svc
kubectl describe svc database

Django app running within Gunicorn

We begin with three app pods (copies of the orange app container) talking to the single database.

cd kubernetes/app
kubectl create -f replication-controller-orange.yaml
kubectl get pods

kubectl describe pod <pod-id>
kubectl logs <pod-id>

Then we start a service to point to the pod. This is a load-balancer with an external IP so we can access the site.

cd kubernetes/app
kubectl create -f service.yaml
kubectl get svc

Before we access the website using the external IP presented by kubectl get svc, we need to do a few things:

1. Perform initial migrations:

   kubectl exec <some-app-orange-pod-id> -- python /app/manage.py migrate
   

2. Create an intial user for the blog:

   kubectl exec -it <some-app-orange-pod-id> -- python /app/manage.py createsuperuser
   

3. Have a CDN host static files since we don't want to use Gunicorn for serving these. This demo uses Google Cloud storage, but you're free to use whatever you want. Just make sure STATIC_URL in containers/app/mysite/settings.py reflects where the files are.

   gsutil mb gs://demo-assets
   gsutil defacl set public-read gs://demo-assets
   
   cd django-k8s/containers/app
   virtualenv --distribute --no-site-packages venv
   source venv/bin/activate
   pip install Django==1.9.5
   export DATABASE_ENGINE='django.db.backends.sqlite3'
   ./manage.py collectstatic --noinput
   gsutil -m cp -r static/* gs://demo-assets
   

At this point you should be able to load up the website by visiting the external IP for the app service (obtained by running kubectl get svc) in your browser.

Go to http://app-service-external-ip/admin/ to login using the credentials you setup earlier (while creating a super user), and return to the site to add some blog posts. Notice that as you refresh the site, the name of the app pod serving the site changes, while the content stays the same.

Play around to get a feeling for Kubernetes' API

Now, suppose your site isn't getting much traffic, you can gracefully scale down the number of running application pods to one. (Similarly you can increase the number of pods if your traffic starts to grow!)

kubectl scale rc app-orange --replicas=1
kubectl get pods

You can check resiliency by deleting one or more app pods and see it respawn.

kubectl delete pod <pod-id>
kubectl get pods

Notice Kubernetes will spin up the appropriate number of pods to match the last known state of the replication controller.

Finally, to show how we can migrate from one version of the site to the next, we'll move from the existing orange version of the application to another version that's maroon.

First we scale down the orange version to just one copy:

kubectl scale rc app-orange --replicas=1
kubectl get pods

Then we spin up some copies of the new maroon version:

cd kubernetes/app
kubectl create -f replication-controller-maroon.yaml
kubectl get pods

Notice that because the app service is pointing simply to the label name: app, both the one orange and the three maroon apps respond to http requests to the external IP.

When you're happy that the maroon version is working, you can spin down all remaining orange versions, and delete its replication controller.

kubectl scale rc app-orange --replicas=0
kubectl delete rc app-orange

Cleaning up

After you're done playing around with this example, remember to cleanly discard the compute resources we spun up for it.

gcloud container clusters delete demo
gsutil -m rm -r gs://demo-assets

And coming in the future

Future iterations of this demo will have additional enhancements, such as using a Persistent Volume for PostgreSQL data and learning to use Kubernetes' Secrets API to handle secret passwords. Keep an eye on the issues for this project to find out more. And you're free to help out too!