Welcome to Tech Talk.
Today's topic is GitOps the single source of truth for deploying your code to production
of Kubernetes environment.
And today I'm joined by Brad Topol, who's going to explain some of the tools that you
can use to make that happen.
The first of which is probably familiar to most is Tekton.
And the other, which Brad is going to introduce us, called ArgoCD.
Could you explain how these two are going to play together?
Absolutely.
So let's first look at what Tekton gives us.
If you look at tech time, that's got two main pieces.
It's got tasks
and pipelines.
Right.
And so what happens is we have these reusable tasks and these are steps like clone,
a repository run unit test building, deploying image and Tekton allows you to take this
reusable tasks and compose them into pipelines.
And those pipelines do all the stages of CI/CD and
can even deploy to production.
Great.
Okay.
So that makes it so you can simplify your deployments
and save a lot of time not having with manual steps.
Absolutely.
Okay.
And so how does Argo come in?
How does it help with Tekon?
Well, the nice thing about ArgoCD is it's a pull based model.
So with Tekton, it's a push based model.
But ArgoCD is one a pull base model and it's declarative.
So just like Kubernetes is declarative, you declare everything.
ArgoCD allows you to to put your YAML files, your configuration in a git repository
and declare what you want to happen.
And ArgoCD.
So it's going to.
Pull things from your repo.
Right.
And then it's also going to have a little Kubernetes cluster.
Sure.
Okay.
I got it.
Right.
So you've got these two models you can use Tekton
all the way up to the step of building and deploying an image and putting an image in
a registry.
And then you can take all your configuration files, put them in a repo, and all you got
to do with ArgoCD is
point at the gt repo and point it a Kubernetes cluster and it's going to do the rest.
So let me play that back to you.
You' re saying in Tekton essentially when I put out my declarations, that's what actually
calls causes the deployment to occur.
But in this case, you're saying ArgoCD is actually monitoring my declaration inside
the repo itself
and then re synchronizing.
Did I get that right?
Yeah, absolutely did.
It's going to look for what's in that that git repo with your deployment files
and it's going to look what's running in production and it's going to make sure that what runs
production matches the source of truth, which is what those YAML files are in that git repository.
Fair enough.
But I'm a developer.
I'm kind of curious, is this something that I need to be worried about or is that something
that's on the ops?
Is more ops focus or is it both?
It's really both.
If you put the two tools together, it's making everyone's life simpler.
Right.
So we're doing the best of breed to build up and create and publish an image.
And then we're doing the best of breed of being able to understand that your git repository
is a source of truth.
And so, you know, being able to do a git ops model in a declared of fashion
and what's nice about this is if somebody comes in and makes changes inside the cluster,
ArgoCD is going to see those changes, realize that the configuration is not matching the
source of truth
and it's going to change things.
It's going to update the what's running in the production cluster to ensure it matches
the source of truth.
I got it.
So if I already have an existing deployment using Tekton and I want to introduce ArgoCD
what are the steps involved?
What do I need to do?
Right.
So there's not much you need to do.
So we need to drop off the last step and this is really nice.
So the last step would typically be using Kube Control to then push your application
into a Kubernetes cluster
and understand with Kube control, you're going to have to set some credentials and set up
the security
so that, you know, your automated system has the authority to publish into the Kubernetes
environment.
You don't have to do that.
You don't need to know Kube control, and you don't have to set up those credentials
because what ArgoCD is going to do is it's not going to use Kube control.
It's going to look at what's in the repo and it's going to pull those configuration files
and understand what it needs to deploy in the cluster.
Now, the one thing you have to look out for is ArgoCD is you typically have two repos.
You've got the repo for the YAML files and the repo for the source code.
So the source code of my actual applications and then for the infrastructure, I have a
separate one as you're saying.
You've got a separate repo for the actual source code
and a separate repo for those YAML files that control the deployment of your applications.
Okay.
And so where are the payoffs for this?
Am I going through this trouble?
How does it make my life easier?
So how it makes your life easier?
Again, you're not going to have to
learn all those kube control commands.
You're not don't have to worry about that.
If somebody goes into the environment, make some changes.
ArgoCD is going to make sure that those changes are rolled back.
And the source of truth.
You're saying, for example,
like an operator goes and accidentally does something thinking they're going to fix it,
right?
That's right.
You can sleep well at night because of that operator who thinks they know what they're
doing goes and make some changes.
ArgoCD is going to see that that's not putting the source the truth
and that's really the best part of GitOps.
Right?
Is making sure your git repository is a source of truth.
And so if it's not the source of truth and they make some changes, it's going to update
what's running
in your cluster to match what's in the git repo.
I'm all for sleeping better at night.
And with that,
we're going to go ahead and wrap.
We've now told you what it is, why it's important, how it works.
If you'd like to see more topics for tech talk, be sure and leave it down in the comments.
And please, before you leave, remember to subscribe and hit like.