Victor Farcic - The DevOps 2.4 Toolkit: Continuous Deployment to Kubernetes - Continuously deploying applications with Jenkins to a Kubernetes cluster

Just like the other books I wrote, this one does not have a fixed scope. I did not start with an index. I didnt write a summary of each chapter in an attempt to define the scope. I do not do such things. There is only a high-level goal to explore continuous delivery and deployment inside Kubernetes clusters. What I did do, though, was to set a few guidelines.

The first guideline is that all the examples will be tested on all major Kubernetes platforms. Well, that might be a bit far-fetched. Im aware that any sentence that mentions all together with Kubernetes is bound to be incorrect. New platforms are popping out like mushrooms after rain. Still, what I can certainly do is to choose a few of the most commonly used ones.

Minikube and Docker for Mac or Windows should undoubtedly be there for those who prefer to play with Docker locally.

AWS is the biggest hosting provider so Kubernetes Operations (kops) must be included as well.

Since it would be silly to cover only un-managed cloud, I had to include managed Kubernetes clusters as well. Google Kubernetes Engine (GKE) is the obvious choice. It is the most stable and features rich managed Kubernetes solution. Adding GKE to the mix means that Azure Container Service (AKS) and Amazons Elastic Container Service (EKS) should be included as well so that we can have the big trio of the hosting vendors that offer managed Kubernetes. Unfortunately, even though AKS is available, it is, at this moment (June 2018), still too unstable and its missing a lot of features. So, Im forced to scale down from the trio to the GKE and EKS duo as representatives of managed Kubernetes well explore.

Finally, a possible on-prem solution should be included as well. Since OpenShift shines in that area, the choice was relatively easy.

All in all, I decided to test everything in minikube and Docker for Mac locally, AWS with kops as the representative of a cluster in the cloud, GKE for managed Kubernetes clusters, and OpenShift (with minishift) as a potential on-prem solution. That, in itself, already constitutes a real challenge that might prove to be more than I can chew. Still, making sure that all the examples work with all those platforms and solutions should provide some useful insights.

Some of you already chose the Kubernetes flavor youll use. Others might still wonder whether to adopt one or the other. Even though the comparison of different Kubernetes platforms is not the primary scope of the book, Ill do my best to explain the differences as they come.

To summarize the guidelines, it explores continuous delivery and deployment in Kubernetes using Jenkins. All the examples will be tested in minikube, Docker for Mac (or Windows), AWS with kops, GKE, OpenShift with minishift, and EKS.

The moment I finished writing the previous paragraph I realized that I am repeating the same mistakes from the past. I start with something that looks like a reasonable scope, and I end up with something much bigger and longer. Will I be able to follow all of those guidelines? I honestly dont know. Ill do my best.

I was supposed to follow the best practice by writing the overview at the end. Im not doing that. Instead, you are reading about the plans for the book, not the end result. This is not an overview. You can consider this as the first page of the diary. The end of the story is still unknown.

Eventually, you might get stuck and will be in need of help. Or you might want to write a review or comment on the books content. Please join the DevOps20 Slack channel and post your thoughts, ask questions, or participate in a discussion. If you prefer a more one-on-one communication, you can use Slack to send me a private message or send an email to viktor@farcic.com. All the books I wrote are very dear to me, and I want you to have a good experience reading them. Part of that experience is the option to reach out to me. Dont be shy.

Please note that this one, just as the previous books, is self-published. I believe that having no intermediaries between the writer and the reader is the best way to go. It allows me to write faster, update the book more frequently, and have more direct communication with you. Your feedback is part of the process. No matter whether you purchased the book while only a few or all chapters were written, the idea is that it will never be truly finished. As time passes, it will require updates so that it is aligned with the change in technology or processes. When possible, I will try to keep it up to date and release updates whenever that makes sense. Eventually, things might change so much that updates are not a good option anymore, and that will be a sign that a whole new book is required. I will keep writing as long as I continue getting your support.