Which self-managed kubernetes-native CI/CD pipeline is the best choice? Is it Tekton or Argo Workflows? Which one should you pick?Continue reading
Should we be using Jenkins for our Kubernetes CI/CD pipeline needs in 2021? How to deploy Jenkins in k8s? How to run Jenkins builds in Kubernetes? How would a full CI/CD pipeline look like?Continue reading
Tekton is a powerful and flexible open-source framework for creating CI/CD systems aiming at becoming a de-facto standard for running pipelines and workflows in Kubernetes. It allows developers to build, test, and deploy across cloud providers and on-premise systems.Continue reading
What is GitHub actions? How to use GitHub Actions, and does it work? How can we leverage its marketplace, and what is the pricing? Is it a good solution for CI/CD pipelines? Let’s answer those and other questions through tutorial and review.Continue reading
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
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.
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.
GitOps is nothing new. Or, to be more precise, the principles of GitOps existed long before the term was invented. But hey, that’s the pattern in our industry. It is the fate of all good practices to be misunderstood, so we need to come up with new names to get people back on track. That is not to say that we are in a constant loop. Instead, I tend to think of it as a periodic reset trying to eliminate misinterpretations. GitOps is one of those resets. It fosters the practices and the ideas that existed for a while now and builds on top of them.
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.
What’s wrong with
jx create cluster and
jx install commands? Why do we need a different way to install, manage, and upgrade Jenkins X? Those are ad-hoc commands that do not follow GitOpts principles. They are not idempotent (you cannot run them multiple times and expect the same result). They are not stored in Git, at least not in a form that the system can interpret and consume in an attempt to converge the desired into the actual state. They are not declarative.