►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
GitOps Working Group Update - Cornelia Davis, Weaveworks & Chris Sanders, Microsoft
In late 2020 the GitOps Working Group was formed under the App Delivery SIG. The goal for the WG is to “provide companies and individuals with the skills, knowledge and competency to implement GitOps tooling and methodologies which simplify the operation and management of infrastructure and cloud native applications.” Within days of the announcement more than 60 individuals from more the 30 companies expressed an interest in participating and the working group was launched. The group is meeting these goals through content creation and evangelism – white papers, blog posts, sample applications, demonstrations and more. In this session we will give an update on the working group and we will evangelize. We’ll present agreed upon key principles and practices, and we’ll teach through demonstrations using a variety of CNCF and other OSS projects such as Flux, Argo, Tekton and more. Most importantly, we will present concrete steps that will help folks get started with cloud-native (Git)ops.
A
A
A
A
A
You
can
get
ops
things
that
are
in
your
infrastructure,
so
you
could
be
doing
a
variety
of
different
infrastructure
things
on
azure,
for
example,
or
you
could
be
doing,
get
opting
from
your
ldap
system
or
something
like
that.
There
could
be
a
number
of
different
runtime
environments,
but
we're
using
kubernetes
here,
just
as
an
exemplar.
A
Now.
The
next
element
is
that
we've
got
a
number
of
individuals
who
are
operating,
that
runtime
environment,
they're
operating
the
infrastructure,
the
applications
running
on
that
the
roles-
and
you
know
the
roles-
you
know,
role-based
access
control,
all
of
those
types
of
things
and
what
we're
talking
about
with
gitops
gets
to.
How
do
they
do
that?
How
do
they
operate?
Those
things
in
the
runtime
environment
and,
as
you
can
imagine,
because
there's
some
white
space
there
there's
something
coming
well.
A
A
It's
not
that
they're
doing
operations
elsewhere
and
then
coming
back
to
get
to
record
things,
it's
that
they
are
using
that
interface
into
git
has
the
interface
for
operations,
so
that
is,
is
really
really
critical.
Now,
when
they
do
commit
things
into
git,
using
prs
or
whatever
the
case
may
be,
and
then
approvals.
A
There
is
some
automation
that
has
to
happen
to
make
that
so
in
the
runtime
environment,
and
the
second
really
important
element
of
get
ops
is
that
that
automation
needs
to
be
special.
It
needs
to
be
convergent,
and
now
you
can
see
why
I
started
with
kubernetes,
because
kubernetes
is
by
its
very
nature,
convergent
system,
so
we're
kind
of
capitalizing
on
that
so
get
ops
is
using
an
interface
into
a
versioned
immutable
store
like
git
and
then
using
convergent
automation
to
make
it
so
in
the
runtime
environment.
Now,
there's
one
final
element,
which
is
these
days.
A
Modern
operations
is
all
about
feedback
loops
if
there
is
any
reason
that
something
has
changed
in
the
runtime
environment,
we
also
want
to
automate
that
loop
back
in
to
the
versioned
immutable
store
that
has
the
desired
state.
So
if
we
had
to
do
some
kind
of
quick
fix
in
the
runtime
environment,
we
want
to
automate
that
feedback
back
into
the
git
repository
as
well.
So
that's
kind
of
a
quick
overview
of
get
ops
with
that.
B
B
This
working
group
was
formed
last
november
and
it
was
announced
there
was
several
companies
who
are
initiators
here,
including
a
code
fresh
and
amazon
and
github
and
weaveworks
and
microsoft,
who
initiated
this
working
group,
but
as
you'll
find
out.
This
is
a
work
group
that
is
open
to
to
all
next.
B
So
the
goal
of
this
working
group
is
to
provide
companies
and
individuals
individuals.
You
know
you
folks,
who
are
watching
with
the
knowledge,
the
skills
and
the
competency
to
be
able
to
implement,
get
ops
using
tooling
and
methodologies
with
simplify
your
operation
and
management
of
the
infrastructure
and
cloud
native
applications.
So
you
can
see
here
that
one
of
the
core
reasons
for
the
working
group
is
to
help
educate.
You,
educate
companies,
educate
individuals
on
the
principles
of
git
ops.
B
A
Yep
and
I'll
just
really
quickly
before
I
advance
the
slide
re-emphasize
two
words
on
the
screen
here
I
already
said
it,
chris
is
going
to
say
it
repeatedly,
which
is
get
ops,
doesn't
just
apply
to
infrastructure.
It
doesn't
just
apply
to
applications.
It
applies
to
everything
anything
that
you
need
to
operate
in
a
runtime
environment.
You
can
apply
githubs
to.
B
Cool,
so
where
does
this
new
working
group
live?
Well,
an
obvious
obvious
place
for
it
to
live,
is
the
cloud
native
computing
foundation
and
that
foundation
has
a
mission
to
make
cloud
native
computing
ubiquitous.
So
this
is
where
the
working
group
lives
and
in
the
next
slide,
you'll
see
the
next
step
down
of
where
it
lives,
which
is
in
the
app
delivery
special
interest
group
within
the
cncf.
B
B
So
you
can
see
this
great
icon.
We
have
for
the
getups
working
group
and
the
focus
of
the
get
out
working
group
is
again
to
clearly
defined
a
very
a
vendor-neutral
and
principle-led
meaning
of
of
get
ops
so
that
it's
a
very
open
type
of
process
that
we're
using
open,
tooling
system
and
the
get
ups
working
group
will
help
define
and
establish
a
foundation
for
the
interoperability
again
between
tooling,
from
from
various
vendors
conformance
of
systems
with
with
git
ops
and
also
certification
of
practitioners
of
get
ups
as
well.
B
B
B
A
A
Yeah,
so
the
what
we
have
in
mind
with
the
getups
landscape
is
that
there
are
several
elements,
even
in
the
intro
that
I
gave
at
the
beginning
of
the
presentation,
you
saw
that
there
were
several
elements.
There
were
elements
around
this
versioned
immutable
store
that
I
was
talking
about.
There's
also
this
element
around
automation
and
this
element
around
targets
and
then
there's
even
within
the
automation
category,
there's
a
number
of
different
ways
that
you
might
categorize
its
automation.
A
That
is
specifically
for
infrastructure,
specifically
for
kubernetes,
and
so,
if
you
think
about
operation
cloud
native
operations,
you
really
can
think
of
git
ops
as
cloud
native
operations.
So
when
we
talk
about
a
git
ops
landscape,
we're
talking
about
well
there's
so
many
things
that
are
involved
in
cloud
native
operations.
How
do
we
start
to
break
that
down
and
categorize
it
so
that
we
can
then
take
things
like
tools
and
put
them
in
categories?
A
B
Next,
so
you
know
out
of
the
cloud
native
working
group,
there's
going
out
of
the
get
ops
working
group,
there's
going
to
come
some
permanent
artifacts
that
are
going
to
be
things
like
programs
and
documents
and
code
that
are
going
to
live
for
you
to
access
and
so
in
order
to
help
find
a
place
for
those
to
to
live.
We've
created
the
open,
git
ops
project
within
cncf.
It's
currently
a
cncf
sandbox
project,
and
this
will
be
a
place
where,
where
the
artifacts
will
be
stored,
next.
B
A
Excellent,
our
super,
thank
you,
and
so
one
of
the
things.
The
very
first
thing
we
talked
about
it.
We
refer
to
it
as
github's
principles
or
good
ops
definition.
The
principles
are
actually
only
part
of
the
definition
there
it's
in
a
pr,
and
so
when
chris
was
mentioning
that
we
invite
you
to
participate
with
us
on
the
definition
of
what
gitops
is
and
and
the
expression
of
these
principles
and
I'm
going
to
go
over
those
principles
in
just
a
moment.
A
Right
now,
those
exist
in
the
pr
so
I'll
come
back
to
that
slide
at
the
end,
that
shows
you,
the
git
repository
where
the
get
ops
working
group
is
doing
its
work
and
right
now
there's
a
pr
against
that
repository
that
captures
that
getups
definition
we're
capturing
it
in
three
different
places:
one
there's
a
glossary
and
that
glossary
talks
about
things
like
the
desired
state.
The
state
store
reconciliation.
A
A
So
let
me
present
to
you
what
the
principles
are.
Looking
like
right
now
in
the
discussion
in
that
get
ups
working
group,
it
starts
out
with
principle
number
one
and
principle
number
one
says
that
we
it's
the
principle
of
declarative
state,
so
this,
if
you
will
for
those
of
you
who
are
familiar
with
kubernetes.
Oh
it's
funny
that
I
should
say
that
right.
This
is
kubecon.
Most
of
you
probably
are
is
that's
the
way
that
you
configure
your
kubernetes
systems.
A
So
that's
principle,
number
one
principle
number
two
is
that
that
desired
state
that's
declaratively
expressed,
is
stored
in
a
way
that
supports
versioning,
immutable
immutability
of
those
versions
and
retains
that
version
history.
So
I
hinted
earlier
that
it
didn't
have
to
be
get,
but
there
are
certain
semantics
that
we
depend
on
for
get
ops.
So,
for
example,
that
last
part
that
says
retains
a
complete
version
history.
A
A
That's
really
important,
because
one
of
the
one
of
the
benefits
of
get
ops
that
we
talk
about
is
that
you
can
roll
back
that
you
can
easily
recover
the
state
of
a
system
either.
You
have
moved
forward
a
version
and
some
unanticipated
problems
showed
it's
reared
its
ugly
head
way
too
late.
Now
we
need
to
pull
back,
we
want
to
roll
back
to
the
previous
version,
or
I've
had
some
kind
of
a
disaster,
and
I
need
to
quickly
stand
up
my
system
in
a
different
region,
for
example,
being
able
to
do
that.
A
So
you
can
see
that
these
principles
are
very
specifically
crafted
to
support
some
of
these
benefits
that
we
realize
from
get
ops
principle
number
three
gets
to
that
automation,
piece
that
I
showed
you
in
the
earlier
slide,
which
it
says
well
when
you
have
stored
this
desired
state
which
you've
expressed
declaratively
and
you've
stored
it
appropriately
in
the
right
kind
of
store
and
there's
going
to
be
software
agents
that
respond
to
that
now,
you
could
imagine
that
we're
just
sending
out
web
hooks
and
running
some
bash
script
somewhere.
That's
not
get
ops.
A
What
we
are
saying
here
is
in
order
to
take
advantage
of
that
declarative
state,
we're
saying
that
the
automation
has
to
be
that
convergent
system
that
reconciliation
based
system
that
I
talked
about
earlier.
So
those
are
those
software
agents.
Now
I've
put
a
couple
of
icons
up
here
to
show
you
that
those
software
agents
fall
into
a
couple
of
different
categories.
A
You
see,
for
example,
there's
a
flux
logo,
that's
the
the
the
far
left
one
and
then
there's
the
argo
cd
logo,
which
is
a
little
octopus
there.
Those
are
both
reconcilers
that
deal
with
delivering
things
from
the
git
repository
over
into
the
kubernetes
environment.
Those
are
all
reconciliation
based.
Then
kubernetes
itself
has
all
sorts
of
reconcilers
like
your
deployment
controller
and
your
replica
set
controller
and
then
the
little
stacked
turtles
there
if
you're
not
familiar
with
those,
that's
the
logo
for
cluster
api,
so
cluster
api
is
a
reconciliation-based
way
of
managing
your
kubernetes
clusters
themselves.
A
So
that
means
you
can
declare
your
desired
cluster
state,
not
workload,
but
cluster
state
and
you
can
have
a
you-
can
have
something
like
flux
or
argo,
deliver
that
and
then
you've
got
these
reconcilers.
That
will
make
it
so
and
stand
up
and
take
care
of
the
kubernetes
clusters
that
you
want.
So
that's
principle,
number
three:
is
this
special
nature
of
these
software
agents
and
then
finally
principle
four
says
this
is
the
only
way
that
you're
going
to
operate
your
system.
You
are
not
going
to
go
in
through
the
back
door
now.
A
There
are,
of
course,
exceptions
you
sometimes
are
going
to
have
to
go
through
the
back
door
and
you
saw
the
feedback
loop.
That
said,
well,
if
you
go
in
through
the
back
door,
if
you
essentially
ssh
in
do
a
coupe
cuddle
apply
that
will
record
that
back
into
the
git
system,
but
the
normal
mode
of
operation
is
for
operations
to
happen
via
these
mechanisms
and
then
the
software
agents
make
it
so
so
those
are
the
four
principles
that
you
can
find
currently
in
that
pull
request.
A
If
you
want
to
participate
in
that,
we
very
very
much
welcome
your
opinions
and
your
feedback
in
that
poll
request.
So
please
come
there,
and
so
really.
The
whole
point
here
is
that
it's
really
about
this
convergent
system
and
there's
continuous
delivery
and
continuous
operations.
So
we
sometimes
like
to
say
get
ops
does
not
equal
cd.
It
equals
cd
plus
co.
So
that's
what
this
picture
is
showing.
So.
Finally,
I
want
to
reiterate
chris's
invitation
from
earlier.
Please
join
us.
I've
mentioned
that
the
get
ops
principles
is
a
pr
there.
A
The
repository
I've
put
it
there
in
a
larger
font
as
well,
so
the
repo
there
is
in
github,
it's
get
ops,
working
dash
group
and
that's
the
organization,
and
then
we've
got
a
number
of
repositories
under
there.
The
kind
of
home
for
the
working
group
is
there.
We
also
meet
synchronously
the
second
thursday
of
every
month
at
1800
hours,
gmt.
A
That
occasionally
moves
so
keep
an
eye
on
the
cncf
calendar
when
it
does
move
because
of
holidays
or
those
types
of
things
we
do
update
the
cncf
calendar.
You
can
find
all
of
the
details
really.
The
only
url
that
you
need
to
remember
is
that
gitops
working
group
and
you
can
find
everything
else
there.
It
will
take
you
to
documents
and
press
releases
and
all
of
that
kind
of
stuff.