Automation and repeatability are two very different pieces of the Platform Engineering and DevOps possible.

Automation can be anything from creating a couple of line bash script, throwing it into a cron job, and moving forward.

Repeatability is automation that can continuously run without intervention (other than maintenance, feature updates, etc.) and is reliable.

In this blog post, you’ll learn about one of the major ways to set up repeatability in your Kubernetes environment with GitOps.

What’s GitOps?

Before diving in, let’s briefly discuss what GitOps is. This is a huge topic, so let’s talk about it from a high-level perspective as it could be an entire book topic in itself.

If you’re deploying containerized apps to Kubernetes, there are most likely a ton of Kubernetes manifests. Deployment types, Services, DaemonSets, ConfigMaps, Ingress, and on and on the list goes. The problem with such a huge list is that:

You’re expected to install them all manually or with a bunch of pipelines running kubectl apply -f.
There’s nothing ensuring that the current state of the Kubernetes Manifests deployed is the desired state.

This is where GitOps comes into play.

GitOps is a way that not only makes deploying Kubernetes Manifests repeatable, but it allows you to confirm that the current state of what’s deployed in a Kubernetes environment is the desired state. GitOps checks the current state and desired state by using a Git-based source control system (like GitHub) as the source of truth for all Kubernetes Manifests.

If you’d like to learn more about GitOps, check out the GitOps For Kubernetes live training found here.

What is ArgoCD?

Now that you know a little bit about what GitOps is, let’s dive into learning about what ArgoCD does for GitOps.

The important distinction to remember here is there’s a difference between “systems” and “platforms” or “products”.
GitOps is the “system”.

ArgoCD is the “platform” or “product”.

ArgoCD is one way that you can use GitOps, but there are many others. ArgoCD just so happens to be one of the most popular ways, and for good reason.

By definition, ArgoCD is a Kubernetes Controller responsible for continuously checking and confirming that all apps running have a current state that matches what’s in source control.

One of the really cool things about ArgoCD is that it spans outside of the portion of what GitOps does by giving you a UI that you can view and see what’s happening inside of your system. That way, it’s not only doing the “GitOps thing”, but it’s also giving you monitoring capabilities that you can see in real-time what’s failing and the source of where it’s failing from. You can even deploy apps right from the ArgoCD UI, giving it a more “point and click” feel when needed. Although it’s certainly not recommended as all of your configurations should be in code, it is a nice option if you need it for a quick demo or for a dev environment to test something out quickly.

Getting Started With ArgoCD

ArgoCD is an awesome platform and one of two of the most popular GitOps platforms in today’s world. The other most popular GitOps platform is Flux, which you can’t go wrong with using either.

Let’s dive into the hands-on goodness of ArgoCD. You’ll start by setting up an ArgoCD server and then you’ll deploy an application. To fully follow along with this section, you should have a Kubernetes cluster up and running. This could be a Minikube cluster, KinD cluster, or any other type of Kubernetes cluster that you’d like.

Deploying The ArgoCD Server

There are a few different ways to deploy ArgoCD, but the quickest for a quickstart/dev environment is with the Manifest below. The Manifest below installs various components including:

ConfigMaps
Services
Deployments
NetworkPolicies

and a few others. If you’re curious about the Manifest, copy the link below before deploying it and check out the code.

When you’re ready, run the following command to deploy ArgoCD.



kubectl apply -f https://raw.githubusercontent.com/argoproj/argo-cd/v2.4.3/manifests/ha/install.yaml

You should see an output similar to the screenshot below.

Once ArgoCD is deployed, you’ll need the initial password to log in. For production purposes, please ensure that the first thing you do is change the admin password.

Run the following command to obtain the initial admin password.



kubectl  get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d

Next, you’ll need a way to access the ArgoCD UI. To do that, you can set up a port forward to the argocd-server Kubernetes Service, which is what hosts the UI.

Run the following command.



kubectl port-forward service/argocd-server :80

You should see an output similar to the screenshot below, but the destination port might be different.

By default, the ArgoCD service doesn’t come with a type:LoadBalancer. If you would like to use a load balancer instead of port forwarding, you can patch the Service. However, keep in mind that if ArgoCD is re-deployed, the patch will no longer exist.



kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}'

Open up a web browser and go to:



127.0.0.1:port_number

You’ll see the ArgoCD UI per the screenshot below.

You should now see your newly created ArgoCD server.

Registering A Cluster

For the purposes of this blog post, you installed ArgoCD in the same Kubernetes cluster that you’re going to be deploying a containerized app on. There’s another way to configure the environment, which is essentially having ArgoCD run on its own Kubernetes cluster without other apps deployed, and then using that Kubernetes cluster as a sort of control plane. Then, you can have other Kubernetes clusters that are running apps, but aren’t running ArgoCD, use the existing ArgoCD environment.

You won’t have to do any of that for the purposes of this blog post, but it’s still good to know.

Below are the commands that you’d use to do that.

First, you’d get all of the Kubernetes contexts from your [localhost](http://localhost) so you can choose which Kubernetes cluster you want to register in ArgoCD.



kubectl config get-contexts -o name

Next, you’d use the argocd CLI to add the Kubernetes cluster to ArgoCD.



argocd cluster add kubernetes_context_name_here

Logging Into ArgoCD CLI

Before you can deploy an app on the command-line, you must first log into the CLI. If you don’t have the argocd CLI installed, you can check out the installation guides here.

To log into ArgoCD via the CLI, you’ll have to run the argocd login command. The command will consist of the IP address and port number that ArgoCD is currently exposed to. Because you ran a kubectl port-forward in the steps above, the IP address that ArgoCD is exposed on is 127.0.0.1. For the port, it’s going to be whichever port ArgoCD was exposed on. Below is an example, but the port may be different for you.



argocd login 127.0.0.1:56067

Once you run the argocd login command, you’ll be prompted for the username and password of the ArgoCD server, which is the same as when you logged into the UI.

Deploying An App

The app that’s being deployed is coming from the Kubernetes Examples repo and the imagePullPolicy directory

The command below does the following:

Utilizes the argocd CLI to deploy the app.
Points to a specific GitHub repo.
Points to a specific path/directory inside of the GitHub repo that contains your Kubernetes manifest(s).
Specifies the default Kubernetes cluster that you’re logged into.
Specifies the namespace that you want to deploy your app into.