So a term we probably heard pretty often is the term GitOps and you're probably wondering
what it is or you've heard about it and you've maybe even use it to an extent. I'd like you to
introduce you to a tool that makes GitOps easier to implement and easy to understand.
And it's called ArgoCD. ArgoCD is a declarative GitOps tool that's based on Kubernetes. Let's
break that down a little bit here. First of all, it's a GitOps tool and GitOps is all about
taking the code that you write, that you commit to a git repository, whether that be GitHub or
Bitbucket, and taking it all the way from the code to a deployment which is the production server.
The declarative part is all about making sure that the deployment and the architecture that
you want to have in production is exactly as you want it to be. And so you write down all
the specifications of the architecture in stone, so to speak, in a YAML file. And these YAML files
describe how the architecture is going to look like. And this ensures that there's consistency
between what you're expecting and what's actually on production. And finally, it's based
on Kubernetes. So it requires a little bit of understanding about Kubernetes. And we have videos
on this channel that can introduce you to it. But the main takeaway from the Kubernetes part is that
our code is going to be deployed into little pods, maybe have a back-end pod and a front-end pod. And
those are scaled up to meet the users' need based on your specifications in your declarative YAMLs.
So I'd like to introduce ArgoCD to you and illustrate it to you using a few stories.
So let's say we have Rav. Rav is a developer at Company ABC. Rav has just decided to take
a quick lunch break nap at his laptop, and his cat Twinkles has now walked across his keyboard.
Twinkles is able to write some code and push it. And because we have GitOps pipeline in place,
the code makes it all the way to production. Well, when Rav wakes up to the call of the ops
guy trying to figure out what's going on on the production server, Rav is able to-- in ArgoCD --just
use something called a rollback. And they'll just roll back the state that's currently on production
and just take it back to the last stable state. Pretty nifty, huh? Another person who works
at a Company ABC is John. And John is the ops guy. He's in charge of writing out our declarative
get ops infrastructure. John has just went to get coffee and sometimes happens when you walk
back into a room, you forget what you were doing. John can just go in to the YAML files and read out
the whole architecture, read out exactly what we're expecting to see on production,
and read what he planned to do. Maybe they'll remind him. And if that doesn't get it, then
ArgoCD also has in the UI and in the CLI a robust health check system that lets you know the health
of your deployment. Maybe a image registry needs a secret that your images are not able to reach.
Argo CD shows that in the UI and you can also query that from the CLI.
Finally, let's say this company also works a guy named Steve. And Steve is a little bit old
fashioned. He doesn't really care about all this automation stuff. And so Steve sort of just shoots
from the hip. Let's say Steve gets into our Argo CD deployment and he just wants to deploy more
pods. He deploys ten more pods than we actually need. But Argo CD has built in automation,
and I'm drawing a robot for that, that will allow the ArgoCD to robustly and
automatically scale back down the number of pods. That way, the bill at the end
of the month from the server isn't huge. I hope these illustrations have given you a little bit
of intuition about Argo CD and the underpinning concepts of GitOps. Thanks so much for your time.