►
From YouTube: Behind the Scenes of Keptn: Event-Driven Delivery & Ops Orchestration - Andreas Grabner, Dynatrace
Description
Behind the Scenes of Keptn: Event-Driven Delivery & Ops Orchestration - Andreas Grabner, Dynatrace
Speakers: Andreas Grabner
Keptn orchestrates delivery & operational workflows by automatically your DevOps tools (deploy, testing, observability, notifications, configuration management, remediation ...) through events based on CloudEvents. Keptn workflows are declarative, the supporting configuration files are version controlled, and Keptn decides on whether or not to move a workflow further by continuously validating your Service Level Objectives (SLOs). In this session Andreas Grabner, DevRel at Keptn, will do a deep dive on the latest version of Keptn. He will explain the event-driven architecture, the recent separation of control and execution plane introduced with Keptn 0.8, and will give you guidance on how to best get started for integrating Keptn into your existing delivery tools and processes to automate tasks around quality gates, performance & chaos engineering, delivery or auto-remediation.
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
I
am
a
deaf
real
for
the
open
source
project
captain
and
I
would
like
to
give
you
a
little
bit
of
insight
today
on
what
captain
is
all
about.
Looking
behind
the
scenes
on
the
new
approach
that
we
take
with
captain
when
it
comes
to
delivery
and
operations,
automation
is
specifically
supporting
devops
initiatives.
A
A
Also,
a
lot
more
information
about
captain
the
open
source
project,
cncf
sandbox
project,
where
you
know,
if
you're
interested,
follow
us
on
twitter
check
out
the
git
repository,
also
join
the
slack
conversation
or
stars
on
github
right
and
better
the
bigger
the
community
the
easier
it
is
also
for
us
to
move
towards
an
incubation
project
status
with
the
cmf
foundation.
All
right
now,
let's
get
into
the
into
the
details.
A
So
one
of
the
things,
the
reason
why
we're
building
captain
is
because
we
know
that
devops
and
sres
have
to
automate
a
lot
of
tasks
in
the
pipelines.
You
know.
Traditionally,
when
I
started
with
automation,
we
looked
at
a
lot
of
ci
tools
to
to
do
some
unit
testing
some
building,
and
then
we
kind
of
used
these
tools
to
do
more
and
more.
A
You
see
the
list
here,
so
there's
a
lot
of
things
that
our
organizations
want
us
to
automate
in
order
to
speed
up
delivery,
especially
as
we're
moving
to
more
modern
architectures.
Now,
there's
clearly,
no
shortage
of
do-it-yourself
swiss
army
knife
tools,
there's
a
lot
of
great
tools
out
there
in
the
cd
space,
for
instance.
If
you
look
at
jenkins
right,
I
can
use
jenkins
to
do
everything
and
I
can
execute
my
tests.
I
can
put
some
code
in
to
analyze
my
test
results,
whether
it's
a
functional
test
or
performance
test.
A
So
I'm
sure
there's
a
plug-in
out
there.
You
can
add
your
notifications
right
if
you
are
want
to
push
information
to
slack
or
whatever
your
chat
ups
tool.
Is
you
can
do
that
easily?
You
can
integrate
with
your
apm
tool
with
your
observability
tool,
because
I'm
sure
these
tools
have
their
own
plugins,
where
you
just
call
their
apis.
A
A
But
the
thing
is,
if
you
end
up
with
a
pipeline
like
him,
where
a
simple
pipeline
that
is
deploying
a
new
container
into
a
cluster,
then
running
some
gmeter
tests
and
then
parsing
the
results,
and
if
this
script
is
more
than
a
thousand
lines
long
longer
than
maybe
the
micro
service
that
it
deploys,
then
obviously
something
is
wrong.
I
also
see
a
lot
of
people
are
not
following.
You
know:
engineering
best
practices
of
good
code,
refactoring
good
modalization,
so
you
quickly
end
up
with
things
that
are
very
hard
to
maintain.
A
Now.
The
other
thing
is
talking
about
engineering
best
practices
hard
to
maintain
refactoring,
repurposing
content,
details
from
dynatrace
and
at
dynatrace
they
are
moving
from
individual
from
let's
say
for
more
like
the
monolithic
architecture
to
microservices,
and
obviously
they
have
used
jenkins
as
their
tool
of
choice
start
with
a
microservice
building
a
pipeline
for
it.
Taking
that
pipeline,
making
slight
modifications
for
the
next
service
and
with
this
onboarding
more
and
more
pipelines
which,
in
the
end,
ended
up
in
the
snowflake
effect,
so
what
they
actually
did.
A
So
this
is
a
problem
that
we
want
to
solve,
because
this
this
doesn't
scale,
especially
as
more
and
more
organizations
need
to
build
the
same
type
of
automation.
So
this
is
why
I
want
to
introduce
it
to
captain
and
give
you
a
little
behind
the
scenes,
look
on
what
drove
us
to
the
architecture
and
how
it
works.
A
So,
first
of
all,
we
looked
at
these
automation
pipelines
that
we
see
out
there
right
now,
where
everything
is
kind
of
in
one
big
file
in
one
big
pipeline
file
or
script
or
whatever
it
is
meaning
the
process.
The
tool
integrations,
and
even
some
configuration
like
you
saw
earlier
from
the
screenshot
from
christian.
Everything
is
in
one
big
file.
So
what
we
said
this
is
something
we
need
to
change.
We
need
to
get
rid
of
these
dependencies.
A
A
A
I
have
this
artifact
that
needs
to
be
deployed
in
the
dev
stage
and
have
some
additional
metadata,
like
whoever
defined
that
process.
They
want
to
do
a
blue
green
strategy.
So
now
you
can
have
one
or
multiple
capabilities
on
the
right
side
that
are
subscribing
to
these
events.
It
could
be
a
jenkins
pipeline
that
you
use
to
deploy.
It.
Could
be
a
gitlab
pipeline,
it
could
be
techton,
it
could
be
just
a
python
script,
whatever
you
have
or
a
helm
chart.
So
that
means
you
can
have
capabilities
that
are
subscribing
to
these
events.
A
Doing
that
particular
task
additionally
reach
out
to
the
git
repository
to
access
additional
config
files
like
helm,
charts
that
is
needed
to
exit
then
do
the
deployment
once
it's
done
sends
back
the
event
to
captain
that
either
everything
is
good
or
something
failed
and
based
on
that
makes
a
decision
to
move
forward.
So
really
from
a
captain
perspective-
and
you
will
hear
this
later
and
see
this-
we
have
a
shipyard
that
really
defines
sequences
of
tasks
per
stage
that
you
want
to
automate.
A
We
then
have
the
captain
uniform,
which
are
basically
the
list
of
subscribed
kept
services.
This
is
how
we
call
them.
So
these
are
the
actual
tool
integrations,
but
they
are
subscribed
to
events.
So
that
means
you
can
easily
repurpose
it.
There's
no
hard-coded
integration
into
the
process
itself,
but
it's
through
an
event
subscription.
We
have
the
configuration
and
git,
as
I
mentioned,
and
we're
using
events,
but
not
just
any
events.
We're
using
cloud
events
we're
basing
all
this
based
on
the
cloud
event
standard.
A
You
can
look
at
captain
and
easily
use
the
declarative
approach
to
say
I
want
to
automate
this
sequence
of
tasks
and
then,
through
event
subscription.
You
can
say
which
tools
should
handle
it.
Now,
some
stats
on
the
right
side,
we've
seen
ninety
percent
less
the
donation
code.
Captain
has
been
built,
as
you
explained
earlier,
on
the
concept
of
separation
of
concerns,
process
tool
and
configuration
has
changed.
Config
is
also
in
git.
Now.
Slos
is
a
very
big
topic.
I
will
come
this
later,
but
slos
are
built
in.
A
That
means
where
captain
can
evaluate,
after
every
step,
if
you're
still
meeting
your
quality
criteria
based
on
service
level
objectives
and
then
decide
whether
the
process
should
go
forward.
Most
importantly,
captain
doesn't
replace
any
of
your
tools.
It
connects
the
tools
it
avoids.
Your
needs
to
build
automation,
to
connect
the
tools
and
chain
them
together
in
the
automation
sequence,
that
you
need
all
right.
That
means
whatever
tool
you
have
keep
those
tools,
whether
it's
a
jenkins,
a
gitlab,
a
harness,
an
octal
whatever
it
is,
keep
it.
A
But
if
you
want
to
add
additional
automation,
steps
like
reaching
out
to
your
monitoring
tool
for
slo
configuration,
automating
performance
test
execution,
sending
out
notifications,
use
captain
use
the
declarative
approach.
Captain
orchestrates
these
tasks,
for
you
now
quick
word
on
shipyard,
we'll
see
this
later
in
my
live
demo
as
well
sheet,
but
it's
the
key
concept
where
you
actually
specify
the
automation
sequences
that
you
want
captain
to
orchestrate
for
you,
so
you
can
have
sequences
within
each
stage.
You
can
have
multiple
stages
within
a
stage.
A
You
have
sequences
like
here's,
the
testing
sequence,
and
you
can
see
here
there's
some
tasks
in
there
that
are
executed.
You
will
see
this
also
later
in
my
demo.
In
the
ui
we
call
the
ui.
The
captain
bridge
interesting
is
so
captain
sends
events
internally.
So
when
I
kick
off
this
particular
sequence,
when
I
say
captain
please
trigger
the
testing
sequence,
then
captain
starts
sending
the
individual
events
to
triggered
individual
tasks
like
actually
running
a
test
with
the
additional
metadata
from
the
sheet
that
file
like
a
functional
dish
to
be
executed.
Now.
A
The
reason
why
I
highlight
this
here,
because
this
is
a
very
cool
concept,
so
you
specify
your
automation
sequences
and
you
can
also
chain
them
together
through
the
triggered
on
option
here,
so
you
can
do
conditional
chaining
of
events
or
of
sequences
as
we
call
them.
That
means
in
case
the
testing
sequence
finishes
with
the
result
passed
in
this
case,
the
performance
light
sequence
will
trigger,
which
will
then
you
know,
maybe
trigger
some
additional
performance
tests
and
you
can
also
trigger
them
across
stages
right.
So
this
is
a
really
cool
thing.
A
On
on
on
our
shipyard
concept,
you
specify
sequences
sequences,
contain
tasks.
They
will
then
through
events
triggered
individual
tools
and
they
can.
They
can
all
be
chained
together.
Very
important
like
how
does
this
really
work?
I
know
a
lot
of
people
are
asking
us
what
tools
are
supported.
How
do
I
get
in
my
own
tool?
We
have
a
set
of
tools
that
we
have
already
built
so
called
captain
services,
for
you
can
find
them
on
the
github
repository.
You
can
also
build
your
own.
A
A
A
It
will
also
then
receive
additional
metadata
that
is
specified
in
the
shipyard
file,
so
your
tool
actually
knows
what
additional
thing
we
should
consider
now.
This
will
then
trigger
the
actual
tool
in
this
case
gmeter.
It
could
also
be
if
you
build
an
integration,
let's
say
with
a
modification
tool
like
slack
you
could,
then
you
know
make
a
call
to
that
particular
tool.
Now
one
thing
that
is
important
because
everything
happens,
obviously
event
driven
and
a
lot
of
things
are
asynchronous.
A
A
A
Another
very
key
concept-
and
I
want
to
show
you
this
again
in
more
detail-
is
slos.
I
mentioned
that
captain
is
using
service
level
objectives
for
making
data-driven
decisions.
That
means
you
have
the
opportunity
to
add
the
so-called
evaluation
task
into
any
of
your
sequences
at
any
particular
point
in
time
of
your
automation
sequence.
Whenever
you
want
captain
to
reach
out
to
your
observability
platform,
to
figure
out,
how
is
your
system
doing?
How
are
certain
tasks?
How
is
it
metrics
doing
now
the
way
this
works?
A
We
have
a
another
captain
service.
We
call
it
the
lighthouse
service
that
is
there.
They
will
retrieve
slis
and
compare
them
against
your
solos.
Now
you
can
actually
specify
your
slos
service
level
objectives
on
which
means
what
type
of
metrics,
what
type
of
sli
is
like
error
rate
jvm
memory
count
db.
This
can
be
any
type
of
metrics
that
you
can
pull
in
from
your
observability
platform
from
your
testing
tool
that
provides
it
as
a
result.
So
you
specify
what
are
the
objectives?
A
A
If
you
want
to
learn
more,
but
what's
important
here
is
the
also
the
the
concept
of
the
separation
of
concerns
again
on
the
ones
that
you
have
slos.
What
are
the
objectives
on
the
other
side?
Is
you
need
to
figure
out?
How
do
I
get
the
data,
and
this
is
where
our
sli
providers
come
in,
so
captain
supports
multiple
data
sources.
We
call
them
sli
providers,
they
all
again
come
in
through
events,
every
sli
provider
that
you
want
to
hook
up
to.
A
Captain
therefore
also
has
its
own
configuration
on
how
to
actually
retrieve
these
metrics
right.
It
could
be
that
using
prometheus,
and
here
are
the
queries
that
then
are
executed
against
promptql.
To
query
this
particular
data
or
if
you're,
using
a
tool
like
diamond
trace
here,
are
the
dyna
choice
queue
languages?
The
nice
thing
about
this?
Is
you
have
a
nice
separation
of
concerns?
You
have
somebody
in
your
organization
that
can
define
the
queries.
A
Those
are
the
experts
on
your
observability
platform
and
then
the
users
of
it
that
want
to
enforce
slos
can
just
define
their
slos
the
criteria
without
having
to
become
expert
in
your
stability
platform.
Now
how
this
works
right,
the
lighthouse
basically
says
I
need
this
type
of
data
based
on
the
slos.
A
Through
events
reaches
out
to
the
providers,
they
get
the
data
from
the
external
tool,
pull
it
back
to
the
lighthouse
service
and
then
the
lighthouse
service
does
all
the
evaluation
based
on
the
pairs
and
warning
criteria
and
then,
in
the
end
calculates
a
total
score
that
is
then
used
to
make
a
decision
on
whether
we
should
stop
the
process
or
not
really
powerful.
Another
thing
behind
the
scenes.
This
was
brought
in
with
an
architectural
change
with
captain
0.8
multi-cluster
support.
A
This
was
a
big
thing,
so
you
now
can
install
the
captain
control
plane,
the
heart
of
captain,
the
shipyard
controller,
the
lighthouse
service,
the
configuration
service
and
whatever
services
you
want
to
have
centrally
available
for
all
of
your
projects
or
just
centrally
on
that
same
cluster.
But
what
we've
also
now
allow
you
to
do
is
you
can
now
install
the
captain
services
that
then
do
a
particular
task
like
executing
a
test
deploying
two
different
machines
to
different
servers
to
different
stages.
A
So,
for
instance,
you
could
have
right,
as
you
see
here
in
the
example
the
helm
service
in
pre-prod,
but
also
improv
on
a
different
cluster.
You
may
have
a
particular
pre-prod
staging
environment
where
you
have
a
different
testing
service
like
the
new
load
service
as
compared
to
the
dev
environment.
A
So
that's
the
cool
thing
you
can
you
can
you
can
install
these
captain
services
now
in
different
environments?
Maybe
behind
the
firewall
or
just
you
know,
wherever
you
need
to
have
them
based
on
the
way
you
structure
your
stages
and
the
way
this
works
is
these
execution
plane
services
are
polling,
the
captain
api
and
simply
ask
hey.
Is
there
something
for
me
to
do
yes
or
no?
Now
the
nice
thing
is.
The
execution
plan
is
not
limited
to
kubernetes.
The
control
plane,
yes,
needs
to
run
on
kubernetes,
but
these
execution
planes.
A
These
are
just
the
captain
services
itself
that
paul
the
api
can
literally,
you
know,
run
where
wherever
they
you
want
them
to
run
all
right.
Multi-Cluster
support
also
allows
some
really
interesting
features
for
delivery.
This
was
heavily
driven
by
some
of
our
early
adopters,
where
they
said
we
need
to
have
multi-stage
parallel
deployment
into
different
environments.
A
A
You
can
automatically
have
captain
roll
out
or
execute
sequences
that
deploy
an
app
on
gk,
eks,
aks
and
wherever
at
the
same
time,
and
then
always
triggering
the
right
execution
plan
that
is
installed
then
listening
for
these
type
of
events,
all
right
enough
with
the
words
with
the
slides,
let's
see
and
explore
it
in
action.
Let
me
switch
over
to
my
browser
okay,
so
I
have
a
captain
installation
here.
Let
me
just
zoom
in
a
little
bit
bigger,
I
run
my
captain
actually
on
k3s
so
keys,
you
can
install
captain.
A
As
I
said
on
any
type
of
kubernetes
cluster,
I
decided
to
use
k3s.
I
have
also
a
tutorial
that
is
automatically
then
installing
a
couple
of
these
projects.
Here
now
before
I
go
into
too
much
details,
let
me
show
you
one
thing:
let's
focus
on
the
demo
delivery
and
I'm
opening
up
this
here.
So
what
I
have
in
the
demo
delivery-
I
have
a
three-stage
environment,
dev,
staging
and
production,
and
on
this
particular
project
I
have
a
service
called
the
simple
service
right.
A
A
I
also
have
our
automation
sequence
overview,
so
here
I
can
actually
see
what
is
captain
currently
doing
right,
what's
happening
in
depth,
what's
happening
in
staging
and
also
what's
happening
in
production?
Where
is
it
maybe
currently
stuck?
Where
is
it
waiting
on
things?
Now,
let
me
go
back
to
this
dev
staging
and
prod.
A
If
you
want
to
set
up
a
project
like
this,
like
the
demo
delivery,
then
initially
remember
we
have
this
concept
of
a
shipyard
file.
So
let
me
open
up
this
upstream
git,
because
captain
internally
holds
a
git
repository,
but
you
can
then
specify
an
upstream
kit.
This
could
be.
Github
could
be
a
bit
buck.
It
could
be
whatever
git
you
have.
I
have
decided
to
use
gitti
here.
A
So
this
here,
basically,
is
the
git
project
that
captain
holds
internally
for
my
demo
delivery
project
and
on
the
main
branch
I
have
my
shipyard
file.
This
is
the
shipyard
file
that
I
have
initially
specified
and
and
like
nice
thing
is,
I
can
change
this,
so
I
can
add
new
sequences
at
any
point
in
time,
but
you
see
here
really.
This
is
the
whole
definition
of
my
automation.
Sequence
is
like
this.
A
It
is
72
lines
long,
which
means
three
stage:
delivery
with
direct
deployments,
blue
green
deployments,
automated
rollbacks,
it's
just
that
the
definition
of
the
process,
so
I
have
a
delivery
sequence
that
starts
with
the
deployment
with
some
testing
with
an
evaluation.
Remember
the
sli
and
slos,
with
an
additional
release:
option
where
I
can.
You
know,
notify
somebody
that
hey
there's
a
release.
A
Do
you
really
want
to
prove
it
or
do
you
want
to
know
something,
and
then
we
actually
even
have
an
approval
process
where
I
can
have
a
human
being
or
also
to
an
api
say:
do
you
want
to
approve
this
based
on
the
evaluation
results?
And
here
I've
actually
specified
the
approval
should
happen
automatically
in
case
the
evaluation
results
in
password
and
warning,
and
then
you
can
see
here.
A
I
have
my
staging
stage
and
in
here
again
I
have
a
delivery
sequence
that
I
say
I
want
to
trigger
it
on
when
dev
delivery
is
finished.
Here
I
have
some
different
tasks.
I
have
monaco.
This
is
where
I
automatically
let
a
task
execute
that
can
do
monitoring
configuration
for
me
so
making
sure
my
prometheus
is
properly
set
up.
Well,
my
dynamics
is
probably
configured
and
then
it
goes
on
and
on
and
on
and
in
staging
you
can
see
here.
A
I
also
have
an
approval
process
where
I
say
I
always
want
to
have
a
manual
approval
before
it
goes
into
production
all
right.
So
this
is
this.
Is
this
here,
so
let
me
just
go
back
quickly
to
show
you
demo
delivery
right.
If
you
saw
this
earlier
everything
you
see
here,
the
three
stages,
dev
staging
and
prod.
A
This
everything
was
just
the
process,
the
definition
behind
that
that
is
happening.
Now,
where
are
the
tools?
Remember
what
I
talked?
What
I
told
you
about
the
tools?
There's!
No
tool
definition
in
my
process
definition-
this
all
happens
through
events.
Now,
where
can
I
look
at
events?
I
can
look
at
the
so-called
sequences
here
right.
If
I
go
back
to
dev,
remember
I
had
a
delivery
sequence
and
in
that
delivery
sequence
I
started
with
a
deployment
test
evaluation.
A
I
am
triggering
the
deployment
and
here's
some
additional
information
that
I
got
from
the
user,
for
instance,
which
docker
container
should
be
deployed,
and
this
is
then
passed
on
to
any
tool
that
is
subscribing
to
the
events.
In
my
case,
I'm
using
helm
so
helm
that
is
listening
and
subscribing
to
this
event
says
hey.
I
think
I
can
do
it
I'm
responsible
for
this
stage.
A
Therefore,
it
sends
back
deployment
started,
it
does
the
deployment
and
when
it's
done
it
is
sending
a
deployment
finished
event
with
additional
information
like
hey,
it
did
a
direct
deployment
and
here
is
the
deploy
uri,
and
here
is
the
public
api
public
uri,
some
additional
information.
This
information
is
then
taken
and
also
passed
to
the
next
sequence.
So,
for
instance,
the
next
step
was
testing,
so
captain
triggers
an
event
and
says
hey.
A
A
Well,
let
me
go
back
to
the
git
repository
remember
this
is
my
demo
delivery
git
repository
I'm
here
in
the
main
branch,
but
what
captain
automatically
does
it
creates
a
branch
for
every
stage
and
in
that
one
we
are
our
convention?
Is
you
have
a
subfolder
for
your
service,
so
approach?
You
can
have
multiple
micro
services
or
applications
whatever
you
want
to
call
them,
and
then
here
you
can
then
upload.
The
two
specific
files
like
here
are
all
my
helm
charts.
Now
you
may
wonder
so
where,
where
are
the
cheat
meter
scripts?
A
Well,
the
good
news
is,
we
also
have
an
inheritance
option.
So
if
I
go
back
to
the
main
branch,
I
have
some
global
jmeter
files
here.
That
means
you
can
actually
put
config
files
either
on
a
project
level
on
a
stage
level
or
on
a
service
level.
First
stage,
so
you're
really
flexible.
You
also,
you
know
it
allows
you
to
really
inherit
files
from
or
defined
in
project
level,
project,
white
stage,
light
or
service
right
now.
Last
thing
I
want
to
show
you
because
you
may
wonder
so
andy.
A
You
talked
a
lot
about
slis
and,
as
slows,
where
is
this
all
happening,
I'm
clicking
to
the
staging
environment
now,
because
in
staging
I
actually
have
an
evaluation
here
after
test
that
produced
some
result.
The
concept
is
the
same
right.
We
got
an
event
and
then
the
lighthouse
service
is
kicking
in
with
started
and
finished.
A
Now
the
question
is
okay:
what
are
the
results?
So
we
have
a
special
visualization
of
all
of
these
results.
These
results,
or
these
data
points
have
been
pulled
out
automatically
from
my
monitoring
tool.
The
only
thing
I
had
to
specify
is
remember
the
slis
and
dslos,
and
you
can
specify
them
either
as
yamls
again.
They
are
stored
in
the
git
repository
where
we
also
have
an
option,
depending
on
your
monitoring
tool,
with
some
some
specific
integrations,
so
instance
with
dynatrace.
A
Obviously
a
day
I
work
at
dynatrace
with
an
integration
where
the
only
thing
you
need
to
do
is
you
need
to
build
a
dashboard.
You
put
a
couple
of
metrics
on
it
and
then
this
will
automatically
be
analyzed
for
you,
but
this
is
specific
to
that
particular
tool
yeah.
So
last
but
not
least,
let
me
just
quickly
still
show
you
if
I
go
to
staging
and
obviously
I
want
to
be
in
skill
staging
and
I
go
into
my
simple
node.
A
The
only
thing
you
really
need
to
do.
If
you
want
to
use
this,
you
have
to
specify
what
type
of
tasks
you
want
to
automate
and
then
you
provide
the
config
duration
files
for
the
individual
tools,
but
there's
no
hard
coding
anymore.
Captain
takes
care
of
all
the
integration
for
the
events,
and
captain
also
takes
care
of
managing
that
process.
A
Last
but
not
least
before
I
click
go
back
and
final
and
finish,
how
do
you
interact
with
captain
there's
a
captain
cli,
so
I
could
for
instance,
say
I
want
to
trigger
a
new
delivery,
so
I
can
say:
captain
trigger
the
delivery
sequence
in
a
particular
project
for
a
particular
space
stage
for
a
service,
and
then
you
can
add
additional
metadata.
Like
you
may
have
wondered:
where
did
the
the
the
container
image
earlier
came
from
so
now?
I
just
said
I
for
the
demo
delivery
project
right,
which
is
there
we
go
demo
delivery.
A
I
now
just
kicked
off
a
new
process.
It's
now
starting
in
depth,
and
it's
not
going
through
the
whole
thing
again,
so
I
can
kick
it
off
through
the
cli
or
I
can
also
kick
it
off
through
the
api.
This
is
typically
the
way
how
you
would
use
captain
and
integrate
it
with
your
existing
tool.
Let's
say
you
use
jenkins
for
your
ci
or
you
use
tekton
for
for
building,
and
then
you
can
kick
off
a
automation
sequence
in
captain,
so
you
have
the
option
to
post
an
event.
A
Just
as
I
did
here
and
then
just
say,
this
is
kept.
What
I
want
you
to
do,
there's
also
some
other
cool
api
endpoints,
where
you
can
access
the
configuration
service,
which
means
all
the
git
repository
behind
the
scenes,
excess
statistics
and
so
on
and
so
forth.
All
right!
Hopefully
you
you
like
what
you
see
there's
a
lot
of
cool
things.
I
also
encourage
you
to
look
at
some
of
the
tutorials
with
out
there.
A
One
that
I
have
is
with
argo
rollouts,
where
I
am
using
the
same
app
that
I
had,
but
with
canary
deployments,
so
so
check
it
out
also
with
some
additional
slis
and
sms,
and
so
on.
Okay,
let's
go
back
and
and
kind
of
finish,
so
I
hope
you
have
seen
captain
so
captain,
I
believe,
is
a
really
cool
opportunity
for
you
to
pick
the
use
case
that
you
need
to
automate
in
your
organization
and
it
ranges
from
something
simple
as
just
the
evaluation
you
can
also
do
test
and
evaluation.
A
You
can
do
delivery,
you
can
do
chaos
engineering,
you
can
do
all
the
remediation.
I
even
haven't
covered
this
use
case,
so
you
can
also
automate
tasks
in
production
like
receiving
an
event
from
your
alerting
tool
and
then
triggering
all
the
remediation
actions
bring
the
configuration
for
the
use
case.
You
saw
this
bring
the
individual
tools,
they
slice
the
slos,
the
run
books.
The
shipyard,
most
importantly,
connect
to
your
tools.
If
we
haven't
yet
already
built
an
integration
for
your
tool,
then
it's
easy
to
build
your
own
captain.
A
A
Automation
and
we've
also
received
some
nice
words
from
folks
like
karash,
who
is
a
software
engineer
at
facebook,
and-
and
I
think
this
is
the
best
quote
you
can
ever
get
captain
feels
like
a
reference
implementation
of
google
site,
reliability,
engineering
and
the
site.
Reliability
workbook
thanks
for
that.
So
if
you
want
to
get
started,
go
to
tutorials
captain.ch,
we
have
a
couple
of
tutorials
out
there
just
or
go
to
the
docs
go
to
the
slag
channel.
Join
us.
A
A
A
A
A
And
I'm
just
answering
some
more
questions
that
I
can
see
here
on
the
q
and
a
fruity
you're
asking
about
what
is
the
process
of
integrating
with
services
which
are
not
currently
using
cloud.
Events
pull
the
data
from
the
captain
api
if
or
pull
the
events
from
the
captain
api
we're
also
working
with
the
cdf
not
to
standardize
our
cloud
events,
but
in
general
you
can
pull
the
captain
api
and
ask
captain:
are
there
any
events
that
need
to
be
handled?
A
You
can
then
filter
it
on
project
services
and
stages,
meaning
you
can
say
you
have
a
service
that
is
acting
or
wants
to
act
on
a
certain
task
in
a
particular
environment.
So
you
can
pull
the
captain
api
and
when
you
think
this
is
an
event
that
you
want
to
handle
then
pass
it
on
to
your
tool.
Let
kept
know
about
it
and
then
once
you're
done
send
it
back.
We
are
currently
implementing
some
other,
let's
say
interesting,
hopefully,
tools
or
extensions.
A
There's
a
generic
executor
service
already,
where
you
can
just
execute
a
python
script,
a
shell
script
or
an
hdb
web
hook,
there's
also
native
web
hook.
Support
coming
and
there's
also
one
project
where
you
can
just
deploy
a
a
container,
basically
as
part
of
reacting
to
an
event
or
a
particular
task
bruno
is
asking:
is
there
any
plans
to
offer
captain
as
a
service?
Could
it
be
replacement
for
full-fledged
cicd
tools?
So
captain
really
aims
to
automate
to
help
you
with
automation,
around
delivery
and
also
operations.
A
A
I
think
we
see
us
integrating
a
lot
with
these
tools
like
circle,
ci
and
jenkins.
You
know
for
some
use
cases,
I'm
pretty
sure
you
could
even
go
just
with
captain
what
captain
provides,
but
I
see
us
more
as
the
the
the
connect
and
the
orchestrator
is
there
a
plan
to
offer
captain
as
a
service.
We
currently
bring
a
steiner
trace
from
a
commercial
side.
We
are
bringing
in
some
parts
of
captain,
especially
the
quality
gate,
into
our
commercial,
offering
as
a
service,
and
maybe
in
the
future.
A
A
A
This
is
why
we,
our
aim,
is
not
to
replace
tools,
but
what
I
always
say,
friends,
don't,
like
friends,
build
their
own
cloud
automation
because,
as
you've
saw
from
some
of
my
examples
earlier,
of
course,
you
can
build
all
type
of
automation,
all
the
logic
and
all
the
tooling
integrations
yourself,
but
this
is
really
what
you
want
to
do.
This
is
really
your
job
or
is
your
job
just
helping
your
organization
getting
better
business
features
out,
and
so,
let's
use
some
open
standards
and
better
approaches
to
define
automation.
A
Let's
learn
from
google
liability
engineering
to
bring
in
slo
evaluations
as
every
step
along
the
way.
Let's
use
open
events
like
cloud
events
to
connect
tools,
so
our
hope
in
the
future
is
that
more
tools
will
support
these
cloud
events
out
of
the
box,
so
the
need
for
building
integrations
will
also
you
know.
Go
away
is
kept
an
alternative
to
spinnaker.
We
actually
have
people
that
integrate
captain
with
spinnaker.
A
So
captain
itself,
as
I
said
when
you
talk
about
deployment
captain-
is
orchestrating
the
deployment,
the
testing
and
the
evaluation.
The
question
is:
what
do
you
use
for
deployment?
You
can
use
our
helm
service
that
comes
with
captain.
You
can
call
it
jenkins
pipeline.
You
can
call
any
other
script.
That
does
the
deployment
or
you
can
call
spinnaker
and
say:
hey
spinnaker,
you
do
the
deployment,
you
can
also
revert
it,
and
this
is
one
thing:
we've
seen
people
using
spinnaker
for
deployment
and
then
for
the
evaluation
for
their
calendar.
A
Pulling
the
metrics
and
evaluating
your
canaries
then
use
captain
for
the
the
capability
that
captain
has
for
slos.
So
in
the
end,
it's
it.
I
think
the
nice
thing
is,
you
can
decide
which
tools
you
want
to
have
in
your
tool
belt
and
how
to
connect
them.
So
yes,
for
certain
use
cases,
I'm
sure
you
can
go
with
captain
what
comes
with
captain
out
of
the
box,
but
in
the
end
you
need
to
figure
out
what's
the
best
tool
for
a
particular
task
and
then
use
captain
to
connect
the
dots
and
chain
them
together.
A
And,
as
I
said,
we've
we've
seen
we
have
some
users
that
have
that
are
using
spinnaker
in
combination
with
captain.
We've
also
have
an
argo
rollout
integration
already,
so
an
argo
rollout
service
where
captain
can
use
algorithm
for
the
canary
rollout
and
then
between
the
rollouts
is
using
the
slo
capability.
It's
also
part
of
the
tutorial
that
I've
put
out
there,
which
includes
argo
rollout
by
the
way.
A
A
Yeah
we'll
see
what
happens
tonight.
I'm
actually
a
little
disappointed
about
spain,
but
I
guess
I
was
expecting
a
little
bit
more
from
them.
I
am
from
austria
and
I
am
very
excited
that
we
made
it
to
the
next
round
unexpected
but
happy,
even
though
the
italians
will
kick
our
ass
on
saturday,
but
that's.