Couchbase is a distributed NoSQL cloud database. The Couchbase Autonomous Operator enables us to automate the management of common Couchbase tasks like, for example, configuration, scaling, and recovery. It lets us focus on the desired configuration and by automating deployment and life-cycle management.
In this video, we are going a step further and applying GitOps principles through ArgoCD.
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.
Flux v2 is a tool for converging the actual state (Kubernetes clusters) into the desired state defined in Git. It is a GitOps-based deployment mechanism often used in continuous delivery (CD) processes.
Argo CD is a declarative GitOps deployment tool for Kubernetes.
It is one of the best, if not the best tool we have today to deploy applications inside Kubernetes clusters. It is based on GitOps principles, and it is a perfect fit to be a part of continuous delivery pipelines. It provides all the building blocks we might need if we would like to adopt GitOps principles for deployments and inject them inside the process of application lifecycle management.
Argo CD is a tool that helps us forget the existence of kubectl apply, helm install, and similar commands. It is a mechanism that allows us to focus on defining the desired state of our environments and pushing definitions to Git. It is up to Argo CD to figure out how to converge our desires into reality.
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.
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.
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.