Hide the Complexity of Building/Deploying your Applications on Kubernetes – DevOps Series, Part 9

“Draft” is a useful tool that enables developers to easily build applications and run them in Kubernetes (k8s). It helps you by hiding the complexity of building images, publishing them, and creating the deployments. That way you can focus on what is really important… your code. With only a couple of commands (draft create and draft up) you’re good to go!

Let’s imagine you’re on a team working on a specific microservice (like our own myhero-data: see previous posts). You would be a python coder, constantly expanding its functionality and testing that it works fine. You would need to test it before going to production. But testing it correctly implies deploying into a similar k8s cluster, and you don’t want to be concerned about k8s management. You just want to code!

So once your code is ready you could use a tool like Draft to automatically detect the programming language used, create the required packaging info, build the required images and automatically create a deployment into a k8s test cluster. Sound helpful? Let’s give it a try.

Let’s get it working! First install Draft.

If you choose to use minikube you will have a 1-node k8s cluster running in your own laptop for testing. Otherwise you can use any k8s cluster from a Cloud provider.

First please create a new draft directory, clone there the myhero_data repo and rename it to myherodata (draft does not support the _ character in deployment names):

[cc lang=”python”]mkdir draft
git clone https://github.com/juliogomez/myhero_data.git
mv myhero_data myherodata[/cc]

Go into the new directory and containerize the app by creating a draft pack.

[cc lang=”python”]cd myherodata
draft create[/cc]

This will create the required Helm chart structure and config file (draft.toml). It would also create a default Dockerfile, but we already have one with everything we need.

Let’s quickly configure this for our specific microservice (you just need to do this once before the first test):

• Edit myherodata/charts/python/values.yaml and do 3 things:

1. Replace the default service.internalPort from 8080 to 5000, which is the port defined in our Dockerfile.

2. Change service.type from ClusterIP to NodePort, so that service is accessible from your laptop.

3. Disable ingress access by adding the following 2 lines at the end of the file:

[cc lang=”python”]ingress:
enabled: false[/cc]

• Edit myherodata/charts/python/templates/deployment.yaml to include the required environment variable under spec.template.spec.containers:

[cc lang=”python”]env:
– name: myhero_data_key
value: SecureData[/cc]

We are all set! Now you just need to run:

[cc lang=”python”]draft up[/cc]

It will automatically initiate the process to build the image, push it to your local registry and deploy the microservice in your local k8s cluster (ie. minikube). And as you can see… no k8s management is required from the developer, Draft does everything for you!

Now you can connect to your deployment, although it may take a couple of minutes until Pods are ready. Check with:

[cc lang=”python”]kubectl get pods[/cc]

Once Pods are up and running, check the IP address for your myherodata-python to use by running:

[cc lang=”python”]minikube service list[/cc]

In my case I got the following: http://192.168.99.100:31833
So go ahead and test access via its API with:

[cc lang=”python”]curl -X GET -H “key: SecureData” http://192.168.99.100:31833/options[/cc]

Success!

With any further change made to your code, you just need to issue again:

[cc lang=”python”]draft up[/cc]

And it will automatically upgrade the deployment in your local k8s cluster (minikube). Easy! When you are done, you can delete your deployment by executing:

[cc lang=”python”]draft delete[/cc]

In summary, a python developer creates a microservice called myhero-data. Before sending it to production you want to test it in an environment that is as similar as possible to the production one. Using Draft you can test your new code on a real k8s cluster (like the one in production) with just a couple of commands, and without having to manage at all the k8s cluster you are using.

How cool is that?!?

See you in my next post, stay tuned!

Any questions or comments please let me know in the comments section below, Twitter or LinkedIn.