Run your service like a drug lord

Containers changed how we develop, deploy and run our software but it’s still relatively new area, people tend to bring old bad habits.

In this article I will give a short demo on how to run your service with Github, GKE and Keel. We will deploy a simple application that can be then updated automatically by tagging a new release.

You might not have heard yet about Keel. It is a tool that automatically updates your deployments and Helm charts based on policies. It has no CLI, API/UI — all configuration is done through native k8s labels or Helm chart so no need to learn or download new tools.

First things first, let’s define some rules on how we do “business”:

• Don’t be sloppy.
• Don’t do dirty work yourself.
• If something *cough* happened *cough* to you — service must keep running.

Prerequisites

• Basic knowledge of Kubernetes, containers.
• Google Cloud account, register for free tier here.
• Provisioned Kubernetes cluster.

If you have these then good, if no — you can either get that cluster up and running or just continue reading.

Don’t be sloppy

Use semver, seriously, just use it. Git is a single source of truth for your software, so when you tag a new release that should be it — no bugfixes/features can go into that version. If you add something then make minor or patch release.

Let’s have a look at this example Docker repository: https://hub.docker.com/r/karolisr/keel/tags/

and corresponding Git repository:

https://github.com/rusenask/keel/releases

what do we see? A mirrored Github and Docker image tags. Easiest way to setup this is with https://cloud.docker.com or Google Cloudbuild. It’s important that a 3rd party tool and not you build the image as it will checkout latest release from source control without your undocumented local quick-fixes. Docker cloud configuration looks like this:

Our example application will be Keel itself because if a continuous delivery tool cannot upgrade itself then it can’t call itself an automation tool.

Don’t do dirty work yourself

It’s time consuming to deploy your service once. Don’t make it a habit to redeploy everything by hand for each release.

Let’s imagine that we have an outdated version of our application. Get this deployment sample file:

curl https://raw.githubusercontent.com/rusenask/keel/master/hack/deployment.sample.yml > deployment.yml

Now add two labels to deployment metadata:

keel.sh/policy: major
keel.sh/trigger: poll

These labels will indicate update policy and trigger type. Update policies can for example allow only major, minor or patch releases. We are setting poll type trigger to start actively looking for updates.

Change deployment image version to something a bit ancient like:

- image: karolisr/keel:0.3.1

Create it:

kubectl create -f deployment.yml

Now sit back and relax, in a minute Keel will update itself. Why minute? It’s default polling schedule, you can change it. If you had Slack notifications configured you would see something like:

Don’t update deployments yourself, it’s not interesting, not safe and sloppy. Someone else (in this case it’s Keel) can do it.

Check pods (you can describe pod as well to make sure that newest version is there):

$ kubectl get pods -n kube-system | grep keel
keel-3397426012-1lx2x                                  2/2       Running   0          1m

If something *cough* happened *cough* to you — service must keep running

Let’s say that you want to take a weekend off (some of you might not have side projects, lucky!) or go for a holiday and you are a single person in the team/company. Who watches your services? If you are using managed services like GKE with several nodes and enabled node repair — it’s highly likely that this cluster will survive for a long time without you.

If a cache server, some 3rd party worker service got a patch release for a critical bug/vulnerability — Keel would update it (assuming that patch policy is set).

Furthermore, Kubernetes encourages users to implement readiness also known healthcheck endpoints so it can restart, move your applications around the cluster (even if your cluster consists of 3 f1-micro nodes).

Conclusion

In this article we saw how easy it is to get a mini PaaS where on Github release tag using tools like Cloudbuild on docker cloud builder you can get an image with the same version.

We also saw how easy it is to install Keel and mark deployments for automated updates, just specifying few labels, Keel user guide is available here: https://keel.sh/user-guide.

I haven’t touched testing, but 3rd party automation tools like CircleCI are easily approachable and free, use them.

I am usually available on Kubernetes Slack channel, feel free to dm me.

Twitter: https://twitter.com/KRusenas.

Don’t forget to start Keel repo https://github.com/rusenask/keel !

Thanks for reading.