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!
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.
There are some points, which we would like to achieve:
… continue reading on Medium