How kubernetes and CI made my job so easy

When I started publishing my web apps online I used a simple linux VM running a native process behind an nginx reverse proxy, that sounds good in theory, especially for smaller sites that don’t have an SLA, infrequent updates and are a single binary. The problem is that for anything serious something as simple as a no-downtime upgrade can be very tedious to implement and maintain. Sure, use HAProxy in front of your server processes and call it an evening, but that still will come with it's own set of issues and is not recommended for small teams with no time to spare.

Containerization

The first step in my journey as a dev with real technical needs was containerization. It’s amazing, just define your build process in a file, let the tool build it for you and push it to a registry and run that as an easily manageable unit on your host. I've initially used portainer as it enabled managing docker containers via a web UI, it easily gets the job done.

Sadly using only this approach is not perfect, when updating you still need to drain your backends to avoid failed requests, and update your containers one by one. High availability is also tedious to maintain, you need to secure multiple hosts and have a separate machine running a reverse proxy, it can get real messy even if less than native executables.

Continuous integration

If you use something like Github, you likely have heard of Github Actions, a simple yet effective tool to run scripts on a branch push or merge. With Actions, our team has created a build system that generates a build version, creates and pushes the containers to a registry.

Versioning your images

Pushing to your “latest” tagged image will seem like a simple and efficient approach, just re-pull the latest image whenever there is a new version. However this is a major issue, you want to have a version tag on your images for something as simple as a rollback or just to know what version is currently running on the host. Using portainer with versioning is quite a hassle as you need to manually update the tag on your containers, this is error prone and tedious.

But worry not! Continuous integration is here just for this, you can create a simple python script that generates a version number in a file inside your repository. I personally prefer using a [YEAR].[MONTH].[BUILD NUMBER] version system (ex. 2024.1.49) but some people prefer semantic versioning [MAJOR].[MINOR].[PATCH] system (1.28.189). In my opinion both are valid and serve their specific purpose. Date based versioning is useful in a "live service" approach and semantic versioning is better for applications that require maintaining compatibility with previous products.

Once you have decided on a system for versioning, you simply store the output in a repository file and tag your docker images before pushing them.

My experience with Kubernetes

A few weeks before deploying my first ever production application I had to consider a few technical requirements, the following:

• Deploy the latest services using a single command
• No downtime upgrades to deployments
• Rollback capabilities
• Easy horizontal scaling

All of these boxes are ticked by Kubernetes, I can simply create a helm chart describing the desired state of my deployments, their numbers of replicas, etc... After a few days of tinkering with the cluster we created with our cloud provider I was starting to get the hang of it. K8S (Kubernetes) has lots of options for configuration but runs reliably with a few essential ones.

Allowing for near-instant scaling of worker nodes, K8S is a top contender in the container orchestration space along with alternatives such as Nomad w/ Terraform. Run containers, jobs and route traffic to your backends easily. K8S also couples very closely to your cloud provider of choice for things such as load balancers and block volumes.

Conclusion

Now thanks to continuous integration and Kubernetes, pushing an update is as simple as merging from the feature branch to a "central" branch that generates a version, then merging into the preview branch and then onto master, with each step having its own scripts. Once the patch makes it onto master, the DevOps only has to run a single command to upgrade the helm chart. The entire process being highly automated and taking less than 15 minutes including build time. We run 9 services across 40+ pods reliably and they get upgraded easily.

Register to the newsletter to get the latest articles! Have a good one.