>> Really excited to dig a little deeper on GitOps.
What is GitOps?
I think most of you are probably familiar
with the Git part of GitOps because
you're used to taking the Git repo
and using it to manage your source control.
That's a pretty familiar experience
for a lot of developers,
maybe it's using GitHub or any other kind of Git server.
The idea behind GitOps is to combine
the Git with the operations so that you can
actually use the exact same workflows that
you're used to with your source control to
manage the configurations of
your applications deployed to Kubernetes,
deployed in arm templates or really
anywhere where you can do Infrastructure as code.
The really great thing about this is a lot of
the same processes that are associated with Git,
like code review, so you can have
multiple people looking at
the same piece of source control.
They all apply when you're doing the operations as well,
and that leads to more reliability,
better understanding of the whole thing,
and how the whole all the different pieces
of your system fit together.
Today we're going to take a little bit of
a deeper look at exactly how we implement
that with Arc and the Azure Kubernetes Service.
Additionally, we're going to see how this pattern in
the context of a single cluster is
great for managing your infrastructure.
But in the context of multiple clusters,
it's even better for scaling out your operations.
Let's take a look at the details
of what GitOps looks like.
Maybe some of you are familiar with
the JSON that's associated with an arm template,
or the YAML that's associated with Kubernetes,
or maybe you're even discovering Bicep,
which is a new way of managing
infrastructure's code on Azure.
Those source control files are exactly what
you're going to put into your Git repository.
You're probably familiar with
taking these infrastructure as
code text files and pushing them into a Git repository.
Once you do that,
you can turn it into a GitOps repository
by adding automation.
I'll draw a little gear here to represent the automation.
I apologize for my gear drawing skills,
they definitely could use a little bit more practice,
but you're going to add some automation
connected to that Git repository.
The net effect of that is,
every single time you push
a new configuration into that Git repository,
the automation is also going to
notice that and it's going to take an action.
It's going to create a pod or a service,
and it's going to deploy your
application out to the cluster.
If we dive a little bit deeper into how that
actually works inside of the cluster,
it's an example of the operator pattern.
The operator pattern is basically
the idea that inside your Kubernetes cluster,
you're going to have a little actor,
this is the operator,
and it's running and taking action on behalf of you,
so just like someone who might actually be operating
an old computer back
in the 1950s before they were operating systems,
we came out with the idea of
an operating system to replace that operator.
The operator in your Kubernetes cluster
replaces a human taking action to
deploy an application and becomes
a process that deploys that application instead.
This operator is listening to the Git repository,
it's listing at a particular branch,
and this is important,
we'll see in a little bit, and
a particular tag within that branch.
What it's basically doing is whenever it notices
a change between what it sees inside of the cluster,
so it's looking at the various pieces
that are inside of the cluster.
When it notices a change between
the description of what should be in the cluster
that's in the Git repository and
the actual things that are inside of the cluster,
it takes an action.
You can think of this like a thermostat.
If you're familiar with the idea of a thermostat,
you set the temperature to 75 C,
and depending on the temperature of the room,
that thermostat is going to take action to either heat or
cool the room to achieve your desired state.
The GitOps operator is the exact same way.
It's going to treat the Git repository
as the equivalent of
that temperature that you're setting.
In this case, it'd be the
configuration of your application,
and it's going to take actions inside of
the cluster to make the state of your application
in the cluster match the desired state that you've
expressed in that GitOps repository.
A really fantastic thing about this
is that the only thing that you did in order to
take that action is you went and you wrote a new version
of the text file and you pushed it into the repo.
That's very familiar if you're
used to doing that for code,
and then the amazing thing about that
is because it's in a Git repo,
you get to take advantage of things like rollback.
If it turns out that this configuration is bad,
well, remember, this is my V2 say.
In that same Git repository,
I've got a V1, and I
can actually come along and say, "You know what?
I don't actually like that V2.
I'm going to roll it back
and I'm going to go back to V1."
That's all I do, and
then that same operator that's paying attention to
your Git repository takes the action
to actually make the state of
the world match up to your desired state.
Going back to our thermostat analogy,
maybe we turned the temperature up too high.
We're going to take a step back, turn it down.
That same operator will fix the state
of the world to be the desired state that we want to see.
The great thing about this is not just that you're doing
infrastructure as code and
declarative configuration in a really simple way,
and you can manage your cluster
just using Git push and Git pull.
There's also a lot of best practices that you can
associate with GitOps that make it even better.
We're going to actually erase this to take
a little bit of a better perspective,
get a little more space to take a look at some of
the practices you can put into place with GitOps.
Then we'll dive into the scale aspects
and how you can use it to expand,
to manage multiple clusters at once.
Now, you're taking your configurations and
expressing them as text files in that Git Repository,
and you've got your GitOps automation setup
so that any changes that you
push into that repository end up
as configurations of your cluster.
But what can we add on top of that?
The number one thing that we can add on top
of that is human oversight.
I think in source code,
it's quite familiar at this point that code
shouldn't merge without it
having gone through a code review.
This is the whole pull request process on GitHub.
The great thing about this is,
instead of just having a single person's eye,
it's my best eye that I got, say,
having a single person's eyes on the code.
Now we can actually have
multiple people's eyes on the code,
and by having multiple people looking at
the change in reviewing the change before
it gets committed and before it gets
manifested out into our production environment,
we have a better chance of catching errors.
That's a huge step forward in terms of reliability
because a single person can make mistakes,
it's much harder for two people to make
the same mistake when looking at the same change.
Now, as long as we're thinking
about fixing errors and that sort of thing,
one of the other things that we can add is testing.
I think, again, it's familiar
into the source code environment that
you're going to add unit tests before
this code merges into Git.
You can do the exact same thing with
the configurations of your application.
You can say something like there shouldn't be
fewer than three replicas of my application.
You can assert and say
replicas will always be greater than three,
and this is a test that you can apply to
this configuration before it merges
into the Git repo and before it pushes out to production.
Again, just like the code review was adding validation of
a human taking a look at
the change to make sure that they thought it was safe,
automation and unit testing,
the same analogies that you're using in source control,
can be used to test and ensure that
the configuration is valid before it
gets anywhere near a production environment.
Not only does GitOps make it much,
much easier for your developers to push code,
it actually also makes it more reliable.
Finally, there's a really strong element of
security as well in a GitOps environment.
Remember, this process of going from
the repo out into the environment is done by automation,
so I'll draw my gear again here. Do my best.
We got a little bit of automation that's doing this.
Now it turns out that that automation
is the only thing that
you need to give the keys to your cluster.
The only thing that needs access via
RBAC to the cluster to make changes is this automation.
The people who are actually taking action,
they only need to be able to write
these configuration files and be
able to push them into the Git Repository.
This really allows a separation of concerns so
that even if this person's account
is compromised in some way,
maybe they leave their laptop in a coffee shop
or their password gets compromised,
they don't have the ability to
actually modify your production cluster.
It has to go through this automation process.
It has to get a code review,
it has to get validation,
and then it's only then is it pushed out through
the access control of this automation that
you have running inside of your cluster.
That's a huge improvement,
not only in ease of use,
not only in reliability of the deployment,
but also the security of the deployment as well.
I hope that gives you a perspective about what
GitOps is and how it all fits together.
I want to take the last step and
describe how GitOps enables you to scale.
The whole purpose of Arc and the whole purpose
of what we're doing with enhanced management
for Kubernetes clusters anywhere is this idea that
actually Kubernetes clusters are popping up all around.
I think there's a great example in the talk of
the need to have clusters
in various geographic locations.
Sometimes we see it was shipping companies.
They need a Kubernetes cluster on a ship,
clearly a ship that's sailing out in the ocean,
that's not going to be inside one of our data centers,
and there could actually be lots
of ships all over the place.
We have lots of ships.
Each one has their own Kubernetes cluster.
Actually, managing the software,
ensuring that all the software is up to date, secure,
reliable on all of
those different ships could actually
be a really challenging thing,
especially because when the ship
is in the middle of the ocean,
they may not have any network.
Maybe they have one Wi-Fi bar.
If they're in the port, they've got a bunch of Wi-Fi,
so it means that it actually not every single cluster
is connected to the Internet at any particular time.
You can't rely on
pushing things out to these environments.
GitOps is a great fit
for managing these clusters at scale,
and the reason for that is because we have
our Git repository and it's at
the center of the configuration,
it has stored in it the desired state.
In each of these clusters,
you have the GitOps operator.
That GitOps operator is always watching.
No matter what, it's always watching the Git repo.
The good thing about that is
if sometimes it can't watch it,
if there's a network problem and it can't watch the repo,
it doesn't matter, it's going to try later.
But you as a human have
the ability to just push it into this repository once.
There's one time that you push
the code into this repository,
and no matter how many ships you add,
and no matter when they're connected to the network,
they'll all come back to this shared
home Git repository in order to adopt that configuration.
Let's say over a week,
all of the various ships in your fleet
connect into the Git repository and the configuration
that you've placed into this single place
gets pushed out to all of
these different clusters without
any real intervention by you,
other than just the first step of placing it into
the Git repository and
setting up GitOps in all of these clusters.
I hope that's given you a perspective about
what GitOps is and how you can use it
to build more scalable and more
reliable applications and also deploy
those applications to Kubernetes wherever it
happens to be around the world with Azure Arc.