GCP GKE Kubernetes deployments with GitLab the KISS way

Simple, flexible, traceable and reproducible GitOps based Kubernetes deployments - no Helm, no Kustomize - just templates. There are many tools out there which are all great and these tools are solving the problems which they are made for very well. But, at work, we have a different situation. As you might know, we do not have one application with thousands of containers. We have hundreds of applications with 3 two 20 containers. And as you can imagine, this applications are using different technology stacks and are in varying stages of technology progress. Some applications are already capable to use services meshes, like single plage applications where others are still war-file based monoliths and this is also OK!

The idea

At first, I’ve tried to use the usual suspects: Kustomize and Helm. Both are very nice tools and they are solving specific problems. Kustomize makes it easy to handle different environments for example whereas Helm makes it easy to “package” your application to be distributed on the internet. So at the end, if you need to be flexible, you may end up that you need both tools. Have you ever typed “Kustomize vs Helm” into Google? Helm Is Not Enough, You Also Need Kustomize is one of the first results. Using two abstraction layers is too much because you have to take care about the situation, that both tool have to fit together and if something is not covered one of these tools, you will need a third one. Thats not what you want, though. One again, if you do not have a highly diverse application situation, you can probably go with one of them easily!

So what know? Well somewhere back in time, I wrote a tool (in Golang) which was able to take some data (from JSON) and a template to create a config. The power of *nix comes with the config-files. Simple files, nothing more. The tool was not very powerful but thankfully Dave Henderson wrote an impressive tool, called gomplate. So, hey, easy-peasy we will write our own glue to fit our needs. I will call this approach Kploy.

One reason for this is, that we are not willing to give up our GitOps way of work, even when we are using Kubernetes.

The environment

There are some points, which we would like to achieve: * GitLab as the one and only source of truth * If a deployments fails, we would like to roll back not only by Kubernetes but with Pipelines * If a Kubernetes cluster fails, we would like to redeploy, everything needs to be stored as code * If a change is made, it must be know who did the change (GitLab commit) * Different deployment strategies must be supported * Istio * various other ingress controllers (even hand made) * all of the needed configurations (Istio gateways for example) must be configurable and deployable * Node ports, raw deployments * blue-green deployments, dog food tagging, … * Different environments must be supported * dev, test, staging, education, productive * external variables are needed, different clusters, images * certificate management for the Istio SDS or other solutions * …

… continue reading on Medium