GitOps With ArgoCD Getting Started
Tags: kubernetes, gitops, git, docker
Published: 2022-08-17 12:19:16

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](https://www.oreilly.com/live-events/gitops-for-kubernetes/0636920078987/0636920078986/).

## 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.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9qms4ldrhf7keiteq91a.png) 

## 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.

```jsx
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.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6a37t723b7h63wrk7trt.png) 

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.

```jsx
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.

```jsx
kubectl port-forward service/argocd-server :80
```

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

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/o6xlw5pn5ttl3pj7vkm1.png) 

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.

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

Open up a web browser and go to:

```jsx
127.0.0.1:port_number
```

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

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/f4v6cz77e9qlrvbcpt7m.png) 

Log in with the initial admin password and the username `admin`.

You should now see your newly created ArgoCD server.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/tmldmyt5tdi7mndal8az.png) 

### 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.

```jsx
kubectl config get-contexts -o name
```

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

```jsx
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](https://argo-cd.readthedocs.io/en/stable/cli_installation/).

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.

```jsx
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](https://github.com/AdminTurnedDevOps/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.

Run the following command.

```jsx
argocd app create nginxdeployment --repo https://github.com/AdminTurnedDevOps/kubernetes-examples.git --path imagePullPolicy --dest-server https://kubernetes.default.svc --dest-namespace default
```

Log into the ArgoCD UI and you should now see that the app has been successfully deployed.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6dhb25q9zkhkm24z79n1.png) 

Congrats! You have successfully set up an ArgoCD server and deployed an application.