►
From YouTube: OpsMx Workshop - Spinnaker: Source to Production wi... Nirmalaya Sen, Robert Boule & Gopinath Rebela
Description
OpsMx Workshop - Spinnaker: Source to Production with Rollout Strategies - Nirmalaya Sen, Robert Boule & Gopinath Rebela, OpsMx
In this workshop, you will learn how to use Spinnaker to automate the whole process from code check-in to git to all the way to deploy to your production system. You will learn how you can deploy to different cloud environments - Kubernetes, AWS. You will learn how you can integrate your CI systems (Jenkins in this case) to build your artifacts. Finally, deploy them through the stage to production with approval controls and only have authorized people to deploy to production. And you will also learn how you can leverage Spinnaker to roll back your deployment if the new release does not work as expected.
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
All
right
everybody
I
want
to
first
thank
everyone
for
joining
us
at
this
workshop
spinnaker
source
to
production
with
rollout
strategies.
My
name
is
bob
boulay,
I'm
the
head
of
solution
engineering
here
at
at
ops
and
I'm
joined
by
normalia
and
gopi.
We'll
do
some
formal
introductions.
You
know
before
we
dive
into
the
the
workshop
at
large,
but
again,
thank
I
want
to
thank
everyone
for
joining
the
band-aid.
A
I
want
to
rip
off
right
now
is
in
the
event
that
those
of
you
that
don't
know
what
opsamex
does
we'll
go
ahead
and
just
throw
that
in
there
real,
quick
and
then
we
can
get
on
with
the
workshop
proper.
Our
mission
is
to
deliver
software
without
human
intervention.
We
are
a
a
company
that
obviously
provides
you
know
not
only
support,
but
also
a
stack
on
top
of
spinnaker,
a
layer
of
intelligence.
A
If
you
will
that
helps
as
you
go
down
the
path
of
looking
to
create
decision
gates,
to
create
continuous
verification
gates
to
ultimately
go
ahead
and
actually
deliver
software,
while
collecting
data
from
other
tools
in
your
tool
chain
and
ultimately
making
that
data
actionable
as
part
of
your
spinnaker
pipeline
process,
and
so
we're
we're
really
happy
to
be
here
today.
You
know
obviously-
and
we
wanted
to
just
tell
you
a
quick
little
background
on
sort
of
what
it
is
that
we
do
for
those
of
you
that
might
not
be
familiar
with
us.
A
Today's
agenda,
you
know,
I
think
we
want
to
walk
through
leveraging
spinnaker
in
a
source
to
production
scenario
right,
so
you're,
going
to
see
pipelines
that
ultimately
are
triggered
from
a
source
code
repository
and
ultimately
being
able
to
leverage
various
types
of
deployment
strategies.
You
know
whether
that
be
a
canary
or
a
red
black
type
of
deployment.
You
know
gating
deployments
and
automating
rollbacks
based
on
tests.
A
You
know:
we've
got
a
number
of
pipelines
that
we're
looking
forward
to
walking
through
walking
you
through
and
ultimately
showing
you
sort
of
what
we've
picked
up
in
our
experience
as
we
work
with
customers
to
ultimately
go
ahead,
and
you
know
sort
of
generate
the
types
of
complex
deployment
strategies
that
they're
looking
for
in
connection
with
their
spinnaker
deployments,
and
so
it's
really
something
that
this
was
an
easy
thing
to
sign
up
for,
because
it's
something
that
we're
very,
very
passionate
about.
We've
got
some
bonus
material.
A
You
know
we'll
sort
of
deliver
what
we
had
planned
and
then
some
bonus
material
depending
on
sort
of
how
the
time
goes
with.
You
know
a
canary
deployment
to
app
engine
and,
ultimately,
you
know
sort
of
showing
you
that
sort
of
source
to
broad
piece
and
then
ultimately,
I've
got
a
pipeline
that
I
know
that
I've
used
with
customers
around
aws,
app
mesh
and
we've
got
a
review
of
those
moving
parts.
A
So
who
are
we
I
mentioned
earlier?
My
name
is
bob
boulay.
I
am
the
head
of
solution
engineering
here
with
ops,
mx
I've
got.
You
know
previous
experience
previous
time
with
companies
like
time
scale
db
a
time
series
database
along
with
those
of
you
that
may
know
black
duck
software.
I
spent
quite
a
bit
of
time
with
blackduck
and
subsequently
synopsis
as
they
acquired
us.
Let
me
bounce
it
over
to
normalia.
Maybe
tomorrow
you
could
give
a
quick
intro.
B
C
And
gopi
rebala,
I'm
the
cto
of
ops
mix.
We've
been
providing
cd
solutions
for
few
years
now,
privately
based
on
spinnaker,
and
he
made
before
that.
We
worked
with
some
large
companies
and
startups
and
did
some
major
transformations
from
on-prem
software
to
cloud
with
microservices
and
we
are
very
passionate
about
delivering
software
without
human
intervention.
Although
that's
the
vision,
we
are
moving
towards
that.
A
Excellent
excellent,
all
right
guys
now
that
you
sort
of
know
who
we
are:
let's
go
ahead
and
jump
in,
and
just
so
you
know,
I'm
gonna,
you
know
start
with
the
first
pipeline
and
then
I'll
be
walking
us
through
this
in
in
sort
of
painstaking
detail,
running
this
pipeline,
introducing
some
errors
so
that
you
can
sort
of
see
when
when
things
need
to
be
rolled
back
sort
of
how
it
works
and
then
I'll
be
transitioning
it
over
to
normalia
who's,
also
prepared
a
pipeline.
That's
that's!
A
You
know
with
you
know,
sort
of
the
triggering
event
and
and
for
us
you
know,
you
know
more
and
more.
We've
been
talking
to
customers
who
are
really
trying
to
make
sure
that
they're
embracing
sort
of
that
git
ops
model
where
they
want
git
to
be
the
single
source
of
truth.
They
want
git
to
sort
of
be
the
center
of
the
universe
and
they
want
it
to
be
able
to
go
ahead
and
trigger.
A
You
know
the
various
pipelines
that
are
required
to
ultimately
go
ahead
and
actually
deliver
the
software
to
production.
Now.
Obviously,
spinnaker
plays
a
critical
role
in
that,
in
terms
of
being
that
delivery
vehicle
being
that
orchestrator
and
ultimately
allowing
you
to
go
ahead
and
actually
leverage
all
the
tools
around
spinnaker
to
sort
of
orchestrate
that,
but
again
obviously
it
starts.
You
know
with
that
code
change
right,
it
starts
with
you
know,
sort
of
what
someone
does
or
what
modification
that
they
make.
A
They
go
ahead
and
actually
submit
that
pull
request.
It's
approved
it's
committed
and
then
the
process
can
start,
and
so,
as
you're
seeing
here,
my
pipeline
starts
off
with
you
know,
basically,
just
a
monitoring,
a
simple
git
repository
now,
those
of
you
that
are
unfamiliar,
you
know
with
spinnaker
in
terms
of
how
that
works.
A
I'm
actually
looking
at
the
master
branch,
and
so
obviously
as
developers
create
their
own
working
branches
and
then
submit
pull
requests.
Those
are
approved
in
some
cases.
There
are
there's
tooling
that
will
go
ahead
and
actually
go
ahead
and
trigger
you
know,
sort
of
code
review
or
you
know,
static
code,
analysis
or
something
along
those
lines,
and
then,
ultimately,
it
gets
approved
and
then
promoted
to
master.
A
I'm
monitoring
that
here,
the
master
branch
of
this
particular
repository
now,
the
one
thing,
the
one
question
that
I
get
quite
a
bit
of
is
hey.
You
know
I
want
to
monitor.
You
know
I'm
using
a
mono
repo
and
I
want
to
monitor
just
a
certain
artifact
or
a
certain
set
of
artifacts.
Well,
we
certainly
can
do
that
as
well.
Right,
I
mean,
obviously
you
know.
A
A
Those
are
the
folks
that
will
actually
make
changes
to
you,
know,
sort
of
the
chart
and
you
know
sort
of
the
software
and
the
way
it's
deployed
and
then
ultimately,
there's
also
the
values.yaml
file
or
the
the
configuration
file
for
this
particular
helm
chart.
That
is
something
that
ultimately
belongs
to
the
operations,
folks
in
a
lot
of
cases
or
the
deployment
folks
or
the
devops
folks
who
actually
want
to
ultimately
deploy
the
software
and
be
able
to
make
those
types
of
changes.
A
And
so
ultimately,
you
know
we
can
go
ahead
and
actually
have
those
separations
of
concerns
as
we
go
through
and
and
do
this,
and
so
you
know,
obviously
I'm
looking
at
this
git
repo
I've
got
my
web
hook
set
up
here
and
then,
ultimately,
if
I
look
at
the
code,
you
know
I've
got
my
values.yaml
here,
that's
all
set
up
and,
as
you
can
see,
this
is
a
helm
chart.
That
is
doing
something
very
simple.
A
A
A
The
next
thing
that
I'm
doing
here
is
I'm
gonna
go
ahead
and
actually
retrieve
the
artifact
that
I
need
here
right.
So
there's
the
google
bucket,
that's
where
the
artifact
from
execution
is
coming
from,
and
then
I'm
ultimately
going
to
use
helm3
as
a
rendering
engine
to
ultimately
distill
a
manifest.
A
That
will
ultimately
be
used
later
in
the
process.
The
next
part
of
this
is
to
ultimately
deploy
this
manifest.
Now
you
know,
I've
got
a
really
rudimentary
setup
here
again,
because
I
use
this.
You
know
to
demo
to
people
and
talk
to
people
about
it
that
don't
have
a
lot
of
spinnaker
experience.
However,
you
know
it
really
does
you
know
sort
of
solve
the
problem
in
that
I'm
going
ahead
and
actually
targeting
a
kubernetes
cluster?
A
Now
the
next
part
of
this
is
in
this
particular
case
here
I've
chosen
to
go
ahead
and
do
a
post,
login
check
or
post
post
deployment
login
check.
So
what
I
want
to
do
in
this
stage
here
is:
I
want
to
make
sure
that
I
can
address
the
database
right.
So
I
have
another
jenkins
job
that'll,
ultimately
go
ahead,
and
actually,
once
this
manifest
is
deployed
and
it's
stable,
it
will
go
ahead
and
actually
do
that
login
check
now.
A
You
know
I
want
to
go
ahead
and
actually
have
this
test
run,
but
you
know
you
note,
I'm
ignoring
the
failure,
so
if
it
fails,
I'm
going
to
ignore
that
only
because
I
want
it
to
go
on
to
the
next
stage
and
what
I'm
doing
here
is
I'm
using
a
spell
expression
to
ultimately
a
conditional
spell
expression
here
to
ultimately
go
ahead
and
actually
process
this
rollout.
If
I
need
it.
So
if
you
look
down
here
at
this,
this
spell
expression.
A
If
it's,
if
the
previous
stage,
the
post
deployed
login
check,
is
in
a
failed
underscore
continue
state,
it
will
go
ahead
and
actually
undo
this
rollout.
It
will
roll
this
back,
because
that
means
I'm
in
a
state
where
I'm
unable
to
log
into
the
database,
and
so
I
want
to
roll
this
back,
and
so
I
can
automate
that
now.
A
One
of
the
things
that
I'll
do
next
is
I'll
actually
trigger
this
pipeline.
So
let's
come
over
here
and
let's
edit
this
file,
and
in
this
case
here
I
want
to
do
an
upgrade.
I
want
to
go
to
postgres
11.7,
so
let's
go
ahead
and
actually
commit
that
change
to
master
that'll
go
ahead
and
commit
that
change
and
as
expected,
my
pipeline
has
started
to
run,
and
so
now
it's
going
out
and
doing
my
jenkins,
build
and
ultimately
waiting
for
that
response.
A
A
A
You
know,
spinnaker
does
a
nice
job
of
giving
you
sort
of
that
visibility,
and
I
can
also
see
inside
the
pod,
you
know
sort
of
what
does
the
log
console
output
look
like
you
know
from
this
particular
perspective,
so
it's
gone
ahead
and
actually
completed
that
step
and
that
that
seems
to
be
up
and
running.
We'll
just
wait
for
that
to
sort
of
stabilize.
A
A
There
we
go,
and
so
it's
gone
ahead
and
done
that
deployment.
It's
completed
the
stabilization
and
as
you'll
notice,
the
post
deployment
login
check,
succeeded
right,
and
so
it
went
ahead
and
actually
skipped
my
rollback
step,
and
so
that
job
succeeded,
and
so
everything
is
working
the
way
it's
supposed
to
now.
If
this
rollout
went
the
way
we
were
hoping
it
was
going
to
go.
I
could
come
over
here
to
my
database
and
let
me
go
ahead
and
actually
make
sure
that
I'm
connected
and
what
I
should
see
is,
and
there
we
go.
A
We
went
from
11.3
to
11.7,
so
I've
now
deployed
the
11.7
version
of
postgres
by
simply
making
those
changes
to
that
values.yaml
and
again,
I
think
it's
it's
very,
very
straightforward
to
ultimately
be
able
to
set
something
like
this
up
now.
This
again
is
a
extremely
simple
example
of
this
right,
extremely
simple.
However,
I
think
it
sort
of
makes
the
point
now.
What
I
want
to
do
actually
is.
A
I
want
to
now
introduce
a
failure
here,
so
you
can
sort
of
see
how
this
pipeline
reacts
when
something
fails,
and
so
for
that
I'm
going
to
go
in
here
and
just
change.
My
post
login
check
job
and
I'm
just
going
to
give
it
the
wrong
password,
so
it
it,
you
know,
simply
won't
be
able
to
log
in,
but
I
mean
to
spinnaker.
This
is
gonna.
Look
like
a
failed
job
step
right,
so
any
number
of
things
could
cause
this
to
happen
right
and
so
and
now
we're
gonna
get
to
see.
A
A
Now
again
we
should
see
it
and
there
it
is.
It
went
ahead
and
actually
triggered
my
pipeline.
So
that's
going
to
start
running,
and
you
know,
like
I
said,
what's
going
to
happen
here-
is
it's
going
to
get
through
all
of
these
phases?
It's
ultimately
going
to
be
able
to
deploy
the
manifest,
but
the
last
phase
here
this
post-deployment
login
check-
is
what's
ultimately
going
to
fail,
based
on
sort
of
what
the
changes
I
made
to
the
jenkins
shop.
But,
of
course
again
anything
could
cause
that
failure.
A
If,
for
some
reason
there
was
a
mistake
in
the
port
that
was
being
used
because
these
things
are
all
sort
of
settable
through
values.yaml,
if
that's
indeed
the
case
that
would
ultimately
trigger
a
failure,
and
so
ultimately
you
know
what
we'll
wind
up
with
is
a
situation
where
we're
going
to
want
to
roll
it
back
and,
as
we
can
see
here
this.
Ultimately
this
build
failed.
A
So
the
attempt
to
go
ahead
and
actually
do
that
particular
scenario
in
terms
of
testing
this
deployment
was
unsuccessful,
and
so
now
the
job
is
in
the
midst
of
sort
of
rolling
back
that
manifest
that
was
rolled
out,
and
so
once
this
stage
completes
what
I'll
be
left
with
is.
I
should
be
left
with
the
exact
same
version
that
that
I
had
previous,
which
is
11.7.
A
It
should
be
taking
that
11.9
rollout
that
was
successful
during
this
phase
here
and
ultimately
now
be
rolling
that
back
to
something
that
that
previous
version
now
again
guys.
This
is
extremely
linear
and
extremely
basic,
but
I
think
you
know
it
also
sort
of
helps.
You
see
some
of
the
capabilities
and
some
of
the
things
that
you
can
do
in
terms
of
being
able
to
sort
of
deploy,
test,
post
deployment
and
then
ultimately
automate.
A
You
know,
sort
of
roll
back
scenarios
as
they're
required
and
again
I
think
you
know
this
is
one
of
those
situations
where
you
know.
If
you
have
a
problem
or
you
have
a
much
more
robust
set
of
tests
that
you're
running
and
you
run
into
a
problem.
You
know
with
this
particular
scenario.
Ultimately,
you
can
sort
of
automate
that
roll
back
if
there's
a
hard
and
fast
rule.
A
A
You
know,
I'm
not
sure
why
that
happened.
I
think
there's
a
problem
with
my
helm
chart,
but
ultimately
you
know
that
rollback
from
that
11.9
should
have
rolled
back
to
my
11.7
and
I
think
I'll
have
to
troubleshoot
that
that
helm
chart
as
to
why
that
happened.
But
I
think
my
problem
is
in
that
code,
but,
as
you
can
see
there
guys,
I
think
you
know
you
can.
Ultimately
again.
A
If
we
were
to
look
at
this,
you
know
I
can
ultimately
do
that
deployment
identify
a
problem
now
talking
for
a
moment
about
sort
of
this
post
login
check
this
post
login
check
can
be
a
number
of
different
things
right,
so
I
can
deploy
this.
I
can
run
a
continuous
verification
step
against
this,
using
something
like
kyenta
or
you
know,
the
ops,
mx,
continuous
verification.
A
That
rollback
is
really
demonstrates,
one
of
the
more
powerful
elements
of
sort
of
spinnaker,
because
any
time
we're
we're
sort
of
deploying
in
a
very
declarative
way
in
terms
of
you
know,
making
sure
that
when
we
go
and
see
a
change
in
git
we're
ultimately
rolling
that
change
out
the
ability
to
have
that
check,
or
this
you
know,
sort
of
this
safety
net
here
or
this.
This
sort
of
fuse
breaker
to
make
sure
that
hey,
if
there's
a
problem
up
front
and
that
problem
could
be
something
as
simple
like
hey.
A
I
deployed
this
thing
and
I
can't
log
into
the
database
or
something
more
complicated.
Like
hey,
I
deployed
this
thing
it
started.
I
could
log
into
the
database.
It
started
to
accept
traffic,
but
now
I'm
seeing
some
sort
of
anomaly
either
in
a
log
or
metric
scenario,
and
so
again
all
of
these
things
are
critical
when
it
comes
to
doing
this
type
of
of
deployment
and
ultimately
being
able
to
go
through
the
the
process
of
understanding
what's
happening
and
then
instrument
that
type
of
rollback
or
ultimately
instrument
some
sort
of
action.
A
That
will
allow
you
to
sort
of
remediate
where
the
problem
might
be
and
again
making
it
really
simple
to
be
able
to
do
that
in
terms
of
being
able
to
automate
or
orchestrate
those
things
now.
Obviously,
the
other
piece
of
this
is,
you
know,
sort
of
doing
some
of
that
testing
prior
to
the
rollout
as
well.
A
So,
ultimately,
if,
if
you
were
in
say
a
red
block
type
of
scenario
where
I
might
have
you
know,
deployed
my
second
version
of
this
database
and
then
ultimately-
or
this
this-
you
know
sort
of-
maybe
it's
a
stateless
set
where
I've
deployed
a
second
version
of
this
thing
and
ultimately
a
running
test
against
that.
And
then
ultimately,
once
those
tests
have
passed
and
that's
been
promoted.
A
A
B
Off
from
where
bob
left
off,
you
know
the
whole
thing
where
these
things
are
going
or
what
bob
showed
is
that
really
once
a
pipeline
is
set
up,
you
don't
need
to
do
any
deployment
right.
You
make
the
change
to
get
and
it
flows
through
the
whole
process
and
it's
deployed
right.
There's
no
extra
deployment
action
being
taken
by
anyone.
B
So
that's
what
tools
like
spinnaker
helps
you
achieve,
and
the
other
big
advantage
of
tools
like
spinnaker
is
its
multi-cloud
support
right.
What
bob
showed
you
was
doing
a
deployment
to
kubernetes
right
now.
Spinnaker
doesn't
just
stop
with
kubernetes.
It
provides
first-class
support
for
providers
like
aws
google
cloud
azure
cloud
right,
but
the
concept
remains
the
same
thing
right.
You
build
you
bake,
you
deploy
you
validate
and
if
it
looks
good
you
move
on
to
production.
If
it
looks
bad,
you
roll
it
back
right.
B
The
same
same
process
goes
on
and
you
know,
if
you
go
look
at
spinnaker.
There
are
other
folks
are
also
coming
in
and
adding
support,
tencent
cloud
or
huawei
alibaba.
So
you
know
there
are
other
providers
that
is
getting
added.
So
that's
the
other
great
nice
thing
about
benefit
that
support
for
different
clouds
are
also
growing
so
coming
to
the
part
that
I'm
going
to
demo
here
is
a
little
schematic
of
you
know
what
my
pipeline
does
same
as
what
palm
had
earlier.
Is
that
hey?
B
B
So
in
our
build
process,
what
the
jenkins
job
does
is
takes
the
git
repo
compiles.
It
builds,
creates
a
debian
package
and
that
pushes
that
package
to
s3
right,
that's
what
it
does,
and
you
know
here.
Let
me
talk,
walk
through
the
schematic
and
when
we
go
to
the
pipeline
I'll
walk
you
guys
through
that,
so
how
it's
done
so
once
you
have
built
your
package,
you
have
your,
you
know,
jar
files
or
your.
B
You
know
debian
packages
or
rpm
packages,
you
basically
in
the
world
of
vms
and
amis,
and
all
that
you
basically
create
your
image
right.
That's
what's
called
the
big
process,
so
in
the
big
process
it
would
generate
your
image.
In
this
case
it
will
generate
an
aws
ami
and
in
the
process
it
would
pick
up
the
image
or
the
the
package
that
was
built
in
the
previous
stage.
B
Now
spinnaker
uses
packer
to
build
it.
So
you
know
any
customizations
with
your
packer
templates
to
build
it
to
build
your
images.
You
can
absolutely
include
that
to
build
your
images
and
then,
once
you
have
your
image
built,
you
basically
use
spinnaker
to
deploy
it.
What
bob
did
was
he
deployed
it
in
kubernetes
he
deployed
a
manifest
in
kubernetes
that
was
baked
out
of
hell
in
the
case
of
aws.
B
It
will
deploy
the
same
thing
or
it
would
do
the
same
thing
except
it
will
take
the
ami
image
and
deploy
it
to
aws
right
and
then
it
will
monitor
it.
If
it's
successful,
you
know
it
will
proce,
you
can
say
it
or
you
can
tell
it
to
proceed
to
deploy
to
production
or
if
it
looks
bad,
you
can
ask
it
to
roll
back
right.
B
This
process,
in
our
case,
is
a
manual
judgment.
A
human
comes
in
and
takes
a
manual
step
and
saying
looks
good
bad
and
proceed,
but
you
know,
like
we
have
said
earlier,
a
motto
is
you
know
continuous
deployment
without
manual
human
intervention?
You
really
don't
need
a
human
being
in
there.
Spinnaker
itself
has
tools
using
which
you
can
test
your
new
deployment.
B
B
B
So
let
me
go
in
here
and
so
what
are
the
setup
needed
to
be
able
to
deploy
to
aws?
Obviously
you
need
a
spinnaker
installed
here.
I
have
1263
set
up
here
running
here.
Then
you
need
to
set
up
accounts
in
spinnaker.
I
said
I'd
be
deploying
to
aws
I'd,
be
using
jenkins
to
build
and
then
I'd
be
using
github
right.
B
So
let's
go
look
at
like
you
know.
If
you
go
look
at
the
spinnaker
documentation
on
amazon
ec2,
it
talks
about
how
you
can
set
up
ec2
or
an
aws
provider
in
spinnaker.
They
give
three
options.
They
provide
some
cloud
formation
templates
using
which
you
can
do
it.
You
can
follow
the
instructions
here
or
you
can
use
aws
cli
to
configure
it
and
they
have
the
instructions
in
here
how
to
do
it,
and
obviously
there
is
the
long
way
of
doing
it.
B
You
know
my
cake
is
that
you
know
if
you
can
use
this,
you
have
an
aws
cli
access
and
all
that
this
is
the
easiest
of
all
and
then
at
the
end
of
it.
It
also
talks
about
what
you
need
to
do
in
spinnaker
to
enable
this
right.
You
enable
the
aws
provider
inhale
and
then
you
add
your
aws
secret
and
key
to
hallyard
to
so
that
spinnaker
knows
how
to
talk
to
aws
right.
B
B
Here,
that's,
let
me
call
it
aws
app
and
aws
app
and
give
it
an
email
and
the
cloud
provider
that
I'm
going
to
support
in
this
is
aws
right.
If
and
again,
nothing
stops
you
from
having
different
types
of
provider
in
the
same
cloud
like
if
your
application
has
both
aws
and
kubernetes.
You
could
absolutely
do
that,
but
I'm
just
going
to
stick
to
aws
here.
B
So
let
me
go
ahead
and
create
this
application
over
here.
So
I
have
a
brand
new
fresh
application.
That's
the
overall
sort
of
logical
grouping
in
spinnaker
by
the
way,
I'm
assuming
that
you
know
basic
concepts
of
spinnaker
is
known.
So
you
know
in
case
there's
some
questions
around
you
know
around
spinnaker
definitely
feel
free
to
ask
questions
now,
like
bob
mentioned
right
to
do
anything
in
spinnaker,
you
need
a
pipeline,
so
I'm
going
to
create
a
new
pipeline
here
and
I'm
calling
going
to
call
it
as
aws
depth.
B
Now
I
can
always
go
ahead
and
add
stages
here
and
go
through
the
ui
and
define
the
pipeline.
Now
spinnaker
supports
a
great
git
ups
model
right.
Everything
is
managed
as
code.
So
even
these
pipelines
are
available
as
json
objects
right,
so
there's
a
pipeline
json.
So
what
I'm
going
to
do
instead
of
trying
to
build
this
all
over
here
in
the
ui,
like
I
showed
over
you
over
here,
I
have
these
aws
dev
pipeline
json
over
here
right.
B
B
C
B
Create
the
two
pipelines
and
trigger
it
off,
it
would
take
about
10
minutes
to
run
and
when
it's
running
I
can
come
and
walk
you
guys
through
the
sort
of
the
different
constructs
within
each
pipeline.
Okay,
so
let
me
save
this
and
go
ahead
and
create
another
pipeline,
which
is
my.
This
was
my
dev
deployment
pipeline
and
let
me
go
ahead
and
create
a
production.
B
B
B
So
there's
one
change
I
have
to
actually
make
over
here
is
I'm
going
to
configure
this,
and
you
know
here.
I
call
another
pipeline.
My
prod
pipeline,
since,
when
I
created
that
prod
pipeline
was
not
there,
I
have
to
actually
select
that
broad
pipeline.
So
you
know
this
is
a
stage
which
calls
another
pipeline.
It's
in
the
same
application.
It
shows
me
all
the
other
pipelines
that
are
available.
I
can
just
select
this
this
only
other
pipeline,
aws
prompt.
B
I
select
it
and
it's
available
right.
So
just
like
that,
I
have
two
pipelines
available
for
me
to
deploy
and
you
know
they
are
available
in
get.
I
can
make
changes
all
the
changes
will
be
picked
up
and
you
can
actually
have
processes
in
place
to
have
the
sync
between
spinnaker
and
gate,
and
so,
instead
of
making
a
change
to
get
and
trigger
this
at
the
trigger
disabled.
This
is
running
on
my
local
machine.
I'm
just
going
to
manually
trigger
this
pipeline.
B
Okay,
you
know
when
you
have
a
pipeline,
it
can
take
in
parameters
and
all
that,
I'm
not
going
to
ask
it
to
rebate.
But
you
know,
if
you
want
any
other
input
parameters,
you
can
just
provide
that
or
those
input
parameters
needs
to
come
in
as
from
the
upstream,
actually
like
I'll
show
it
to
you
over
here.
If
I
try
to
start
this
manual
execution
of
this,
it
wants
an
image
that
it
should
use
to
deploy
right.
B
B
B
B
C
A
B
So
it's
basically
the
source
code
is
here
it's
picking
this
up
and
if
I
make
any
changes
over
here,
it
will
trigger
this
pipeline
right,
which
bob
was
already
shown.
You
he's
making
a
change
in
kits
triggering
the
pipeline,
so
I
skipped
that
part.
You
can
have
other
additional
triggers.
Also,
including
you
know,
you
can
have
a
pipeline
run
at
a
certain
time.
You
can
have
a
cron
job
actually
to
trigger
the
spike
line
at
regular
intervals.
Every
day,
11
o'clock
pick
up
the
latest
and
deploy
you
can
have.
B
Parameters
like
we
saw,
and
you
can
also
have
notifications
right.
You
can
notify
via
different
mechanisms
who
all
gets
to
see
when
it
succeeded,
failed,
or
you
know
when
you
want
to
be
notified
when
it's
starting,
complete
or
as
fail.
So
it
has
pretty
rich
notification
options
in
there
and
also
you
can
have
tags
associated
with
it
so
that
you
can
track
your
python
console.
That
goes
for
the
configuration
of
pipelines
coming
to
build.
B
B
Okay,
so
that
was
so
basically,
the
build
is
a
jenkins
job
right.
I
have
configured
jenkins
and
you
know
I
can
choose
what
controllers.
If
I
have
multiple
jenkins,
I
can
choose
which
jenkins
server
to
use,
and
it
will
show
me
all
the
jobs
that's
available
in
that
jenkins
server,
and
I
can
pick
up
the
job
to
be
done,
and
this
is
intelligent
enough
that
it
will
come
and
show
me
all
the
job
of
parameters.
That's
needed.
B
B
So
so
that's
what
it
does
and
it
will
wait
for
the
result
and
if
the
build
fails,
that
will
fail
the
stage
and
you
know
if
you
want,
even
if
it
fails,
consider
it
as
successful
and
move
on.
You
could
do
that,
and
each
stage
also
has
all
these
options
available.
So
you
know,
if
you
are
new
to
spinnaker,
you
can
decide.
B
So
you
can
know
what
all
these
execution
options
do
is
that
it
can
help
you
hold
the
pipeline
or
you
know
just
ignore
the
failure
or
if
there
are
multiple
branches
parallel
stuff
going
on.
You
can
just
hold
this
branch
and
let
the
other
branches
continue.
So
you
can
do
all
of
those
or
you
can
even
restrict
deployment
during
a
certain
time
frame
or
window,
or
you
know
if
it's
running
for
too
long,
it
should
not
take
more
than
say
10
minutes.
A
B
You
can
execute
this
on
certain
expressions.
Bob
showed
you
one
where
he
executed
the
roll
back
based
on
canary
result,
or
you
can
even
fail
the
stage
on
expressions
that
you
have
so
a
lot
of
nice
options
in
there
and
again,
similar
notification
options
are
available
right.
So
in
your
pipeline,
you
can
invoke
jenkins.
If
you
have
already
invested
in
jenkins.
B
B
B
B
So
this
big
configuration
you
know
regular
aws
stuff
in
which
region
you
want
to
bake
it.
What's
the
package
you
want
to
do
what's
the
base
os,
what
type
of
vm
pretty
much
standard,
aws
ami
image
options
out
there
right?
If
you
have
extra
packer
templates,
you
can
provide
them
here
instead
of
using
the
default
template,
which
is
the
bakery
in
in
spinnaker.
That's
the
component
that
actually
does
the
work
of
baking.
The
image
you
can
provide
the
template
file
packet
template
file
that
you
can
use.
B
You
can
provide
additional
attributes
again.
This
is
a
simple
showing
how
it
works.
You
give
the
base
ami
on
top
of
which
to
build.
If
you
have
your
custom,
you
know
images
in
your
organizations.
You
can
use
those
to
build
it
and
again
standard
stuff
is
in
here.
So
this
is
your
big
stage
which
actually
builds
the
ami
and
then
comes
the
deploy
stage
right,
and
this
is
where
you
get
into
the
deploy
configuration.
B
So,
let's
go
look
at
a
deploy,
configuration
how
it
looks
and
again
you
could
deploy
in
one
deployment
more
than
one
server
group
right.
So
let's
look
at
this
one,
so
you
have
chose
you
have
to
choose
what
aws
account
to
use
right.
So
in
this
case
I'm
choosing
my
aws
account.
It's
an
account
that
I've
configured
with
access
key
secret
like
I
was
showing
you
in
there,
then
I
choose
what
region
to
deploy
to
what
vpc
to
deploy
to.
B
It
will
show
you
all
the
vpcs
and
subnets
that
are
available
right,
so
it
will
pull
all
that
information
and
show
it
to
you
over
here,
and
these
are
names
that
you
use
to
that
you
give
to
track
your
deployment.
These
are
added
as
tags.
Spinnaker
uses
these
to
manage
and
monitor
the
environments
right.
So
I'm
giving
this
a
stack
name,
I'm
calling
it
sas
cluster.
This
is
just
a
name
right
and
then
you
know
I
can
provide
some
sub
information
right.
This
is
my
dev.
B
So
there
are
different
deployment
strategies
that
are
there,
that
you
can
choose
we'll
just
use
red
black
right,
and
then
you
know
if
the
deployment
fails,
you
can
have
it
automatically
roll
back
to
the
previous
server
group,
and
this
is
another
thing
that
it
maintains
for
you
to
roll
back
something
you
can
actually
tell
it
how
many
server
groups
to
leave
behind
you
know
this
time.
I
can
try
to
doing
it.
B
I
know
each
deployment
takes
10
minutes,
but
we
could
try
and
show
that
if
I
do
another
deployment,
how
it
looks,
the
other
thing
that's
important
is
also
is
that
you
need
to
have
load
balances.
These
you
need
to
create
ahead
of
time.
Actually,
okay,
it
will
again
show
you
the
load
balancers
that
are
available.
B
You
know
machine
configuration
what
type
of
vm
you're
going
to
use
the
capacity,
how
many
instances
which
availability
zone
and
then
all
the
different
other
options
that
are
there,
that
you
can
enable
which
you
can
typically
do
in
aws.
So
a
lot
of
those
options
are
available
right
here
that
you
can
do.
B
B
I
do
not
want
to
make
any
changes,
so
let
me
revert
it
back.
If
I
made
any
changes,
let's
go
back,
it
is
waiting
on
manual
judgment.
Well,
this
did
pretty
quickly
typically
takes
five
six
minutes.
So
I'm
saying
everything
looks
good.
I
ran
my
test.
I
did
looked
at
my
dev
deploy
sanity
tests
manual
tests,
automated
tests.
B
Whatever
I
did,
I'm
satisfied
it
looks
good
and
then
I'm
going
to
promote
it
to
production,
so
you
can
see
a
trick
triggered
of
my
production
deploy
pipeline
and
it
found
the
image
that
it's
going
to
use.
Actually
it
was
passed
in
from
the
stage
onwards.
So
let's
go
look
at
that.
What
was
happening
in
there
so
manual
judgment
stage.
B
As
the
name
says,
it's
a
manual
intervention.
You
can
have
inputs,
the
user
can
choose
based
on
which
you
can
take
actions
in
the
subsequent
stages.
One
of
those
actions
could
be.
Is
that
hey?
I
want
to
push
it
to
region
one.
I
want
to
push
it
to
region
two
and
those
can
be
options
that
the
user
can
choose
and
in
subsequent
stages
you
can
use
that
option.
The
user
has
selected
to
take
action
right.
B
B
B
What
this
is
taking
is
that,
from
the
base
stage,
take
this
parameter
from
the
output.
Take
this
parameter
and
pass
it
along,
and
this
is
what
you
saw
as
being
passed
along
as
an
ami
to
the
production
deploy
pipeline
right.
So
what
had
happened
here
is
that
it
went.
Did
some
testing
and
then
you
decided
to
deploy
to
production
and
it
kicks
off.
Another
pipeline
passes
the
image
right.
So
you
know
you,
don't
you
you
can
ensure
the
same
image
that
was
deployed
in
dev
is
being
deployed
in
production.
B
There
is
parity
between
dev
and
production,
there's
no
different
images
being
deployed,
and
then
you
know,
if
it
doesn't
look
good,
the
release
doesn't
look
good.
You
could
roll
back,
obviously
right
again,
it's
a
stage
in
there
and
you
know
you
can
choose
what
cluster
to
roll
back
over
here
right
now,
let's
go
to
and
look
at
the
production
deploy
pipeline
to
look
at
what's
different,
really
that
panometer.
I
want
to
show
it
to
you
what's
different,
so
this
is
running.
Let
me
go
into
configure
this.
B
B
Production
deploy
really
pretty
much
the
same,
except
this
name
production
here.
If
I
go
in
there
and
look
at
it
pretty
much,
everything
is
exactly
the
same
except
you
know
this
tag
I'm
giving.
This
is
what
spinnaker
uses
to
identify
this
deployment
as
being
different
from
others
and
will
manage
this
instance.
B
B
Where
was
I
going
from
here?
Let's
look
at
how
it
did
nice
and
good.
It's
all
deployed
done,
took
about
how
much
five
about
ten.
Oh,
this
took
five
five
ten
about
14
minutes.
It
took
to
deploy
14
15
minutes
to
deploy
this
whole
pipeline
from
beginning
where
it
did
a
build,
build
an
ami
deployed.
It
then
went
ahead
and
deployed
it
to
production
too.
B
Now
spinnaker
is
more
than
an
orchestration
engine
and
that's
what
you
can
do
is
basically
look
at
these
clusters
from
this
cluster
tab
right.
These
are
the
things
that
got
deployed.
I
can
look
at
it.
I
can
act
on
it
over
here
and
I
can
edit
this
now
before.
I'm
sure
show
something
over
here.
Let
me
trigger
off
another
run
of
the
pipeline,
and
hopefully
I
can
show
something
that
I
want
to
show
to
show
you.
The
power
of
spinnaker.
B
B
So
while
this
is
running
so
let's
look
at
the
cluster
here,
so
you
can
see
that
aws
apps
has
clustered
their
production.
That's
how
how
spinnaker
tracks
it
a
v00
of
this
is
deployed
and
which
maps
to
build
591
and
the
same
deployment
has
gone
into
sas
production,
which
also
has
v001
right
and
there
is
a
load
balancer
associated
with
it
right.
It
shows
you
all
the
load
balancer
available
over
there
and
there
is
even
an
url
to
that
load.
Balancer.
B
B
B
So
you
know
I
can
basically
monitor
the
firewall
and
all
that
I
can
also
look
at
the
different
instances.
Like
you
know,
if
I
had
deployed,
if
you
remember,
when
we
configured
that
server
group,
we
say
to
have
only
one
instance,
if
you
had
say
that
I
want
10
instances
of
this
running.
You'll
have
10
little
green
boxes
in
here,
and
you
know
I
can
look
at
each
of
them.
B
B
B
Without
having
to
go
through
any
other
things.
Hey,
I
have
a
production
issue.
You
know,
I
need
to
add
one
vertically
scale.
This
and
add
one
more
instance
increase
this
over
here
and
there
there
you
go.
You
have
another
instance
up
and
there,
so
I
can
take
actions
to
my
server
groups
right
over
here,
including
cloning
destroy.
B
So
that's
another
big
advantage
of
spinnaker,
where
you
know
it's
not
only
deployment,
but
you
can
also
control
what
you
deploy
from
here
and
then
you
can
have
your
load
balancer
same
thing
with
your
load
balancers.
You
can
even
edit
your
load,
balancers
and
add
additional.
You
know
protocols
here.
This
one
is
routing
8080
to
internal
port
80,
why
you
can
add
additional
health
checks
and
all
that
things
that
you
can
add
to
the
load
balancer.
B
B
So
as
I
do
multiple
deployments,
what
would
happen
is
that
it
would
deploy
v001,
v002
or
v003
like
that
right
and
then
it
will
disable
this.
You
can
see
that
this
one
is
sort
of
bright
and
this
one
is
sort
of
grayed
out.
That
means
these
are
disabled
right.
The
clusters
are
still
there,
but
it's
not
connected
to
the
load.
Balancer
right,
you
can
see.
The
up
up
is
33
percent,
because
these
two
are
not
connected
to
the
load
balancer
or
the
load.
B
Balance
is
not
routing
traffic
to
these
two
guys
only
to
this
one
so
as
I
deploy.
This
is
what
the
red
black
deployment
would
actually
do
for
you.
It
will
automatically
do
for
you
without
you
having
to
take
actions
to
control
these
things,
and
you
can
control
how
many
of
these
you
keep
them
around
or
or
roll
back,
and
all
that
and
you
know
like
if
you
want
to
do
it
here.
I
want
to
just
go
ahead
and
delete
this
server
group.
B
B
B
I
think
I'm
just
I'm
running
this
locally
and
I'm
probably
stressing
my
local
environment
up.
You
can
see
the
amount
of
cpu
yeah,
something
definitely
you
know.
Oh
it's
probably
coming
up.
It's
being
deployed,
it's
coming
up.
So
at
this
point
it's
red,
but
it
will
turn
green
and
this
one
should
take
over.
B
So
that's
about
deploying
to
aws
same
thing
what
bob
showed,
but
with
flavors
of
aws
cloud
deployment
and
same
thing,
you
can
do
in
google
cloud
or
azure.
This
is
what
monoliths
you
know
we're
talking
about.
If
you
have
vms
you're,
not
on
kubernetes,
am
I
ruled
out
of
skank?
No,
absolutely
spinnaker
supports
such
things
as
such
deployment
models
for
you
with
that.
I
don't
think
I
had
anything
else
to
cover
here.
A
B
Okay,
let
me
take
a
stab
at
it
and
and
try
to
do
that.
So
one
way
to
incorporate
secrets
is
especially
for
kubernetes
is
that
you
can
have
secrets
available
in
kubernetes
right
it's
an
a
process.
You
can
either
deploy
a
manifest
or
your
kubernetes
cluster
is
say,
synced
up
with
vault,
and
you
know
your
kubernetes
cluster
has
access
to
those
secrets,
and
so
you
can
use
those
secrets
in
there.
B
One
drawback
of
that
is
that
those
secrets
are
available
in
the
pipeline
execution
context,
though
right
it
can
come
in,
you
can
make
them
as
variable
and
then
use
those
variables
as
spell
parameters,
but
the
drawback
of
that
is
that
those
are
available
in
a
pipeline
execution
context.
So
that's
one
copy
the
other
ways
to
handle
it.
C
C
C
We
also
ship
with
hashicorp
work
with
it
through
multiple
mechanisms
of
managing
secrets
that
hide
the
secrets
themselves
in
the
pipeline
and
at
the
deployment
time
using
annotations,
injecting
them
or
having
a
side.
Car
mechanisms
to
inject
them
is
a
more
acceptable
way
of
doing
it
and
we
support
those
mechanisms.
A
Great
excellent,
excellent.
There
was
another
question
and
we'll
deal
with
another
question,
and
then
I've
got
a
couple
of
other
pipelines
that
I
was
going
to
walk
through
guys
just
to
sort
of
give
folks
a
flavor
for
hey.
What.
If
I
want
to
go
beyond
a
simple
manual
judgment
step,
and
I
want
to
run
some
analysis
and
so
I'll
spend
some
time
talking
about
a
little
bit
about
that.
A
But
there
was
another
question
from
the
audience
looking
to
automate
spinning
up
spinnaker
in
different
cloud
environments
and
guys
when
I
hear
something
like
that.
Terraform
is
what
comes
to
mind,
but
maybe
you
guys
want
to
maybe
speak
to
you
know,
sort
of
a
ways
to
go
about
automating,
spinning
up
spinnaker
in
those.
B
B
What
we
have
done
is
that
we
have
spinnaker
pipelines
that
actually
spin
up
kubernetes
clusters,
like
you
say
it
does
use
terraform
but
uses
terraform
to
spin
up
kubernetes
clusters,
and
then
we
have
health
charts
to
deploy
spinnaker,
and
so
then,
just
like
bob
showed
using
health
charts
to
deploy.
You
can
use
the
helm
chart
to
deploy
spinnaker
and
definitely
like
there's
a
extra
flavor
of
oxamax
enterprise
spinnaker
with
some
extensions.
We
also
have
home
charts
for
that.
B
B
B
You
know
what
we
do
in
our
setups
is
follow
the
get
ops
model
like
it's
not
just
code.
The
spinnaker
configuration
is
also
managed
and
get
so
that
you
really
don't
go
to
hall
yard
and
make
the
changes,
but
you
have
to
get
in
there
and
make
the
changes
and
get
and
then
have
us
have
that
trigger
a
spinnaker
pipeline
that
would
refresh
spinnaker
itself.
B
So
that's
another
model
that
is
used
to
basically
not
only
bring
up,
but
also
keep
your
spinnaker
configuration
in
sync
with
kit
that
provides.
One
of
things
is
that
you
know
auditability
and
making
sure
you
know
someone's
not
messing
around
you're,
not
getting
config
drifts
in
your
environment
and
all
that
and
everything
is
managed
properly.
B
A
You
know
being
able
to
do
this
and
get
where
you
get
the
the
natural
sort
of
approval
phases,
and
you
have
sort
of
one
single
source
of
truth
that
can
be
done
outside
of
having
to
log
into
the
kubernetes
cluster
that
that
that
spinnaker
is
is
deployed
on.
Is
that
a
fair
statement
in
terms
of
you
know
the
goodness
around
the
sort
of
that
git
ops
model
and
sort
of
where
customers
see
value.
C
That's
right,
yeah,
so
the
infrastructure
automation
through
this
terraform
kind
of
tools
or
formation,
great
ideas
and
then
life
cycle,
management
of
spinnaker
configuration
management
upgrades
and
all
of
those
through
gdos
model
using
spinnaker
itself
is
the
model
that
we
found
to
be
most
easy
to
maintain
excellent.
That's
the
automation.
A
Excellent,
okay,
great
so
guys!
Let
me
if
you
don't
mind,
I
was
going
to
jump
in
and
and
maybe
walk
the
the
group
through
a
couple
of
other
pipelines
right.
I've
got
a
couple
of
blue
green
examples
here
with
some
traffic
shaping
that
we
can
look
at
some
canary
analysis,
examples
that
we
can
look
at
so
when
it
comes
to
things
like
doing
verification.
So
any
objections
to
me
jumping
into
doing
that.
A
All
right,
so
you
know
we
did
want
to
walk
you
through
a
couple
of
other
pipelines
wow.
That
was
a
trip
the
inverted
screen
share.
You
know,
there's
a
couple
of
things
that
we
sort
of
wanted
to
walk
you
through,
and
these
were
pipelines
that
you
know
again
that
we've
set
up.
We've
worked
with
customers
on.
A
So
in
this
case
here
again
a
very,
very
simple
scenario
here,
where
we're
doing
that
canary,
alongside
the
baseline,
we're
ultimately
going
to
go
ahead
and
actually
start
to
test
or
run
some
load
tests
on
this
application
to
ultimately
get
to
a
place
where
we
could
then
perform
that
canary
analysis
and
that,
in
this
case
here
is
using
kyento
within
spinnaker.
And
ultimately
you
know
what
you
end
up
with.
Is
you
know
the
ability
to
go
ahead
and
start
to
evaluate
the
re?
A
You
know
manual
judgment
steps
right
throughout
this
process,
and
I
think
it's
it's
worth
noting
you
know
sort
of
what
does
one
do
during
a
manual
judgment
step?
What
should
I
be
doing,
and
I
think
it's
really
about
you
know
looking
at
things
like
this,
that
will
help
you
make
again
that
data-driven
decision
as
to
whether
or
not
I
mean
we
all
can
get
a
binary
pass
fail.
A
You
know
from
our
our
testing
scripts.
Did
it
process
the
load
and
did
it
do
it?
A
certain
period
of
time,
but
to
go
that
next
layer
deeper
and
say
how
did
it
behave
while
it
was
doing
that
and
what
are
the
risks
associated
with
this
particular
canary
deployment?
Now,
if
everything's
in
line,
I
can
go
back
to
that
manual
judgment
step
and
simply
go
ahead
and
approve
it.
If
things
don't
look
the
way
they're
supposed
to
or
if
I
see
anomalies,
in
the
way
that
the
underlying
application
behaved.
A
You
know
you're,
ultimately
going
to
be
able
to.
You
know,
look
at
again
whether
or
not
you
should,
as
you
check
those
conditions
or
you
and
sort
of
manual
judgments
that
were
approved
and
validate
the
canary.
This
is
the
data
that
you'll
be
looking
at
and
then
ultimately
make
that
decision
as
to
whether
or
not
you
should
promote
that
canary
to
production
and
again,
I
think
this
is
something
that's.
A
A
The
other
pipeline
that
I
wanted
to
show
off
to
you
guys
that
I
think
is
interesting
and
it's
something
that
we
we
just
have
started
to
work
with.
You
know
a
particular
prospect
and-
and
you
know
ultimately,
you
know
going
down
the
path
of
of
using
some
traffic
shaping
technology.
So
you
know,
a
lot
of
our
customers
are
now
experimenting
with
istio
and
other
sort
of
traffic
shaping
technologies.
A
In
this
case
here
we
had
a
prospect
that
was,
you
know,
working
with
app
mesh,
and
so
you
know
the
ability
to
go
ahead,
and
actually
you
know,
sort
of
deploy
the
various
services
that
you
need
to
through
spinnaker
and
interact
with
app
mesh.
Obviously
this
requires
a
controller
on
that
mesh
controller
to
be
installed
in
your
your
eks
cluster,
but
ultimately
being
able
to
start
the
process
of
controlling
that
traffic
with
an
idea
of
creating
again
when
we
look
at
this
those
virtual
routes.
A
A
You
know
you
want
to
make
sure
that
you
know
you're
either
exposing
a
small
amount
of
this
traffic
or,
if
it's
going
to
be
a
binary
sort
of
zero
to
100
100
to
zero,
that
you
actually
take
into
consideration.
Some
of
that
that
metric
analysis
and
that
data
or
the
comparison
to
a
previous,
build
prior
to
you,
know,
sort
of
making
that
decision
to
either
tear
down
a
previous
or
promote
that
canary,
and
so
this
is
something
that
I
think
in
the
spirit
of
this
workshop.
A
We
wanted
to
make
sure
that
we,
we
talked
a
little
bit
about
in
terms
of
spinnaker's
ability
to
to
ultimately
interact
with
these
various
services,
not
just
do
sort
of
the
out
of
the
box
red
black
that
spinnaker
ships
with
which
is,
which
is.
Obviously,
we
have
a
lot
of
folks
out
there
that
are
taking
advantage
of
that.
A
But
if
you
want
to
explore
other
technologies
for
traffic
shaping
or
you
want
to
use
ingress
for
traffic
shaping,
you
certainly
can
do
that
here
and
ultimately
again
make
those
decisions
based
on
on
data-
and
you
know
not
just
sort
of
binary
pass
fails.
If
that
makes
sense,
let
me
stop
there.
I
don't
know
before
I
move
on
to
the
the
last
pipeline
that
I
wanted
to
show
nermalia
or
gopi
anything
that
you
wanted
to
add.
Or
am
I
missing
anything
from
that.
A
Okay,
excellent
take
a
deep
breath
because
what
I
always
ask
people
that
are
smarter
than
me
if
I
got
everything
right,
it's
always
good
to
hear
that
I
did
so
guys
the
the
last
pipeline
that
I
wanted
to
go
through
and
then
I
think
you
know
we'll
do
the
best
we
can
to
sort
of.
I
see
in
the
background
there
some
additional
questions
coming
in
and
let
me
first
start
by
making
this
bigger.
A
We're
then
going
ahead
and
validating
that
traffic.
And
here
again
we've
represented
this
as
a
manual
judgment
step.
But
one
of
the
things
that
you
might
do
here
is
again
kick
off
that
continuous
verification
analysis,
whether
you're
using
kyenta
or
you
know
something
like
the
continuous
verification
within
opsimex
autopilot.
Anything
that
would
allow
you
to
get
more
insight
into
sort
of
the
health
as
you're
actually
starting
to
stress
these
deployments,
and
then,
of
course,
assuming
this
passes.
A
We
then
up
the
ante
here
to
a
50
traffic
split
and
again
do
another
validation
there
right
and
again,
I'm
I'm
sort
of
slow
rolling
this
out
and
ultimately
going
through
the
process
of
each
step
along
the
way,
using
the
data
that
I
can
collect.
You
know
from
the
metrics
perspective
or
in
the
case
of
the
ops
mx
stack,
both
logs
and
metrics,
to
ultimately
understand
what
the
health
of
this
is
now
again.
This
is
particularly
interesting
and
you
know:
we've
talked
to
a
lot
of
customers
who
are
again.
A
You
know
utilizing
that
sort
of
source
to
prod
sort
of
get
ops
type
of
scenario
where
they're,
they're
sensing
or
they've
they've
identified
a
change
in
git.
It's
been
approved,
you
have,
you,
know,
sort
of
tests
passed
from
a
you
know,
sort
of
code,
quality
perspective
through
the
pull
request
process,
and
then,
ultimately,
you
know,
rather
than
then
sort
of
pick,
an
all
or
nothing
type
of
scenario.
A
They
can
run
that
code
through
a
pipeline
like
this,
where
they
can
ultimately
start
the
process
of
slowly,
adding
that
traffic
to
make
sure
that
they're
not
running
into
any
problems
and
analyzing
it
every
step
of
the
way
and
again
using
the
data-driven
approach
right.
So
whether
or
not
you're
you're,
you
know
sort
of
using
that
cuyanta
piece
here
to.
A
Ultimately,
you
know
sort
of
look
at
these
metrics
and
ultimately
understand
if
there's
anything
out
of
out
of
whack
here
you
know
from
a
time
series
perspective
or
a
histogram,
or
you
know
if
you
use
again
something
like
our
continuous
verification
piece
where
we're
going
to
produce
a
score
that
ultimately
allows
you
to
anchor
a
decision
to
right
so
at
each
step
along
the
way.
Here
you
can
ultimately
go
ahead
and
ultimately
ask
yourself,
you
know:
are
there
any
anomalies?
A
Is
there
anything
I
need
to
be
concerned
with
before
I
start
to
deploy
this
to
even
more
or
expose
this
to
even
more
traffic?
And
so
again,
I
think
guys.
The
the
key
here
is
all
of
these
strategies.
You
know,
obviously,
are
enabled
by
the
underlying
technology
using
something
like
spinnaker.
I
also
wanted
to
comment
on
on
what
normalia
showed
you
at
the
end
of
his
demo,
which
I
think
is
particularly
powerful.
A
Is
you
know,
as
well
as
things
can
go
in
a
scenario
where
you
know
you've
gone
ahead
and
deployed
something
you
know,
there's
always
sort
of
that
3
a.m,
situation
where
you
may
need
to
take
action,
and
I
think
that's
really
where
spinnaker
excels
in
allowing
you
to
interact
with
those
clusters
to
be
able
to
scale
those
things.
So
if
you
have
the
same
underlying
software,
but
the
problem
is
you
need
to
scale
that
deployment,
something
that
you
can
do
right
within
spinnaker
that
you
know
sort
of?
A
A
You
know
the
pipeline
to
focus
on
deploying
net
new
software
and
then
obviously
going
through
this
process
that
you're
seeing
here
to
ultimately
validate
that
that
software,
depending
on
how
you
want
to
do
it
and
then
ultimately,
leading
to
the
ability
to
go
ahead
and
interact
with
that
cluster.
You
know,
as
you
need
to
and
respond
to.
A
You
know
the
environment
as
things
if
you
need
to
again
scale
up
or
if
you're
again
looking
to
later
in
the
evening
scale
back
down
again,
you
can
do
all
those
things
right
through
this
single
tool
and
ultimately
be
able
to
track
all
the
things
that
are
happening
in
all
the
ways
that
this
these
these
deployments
are
being
interacted
with.
So
guys
that
was
sort
of
what
I
had
again.
A
B
A
Comprehensive
when
we
ask
people
if
they've
got
any
questions,
concerns
or
if
they
just
saw
something
that
they
thought
was
either
crazy
or
insane,
please
feel
free
to.
Let
us
know
we
love
the
feedback
and
by
the
way
and
I'll
stop
sharing.
So
I
can
go
into
the
the
questions
piece
here.
We
can
maybe
take
a
look
at
a
couple
of
questions
if,
for
some
reason
you
want
some
additional
information
or
you
just
want
to
continue
the
discussion.
A
Members
of
my
team
will
be
there,
staffing,
the
booth
and
and
be
more
than
willing
to
have
you
come
in
and
ultimately
ask
any
questions
or
any
any
follow-ups
that
you
have,
or
you
know,
maybe
even
set
up
a
time
to
talk
about
your
particular
situation.
We'd
be
we'd,
be
more
than
happy
to
sort
of
help
you
there.
B
B
You
just
stick
with
that:
right,
don't
change
it
and
then
from
jenkins
triggered
the
deployment
pipeline
if
you're,
building
something
new
and
want
to
have
spinnaker,
as
the
center
of
your
universe
sure
have
get
trigger
spinach
pipeline,
which
can
trigger
the
jenkins,
build
and
and
proceed.
I
don't
think
there
is.
Basically
both
the
opinions
are
strongly
supported
by
spinnaker
doesn't
take
a
side
in
there.
A
Yeah-
and
I
think
I
think
I
love
that
answer,
because
I
think
what
it
does
is
it.
It
basically
tells
tells
folks
that
you
know
there's
gonna,
be
a
right
answer
on
a
per
customer
basis
or
on
a
per
user
basis
right.
Each
team
will
have
you
know,
sort
of
a
preference
and
one
of
the
nice
things
that
I'd
like
to
talk
to
people
about
spinnaker.
C
It
makes
sense
integration
here
is
when
you
have
multiple
tools
being
part
of
the
delivery,
and
if
you
want
to
go
trace
how
an
artifact
or
container
got
to
your
production,
then
you
want
to
look
at
multiple
tools
and
if
you
want
to
go
trace
and
auditors,
so
that
would
be
one
of
the
considerations
and
there
are
newer
things
that
we
also
have
provide
an
enterprise
version
which
allows
you
to
collate.
All
these
events
in
one
place
gives
you
the
traceability.
C
So
that
also
adds
to
the
flexibility
in
which
how
you
can
use
finicker
to
orchestrate
your
delivery,
and
even
there
you
have
these
options
of
the
delivery,
the
container
immutable
server,
deploying
to
your
dev
environment,
testing
and
then
a
separate
pipeline.
That's
triggering
off
the
deployments
to
your
production,
usually
if
you're,
using
orgo
kind
of
as
tools
where
you
have
the
git
process,
that's
linked
to
each
one
of
these
deployment
environments
you
get
into
those
situations.
C
B
B
Let
me
take
a
stab
at
that
and
go
if
there's
another
option
call
me
out,
so
I
think
the
where
it
where
you
the
way
you
manage.
That
is
that,
once
you
have
an
ami,
you
just
bring
it
up
right.
This
is
the
immutable
infrastructure
construct
that
gopi
was
talking
about
so
where
you
handle
secrets
and
config
files
in
aws
or
in
other
such
vm
instances
is
during
your
big
process
right.
B
You
have
your
images
and
when
you
bake
them,
you
basically
provide
them
as
parameters,
and
you
know
make
them
part
of
your
image
and
bring
them
up
now.
If
there
are
other
environment
variables,
you
can
do
it
that
you
can
do,
but
you
know
if
it's
configuration
or
something
you
basically
make
them
part
of
your
big
process,
and
you
know,
build
the
image
and
then
deploy
the
image
as
part
of
that
same
immutable
infrastructure
construct.
C
C
B
Active
active
architecture
today,
ansel
is
yes
now.
The
active
active
in
this
spinner
supports
multiple
instances
running
right,
so
that
active
actor
was
in
the
same
region.
If
you,
if
you
want
an
active
active
class
region,
there's
a
some
work
to
be
done,
because
it
does
use
databases
and
caching
to
maintain
some
state
and,
and
that
and
the
latency
of
those
are
very
important
right.
So,
yes,
you,
you
actually
run
a
high
availability
version
of
spinnaker.
A
B
A
C
B
A
A
B
Okay,
is
it
possible
to
run
spinnaker
on
aws
and
azure
cross
cloud
with
single
db
and
operate
on
both
being
run
and
assure
you
can
use
msi
and
avoid
service
principle
and
and
avoid
service
principle
and
aws
iron
role?
I
think
this
comes
to
the
point
that
gopi
mentioned
lately
of
access
to
the
db
is
important
and
again
we
don't
know
having
trying
to
run
cross
region,
databases,
their
latency
issues
and
spinnaker
doesn't
seem
very
happy.
B
C
C
Another
option
that
we
add
to
it
is
that
you
also
verify
logs
along
with
the
metrics,
so
you
run
the
canary
and
you
focus
on
the
errors
of
functional
aspects
of
the
canary
and
use
statistical
thresholds
for
performance
metrics.
So
the
combination
of
that
would
allow
you
to
do
a
better
canary
in
automated
ways.
A
I
know
these
workshops
are
hard
to
sort
of
air.
Your
specific
scenario,
I
think
the
three
of
us
are
more
than
happy
to
sort
of
make
ourselves
available
to
have
sort
of
those
more
private
conversations
where
you
want
to
maybe
talk
to
us
a
little
bit
about
your
particular
scenario.
We'd
be
happy
to
do
that,
so
you
know
don't
be
shy
about
reaching
out
or
stopping
by
our
booth.
You
know
and
and
ultimately
making
that
ask
and
we'd
be
happy
to
schedule.
A
B
A
A
A
B
I'll
it
means
you
know,
this
is
happening
in
aws
right.
The
big
process.
Spinnaker
is
really
taking
the
information
and
passing
it
on
to
aws
and
that's
the
time
it
takes.
But
you
know
spinnaker
is
intelligent
about.
If
it
sees
there
no
changes
and
gopi
correct
me:
it
doesn't
you
bake
and
there
is
an
option
to
force
a
rebate
if
it's
needed-
and
I
think
in
my
scenario
I
think
I
had
that
and
it's
an
option
you
can
choose
so.
B
B
C
A
Okay,
guys,
I
don't
see
any
other
questions,
so
I
guess
we
can
go
ahead
and
and
look
to
wrap
up.
I
think
again,
I
want
to
thank
everybody
for
for
coming
to
the
workshop.
Hopefully
you
know
you
were
able
to
sort
of
get
some
ideas
and
maybe
see
some
things
that
you
hadn't
seen
before,
depending
on
sort
of
your
level
of
maturity
with
with
spinnaker
and
sort
of
how
familiar
you
are
with
the
various
concepts
and
deployment
strategies.
A
So
hopefully
this
was
helpful
and
you
know
sort
of
exposing
you
to
some
of
those
things.
You
know
we
continue
to
be
willing
to
sort
of
answer
any
questions
that
you
might
have
so
again
swing
by
our
booth.
Let
us
know
sort
of
how
we
can
help.
You
know
we.
Obviously,
as
you
can
tell
love
talking
about
this
stuff,
we
certainly
have
a
passion
for
it
and
and
would
love
to
to
chat
with
you
a
little
bit
about.
A
If
you
have
a
specific
situation,
you
want
to
just
trade.
Some
ideas
on,
or
or
or
you
know,
sort
of
get
our
opinion
we'd
be
happy
to
sort
of
help
you
out
there
outside
of
that.
I
hope
everyone
really
enjoys
the
rest
of
the
conference.
I
know
there's
a
lot
of
great
sessions
on
the
docket
here
over
the
course
of
the
next
couple
days,
and
you
know
look
for
us
in
the
various
chat
rooms
and
at
the
various
sessions
and
again
more
than
happy
to
help
any
way.