►
From YouTube: GitOps Days 2021: Orchestrating SLO driven Multi-stage Delivery with Keptn - Jürgen Etzlstorfer
Description
Day 2 (June 10) Session 4
Orchestrating SLO-driven Multi-stage Delivery with Keptn: Merging GitOps and Data-driven Delivery
GitOps has been proven to be a great vehicle to manage the synchronization of configuration to e.g., Kubernetes clusters, and therefore to control the delivery of new applications.
Keptn builds upon this approach by defining a multi-stage delivery with quality-gates that act as a gatekeeper before new software is pushed into production. Keptn uses both GitOps as well as a data-driven approach to orchestrate delivery, test automation, notification, and other tools.
In this presentation, Keptn maintainer Jürgen Etzlstorfer is going to present how GitOps and event-based tooling can be combined to build a multi-stage delivery platform that is open for tool integrations and he will share how this approach is already adopted in the CNCF ecosystem.
Speaker: Jürgen Etzlstorfer, Technology Strategist, Dynatrace
Jürgen is a Technology Strategist in the Innovation Lab at Dynatrace and an active contributor to open-source. He is a maintainer of the Keptn CNCF Sandbox project and especially interested in connecting the CNCF ecosystem by building upon integrations with other CNCF projects. His expertise specializes in CI/CD, operations automation, and open-source ecosystems.
A
Thank
you
so
much.
Let
me
just
start
with
sharing
my
screen
here
and
probably
go
into
full
screen,
and
here
we
go.
So
thanks
a
lot
and
thanks
for
the
great
music,
it
was
really
really
great
to
be
there
backstage
and
listen
to
the
great
music.
So
that
really
makes
this
event
very,
very
special.
I
think
yes,
I,
the
title
you
already
mentioned
title
is
quite
long,
but
I
will
go
into
everything
in
into
detail.
A
I
will
explain
everything:
that's
written
here
into
this
in
these
two
sentences,
my
name
is
jurgen.
I
work
for
a
company
called
dynatrace
and
I'm
also
maintainer
of
the
captain
project,
which
is
an
open
source,
cncf
project,
and
today
I
want
to
talk
about
how
to
kind
of
merge
the
concepts
of
captain,
which
is
more
data
driven
event,
based
delivery
with
git
ops,
with
github's
tools,
and
with
this
we
can
then
orchestrate
multi-stage
delivery
with
quality
gates
based
on
slo.
A
This
is
indeed
everything
is
version
stored
in
git,
and
we
have
this
as
our
single
source
of
truth.
I
think
that's
the
the
biggest
power
of
gitops,
but
what
can
what
kind
of
we
need?
In
addition
to?
This
is
some
way
how
to
manage
our
tests.
Performance
tests
smoke
tests,
functional
tests,
how
to
do
an
evaluation
of
our
tests.
We
might
run
run
tests
for
two
hours
and
then
we
have
to
figure
out
okay.
What
is
the
actual
data
we?
A
This
new
change
and
apply
everything
in
staging,
not
only
the
the
image
tag
but,
of
course,
all
the
configuration
that
has
to
be
applied
in
staging
and
might
be
different
from
from
your
dev
environments.
But
this
is
the
the
whole
power
I
think
of
github,
then
combined
with
an
orchestration
layer
on
top
of
it.
That
can
be
data
driven,
and
this
actually
already
brings
me
to
to
captain.
A
But
the
big
part
for
this
presentation
is
how
to
orchestrate
the
multi-stage
delivery
with
github's
tools
and
also
have
quality
gates
that
make
sure
that
we
do
not
deploy
anything
into
production
that
should
not
go
into
production,
because
maybe
the
error
rate
is
way
too
high,
or
maybe
our
new
version
is
way
too
slow
and
it
would
kill
our
clusters
if
a
lot
of
our
customers
would
use
it.
So
this
is
the
the
main
part
that
I
want
to
focus
on,
but
there's
more
to
it.
A
So
this
is
what
can
be
done
and
for
today
I
want
to
focus
how
we
can
combine
this
all
with
with
the
gitlob's
approach,
so
here
on
the
more
right
hand,
side
of
the
picture.
I
want
to
focus
on
the
honda
small
text
here
on
the
on
on
on
our
favorite
format,
the
ammo.
I
want
to
just
focus
here
on
how,
in
captain
we
define
a
process
and
how
we
define
an
environment
and
basically,
we
in
this
shipyard
file.
A
I
have
defined
a
multi-stage
environment
with
depth
and
staging
and
the
whole
delivery
process
with
the
deployment,
testing,
evaluation,
approval
and
the
release
stage
to
the
next
to
the
next
environment
and
I've.
Maybe
you've
already
noticed,
I'm
not
a
native
speaker
in
english.
I
am
from
from
austria,
we
speak
german
and
captain
for
us
sounds
like
the
captain
of
a
ship.
A
You
have
been
warned
now
that
there
will
be
a
couple
of
those
expressions,
but
now,
let's
take
a
look
at
the
at
this
shipyard
file,
so
we
do
have
the
deployment
we
have
a
test.
We
have
an
evaluation
with
a
couple
of
other
different
tasks,
and
the
important
part
here
is
that
these
tasks,
they
will
get
eventually
sorry
sequentially,
triggered
by
captain
and
the
whole
interaction
between
the
different
tools
and
I've.
Just
put
in
here
some
example:
tools
like
we
can
do
it
with
flux,
for
example.
A
A
That's
the
deployment
is
finished
and
then
captain
can
move
on
to
the
next
stage
and
trigger
the
tests
with
jmeter,
low-cost
artillery,
even
with
low
with
chaos
tests
with
litmus,
for
example,
and
in
this
file
we
do
not
define
what
is
the
actual
test
file
or
test
configuration,
but
again
it's
more
about.
What
is
the
test
strategy
same
goes
for
the
deployment
strategy.
Do
we
want
to
have
blue,
green
or
canary
release?
A
So
this
really
defines
the
process
and
not
so
much
the
tooling.
The
tooling
goes
into
another
concept,
which
is
the
captain's
uniform
and
just
on
this
slide,
I've
kind
of
combined
those
two
a
little
bit.
So
I
put
here
already
the
tools
that
can
be
used,
and
we
can
also
see
here
that
the
captain
part
that
is
really
the
built-in
capabilities
of
captain
for
evaluation,
for
approval
and
for
release
where
usually,
there
is
no
other
tool
needed
that
can
be
done
directly
within
captain
and
for
the
other
tools
there
is.
A
A
So
we
do
have
this
configuration
here
or
definition
here
for
a
dev
environment
and
also
here
a
little
bit
below
we
can
see
for
a
staging
environment.
We
have
also
a
sequence
of
tasks
and
again
this
is
called
the
delivery
sequence.
It
will
be
triggered
once
the
delivery
in
the
in
our
deaf
environment
is
finished,
and
we
we
do
have
our
deployment
strategies.
We
would.
We
are
able
to
change
the
the
testing
strategy.
A
A
So
let's
take
a
look.
How
is
this
kind
of
implemented?
The
conceptual
point
of
view
in
the
conceptual
architecture
of
captain
looks
like
this,
that
we
have
the
captain
control
plane
in
the
kubernetes
cluster,
and
the
captain.
Control
plane
interacts
with
other
tools
via
cloud
events.
So
there
is
the
communication
going
on
back
and
forth
from
the
control
plane
to
the
execution
plane
and
one
of
those
execution
plane.
Services
could
be,
for
example,
g-meter
or
artillery
for
executing
the
tests.
A
So
there
might
be
all
these
different
ways
to
interact
with
the
control
plane
and
everything
here
is
defined
on
cloud
events,
which
is
also
in
cncf
project,
and
we
defined,
I
think,
like
20,
plus
different
events,
how
to
how
how
to
control
a
continuous
delivery
sequence
and
all
these
different
tools.
They
can
subscribe
to
these
events
and
then
we'll
get
notified
if
such
event
occurs,
and
they
can
act
upon
upon
this
event
and
with
this
captain
can
manage
then
multi-stage
deliveries
even
on
one
cluster,
multiple
clusters.
They
have
staging
production.
A
So
we
can
connect
all
these
tools.
But
how
does
it
look
like?
How
does
the
the
deployment
then
actually
look
like
so
we
do
have
in
kit?
We
have
stored
all
of
the
configuration,
so
it
might
be
a
little
bit
small
here,
but
we
only
need
here
for
for
this
first
part,
we
actually
only
need
here
one
line
and
it's
it's
just
called
helm
gear,
or
it
can
also
be
a
manifest
folder.
A
So
when
it
comes
to
the
deployment,
captain
will
have
a
a
git
repository
where
all
the
deployment
information
for
one
specific,
microservice
or
application
is
stored,
and
captain
can
also
update
this
configuration.
So
it
can
act
as
a
promoter
from
one
stage
to
the
other
whenever
there
is
a
quality
gate
passed
for
example,
or
you
could
also
just
trigger
a
deployment
by
updating
this
git
repository.
A
I've
heard
the
trigger
deployment
with
with
the
dashed
line,
so
there
might
be
integrations
where
captain
directly
triggers
the
deployment
such
as
with
helm,
because
it's
not
an
operator
and
looking
for
changes
or
we
can
skip
this
part,
and
we
have
some
kind
of
github's
operator
like
flux,
listening
or
basically
watching
the
git
repository
and
whenever
there's
a
change,
then
it
will
start
the
deployment.
It
will
apply.
A
This
change
into
the
kubernetes
cluster
and
once
it's
finished,
let's
say
by
rolling
out
the
pods
it
can
inform
captain
and
captain
can
then
move
on
to
the
next
task
in
the
sequence
that
we've
seen
earlier
defined
in
the
shipyard
file
and
the
next
task
could
be,
for
example,
a
test.
So
we
can
execute
some
tests
here
and
again.
The
like
high
level
overview
looks
very
very
similar
to
the
deployment,
because,
again,
everything
is
stored
in
the
git
repository.
A
In
this
example,
I
have
two
different
kinds
of
tests
stored
here
for
my
hello
service.
It's
a
gmeter
test
and
it's
a
it's
a
litmus
chaos
test,
so
they
are
stored
in
this.
In
this
git
repository
and
this
the
test
configuration
the
test
files.
They
are
then
passed
to
the
tool
integrations
of
captain
to
the
captain
execution
plane,
and
then
they
can
act.
They
can
execute
whatever
they.
They
want
to
execute
like
running
the
the
gmeter
test
or
executing
the
chaos
that
is
defined
in
in
the
in
the
litmus
crds.
A
So
this
is
how
captain
can
orchestrate
these
tools,
because
only
when
two,
when
both
testing
tools
are
finished,
then
captain
can
trigger
the
evaluation.
Again,
it's
not
necessary
to
trigger
the
evaluation.
But
it's
just
when
we
recall
the
shipyard
file
that
we
saw
earlier.
It
was
a
deployment,
it
was
a
test
and
it
was
an
evaluation.
A
It
was
an
approval
and
then
it
was
released.
So
the
next
part
would
be
to
do
the
evaluation
and
for
the
evaluation
we
again
base
everything
that's
needed
for
evaluation
in
the
git
repository.
We
can
even
see
it
here.
We
do
have
the
prometheus
folder
and
we
do
have
the
slo
file
here
for
promethos.
I
think
most
of
you
can
imagine
it
will
be
the
configuration
for
prometheus
how
to
create
the
data,
but
the
slo
file.
A
A
More
than
five
percent
to
the
previous
runs
something
like
this,
and
we
can
now
define
slis
and
slos
again
in
in
a
declarative
format
that
we
put
into
our
git
repository.
So
for
the
indicators,
it's
basically
a
list
and
a
key
value
for
the
name
of
the
indicator
and
how
to
retrieve
this.
The
value
for
this
indicator,
like
by
a
promptql,
for
example,
and
for
slos.
We
can
then
use
the
as
the
name
of
the
sli
and
define
concrete
objectives
for
our
slis,
something
like
the
success.
A
Percentage
of
a
probe
has
to
be
higher
than
95.
So
that
means
for
a
given
time
frame.
The
time
frame
that
is
evaluated
is
actually
calculated
by
the
by
the
the
length
of
the
tests
that
were
also
orchestrated
by
captain.
So
we
can
exactly
be
sure
that
we
are
evaluating
for
the
correct
time
frame
and
we
need
we
need
a
higher
success
percentage
than
or
at
least
95
of
success,
to
get
full
points
on
this
evaluation,
or
we
would
get
like
only
half
the
points
for
it
will.
A
It
will
be
a
warning
if
we,
if
we
cannot
reach
this
95
percent,
but
still
we
are
higher
than
90.
So
this
is
how
we
can
build
quality
gates,
and
this
is
a
very,
very
simple
example.
It
it's
actually
a
valid
example.
It
will
work,
but
of
course
you
can
imagine
there.
You
might
want
to
have
way
more
indicators
and
way
more
objectives
for
a
quality
check
before
you
move
something
into
production,
so
once
executed
and
once
triggered,
captain
will
use
these
two
definition.
A
A
This
can
be
then
used
in
the
approval
phase.
If
it
should
be
approved.
If
it's
approved
automatically
in
in
case
of
a
of
a
passing
score,
then
it
can
automatically
be
promoted
to
the
next
stage,
maybe
even
production,
or
you
could
also
ask
for
manual
approval,
maybe
in
terms
of
the
pr
that
that
still
has
to
be
approved
by
someone,
because
the
quality
gate
evaluation
was
not
that
good.
But
still,
you
might
want
to
be
want
to
be
able
to
push
this
to
production,
because
maybe
it
was
a
good.
A
A
So
there
are
these
these
two
concepts.
Then
we
can
combine
the
whole
heat
ops
approach
that
will
pull
the
all
the
configuration
that
is
stored
in
versioned
and
controlled
in
git
and
apply
it
to
your
kubernetes
cluster
plus
you
can
orchestrate
the
tests
evaluations,
but
even
more.
It
was
just
an
example,
but
you
can
orchestrate
the
life
cycle
of
your
applications
than
with
captain.
A
So
if
you
are
interested,
I
I
just
put
here
a
couple
of
links
for
for
captain:
it's
a
it's
an
open
source
project.
It's
a
currently!
It's
a
cncf
project
and
we
do
have
quick
starts
tutorials.
Also,
you
can
follow
the
project.
We
always
have
quite
exciting
news
for
new
releases
and
yeah,
I'm
mostly
tweeting
about
also
the
captain
project,
since
I'm
a
maintainer,
but
also
all
things
around
skidops
and
automation.