Getting Started with GitOps with ArgoCD

This post is a continuation of the previous Kubernetes deployment post as I had so much in my head and it didn’t all make sense in one post. For context, go back and read it.

Let’s talk GitOps! If you’re not particularly clear on what GitOps is, it’s the idea that your Git repository is your source of truth for your infrastructure configuration. Think CI but for configuration.

GitOps Platforms

While you could do GitOps with just some scripts and prayer, much like implementing CI for your application, it’s much easier with a platform to be able to run things off of. There are two heavyweights in the cloud-native space today for GitOps: Flux and ArgoCD. Both are open-source CNCF incubation projects and both do effectively the same thing but with a little bit of its own flavor. For the purposes of this post, I’ll be using ArgoCD.

Getting Started

GitOps platforms basically do one thing: take your configuration from your Git repository and sync it with your infrastructure. That’s it. Your Git repo is your single source of truth of your configuration and nobody (and I mean nobody) can mess with that…unless you give them access to your Git repo, but then that’s on you.

So to get started, we’ll want to set up a Git repository. Any ol’ repo will do and it can be hosted anywhere so long as your GitOps platform can access it. Github, Azure DevOps, a server you run under your desk to keep your feet warm - anything will do.

For the platform itself, you could run it on some bare metal server, but why would you? We’re going cloud-native baybeeee!

So go spin up a Kubernetes instance. I’ll wait.

Okay, welcome to next week. To install ArgoCD, it’s super simple. Create namepsace and apply the .yaml file provided:

kubectl create namespace argocd
kubectl apply -n argocd -f

This will install a bunch of stuff including a handful of CRDs to help make your life easier. More on the CRDs later - they’ll help with some declarative configuration.

So now, you should have a running ArgoCD application with a service to access it. You likely want to have this exposed to a nice domain name so get yourself an ingress controller and create an ingress with the hostname. Don’t worry, ArgoCD has authentication (including SSO!) and you should have it behind your firewall anyways.


Once you’re loaded up and logged in, you should get a nice interface with a menu bar to the left:

ArgoCD Menu

Click on the gear icon and get set up your configuration.

ArgoCD Config

There are several things you want to create here:

  • Repositories: Configure your Git repository here. This should point to the Git repo you created at the very beginning that will contain all of your Kubernetes configurations.
  • Clusters: This is where you’ll configure your Kubernetes cluster. I lied, you actually can’t configure your cluster here, you’ll have to do it via the CLI which we’ll cover next.
  • Projects: These are logical repositories of applications that can be grouped together. You can configure settings and whitelist/blacklists throughout the project to prevent any accidental bad deployments.

The ArgoCD CLI

ArgoCD has a CLI tool that is quite useful and can do basically everything you see in the web interface and then some. I’d highly recommend you install it and get familiar with it as at a minimum you’ll need it to configure your Kubernetes cluster and you’ll want it as part of any CI process.

To download it, you can either go directly to the ArgoCD site and download it or just click on the little book icon (the last one) and download it from the options there. You can also get it from your favorite package manager.

The first thing you’ll want to do is to authenticate with your ArgoCD instance.

# is the hostname of your ArgoCD instance
argocd login

ArgoCD can read from your existing .kube/config file to set up your connection to your Kubernetes repository. If you’re using AKS, you can do an az aks get-credential to merge the credentials of your AKS cluster into your local kubeconfig file. Once you can access your cluster locally (kubectl cluster-info to validate), you can tell ArgoCD to use that config for itself:

# k8s-cluster-context is the name of the context from your kubeconfig file
argocd cluster add k8s-cluster-context

Okay, you’re all set! You should be able to see your Kubernetes cluster in the web UI now, or you can check with the CLI.

argocd cluster list -o wide

Setting up your first application

ArgoCD can handle different kinds of applications - regular ol’ YAML, kustomize, helm, jsonnet, etc. We’ll look at regular YAML today but kustomize (my preference) and helm are just as easy to pull in. This makes it really easy if you’re depending on a number of 3rd party Helm charts and have it all deploy out of one place.

Okay, so now we’ve got your Git repo and K8s cluster hooked up to ArgoCD, it’s time to make the magic happen. Create yourself a new app from the web UI and for the source, give it the repository URL (autofill baby!) and path to the folder of YAML files to deploy. For the destination, give it the URL of the K8s control plane. Don’t know it? More autofill, baby! Give ’er a K8s namespace to deploy to and hit the create button.

ArgoCD App

See that cool box on your dashboard? That box is your application! It’ll give you some basic information which you’ll get more if you click on it.

Here you’ll see some health info - pretty important stuff.

  • App Health: Healthy is good. Missing means ArgoCD can’t find your app (which is where you should be at right now).
  • Current Sync Status: Synced means your K8s cluster is in sync with what’s in your Git repository. Out of Sync means there’s a discrepancy and you can use the “App Diff” button at the top to see what’s out of sync, or you can look at the resource tree below and see what’s out of sync.
  • Last Sync Result: Sync OK is good! Sync Failed is bad! You didn’t need me to tell you this. You did need me to tell you that if you ever wanted to terminate a sync in progress, click on the result and details will show about the sync, including a button to allow you to terminate.

Resource Visualization

ArgoCD does a good job of mapping out the resources from your Git repo - here’s my Sitecore application for example (obfuscated by shrinking):

ArgoCD Sitecore App

There’s also this cool view by node:

ArgoCD Sitecore App by Node

Sync it!

Now comes the big moment - hit Sync and wait for everything to turn green! ArgoCD will pull your latest changes from the Git repository and apply it to your Kubernetes cluster. Once everything is up and running, you’re all done!

If you ever want to make any changes to your application, all you’ll need to do is to push the changes upstream to your remote Git repository and ArgoCD will detect it. If you have auto-sync turned on, it will even automatically apply your changes without any other manual intervention.

There’s a lot of way cool things you can with ArgoCD including managing multiple environments, sync waves, declarative configuration (xhibit-meme-yaml.png), and more fun with the CLI that we can’t cover all here. For more info, hit up ArgoCD’s documentation and Getting Started guide which will also help you through a lot of this. Enjoy!