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.
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.
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 https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
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:
Click on the gear icon and get set up your configuration.
There are several things you want to create here:
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.
# argocd.mycooldomain.com is the hostname of your ArgoCD instance argocd login argocd.mycooldomain.com
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
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.
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.
ArgoCD does a good job of mapping out the resources from your Git repo - here’s my Sitecore application for example (obfuscated by shrinking):
There’s also this cool view by node:
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!