How to Deploy a Multi-Tier Scalable Django Application with Kubernetes
We’ll take you through how to deploy a multi-tiered web application. Using redis and Django_cache to perform caching for the django application.
Open your terminal window then run the command:
Below are the steps that we'll be using to deploy a complete web app and test the Load of application. This blog will deploy a broken application and we'll be fixing the Kubernetes YAML documents to make the deployment successful. the application will query from the database and return data, but subsequent calls to the URL will bypass the database and query from the cache since the data is already available in the cache.
You’ll first need to provision a namespace. A namespace is a way to segment and bucket objects that you're provisioning in the Kubernetes API. You can check the existing namespaces by running:
kubectl get namespace
We are going to create a new namespace:
kubectl apply -f namespace.yml
The -f flag signifies you’re going to pass a file to kubectl for it to submit to the Kubernetes API. You can run your get namespace command to see what you’ve created.
You can run your get namespace command to see what you’ve created.
You’ll now deploy the first tier of the web application starting with your stateful back-end that stores state for the webapp. kubectl allows you to take a series of YAML files, put them in a folder and run kubectl apply -f against an entire folder. It will provision all of the resources and objects defined underneath the folder.
This allows you to create a grouping of objects and mini-YAML files instead of having a single YAML file with a thousand lines defining everything.
You’ll first roll out the back-end tier of this multi-tier web application - an HA Redis implementation. To have a look around, you can run ls -l redis-app/
You’ll now apply your YAML definitions to the cluster. Run:
This command went through all the files reviewed above and created objects for each one of them.
Now you’ll want to read those objects and get data on what’s running.
You’ll see you have two pods running - A Redis primary and replica.
Now take the same step for the deployments:
You’ll see information about your deployments—the Redis replica, redis primary, the desired count of 1, current 1, up to date, what’s available and the age of the pod.
If you are doing a rolling deployment, you’ll see more interesting information here about the state of an application.
You can also look at services by running:
Here you can see the two services—the primary and replicas.
Both of these services are clusterIP services (i.e. only available on the IP that’s internal to the cluster). You’ll also see the IPs and some info on ports and age. If you wanted to summarize in a single command, you run:
kubectl -n django-multi-tier get deployments,pods,services
This allows you to show all the resources in a single image.
Working through these steps, you should now see a healthy redis master and replica in the django-multi-tier namespace in Kubernetes.
Next you will:
To deploy the basic webapp:
This deploys all the yaml definitions in the django-app/ folder. Note that we are not defining the namespace in the metadata of the YAML, so it will default to the default namespace configured with kubectl.
Accessing Your Services:
Now you can take a look at the services available to see how you might actually access the webapp.
You can see that you have both services attached to Redis which are ClusterIP services only accessible from within the cluster. You’ll also see the third service, the webapp, which is exposed publicly because it’s a load balancer service. When you list services, you get an external IP.
Please check with deployment with URL: http://<IP Address>:31550 or http://<IP Address>
© All rights reserved by Bluetick Consultants LLP