Chat is continuous integration (CI), continuous delivery (CD), continuous deployment (CDP), and continuous testing (CT)? How do they differ from each other? Which one should we use?Continue reading
What do we get if we combine events, workflows, GitOps, progressive delivery, and secrets management? The short answer is that we get automation of everything in Kubernetes in a way that we should be operating in 2021.
We’ll combine Argo Events, Workflows & Pipelines, CD, and Rollouts and sprinkle all that with SealedSecrets, Kaniko, and a few other tools.
Argo Workflows & Pipelines is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. It is a cloud-native solution designed from ground-up for Kubernetes.
Progressive delivery (blue-green, rolling updates, canaries, etc.) is a set of deployment practices that aim at rolling out new features gradually.
Release frequency keeps increasing and, with it, the need to get away from static environments like staging, integration, and other permanent setups. Dynamic environments based on pull requests are probably the best example of a need for a much higher level of dynamism. Kubernetes allows us to easily create whatever we need, and destroy what is not in use. There is no need for anything, especially not environments to be permanent, except for production. We can get far in that direction by combining GitOps practices and Argo CD in a way that each pull request (PR) creates a new environment that is destroyed when a PR is closed. By doing that, we can improve efficiency while, at the same time, reducing the costs.
Since the increase in popularity of continuous delivery (CD), there was an increase in the number of tools marketed as CD solutions. That’s normal. It is only natural for software vendors to ride the waves. They need to sell, and there’s nothing better to sell than whatever is popular at a given moment. Continuous delivery is one of those "popular" waves.
On the surface, there is nothing wrong with buying tools that solve problems. You have a problem, a vendor has a solution, you buy it, they earn money, and you have a good return on investment. Everybody wins, except when the tool does not do what it’s supposed to do. That’s when we run into issues.
The video below is a clip from the "Canary Deployments To Kubernetes Using Istio and Friends" course in Udemy. It provides the introduction to the course we released in December 2019. Additional preview clips are available inside the course. Please use the coupons with discounts provided below.
If you do enrol into the course, please let us know what you think and do NOT forget to rate it.
$9.99 coupon available until December 30, 2019: https://www.udemy.com/course/canary-deployments-to-kubernetes-using-istio-and-friends/?couponCode=66C518BC01D2339CABCB
$13.99 coupon available until January 27, 2020: https://www.udemy.com/course/canary-deployments-to-kubernetes-using-istio-and-friends/?couponCode=7F311AD2C040117054AB
Coupon with whatever is Udemy’s best price: https://www.udemy.com/course/canary-deployments-to-kubernetes-using-istio-and-friends/?referralCode=75549ECDBC41B27D94C4
Welcome to practical guide to canary deployments. Unlike some other work that I did…tutorials, workshops, and so on and so forth, that were very focused on a single tool, this time I will focus more on a process.
We’re going to try to figure out how to do canary deployments inside of Kubernetes. Because Kubernetes is everywhere now, I will assume that you are using Kubernetes. But outside of that, we are going to try to figure out which tools to use, but all serving as the process itself, not for the sake of learning a specific tool. And during that process, we are going to decide which tools to use and why to use them and the end result will be a fully operational canary deployments process that you will be able to plug into any CI/CD tool or any tool that orchestrates the lifecycle of your application.
So we will definitely choose some tools that we will use in a process.
And those tools will be revolving around Istio. I will explain why Istio a bit later.
So we will use Kubernetes and Istio for canary deployments, but the end result will be agnostic to the tool that will orchestrate your processes. We will most likely also have to choose one or two additional tools. Which tools we’ll choose is yet to be discovered.
For now just think of this as being a practical guide to a specific process. And that process today is canary deployments in Kubernetes.
A while ago, we (Viktor Farcic and Darin Pope) thought it would be a good idea to add an out-of-the-box option to use canary deployments in Jenkins X. We should have finished it by now, and yet we did not even start working on it. Instead of just adding it to Jenkins X, we spent considerable time exploring the subject.
Applying GitOps Principles
Git is the de-facto code repository standard. Hardly anyone argues against that statement today. Where we might disagree is whether Git is the only source of truth, or even what we consider by that.
When I speak with teams and ask them whether Git is their only source of truth, almost everyone always answers yes. However, when I start digging, it usually turns out that’s not true. Can you recreate everything using only the code in Git? By everything, I mean the whole cluster and everything running in it. Is your entire production system described in a single repository? If the answer to that question is yes, you are doing a great job, but we’re not yet done with questioning. Can any change to your system be applied by making a pull request, without pressing any buttons in Jenkins or any other tool? If your answer is still yes, you are most likely already applying GitOps principles.
GitOps is a way to do Continuous Delivery. It assumes that Git is a single source of truth and that both infrastructure and applications are defined using the declarative syntax (e.g., YAML). Changes to infrastructure or applications are made by pushing changes to Git, not by clicking buttons in Jenkins.