Limited Time Offer!

For Less Than the Cost of a Starbucks Coffee, Access All DevOpsSchool Videos on YouTube Unlimitedly.
Master DevOps, SRE, DevSecOps Skills!

Enroll Now
Uncategorised

What is Argo CD and Use case of Argo CD?

June 13, 2022 Leave a Comment

Source – Pluralsigt

Understanding GitOps Core Concepts

Let’s take some time now and talk about GitOps so we can gain an understanding of GitOps being that Argo CD is a GitOps operator. So we need to understand GitOps and its core concepts, and let’s dive in. So what is GitOps? It’s an operating model pattern for cloud native applications and Kubernetes. And it’s important to understand that it’s not just for Kubernetes, but also for the cloud native applications. And it’s used for storing your application and your declarative infrastructure code in Git, and it makes Git the source of truth and it provides the automated continuous delivery. Now what is the history of GitOps? It was launched in 2017, and the term was coined by Alexis Richardson of Weaveworks. There was a blog post, and it’s still out there and I recommend that you go read it, it’s titled Operations by Pull Request. Now Weaveworks was actually using GitOps to manage their Kubernetes clusters for a while, and in 2017 they decided to blog about it and share it with the rest of us. And then in 2018, Kelsey Hightower tweeted about GitOps, and this tweet really took wildfire, and it was a pivotal moment in the history of GitOps just helping to raise the popularity and also drive adoption. Also in 2018, we started to see major cloud providers GCP, AWS, and Azure start to adopt GitOps in their managed Kubernetes offerings and just in their cloud in general. And then in 2020, we saw the creation of a GitOps working group, and they hosted their first meeting. And this group gives governance, documentation, and guidelines for GitOps. Now in 2021 and beyond, we’re starting to see a lot more around GitOps. Like in 2021, we saw the first GitOpsCon launched. And we’re just seeing more and more adoption and growth around GitOps in general. Now let’s talk about some GitOps principles. First of all, Git is the source of truth for your entire system with GitOps. You should have your desired system state defined and versioned in Git. Your system state should be described declaratively. And Git is the single place for your operations, so you create, your change, and your delete. And then we should have autonomous agents that enforce our desired state and alert us if there’s drift. So, Argo CD is an example of the autonomous agents. Argo CD is a GitOps operator, and the autonomous agents essentially are the GitOps operators. And we should also have automated delivery of approved system state changes. So, we have our commits going into our repositories, and those should be going into branches, and then we should have pull requests and merges, we should have a process there that goes into our main repository, and then we have our GitOps operator pick it up from there. Now, let’s look at GitOps architecture components. First of all, you need a source control system, so this could be a number of any source control system that you use in your company, so Azure DevOps, GitLab, etc., etc. You’ll need that Git repository, you’ll need to have a registry, whether it’s for just container images or maybe Helm charts, and then you’ll need your GitOps operator, so Flux is an example, Argo CD, and that’s what we’re covering in this course, and there’s many others. And then you’ll need your runtime environment, and what this means is where you’re going to actually run your workloads. Now in this case and in regards to Argo CD, we’re going to be focused on Kubernetes. So you need to have your runtime environment figured out, like how many clusters you’re going to have, are you going to have namespaces, how are you going to chop things up. And then your namespaces, so you’ll want to figure that out as well and things like RBAC and what teams will have access to what. And that’s going to help you determine, especially with Argo CD, like what apps in Argo CD is going to have what access to what namespaces. And we’ll get more into that as we move through the rest of this module. Now what are some use cases for GitOps? Cloud native app management, so the continuous delivery in CI/CD, service rollouts, and then infrastructure management. So, managing your Kubernetes clusters, fleets of Kubernetes clusters or even microservices. Now, let’s talk about GitOps operators. The two most popular are Flux and Argo CD. Now, Flux is a Kubernetes‑based GitOps operator, and you have Flux 1, and Flux 2 is coming out, and it’s command line only with Flux 1. With Flux 2, there’s going to be some GUI components to it. Now with Argo CD, it’s another Kubernetes GitOps operator. Now with the first version of that, it came out with a command line interface, as well as a GUI interface, and we’re going to dive deep into Argo CD in this course. And there’s also Kubestack. So remember, I talked about GitOps going beyond just Kubernetes and being available for cloud native applications. Well, Kubestack focuses on the framework and the infrastructure that powers your Kubernetes clusters, so for example your cloud environments, and it uses Terraform at the core of itself, but it takes those GitOps principles. And then we have Jenkins X. Jenkins X is a full blown CI/CD system, but it also has a GitOps operator built into it. And then we have Atlantis. Now, Atlantis is another one that’s based on Terraform, and so this expands to your cloud native. It really helps you automate the infrastructure in a GitOps way.

History and Overview of Argo CD

Let’s explore the history and gain an overview of Argo CD. Now, there’s something called the Argo Project, and within the Argo Project there’s four core solutions, and Argo CD is one of those solutions. Now, each of these solutions covers different functionality and features and use cases, and these all make up the Argo Project. So, Argo goes beyond just Argo CD. Now the first one we have is Argo Workflows, and this really is a workflow engine for orchestrating parallel jobs on Kubernetes clusters. And then of course we have Argo CD, and this is a declarative continuous delivery GitOps operator for Kubernetes clusters. And that’s the one we’re going to focus on in this course. And then we have Argo Rollouts, and that gives you advanced deployment capabilities such as blue/green, canary, and canary analysis. And then we have Argo Events, and this gives you event‑driven workflow and an automation framework for your Kubernetes clusters. So, as you’re starting down the path of Argo, it’s good to get a footing with Argo CD and start there and kind of branch out from there and start to explore the other Argo solutions that are in the Argo Project. Now, Argo CD, it’s the core component of the Argo Project, like this is the most popular one, it gives you the most functionality, it’s the one that organizations and teams usually go to first because it covers that continuous delivery. And Argo CD is a GitOps operator, and we talked about GitOps operators, and Argo CD provides that continuous delivery for your Kubernetes environment deploying your applications to your Kubernetes clusters. Now, it has an application controller in it that continuously monitors what’s running on your Kubernetes cluster and comparing that to what’s in your Git repository and making sure that your desired state is enforced at all times and that your application is healthy. Let’s look at the history of Argo CD. So in 2016, there was a new startup launched, and by 2017 they had Argo Workflows that they created and they launched. That was the first solution in the Argo Project. Now in 2018, this startup was acquired by Intuit. Yes, the folks that write the tax software. They acquired this startup, and after they acquired the startup, they tasked the team with creating a better tool that would be able to do continuous delivery and take the GitOps principles and best practices into account, and that would be core of this new product. And so Argo CD was born. Now in 2018, on August 30, Argo CD was officially announced, and that was essentially the start of Argo CD. Now let’s talk about the top features for Argo CD. There’s a user interface, it’s really easy to work with, we’re going to explore that through some demos and get you started there, and then automated deployment of your applications. So, again, we’re going to go through creating applications and deploying those to Kubernetes clusters. And then keeping track of the health of your application and its resources and syncing that health to enforce the desired state. And these are all core features of Argo CD that make it a really great product to work with and useful. Now, let’s talk about standard CI/CD workflow and then we’ll explore Workflow with Argo CD. So in a nutshell, you have your dev team here, and your dev team is making commits, they’re writing the code, they’re sending that to the application repo, and then it’s compiling. There’s a process to do testing. And then they’re done with the code, they push it up to Container Registry and they might notify the ops team that, hey, this is ready to go. So the ops team will go ahead and put their code in an ops repo, so that might be like Kubernetes manifest files, some infrastructure as code files, scripts, and then they’ll pull down that image and deploy it to the environment. Well, there’s a disconnect there. And so, things can get lost in translation when there’s updates that need to be done to the environment, whether it’s the config maps or configuring ingress or things like that, things can get missed. That could introduce risk and make the environment so it’s not as stable. All right, now let’s take a look at the CD with Argo CD. So, we have our repository, we’re committing code in there, and then Argo CD sees that and it’ll pull that desired state from there and deploy it to the Kubernetes cluster. We might have new features we need to add to the code or even the configuration, and we’re submitting that to the repositories and Argo CD will pick that up and deploy it to the Kubernetes cluster. Now, we should have pull requests there and we should have merges that happened after the pull requests are improved, and we’re moving code from branch repositories into a main repository where Argo CD is pointed to and will pick it up. And then the Argo CD is doing a constant pull and it’s constantly monitoring that Git repo looking for changes and any updates, and it’ll make that stuff happen in the Kubernetes cluster.

Understanding Argo CD Core Concepts and Architecture

Let’s dive in now and gain an understanding of Argo CD core concepts and learn about its architecture. Let’s start off with the architecture. So, Argo CD has three main components. So it has an API server, and this is where your web UI, your command line interface, and if you’re connecting from CI/CD systems are connecting to that API server. Now typically if you have CI/CD systems or maybe some other sort of system connecting to it, it’s going to use the gRPC or REST. If you’re a user connecting to the web interface or using the command line interface, you’re connecting through Argos tools there to connect to that API server. And then we have a repository server, and this is just an internal service that does a cache of our Git repositories that have the app manifest. So, it’s syncing between this cache and the actual Git repositories. And then we have an application controller, and this is a Kubernetes‑based controller that continuously monitors what’s running on our Kubernetes cluster, and it’s comparing that with what we have desired in our Git repository. If it sees changes, it’s going to go ahead and mark things as out of sync and unhealthy, and then Argo CD will make those updates into our Kubernetes cluster, bringing our Kubernetes cluster back into sync. So what does this look like visually? So, here’s a diagram that kind of breaks this down. So you can see there, we have our user interface where we could log into our web‑based Argo CD, we also have our command line interface, and those things are going to talk directly to the API server. And then we have our Git repository and Argo CD syncing back and forth with that, it’s continuously monitoring that and making sure that our desired state on our Kubernetes clusters are enforced. Now, our repository server is there and it’s keeping that local cache of what’s in our Git repository. And then we have our application controller there too, which is facilitating that continuous monitoring. Now, Argo CD runs on our Kubernetes cluster as a bundle of Pods, so it’s actually running as containers itself, which is kind of cool. Now, we run it on a Kubernetes cluster and we can manage that Kubernetes cluster that it’s running on, but we can also take Argo CD and point it at other Kubernetes clusters. Now, towards the bottom of the diagram here, you can see sync and webhooks, so that’s where we can integrate with other systems, maybe it’s Slack, maybe it’s Jenkins or cloud providers, like services that are running in those cloud providers, there’s a lot of flexibility in what we can do with Argo CD in those advanced scenarios. And then, we’re also showing just deployment from Argo CD to many Kubernetes clusters. Now, here’s a further breakdown of the Argo CD components, and what you’ll see here is what you’ll see as deployments and services running in your Kubernetes cluster where you have Argo CD deployed. Now, the first one here is the argocd‑dex‑server, and what this is is it’s basically just Dex and it’s running and facilitating that authentication need. So, you can use Dex to basically delegate the authentication to an external identity provider. And so think of like Azure Active Directory or any other identity provider that you might want to use where the user accounts actually live in there and you’re going to use those user accounts to be able to log into your Argo CD. And so, you’re going to use Dex also to facilitate the single sign on. And then we have argocd‑metrics and argocd‑server‑metrics. Now, Argo CD exposes application metrics and API server metrics for Prometheus. So we could take and consume those metrics in Grafana to get a nice dashboard to see the health of our Argo CD itself and also the applications that are running in Argo CD. Now, you do have monitoring capabilities inside of Argo CD, like you can see the health of your applications, but let’s say maybe you wanted to create a really awesome dashboard and expose that information as well. You can do that through Grafana. And then we have argocd‑redis, and this is simply being used in combination with the Argo CD repository server to do that caching where we’re caching that repository from our Git. And then we have the argocd‑repo‑server, and this basically is cloning the Git repository, and this is what’s working with Redis to keep that cache clone and be able to sync back and forth. And then we have our argocd‑server, and this is essentially what runs the Argo CD API server that we’re connecting to.

Understanding Supported Tooling with Argo CD

Let’s talk about supported tooling with Argo CD. Now with Argo CD, it supports several different ways in which Kubernetes manifests can be defined, and this goes beyond just Helm and Kustomize. So we can work with Jenkins, we can work with Ksonnet, we can work with Helm, we can work with Kustomize, and we can also work with Jsonnet. Now, Ksonnet is actually deprecated, and so it’s not recommended to use that; however, there are teams out there and organizations out there that are still using it, and so there’s documentation out there on Argo CD’s site for it, just in case. Now, when a new application is created in Argo CD, it’s able to automatically detect the tooling that was used to create that application. So, for example, if you packaged your application in a Helm chart, Argo CD is going to pick that up and know how to work with that, or if you use Kustomize it’s going to know what to do with that. Now, Argo CD is able to do the automatic tool detection using the following methods. So, for Ksonnet, it’s going to look for an app.yaml file or a params.libsonnet on that file in the directory. And for Jsonnet, it’s going to look for any file that ends in Jsonnet in that directory, and then it knows what to do with that application. For Helm, it’s going to look for a chart.yaml file. And then for Kustomize, it’s going to be looking for kustomization.yaml. And if it sees that, it knows that you’re using Kustomize and it will know what to do when you’re deploying that application and what type of settings that you’re going to need.

Summary

We covered a lot of ground in this first module in this Argo CD course. Let’s recap what we covered. So in this module, we gained an understanding of containers, Kubernetes, as well as Helm and Kustomize as these are all technologies that you’ll work with as a part of using Argo CD. We then gained a brief understanding of GitOps, including its history, core concepts, and even GitOps operators being that Argo CD is a GitOps operator. We gained an overview of the Argo Project, its core solutions with a focus on Argo CD, and we then explored Argo CD itself, what it is, what it does, including its top features, its history, a dive into its architecture, as well as supported tooling that works with Argo CD. Why is all of this important? It’s important because it’s good to understand core things like containers and Kubernetes, as well as GitOps because those all drive the picture of what Argo CD is and how it’s used, as well as Helm, Kustomize, and other topics that we covered as these are all a part of that Argo CD ecosystem. It’s also good to have knowledge of Argo, the project itself, and Argo CD all up to build on as you continue on with your journey in this course.

Rajesh Kumar
Follow me
Latest posts by Rajesh Kumar (see all)
Subscribe
Notify of
guest
0 Comments
Newest
Oldest Most Voted
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x