►
From YouTube: GitOps As a Journey - Dan Garfield, Codefresh; Scott Rigby, Weaveworks & Chris Short, AWS
Description
What is GitOps and How to Get It Right - Dan Garfield, Codefresh; Scott Rigby, Weaveworks & Chris Short, AWS
The term "GitOps" goes back to Alexis Richardson's initial blogpost on operations by pull request but over time it became clear that GitOps was poorly understood. At the end of 2020, Amazon, Azure, Codefresh, Github, Redhat, and Weaveworks came together to start the GitOps Working Group. The goal was to work together and invite the community to collaborate on clear principles and definitions around GitOps. In this talk, two Open GitOps Co-Chairs will share how the principles were created, what they mean, and some common misunderstanding about what is and isn't GitOps.
A
C
Awesome
person
yeah
thanks
and
you're-
welcome
I'm
chris
short,
I'm
from
aws
senior
dev
advocate
over
there.
I
work
with
these
guys
just
some
housekeeping
items.
We
have
two
tracks.
This
getups
gone
first
time
ever
and
you're
here
for
it.
So
the
keynote
is
going
to
be
we're
going
to
talk.
Christian
is
going
to
do
an
awesome
keynote
and
then,
after
that,
that's
when
we
break
out
our
second
breakout
room
is
upstairs
in
the
joaquin
rodrigo
room.
One
level
up
also
reminder
no
food
and
drink
in
here.
C
B
A
B
A
C
One
thing
I
didn't
mention
I
forgot
to
mention:
we
had
some
people
that
had
some
travel
problems.
It
happens
right
like
people
missed
flights
and
stuff,
so
some
sessions
will
be
virtual.
Okay
and
the
schedule
doesn't
necessarily
reflect
that
we're
sorry
everything
happened
last
minute,
I
swear
thursday
and
friday.
I
remember
sending
emails
to
cncf
about
speakers
not
being
able
to
travel
here
so.
B
A
A
Half
of
you
yeah
makes
sense
how
many
people
feel
like
today.
They
are
practicing
get
ups
about
half,
maybe
a
third,
so
everybody
else
is
definitely
looking
to
to
get
into
get
ops.
Hopefully,
and
we
do
have
a
lot
of
speakers-
we're
gonna
be
talking
about
this.
There
are
four
principles
that
have
been
put
together
and
we're
gonna
go
through
these
one
by
one
first,
but
they're,
really
simple
in
their
language.
A
They
get
more
interesting
as
you
get
into
implementation,
so
we
really
think
of
git
ops
as
a
continuum
as
a
journey
of
best
practices
and
principles
and
a
lot
of
people
they
feel
like
hey,
I'm
doing
get
ups,
because
I'm
doing
this
part
or
I
feel
like
I
could
improve
my
get
ups,
because
I
can
go
to
this
next
level,
and
so
we
think
that
this
is.
This
is
not
just
a
journey,
but
it's
a
destination
and
and
there's
a
lot
to
be
done
here.
A
B
So
so
you
know,
and
while
and
while
we
describe
what
should
and
shouldn't
be,
should
and
shouldn't
be
in
in
git
per
se
or
in
your
your
desired
state
store.
All
of
your
rules
must
be
there
right.
So
if
you
have
external
databases
or
other
things
like
this,
that
have
you
know,
etls,
etc,
like
all
of
all
of
those
need
to
be
should
be,
and
in
an
ideal
state
in
all
declarative
everything
declared.
So
that's
you
know.
B
C
B
A
A
Yeah
infra,
not
necessarily
apps,
that's
right.
So
when
we
talk
about
the
system,
like
scott
said,
there's
a
specific
definition
of
this
that
we
look
at
and
it's
really,
it
really
does
include
your
your
entire
stack,
not
just
the
infrastructure,
also,
the
applications,
also,
the
policy.
All
of
those
elements
that.
C
A
So
so
now
that
you've
got
declarative,
you've
got
your
configuration,
declarative,
the
next
step
on
the
journey,
and
so
you
know
a
lot
of
people
if
you've
adopted
like
terraform
at
this
point,
you're,
probably
at
number
one.
If
you've
adopted
you
know
customize
or
helm,
you're
you're
you're
at
level
one.
Here,
though,
you
may
still
need
to
do.
You
know
additional
work
to
bring
in
those
additional
policies
and
and
everything
you
need.
Basically,
everything
you
need
to
operate,
operate,
control,
access
and
and
bootstrap.
A
These
systems
level
two
over
here
is
versioned
and
immutable,
and
this
one
trips
people
up
because
they're
like
oh,
that
just
means
I'm
using
git
and
it's
actually
a
little
bit
deeper
than
that.
First
of
all,
we
don't
we
don't
use
git
in
the
name
of
the
principle,
although
it
maps
to
git
as
a
source
as
the
source
of
truth.
We
don't
use
git,
because
the
key
is
that
it's
versioned
and
immutable
and
you
can
be
using
git
in
a
non-immutable
or
versioned
way
right
for.
B
B
It's
catchy
is
what
it
is,
and
so
it's
you
know
git
is
the
primary.
It's
probably
it's
the
most
popular
way
of
having
an
immutable
state
store
with
a
full
audit
trail,
but
it's
not
the
only
thing
you
can
use.
You
can
use
object,
storage,
buckets
generally
and
we're
just
talking
prints
on
principles,
not
specific
tools
right,
you
can
use
oci,
you
can
use
other
other
helm.
A
And
your
your
references
need
to
also
be
that
way.
We
were.
We
were
talking
with
some
folks
yesterday,
who
are
using
floating
tags
like
a
latest
version
in
their
manifest.
Well,
that
manifest
is
no
longer
supporting
version
of
version
system,
because
if
you
do
a
new
version,
so
it
deploys
and
you
need
to
do
a
rollback
because
you're
using
a
latest
tag
on
that
image,
you
can't
do
a
rollback
by
just
changing
the
configuration
any
longer.
A
So
by
reverting
the
configuration
you
now
have
to
introduce
new
configuration
to
introduce
an
older
version,
so
it's
not
just
about
using
git
it's
about
using
it
in
the
right
way,
so
that
it's
going
to
support
the
kind
of
things
you
want
to
do
down
the
road.
So
again,
these
principles,
when
you
read
the
words
very
simple
thanks,
but
as
you
as
you
start
to
dig
into
it,
it
becomes
clear,
there's
actually
a
little
bit
more
to
the
story.
A
So
coming
up
on
the
third
principle
pulled
automatically
your
desired
state
is
always
pulled,
it's
not
only
event
driven.
So
up
until
this
point
you
might
just
be
doing
great
devops
hygiene
with
a
simple
ci
cd
pipeline
and
you'd
be
you'd,
be
in
business
yeah.
But
at
this
point
we
have
a
divergence
on
that
right.
C
And
the
don't
get
caught
up
on
push
versus
pull.
That's
that's
not
the
story
here.
The
big
thing
is
is
that
if
a
state
change
happens,
a
reconcile
loop
occurs
or
five
minutes,
whatever,
whatever
your
desired
trigger
action
is
that's
how
you
run
it
and
the
system
pulls
all
the
configuration
in
parses
it
and
then
spits
out
whatever
you
told
it
to.
B
A
Yeah-
and
this
is
this-
is
pretty
common
as
people
make
the
transition
from
kind
of
a
traditional
deployment
flow
to
get
ops.
This
pull
mechanism-
you
know
as
a
as
a
term
becomes
important
because
you
may,
as
scott
said,
you
may
have
a
trigger
that
triggers
reconciliation,
but
you
shouldn't
be
reliant
on
that
trigger,
and
this
this
goes
to
the
resilience
of
your
system
and
its
ability
to
always
figure
out
what
the
source
of
truth
is
saying
about
how
the
the
state
should
be.
B
To
be
the
only
thing
that
triggers
your
your
your
reconciliation,
because
if
something
goes
wrong
in
the
cluster,
something
goes
wrong
with
networking.
Let's
say
you
have
an
entire
system.
Failure
who
knows
you
want
the
system
itself
to
repair
itself
continuously,
just
like
kubernetes
will
with
kubernetes
primitives,
and
so
that
should
apply
to
the
rest
of
your
stack.
C
And
this
is
why
I
say:
get
ops
is
an
implementation
of
devops
right
like
it
takes
it
a
step
further,
it
gives
you
some
guidance,
some
guard
rails
and
a
lot
of
implementation
details
that
in
a
devops,
work
is
kind
of
like
a
dream.
Come
true
because,
oh,
are
we
doing
devops
or
not?
We
don't
know
if
you're
doing
git
ops,
you
are
for
sure
yeah.
A
Yeah-
and
these
I
mean
we're
going
to
get
into
the
process
of
how
these
principles
came
about,
so
number
four
is
continuously
reconciled.
So
this
is
this
is
where
we
get
into
that
drift.
Detection
idea
and
drift
is
a
really
simple
idea.
Drift
just
means
that
the
actual
state
of
your
system
has
diverged
for
any
reason
from
the
desired
state
that
was
previously
set.
A
A
C
It's
fun:
it's
we're,
making
it
better
day
by
day
trying
our
best
but
like
having
your
entire
team
access.
The
console
is
not
exactly
the
most
secure
environment
right,
so
you
want
to
hand
out
those
credentials
very
carefully,
because
the
real
system
that
matters
is
your
reconciler,
your
get
ops
controller,
that's
the
one
that
you
want
to
have
the
full
control.
That's
the
only
one
other
than
some
kind
of
break
glass
procedure.
A
That's
right
and
this
this
continuously
reconciled
thing
goes
to
a
kind
of
deeper
concept.
There
there's
a
concept
within
engineering
called
control
theory
and
there
are
open
loop
systems
and
closed
loop
systems,
and
you
can
imagine
if
we
were
going
to
chop
down
a
tree,
we
would
have
an
open.
An
open
system
would
be
a
machine
that
just
swings
an
axe
right.
A
Okay,
it
just
swings
the
x,
it
doesn't
know
if
the
tree
is
there,
it
doesn't
know
if
it's
hitting
the
tree,
it
doesn't
know
if
it's
making
progress,
it
doesn't
know
if
something
has
fallen
in
the
way
it
just.
It's
just
told
hey
swing
that
x,
but
in
a
closed
loop
system
you
can
essentially
say
my
desired
state.
Is
that
the
tree
is
the
tree
is
chopped
down
right
and
now
the
system
says:
okay,
am
I
connecting
with
the
tree?
Do
I
need
to
adjust
the
angle
of
the
ax?
A
Am
I
making
progress
on
it?
Has
someone
moved
in
the
way,
so
I
shouldn't
be
swinging,
so
there's
there's
this
feedback
mechanism
that
goes
into
that,
and
that's
kind
of
where
this,
where
this
idea
of
continuously
reconciliation
comes
from,
is
that
as
a
software
agent,
a
get
offs
operator?
If
you
will,
there
needs
to
be
some
intelligence
to
understand
what
is
happening
in
the
system,
so
it
knows
what
to
apply.
So
what
is
this?
How
does
this?
Okay,
how
does
chopping
wood
relate
to
mm-hmm.
B
Here's
an
example:
what,
if
you,
what
if
you've
got
you're
you
you
want,
you
want
10,
10
replicas,
but
you've
only
got
eight.
Is
it
because
the
system
is
working
to
create
those
ten
or
is
it
because
it's
drifting
away
from
that-
and
you
know
this
is
one
of
the
reasons
why
okay,
we
are
at
kubecon.
Get
up.
B
Getup
specifically
does
not
mention
anything
about
kubernetes
and
the
principles
themselves
right,
but
it's
not
a
surprise
that
that
kubernetes
is
the
most
popular
platform
that
runs
git
ops,
because
in
some
ways
git
ups
is
a
natural
extension
of
kubernetes.
As
brennan
burns
said
recently,
you
it
already
handle
the
system
already
handles
those
those
events
and
conditions
very
well
and
there's
a
really
good
setup
for
that,
so
building
on
top
of
that
system.
In
this
context,
like
a
tree,
I
guess
in
this
sense
it
would
be.
B
You
know
you,
your
your
controllers
need
to
be
intelligent
enough
to
know
what
to
respond
to
based
on
the
feedback
that
they're
getting
from
the
actual
state
of
the
system.
So
that
is
one
thing
that
the
getups
principle
say
is
in
principle,
four,
that
your
systems
can
excuse
me
that
software
agents
are
continuously
monitoring
the
actual
state
of
your
system
and
comparing
against
your
desired
state
and
then
working
to
bring
them
to
to
resolution
to
reconciliation
through.
B
If
you
dive
into
the
the
glossary
through
through
specific
actions
and
those
actions
can
be
notifying
you.
If
things
are
wrong,
those
actions
can
be
other
kinds
of
policies
or
specific
gates,
and
they
can
also
be
well.
If,
if
these
conditions
are
true,
then
you
know
then
proceed
otherwise
proceed
with
caution.
Sort
of
like
a
how
crash
loop,
backup
works
right.
A
Yeah
and
so
when
we,
when
we
talk
about
continuous
reconciliation,
let's
imagine
a
scenario:
let's
say
that
you
had
a
set
of
kubernetes
manifests
and
you
set
up
a
cron
job
to
coop
ctl
apply
those
manifests
constantly
every
five
minutes
right.
Would
we
then
be
doing
git
ops?
Well,
let's
see
we
have.
We
have
the
source
of
truth
from
git.
Okay,
so
we've
got
check
box
number
one
we're
on
our
way.
We've
we've
got
it
declarative.
So
sorry,
that's
good!
You
get,
but
that's
check
boxes,
one
and
two
right.
A
A
You
know
if,
if
someone
were
to
change
those
things
in
production,
that
would
be
overwritten,
but
not
because
the
system
was
aware
that
it
needed
to
be
so
we're
kind
of
missing
on
that
one
and
then
on
this
on
this
reconciliation,
there's
no
there's
no
real
sense
of
well
what?
If
what?
If
I
can't
reach
the
server
you
know,
what
do
I
do
in
that
case
or
or
what?
If
there
aren't
enough
available
nodes
for
this
deployment?
You
know
I've
applied
the
configuration,
but
I
don't
necessarily
have
any
feedback
mechanism.
B
So
you
wouldn't
be
you
wouldn't
be
not
doing
good
ops.
In
that
sense,
it
would
just
be
operating
in
an
operating
in
a
normal
loop
or
an
open
loop,
and
it
may
not
be.
You
know,
retrieving
all
the
benefits
that
you
could
get
if
you
dig
into
the
to
the
to
the
supporting
documents
for
the
principles
so
as.
A
We
as
we
look
at
kind
of
a
system
overall,
you
can
see.
Basically
you
have
your
desired
state
right.
You
have
your
actual
state,
you
have
this
reconciler,
you
have
your
versions,
and
so
you
can
see
how,
when
you
introduce
a
change,
your
desired
state
has
changed,
that's
the
source
of
truth.
Your
reconciler
sees
that
the
desired
state
has
changed,
it
sees
it,
it
diverges
from
the
actual
state
it
moves
to
the
system.
It
attempts
to
apply
the
desired
state.
A
If
there's
an
issue,
an
error,
maybe
it
needs
to
send
a
message
to
you:
maybe
it
needs
to
wake
you
up.
Maybe
it
needs
to.
It
needs
to
wait
longer.
Maybe
there
are
security
policies
that
aren't
being
met.
Any
of
those
things
from
a
declarative
standpoint
is
gonna
is
gonna
change
the
behavior
of
how
this
reconciler
is
going
to
act
and
the
within
open,
git
ops.
You
know
we
don't
necessarily
choose
a
winner
and
loser.
We
don't
say:
hey,
you
have
to
use
flux
or
you
have
to
use
argo
cd.
A
A
It
really
puts
the
power
in
the
hands
of
the
developer
to
be
effective
with
their
time
and
it
from
a
release
management
team.
You
always
have
a
clear
idea
of
what
do
I
do
if
something
goes
wrong.
You
know
I
can
revert
my
desired
state
and
it's
going
to
fix
my
actual
state,
and
so
that
puts
you
in
the
position
where
we
know
that
when
people
adopt
git
ops
they
deploy
more
frequently,
they
have
fewer
regressions,
their
mean
time
to
repair
goes
down
and
ultimately,
that's
the
goal.
A
C
A
If
you,
if
you
think
about
someone,
if
you're
you're
doing
infrastructure
as
code,
this
maps
really
well
to
the
first
principle,
you've
got
a
declarative
component.
Now
you
need
the
configuration
as
code
and
obviously
you
need.
You
know,
devops
and
dev
setups
and
those
kinds
of
things
and
as
we
move
through
our
journey
infrastructure's
code
is
taken
care
of
in
kind
of
principle.
A
B
Exactly
and
the
thing
is
get
ups
didn't
come
from
nowhere
right,
it's
in
in
the
in
the
in
the
versioned,
in
the
1.0
version
of
the
get
ops
principles.
If
you
go
to
you
know,
if
you
get
to
go
to
open
dash,
get
offs,
github
repo
and
check
out
the
documents
repo,
you
can
see
the
principles
there,
oh
also
on
the
opengithops.dev
right.
B
It'll
say
that
you
know
this
is
a
set
of
practices
that
really
it
builds
on
established
practices
over
the
last
20.
However,
many
years
and
a
lot
of
lessons
learned
yeah
exactly
so
so
so
you
know,
if
someone
says
well,
you
get
upset,
you
know,
that's
definitely
true
you
want
to
we.
We
want
to
help
folks
as
a
group,
and
it's
not
just
the
three
of
us
of
course,
there's
a
bunch
of
people
in
the
get
ops
working
group
and
that
are
participating
in
the
open,
getups
project.
C
A
We
often
say
that
henry
ford
didn't
invent
the
car,
but
he
did
make
it
accessible
to
everybody
and
that's
the
goal
of
open,
git
ops.
It's
to
make
these
things
that
are
the
best
practices
that
we
know
work,
make
those
things
accessible
and
easily
consumable.
So
now
that
you
now
that
we've
gone
through
the
four
principles,
I
asked
you
at
the
beginning
of
this
talk
to
raise
your
hand
if
you
felt,
like
you,
were
kind
of
doing
get
offs
all
the
way.
A
It's
a
it's
a
smaller
yeah,
it's
a
smaller
percentage,
so
we're
all
on
this
journey
right.
So
for
those
of
you
that
have
implemented
all
of
these
things,
all
the
way.
Congratulations
well
done
for
the
rest
of
us,
mere
mortals
that
are
are
still
working
our
way
through
the
journey.
You
know
we
feel
like,
regardless
of
where
you're
at
in
that
journey,
whether
you're
you
feel
like
you're
at
the
end
or
maybe
you're
in
the
midway.
A
A
A
A
Had
over
60
companies
96
different
interested
parties,
a
ton
of
co-authors,
many
of
them
are
here
today,
and
so
this
is
not
something
that
the
three
of
us
made
up.
You
know.
This
is
something
that
I
think
we
have
a
lot
of
those
meetings
recorded
so
there's,
probably
over
like
40
hours
of
meetings
and
a
lot
of
back
and
forth
that
went
into
each
of
these
words
very,
very
carefully
chosen
to
to
make
it
as
clear
and
simple
and
as
accessible
as
possible.
A
That's
right,
git
is
the
source
of
truth
on
this.
Yes,
so
the
question
is
what's
next
like
I
said
this
is
a
journey
and
there
is.
There
is
really
within
this
movement
of
get
ops.
There
is
a
huge
frontier
of
implementation
to
be
done.
We've
seen
a
lot
of
success
of
people
implementing
git
ops
in
kubernetes.
A
We're
still
seeing
these
principles
start
to
come
into
traditional
infrastructure
is
my
s3
bucket
is.
Am
I
managing
that
in
a
good
ops
friendly
way?
What
about
my
networking?
What
about
my
secrets?
How
am
I
handling
that,
and
so
as
far
as
kind
of
these
frequent
topics
I
described,
we
described
this
as
the
breadth
of
get
ups.
How
wide
does
this
thing
go
and
there
are
a
number
of
open
discussions
in
the
open,
get
ops
repo?
A
We
encourage
you
to
jump
in
and
help
out
with
these
and
bring
your
wisdom
as
well,
because
this
isn't
something
that
you
know
a
high
tower
council
right
is
going
to
decree
down,
but
we
have
handling
secrets
is
a
constant
topic.
We're
hearing
people
ask
all
the
time.
Should
I
be
using
sealed
secrets?
Should
I
be
using?
A
Should
I
be
using
sops
is:
is
vault
okay
and
a
lot
of
the
a
lot
of
the
stumbling
blocks
that
people
get
into
with
git
ops
comes
around
secrets
and
technically
within
those
four
principles.
If
you
are
putting
secrets
in
plain
text,
you
would
be
compliant
technically
with
these
principles,
you
would
also
have
a
breach,
but
yeah.
B
They're
no
longer
secrets
exactly
yeah,
but
but
this
is
the
this
is
the
place
to
please
participate
with
the
group.
If
you,
if
you
haven't,
they
get
up
working
group
and
the
open
getups
project,
the
entry
point
is
currently
get
ops.com
open,
dash
get
ups
is
the
org
and
the
project
repo
is
the
landing
spot
for.
For
all
of
these
things,
the
documents
repo
holds
the
outputs.
B
Principles
in
the
glossary
so
far,
but
other
other
documents
that
are
coming
white
papers
and
other
other
things
best
practices,
documents
that
have
already
been
in
progress
for
a
while,
but
are
not
yet
up.
Please
join
that
and
then
join
the
discussion.
So
most
of
these
are
discussions.
Some
of
these
are
just
in
notes,
so
we'll
we
can
send
you
a
link
to
this
this
deck,
so
you
can
click
on
these
things.
B
These
are
just
a
selection
of
some
of
the
topics
that
are
coming
and
one
about
you
know
part
way
down.
I
just
want
to
mention,
because
it's
super
important,
I
think,
and
it
just
happened-
is
there's
also
a
cncf
environmental
sustainability
working
group.
So
for
anyone
here
that
is
remotely
interested
in
surviving
past.
B
A
certain
point
on
the
planet
join
that
please,
and
one
of
the
things
that
we're
looking
at
is
specifically
for
alignment
is
how
does
how
does
and
can
get
ups
impact
that
right,
for
example,
git
apps
can
allow
you
to
turn
off
your
it
there's
a
lot
of,
and
also,
if
done,
poorly
get
ups
could
be
continuously
running
things
unnecessarily
and
probably
impact
impact
negatively.
So
so
these
are
just
you
know
again.
A
A
So
how
deep?
Within
that
stack,
can
we
go
with
git,
ops
and
there's?
There's
there's
work
being
done
to
expand
the
frontiers
of
git
ops,
both
from
a
breadth
perspective,
but
also
from
a
depth
perspective,
because
if
we
can
bring
everything
within
the
entire
stack
and
at
some
point
you
know,
someone
has
to
physically
move
a
server
into
a
rack
right
and-
and
I
don't
know
if
we're
ever
going
to
get
that
part.
B
B
B
C
Exactly
the
biggest
thing
is
that
all
of
these
aren't
solved
problems,
yet
all
those
discussions
are
open
still
right,
like
we
haven't
totally
figured
out
everything
that
we
can
do
with
get
ops.
Yet
we
haven't
figured
out
all
the
implementations
of
get
ops
that
is
totally
up
to
all
of
us.
So
please
get
involved
and
I'll
tell
you
more
about
that
at
the
end.
So
stick
around
to
the
end.
A
Yeah
we're
we're
all
on
this.
We're
all
part
of
this
get
ops
journey
together.
So
the
speakers
that,
in
the
talks
that
we
looked
at
today,
they
focus
on
not
just
the
areas
of
success
and
well-worn
paths,
but
also
on
these
areas
of
exploration,
and
so
there
are
a
number
of
talks
that
address
how
to
do
secrets
really
well
and
and
success
stories
there.
A
There
are
a
number
of
talks
that
look
at
getting
deeper
into
the
stack:
how
how
deep
they
can
go
with
their
get
ops,
so
we
we
hope,
you're
going
to
enjoy
that
program,
and
we
thank
you
for
coming
and
are
just
thrilled
to
have
you.
We
hope
the
day
is
super
successful,
don't
forget
to
tweet
about
it.
Hashtag
that
get
ops
con
and
we're
gonna
have
a
great
day.
It's
gonna
be
awesome
y'all.
So
thank
you
for
for
joining
us
for
the
opening
session.
A
We're
gonna
introduce
somebody,
and
I
want
you
to
give
him
a
round
of
applause,
because
six
months
ago,
seven
months
ago,
we
actually
asked
this
person
as
a
committee.
Can
you
go
and
make
get
ops
con
europe
happen
and
he
jumped
in
worked
with
lindsay
organized
all
that
stuff?
His
name
is
christian
hernandez.
Please
join
us.
Give
a
round
of
applause.
Yes,.