►
From YouTube: Deep Dive into Spinnaker and the Spinnaker Operator Lee Faus and German Muzquiz (Armory)
Description
Deep Dive into Spinnaker and the Spinnaker Operator
Lee Faus and German Muzquiz (Armory)
OpenShift Commons Briefing
July 2020
This Briefing will provide an introduction to new Commons members: Armory, the enterprise software company commercializing Spinnaker, a leading open source continuous delivery platform from Netflix and Google, then provide a deep dive into how they provide your developers the power Armory Spinnaker is the enterprise distribution provided by Armory, Inc with Pipelines as Code, Terraform Integration, Policy Engine, Secrets Management, and the Spinnaker Operator. The Armory extensions help break down silos between teams as it’s adding a level of confidence for DevOps and SecOps.
The Spinnaker Operator makes deploying and managing the full lifecycle of your Spinnaker app simple, automated, and reliable, leveraging a Kubernetes-native GitOps workflow. This represents a significant advance from the current tool for managing Spinnaker (Halyard), which involves significant manual processes and requires Spinnaker domain expertise.
A
All
right,
everybody
welcome
back
to
another
open
ship
Commons
briefing.
Today
we
have
the
folks
from
armory
who
are
experts
in
spinnaker,
they're
gonna,
give
us
a
deep
dive
on
spinnaker
and
the
spinnaker
operator
and
tell
us
how
to
deploy
it
and
all
kinds
of
good
stuff.
We
have
with
us,
come
on
Liz
quiz
and
Lee
Foust,
I'm
gonna.
Let
them
introduce
themselves
and
we'll
have
live
Q&A
at
the
end
of
the
conversation.
So
please-
and
thank
you
very
much
for
being
here
today.
C
And
my
name's
Lee
Falls
field
CTO
at
armory
I've,
got
over
25
years
of
IT
experience.
Supporting
a
lot
of
different
open-source
communities
also
have
a
lot
of
experience
with
enterprise
development
and
delivery
across
multiple
different
verticals
I'm.
Also,
an
X
Red
Hatter
I
worked
at
Red
Hat
in
between
2006
to
2009
on
the
centennial
campus
behind
NC
State
working
on
the
Red
Hat
exchange
and
Red
Hat
Network,
the
Vermont.
C
This
AWS
cloud
environment.
They
used
a
number
of
other
open
source
technologies
inside
their
stack,
so
they
were
using
Java
spring.
They
were
using
Corp
Packer
and
a
lot
of
other
open-source
technologies
that
we
would
see
in
a
common
DevOps
tack.
Today,
this
technology
leader
group
that
was
formed
around
spinnaker,
was
all
around
a
particular
technology
called
a
cloud
driver
and
a
cloud
driver
is
something
that
supports
all
of
the
different
major
clouds.
C
It
also
allows
us
to
be
able
to
work
with
kubernetes,
and
it
also
allows
us
to
be
able
to
do
things
like
defining
custom,
CR
DS
for
deployments,
as
you
would
do
with
open
ship.
Today,
it's
backed
by
an
open-source
community.
The
community
today
is
very
strong
armory
and
a
number
of
other
companies
contribute
openly
through
their
employee
contributions
back
into
the
community
as
a
whole.
We
also
have
built
some
proprietary
capabilities
on
top,
but
because
of
the
way
that
the
application
has
been
architected,
we
don't
actually
fork
the
underlying
code
base.
C
We
actually
build
enhancements
by
using
kubernetes
native
technologies
by
being
able
to
deploy
additional
pods
and
then
integrating
to
the
overall
pipelining
architecture.
Its
target
agnostic
delivery
platform
allows
us
to
be
able
to
focus
our
energies
by
giving
the
api's
back
to
the
cloud
vendors
and
allowing
them
to
actually
build
the
best
practices
into
their
given
environments.
C
Spinnaker
allows
DevOps
teams
to
use
guardrails
instead
of
gates.
So
inside
of
a
lot
of
environments
that
we
talk
to
our
customers
today
is
they
feel
very
comfortable,
giving
direct
access
to
dev,
QA
and
maybe
even
staging,
but
what
they
need
is
they
need
formal
approval
processes
for
deploy
anything
into
production.
So
what
spinnaker
allows
us
to
be
able
to
do?
C
Spinnaker
was
built
for
resilient
safety
and
speed.
This
is
basically
a
golden
path
to
production.
There
are
a
lot
of
capabilities
that
we'll
be
showing
at
the
end
talking
about
how
you
can
use
the
spring
expression
language
to
minimize
the
number
of
pipelines
that
you
would
need
to
create.
So
you
can
actually
reuse
pipelines
and
use
those
pipelines
for
specific
application
types.
So
you
could
define
a
golden
path
to
production
for
every
react
from
front
end.
You
could
build
a
golden
path
to
production
for
your
spring
food
applications.
C
You
can
also
do
that
based
on
technology
type,
so
whether
you're
deploying
two
VMs
or
you're
deploying
two
containers.
It's
a
pluggable
and
extensible
platform,
we'll
be
talking
a
little
bit
more
about
this
later.
The
plug-in
framework
is
something
that
is
relatively
new
and
we
would
love
to
see
the
OpenShift
community
contribute
back
to
the
plug-in
framework
to
give
a
tighter
integration
between
spinnaker
and
OpenShift.
As
a
as
the
two
platforms
work
in
conjunction
with
a
lot
of
joint
customers
or
mine,
can
we
have
the
next
slide
please?
C
So,
as
we
mentioned,
spinnaker
is
a
next-gen
software
delivery
orchestration
tool.
So
this
tool
is
something
that,
as
we
mentioned,
we've
got
Netflix
Google,
Amazon,
pivotal
Oracle,
Microsoft,
a
lot
of
the
major
cloud
providers
even
internationally,
with
Huawei
Tencent
and
Alibaba
there's
over
560
individual
contributors.
C
C
What
you'll
be
able
to
see
is
you'll
be
able
to
see
the
continued
growth
of
spinnaker
across
a
lot
of
organizations
and
when
you
go
ahead
and
compare
this
across
different,
continuous
delivery
tools
with
their
different
tooling
that
exists
on
github
you'll
be
able
to
see
the
numbers
of
repositories,
pull
requests
and
Forks,
showing
the
vibrant
community
and
the
contributions
that
companies
are
making
back
into
the
open
source
community
next
slide.
Please.
C
C
So
new
in
2020,
some
of
the
things
that
we've
been
working
on
with
the
community
is
to
develop
a
spinnaker
operator
that
Herman's
going
to
talk
about
today,
which
makes
it
easier
to
manage
spinnaker
itself.
We've
also
built
a
plug-in
framework
where
some
of
the
work
that
we're
doing
with
the
Netflix
team
is
to
go
ahead
and
focus
on
building
a
lean
core,
while
also
creating
an
extensible
platform.
What
does
will
mean
for
the
people
who
are
wanting
to
use
spinnaker
in
production?
C
You
can
imagine
being
able
to
do
things
like
if
your
environment
is
only
kubernetes.
What
you
can
do
is
you
can
shrink
the
size
of
the
deployment
of
spinnaker
to
only
require
the
things
that
are
required
to
be
able
to
do
spinning
to
do
kubernetes
deployments.
One
of
the
other
things
that
we've
built
over
the
last
year
is
something
called
miniature.
Anybody
who
has
done
any
development
where
applications
have
built
as
micro
services,
where
you
have
direct
dependencies
between
the
api's
across
all
those
services.
C
What
will
happen
is
you
can
end
up
in
a
situation
where
routing
between
those
different
services
can
be
very
difficult
to
manage?
So
what
we've
done
is
we've
built
vinegar
that
allows
you
to
stand
up
a
vm
and
allows
you
to
be
able
to
clone
just
the
repository
of
the
service
that
you
want
to
extend
and
what
we
can
do
is
we
can
use
our
plug-in
framework
with
a
particular
code
that
exists
at
the
plug-in
points
and
allows
us
to
be
able
to
go
ahead
and
set
up
your
development
environments
very
quickly.
C
There's
also
some
very
exciting
work
that
is
coming
out
of
joint
teams
that
are
working
with
Netflix
around
something
called
declarative
delivery.
If
you
look
inside
of
the
spinnaker
organization,
you
will
see
a
particular
repository
called
keel,
where
there's
a
lot
of
very
interesting
work,
being
done
around
being
able
to
do
things
like
defining
environments
and
constraints
that
allows
us
to
move
beyond
the
pipelining
technologies
that
exist
today.
B
Then
you
apply
this
manifest
to
the
cluster
and
the
operator
is
a
pole
running
inside
this
cluster
that
takes
these
kubernetes
kind
spinnaker
service
and
creates
the
respective
deployment
object,
service,
objects,
secrets
and
so
on
for
spinnaker
to
be
run
in
the
cluster
and
using
the
operator,
you
can
use
a
standard
tools
like
keep
CTL,
ocl
or
customize
to
deploy
it
instead
of
custom
tooling.
That
we
are
going
to
to
see,
for
instance,
here
is
a
halyard
which
is
the
official
deployment
tool
for
spinnaker.
B
When
you
use
Kalia,
you
need
to
take
in
mind
that
you
need
to
run
it
in
some
in
some
machine
you
need
to
run
somewhere.
Usually
this
can
be
a
built
on
machine.
It
can
be
a
pod
inside
the
same
cluster
or
it
can
be
somewhere
else,
but
there
are
some
key
points
to
keep
in
mind
when
you
are
deploying
spinnaker
using
handle.
B
B
Another
key
point
here
is
that
the
spinnaker
configuration
files
need
to
live
in
the
same
machine
as
hunger,
and
this
raises
the
question:
how
to
do
to
get
opps
with
halyard?
Well,
you
would
need
to
have
a
some
custom,
tooling
or
automation
for
mounting
these
spinnaker
config
files
into
the
culture
machine.
B
Also,
if
you
want
to
deploy
spinnaker,
there's
the
Hal
CLI,
so
there's
a
special
command
to
tell
Collier
to
deploy
spinnaker,
and
you
will
need
to
the
plot
to
build
again
custom
tooling
around
healthier
life.
If
you
want
to
automate
the
deployment
of
spinnaker
itself-
and
the
last
point
to
consider
here
is
that
hangar
performance
on
validations
on
the
fly.
For
instance,
let's
say
that
you
want
to
add
a
new
docker
registry
to
spinnaker
and
halyard
tries
to
connect
to
this
docker
registry
to
validate
that
the
credentials
are
working.
What
does
it
does
this
mean?
B
It
means
that
you
will
need
to
grant
access
from
the
machine
where
Collier
is
running,
to
be
able
to
worry
your
judo
karate
string.
If
you
are
running
halyard
inside
of
the
same
cluster
as
in
a
pod,
then
there
is
no
problem,
because
you
already
need
to
specify
access
for
the
cluster.
But
if
you
are
running
handling
a
separate
machine,
it
can
impose
on
some
security
restrictions.
B
B
This
has
the
same
considerations
as
before:
halyard
uses
cube
CTL.
Therefore,
you
need
a
cube
config
file
for
deploying
spinnaker
to
the
cluster.
You
need
to
have
the
spinnaker
configuration
files
mounted
into
that
pot.
So
if
you
want
to
automate
the
deployment
of
spinnaker,
that
would
be
some
way
to
update
this
configuration
files.
Inside
of
the
pot,
you
still
need
to
use.
Hansy
align,
the
validations
are
running
from
inside
the
cluster,
which
is
an
improvement.
B
But
now
you
have
the
configuration
spinnaker
split
in
two
places:
one
is
the
native
spinnaker
configuration
files
and
the
other
is
the
add,
12m
charts
tab.
You
want
to
make
some
changes,
you
have
healthier
line
and
then
you
have
home
and
you
have
two
different
sets
of
configuration
files
to
maintain.
B
So
what
we
did
at
armory
is
creating
the
spinnaker
operator
in,
and
the
considerations
for
this
is
that
the
spinnaker
configuration
files
are
basically
included
into
the
spinnaker
service
manifest
file.
This
is
a
seer
thing
and
you
can
apply
this
CFD
to
your
kubernetes
cluster,
using
standard
tooling
in
the
here's,
an
improvement
because
you
do
don't
need,
keep
CTL
or
a
cube
config
file
to
deploy
spinnaker.
Now
you
can
use
pure
OC.
B
If
you
want
to
deploy
or
apply
this
manifest,
you
can
do
an
OC,
login
and
then
also
apply,
and
the
operator
will
take
these
spinnaker
service
manifest
and
create
the
respective
spinnaker
port
services
secrets
and
so
on.
Another
consideration
is
now
the
configuration
lives
outside
of
the
system.
You
no
longer
need
to
mount
this
configuration
files
into
the
pod
or
into
the
Chaldean
machine.
So
this
is
easier
for
automation.
B
B
B
Once
the
operator
is
installed,
then
you
need
to
create
or
modify
your
spinnaker
service
manifest,
and
for
this
you
need
new
to
know
how
to
configure
spinnaker-
and
there
are
a
lot
of
configuration
settings
for
spinnaker,
for
integrating
with
kubernetes
account
with
AWS,
with
the
corral
histories
and
so
on,
and
we
provide
configuration
about
these
configuration
fields,
some
documentation
for
them.
You
can
store
this
manifest
under
source
control.
The
secrets
can
be
stored
somewhere
else.
B
B
B
B
B
What's
the
URL
that
is
used
to
access
a
spinnaker,
normally
using
halyard,
you
will
need
to
install
spinnaker
fields,
then
create
some
load
balancers,
and
once
you
have
these
URLs,
you
need
to
update
the
configuration
with
the
urls
with
the
operator
in
the
case
of
exposing
spinnaker
with
service
load
balancers.
This
is
automated.
B
The
operator
fields
deploy
spinnaker
and
the
service
load.
Balancers
then
waits
for
the
public
URLs
for
these
load
balancers
to
be
generated
and
then
operator
automatically
updates
the
configuration
the
spinnaker
knows
where
it's
exposed
and
finally,
as
I
said
before,
one
feature
of
the
operator
is
that
you
can
store
spinnaker
secrets
as
google
neti
secrets,
like
your
jenkins
credentials
or
your
github
token.
All
of
this
can
be
stored
as
a
kubernetes
secret.
An
operator
will
take
care
of
reading
these
secrets
and
applying
them
to
the
services.
B
And
now
here
we're
seeing
an
example
of
how
to
migrate
from
culture
to
the
operator
with
handle.
You
have
a
set
of
configuration
files.
The
main
one
is
a
dot
holla,
slash
config
file,
and
there
are
some
supplementary
files
that
are
stored
in
subdirectories,
like
the
profile
overwrite
files.
If
you
want
to
migrate
from
culture
to
operator,
it's
just
a
matter
of
of
copying
the
configuration
from
these
files
into
the
spinnaker
service,
yummy.
C
So
for
those
of
you
that
are
out
there
looking
at
wanting
to
use
spinnaker
in
your
environments
with
openshift
and
you'd
like
to
learn
more
from
the
community
starting
July
16th
to
the
23rd,
we
will
be
having
what
we
call
gardening
days
and
one
of
the
things
that's
great
about
these
gardening
days.
Is
you
have
access
to
the
AWS
teams,
the
Netflix
teams,
the
armory
teams,
as
well
as
other
people
inside
of
the
community,
to
actually
help
you
build
new
things
that
you
can
tie
directly
into
spinnaker
itself?
C
So
what
we
have
is
we
have
a
list
of
things
that
we
can
actually
start
building
together.
The
last
time
that
we
did
this,
we
had
a
company
called
plumie
for
those
of
you
that
are
doing
infrastructure
as
code
plumies,
a
great
company
to
look
at
where
they
do
things
a
little
bit
differently
than
defining
things
as
HCl
with
like
terraform
or
doing
things
in
Ruby.
C
C
C
Behalf
of
our
infrastructure,
and
we
have
our
delivery
and
from
the
infrastructure
you
actually
have
access
to
all
the
things
that
Herman
just
talked
about.
So
what
we
do
is
spinnaker
follows
a
service
account
type
model,
so
all
of
the
work
that
you
do
into
your
environments
will
actually
be
working
on
behalf
of
somebody
else.
So
when
you
go
ahead
and
you
two
boy
something
new,
because
it
is
continuous
delivery,
it's
not
acting
as
me
as
an
individual.
It
is
acting
upon.
The
service
accounts
that
you've
defined
through
the
operator.
C
Now,
when
we
actually
go
in
and
look
at
the
infrastructure,
that's
being
defined,
what
we
can
actually
see
here
is
we
can
see
the
regions
where
things
have
been
deployed.
We
can
see
the
accounts
that
are
being
used
and
we
can
also
go
in
and
see
the
states
of
all
of
the
different
things
that
have
been
deployed
now
here.
We've
got
an
example
where
we've
got
a
kubernetes
cluster
and
one
of
the
things
that
our
customers
love
about
this
capability
inside
of
spinnaker.
It's
when
I
actually
look
at
this.
C
These
are
things
that
you
would
normally
need
cube.
Ctl
access
to
which
means
you
would
have
to
define
a
user
account,
you
would
have
to
give
them
a
cube
config.
They
would
have
to
install
the
cube
CTL
seu
CLI,
and
then
they
would
have
to
learn
all
of
the
different
cube
CTL
commands
to
figure
out
how
they
get
access
to
this
data.
Now,
when
we
actually
are
sitting
on
top
of
the
deployment
itself,
what
we
can
do
is
we
can
actually
see
off
of
this
manifest.
C
We
can
scale
it
out,
we
can
undo
a
rollout
or
we
can
do
a
rolling,
restart
so
undoing
a
roll
I'm
doing
a
rollout
is
basically
just
going
back
in
time.
We
can
choose
a
previous
revision.
We
can
give
a
reason
why
we're
backing
this
out
and
we
can
go
ahead
and
redeploy
an
old
version
of
our
application.
C
This
is
really
powerful
again
going
back
to
giving
developers
the
ability
to
self-service
inside
of
the
environment
when
we
actually
go
in
and
look
at
the
pods
themselves,
we
can
even
go
in
this
was
deployed
as
a
replica
set.
We
can
go
in
and
look
at
the
replica
set
action,
so
we
can
delete
this
entire
deployment.
We
can
go
in
and
look
at
the
metadata
about
this
particular
deployment,
and
we
can
also
see
what
the
health
status
is.
Not
only
that,
but
we
can
drill
all
the
way
down
to
the
pod
itself.
C
So
when
we
go
in
and
look
at
the
pod,
we
can
even
go
in
and
look
at
the
logs,
so
here
I
can
see
for
this
particular
application.
I
can
see
that
I've
got
an
exception.
I
can
read
the
exception
from
here,
but
one
things
that
I
don't
have
to
worry
about
is
I,
don't
have
to
worry
about,
knowing
which
namespace
it's
been
deployed
to
and
running.
My
cube
CTL
commands
now
when
we,
how
do
we
actually
get
things
into
this
environment?
Well,
we
have
our
delivery
option
up
at
the
top.
C
Now,
when
we
look
at
the
delivery,
our
delivery
can
follow
a
number
of
different
models.
Now,
one
of
the
things
that
I'm
gonna
switch
over
to
is
I'm
gonna
switch
back
to
my
project
and
I'm
gonna
go
to
a
lot
of
people
struggle
with
the
notion
of
what
delivery
actually
means.
So
when
we
actually
talk
about
delivery,
delivery
is
broken
up
into
three
steps
and
that
is
build
provision
in
deploy.
There's
a
service
inside
a
spinnaker
called
Igor
that
actually
allows
us
to
be
able
to
connect
spinnaker
to
our
continuous
integration
solutions.
C
So
we
can
hook
this
up
to
our
gen
conservers.
We
can
hook
this
up
to
a
drone
I/o.
We
can
hook
this
up
to
conch
or
CI.
We
can
hook
it
up
to
worker,
there's
a
number
of
different
CI
solutions
that
you
can
connect
us
through
and
again.
The
way
that
you
set
up
that
connection
to
those
different
solutions
is
all
using
that
spinnaker
operator
model.
C
Now,
when
we
go
in
and
look
at
how
we
configure
this,
every
pipeline
that
is
created
ends
up
starting
with
a
configuration
and
the
configuration
is
broken
up
into
multiple
parts.
So
the
first
thing
is
what
artifacts?
If
any,
do
we
expect
to
exist
for
this
pipeline?
To
successfully
get
executed
so
here
what
we
can
do
is
we
can
actually
see
that
we've
got
a
get
ups
model
that
we're
making
sure
that
our
manifest
that
we
have
for
kubernetes
exists
inside
of
our
github
repository.
C
We
also
have
things
like
our
service
defined
inside
of
that
get-ups
model
as
well,
and
then
just
like
any
good
get
ops
provider.
What
happens?
Is
we
end
up
triggering
this
off
of
some
other
hook?
So
what
we
do
is
we
actually
have
an
automated
trigger
that
says,
coming
from
get
we're
actually
going
to
look
at
a
repository
type
of
github,
and
then
this
is
going
to
choose
the
organization,
the
project,
which
is
basically
your
repository,
and
then
what
branch
do
we
actually
want
to
listen
for
when
we
have
this
trigger
set
up?
C
We
also
have
permissions
configured
because
inside
of
a
lot
of
our
enterprise
customers,
they
have
the
issue
of
compliance
and
auditing,
as
things
are
actually
executing.
So
what
we
can
do
here
is
we
can
actually
define
the
teams
that
we
are
actually
allowed
to
execute
this
particular
pipeline.
So
when
you
actually
log
in
you,
can
see
up
on
the
top
that
I'm
currently
authenticated
and
I
am
actually
sitting
in
the
SE
manager's
team,
so
this
actually
allows
me
to
actually
trigger
this
manually
if
I
need
it
to.
C
If
it
came
in
through
an
automated
trigger
and
it
came
across.
What
will
happen
is.
Is
this
will
actually
trigger
this?
As
anybody
who
is
coming
from
the
se
manager
group
or
from
the
sales
engineer
group?
What
that
means
is,
if
there's
a
manual
judgment
that
needs
to
take
place
for
this
particular
pipeline.
The
only
people
who
can
approve
or
execute
on
those
manual
judgments
has
to
come
from
one
of
these
two
teams.
Now
up
at
the
top,
once
we've
actually
triggered
a
pipeline.
C
A
lot
of
this
work
is
all
being
driven
from
metadata,
so
down
at
the
bottom.
We
have
the
option
to
be
able
to
set
up
parameters.
Now
you
could
define
parameters
yourself
if
you're
doing
something
like
a
manual
deployment,
so
you
can
actually
choose
or
type
in
a
value,
but
a
better
way
to
be
able
to
get.
Those
values
is
by
actually
getting
those
values
from
some
other
system
in
your
DevOps
tool
chain.
C
So
here,
I
can
actually
set
up
a
build
and
push
so
what
I've
done
here
is
I
go
ahead
and
build
so
again.
I've
got
my
Jenkins
servers
configured,
so
I'm
gonna
go
ahead
and
use
the
Jenkins
API
to
act.
We
called
this
specific
job
now
when
that
job
executes,
you
can
actually
tell
Jenkins
in
the
workspace
to
actually
create
a
file
for
the
output
of
what
actually
happened.
C
So
the
first
thing
that
we
could
be
doing
is
again
in
that
get
ops
model.
We
can
actually
choose
the
account
that
we're
actually
going
to
connect
to
and
the
namespace,
and
what
we're
going
to
do
is
we're
actually
going
to
grab.
We
could
take
this
from
text.
We
could
also
grab
this
from
one
of
those
artifacts
that
we
defined
in
the
beginning.
Those
artifacts
would
then
be
used
to
actually
provision
that
particular
load
balancer
inside
of
our
kubernetes
cluster.
C
C
So
if
I
was
to
deploy
my
back-end
API
services
and
then
I
had
my
web
front-end
connecting
to
that
what
I
can
do
is
I
can
map
those
dynamically
during
the
deployment
process
and
then
the
last
thing
that
we
can
do
is
we
can
even
do
things
where
we've
got
some
work,
where
we
can
even
do
provisioning.
So
here
we
can
provision
an
s3
bucket,
so
you
could
use
this
either
with
our
custom,
terraform
integration
or
you
could
do
this
as
a
run
job
and
possibly
execute
something
as
ansible.
C
Now,
if
we
go
in
and
look
at
what
actually
came
from
the
stages
beforehand,
I'm
gonna
show
you
how
we
can
actually
use
the
metadata
that
comes
from
those
stages.
This
is
using
something
called
spell
so
spell
inside
of
here.
What
we're
doing
is
we're
grabbing
information
from
a
previous
stage,
so
here
we've
got
stage
fine
controller
and
then
we're
just
walking
the
JSON
path
until
we
get
to
the
host
name,
the
host
name
that
is
actually
being
stored
inside
a
spinnaker.
Is
this
name
coming
back
from
AWS?
C
The
other
thing
that
we
can
do
is
we
can
look
at
information
that
came
back
from
Jenkins,
so
here
we
can
look
at
the
build
and
push
stage
and
we
can
actually
get
the
build
info
and
grab
the
number,
and
here
we
can
use
that
as
our
tag
that
we
want
to
use
as
part
of
our
deployment.
Now
when
we
actually
want
to
go
and
deploy
this
particular
item,
what
happens
is
now?
You
would
normally
do
this
as
an
artifact,
so
something
that
would
exist
in
your
git
repository,
but
for
demo
purposes.
C
We
want
to
be
able
to
show
you
what
this
would
actually
look
like
from
inside
a
spinnaker,
so
this
would
be
your
manifest
that
you
would
define
we
would
have
our
deployment
kind,
and
what
would
happen
here
is
if
you
were
using
any
of
the
custom
CR
DS
that
you
wanted
to
use
for
openshift.
You
could
use
those
in
here
as
well.
C
We
have
a
number
of
customers
today
that
are
using
spinnaker
with
our
open
shift,
environments
and
we'd
be
more
than
happy
to
talk
to
anybody
about
how
we
actually
enabled
those
capabilities
inside
of
their
environments
and
down
here
down
at
the
bottom.
We
now
grab
the
eight
yeah
URL
that
was
coming
back
from
the
parameters
that
we
defined
before
and
we
can
then
take
the
value
from
that.
We
can
also
grab
the
image
name
in
here.
We
can
see
that
we
grabbing
the
tag
from
that
expression.
C
Now,
when
we
actually
have
this
information,
this
will
then
end
up
creating
a
deployment
and
if
we
go
back
and
look
at
an
execution
that
happens
so
here
if
I
look
at
all
of
the
artifacts,
so
here
we
can
make
sure
that
we've
got
our
our
get-ups
file.
Here,
we've
got
our
docker
image
here
we
have
our
service
defined
here
and
then
we
have
an
artifact
which
is
a
web
page,
which
is
actually
mapped
back
to
the
github
hash.
We
can
also
see
the
execution
details
of
a
particular
pipeline
directly
from
inside
the
web
UI.
C
So
if
we
go
in
and
look
at
the
provision
s3
bucket,
we
will
see
that
this
is
actually
coming
from
a
different
pipeline.
So
if
I
go
to
that
pipeline,
I
can
actually
go
in
and
see
the
console
output,
and
this
is
the
terraformed
execution
that
actually
happened
on
my
behalf
now,
one
of
the
things
that
a
lot
of
people
don't
like
about
the
way
that
a
lot
of
provisioning
tasks
take
place
is
when
they're
doing
infrastructure
is
code
a
lot
of
times
what
they
do
is
they
have
to
go
into
their
ticketing
system.
C
C
Unfortunately,
what
happens
is
there
are
ways
to
be
able
to
get
access
to
those
resources
outside
of
your
continuous
delivery
tool,
so
somebody
could
go
in
and
modify
the
s3
settings
and
if
they
modify
those
as
three
settings,
nobody
really
knows
until
you
go
through
all
the
different
auditing
that
you
can
go
through
and
find
out
who
actually
made
the
change
with
spinnaker.
What
we
can
do
is
we
can
enforce
the
best
practices
every
time
a
new
deployment
takes.
C
So
if
somebody
was
to
go
in
and
let's
say,
change
the
Akal
for
my
s3
bucket-
and
let's
say
they
changed
it
to
public
right
I
would
actually
see
that
I'm
going
to
be
setting
this
back
to
public
read.
So
what
I
can
do
is
I
can
optimize
my
cloud
security
model
by
enforcing
certain
infrastructure
being
created
at
the
time
of
my
deployment.
C
Rather
than
doing
things
in
two
different
teams,
where
one
team
is
using
ticketing
and
going
off
and
doing
things
outside
the
other
thing
is,
is
the
app
dev
teams
are
going
off
and
expecting
those
things
to
exist?
What
happens
is
as
if
the
app
dev
teams
go
and
deploy,
and
it
wasn't
set
up
properly
and
they're,
using
api's
to
connect
to
those
resources.
C
The
deployment
overall
could
fail
and
a
lot
of
those
things
end
up
getting
lost
in
translation
and
it's
really
hard
for
the
teams
to
communicate
about
why
something
happened
and
why
something
went
wrong.
So
this
allows
everybody
from
inside
of
a
single
web
UI
for
everybody
to
stay
on
task
and
know
what
everybody
else
is
doing
when
we
actually
have
this
work
deployed.
What
we
can
do
is
we
can
do
things
that
make
really
interesting
pipelines.
C
So
what
I'm
gonna
do
is
I'm
gonna
go
back
to
the
backend
piece
and
when
I
look
at
the
backend
piece,
I'm
gonna
look
at
this
particular
pipeline.
Now
this
pipeline
is
really
intriguing,
so
what
happens
is
as
we
trigger
our
deployment
and
we
deploy
to
death
so
we're
gonna,
deploy
our
front-end
load
balancer
and
we're
gonna
deploy
our
pod
on
the
back
end
and
then
what
we're
gonna
do
is
we're
actually
gonna
run
a
Jenkins
job
that
has
already
been
defined
from
previous
work.
C
That's
going
to
use
something
like
a
selenium
runner
to
go
ahead
and
connect
to
the
end
point
of
the
load
balancer
to
go
ahead
and
run
a
smoke
test,
so
we're
gonna
use
the
API
in
Jenkins
to
go,
call
a
job
based
on
a
parameter,
that's
being
passed
in
from
spinnaker
and
then
what
we're
going
to
do
is
based
on
the
success
of
the
smoke
test.
We
will
automatically
go
ahead
and
deploy
to
stage
when
we
it's
a
stage.
What
we
can
do
is
we
could
update
our
service
now
ticket.
C
We
could
update
our
Atlassian
service
test
ticket.
You
could
automatically
say
that
the
smoke
test
has
been
completed,
so
you
have
visibility
and
traceability
in
those
systems
that
you've
already
got
in
place
to
be
able
to
know
when
things
have
been
marked.
As
successful
once
we've
deployed
to
stage,
we
can
run
a
full
QA
suite
and
when
we
do
the
full
QA
suite
one
of
the
things
that
we
want
to
make
sure
that
we
do
is,
we
can
actually
go
in
and
run
what's
called
a
canary
analysis
now.
C
C
So
if
you're
a
website
like
something
like
github
or
Atlassian
or
AWS,
you
can
actually
do
what
we
call
traffic
shadowing
and
actually
generate
enough
traffic
in
a
very
short
amount
of
time
to
be
able
to
know
if
your
application
is
performing
at
the
same
level
based
on
the
latest
code
changes.
If
your
application
is
not
generating
the
same
amount
of
traffic,
then
what
we
need
to
do
is
we
need
to
deploy
equal
baselines
and
equal
experiments.
C
C
Do
something
a
lot
of
organizations
will
either
call
it
a
bake
or
they
will
call
it
a
soak
and
that
application
is
going
to
sit
in
that
environment
for
some
predefined
amount
of
time
again,
depending
on
how
much
traffic
you
can
actually
generate.
You
can
define
this
as
hours.
You
can
define
this
as
minutes
or
any
combination
of
the
two
you
can
delay
how
long
if
you've
got
things
like
you've
got
a
warm-up,
a
cache.
C
So
what
we're
gonna
do
here
is
we're
basically
going
to
say:
how
often
do
we
want
to
go
to
our
APM
vendor
and
go
and
get
the
data
that
we
can
actually
store
inside
the
spinnaker,
and
then
how
often
do
we
want
to
evaluate
that
data
against
a
canary
config
and
that
canary
config
is
actually
defined
here,
and
what
we
can
see
is
from
that
canary
config
we're
going
to
be
evaluating
off
of
these
two
individual
deployments
that
have
taken
place.
So
if
I
go
in
and
look
at
my
canary
config.
C
What
I'm
going
to
see
is
I'm
going
to
see
three
metrics
that
we
have
defined
so
we've
defined
one
for
CPU,
one
for
RAM
and
one
for
I/o
and
down
at
the
bottom.
What
we
have
is,
we
have
something
called
a
judge
now,
a
lot
of
times
when
you
talk
about
doing
canary
analysis,
one
of
the
first
places
that
we
go
to
is
we
don't
really
know
what
data
we
should
actually
be,
comparing
so
what
Google
and
Netflix
have
done
is
they
have
gotten
together,
based
on
the
deployments
into
their
environments?
C
C
So
mann-whitney
will
remove
the
outliers
and
pick
a
square
that
is
underneath
that
bell
curve
for
the
actual
data
that
it
actually
wants
to
compare,
and
then
what
we
can
do
is
off
of
the
data
that's
being
compared.
We
can
then
specify
specific
weightings
where
maybe
we
are,
our
application
is
CPU
constrained
or
it
is
I/o
constrained.
We
can
actually
map
the
group
weights,
so
we
could
group
that
compute
is
more
important
to
us
or
io
is
more
important
to
us,
and
this
really
depends
on
the
workloads
that
you're
deploying
now.
C
C
C
You
can
mark
these
things
as
two
different
types
of
analysis,
so
you
can
actually
look
at
any
one
of
the
individual
plots
and
of
that
plot
you
can
come
back
and
say
this
went
greater
than
80%
when
my
memory
utilization,
spiked
I,
want
to
go
ahead
and
I
just
want
to
fail
this
canary
analysis
completely.
The
other
option
you
have
is
you
can
measure
it
based
on
the
average
across
the
entire
canary
run.
C
So,
if
you're
going
ahead
and
you're
doing
an
evaluation
over
a
24-hour
period
of
time,
what
you
can
do
is
you
can
actually
do
that
analysis
as
an
average
across
the
entire
run,
and
then
do
your
analysis
off
of
that
and
that's
where
those
results
come
back
into
the
pipelines.
If
we
go
back
and
look
at
this
particular
canary
run,
will
that
go
find
it
Oh
to
a
different
application?
C
So
our
canary
analysis,
here
we
can
see
at
a
high
level
that
we
have
a
hundred
percent
and
we
can
see
each
time
that
this
canary
was
actually
analyzed.
We
have
a
hundred
percent
success
rate,
but
you
can
also
go
in
and
look
at
the
specific
charts
for
this
particular
run
of
the
data
points.
You
can
also
go
in
and
see
here
what
time
this
actually
executed
and
when
it
was
executed.
C
So
all
of
these
things
make
spinnaker
a
very
powerful
platform
for
you
to
be
able
to
design
your
continuous
delivery
solutions
off
of,
as
we
talked
about
being
able
to
build
more
and
more
plugins,
so
we're
building
Kayenta
as
a
service
for
canary
so
we're
starting
to
build
plug-in
points
for
cayenne
tests,
we'll
be
able
to
plug
in
things
like
Splunk
or
log
stash.
So
we
can
create
judges
around
error
rates
being
able
to
dig
deeper
into
different
homegrown
solutions
that
you
may
have
developed
internally.
C
So
we've
got
about
eight
minutes
left
and
we've,
given
you
a
pretty
good
overview
of
how
to
get
up
and
running
with
a
spinnaker
operator
to
be
able
to
get
spinnaker
up
and
running,
and
we've
also
shown
you
some
examples
that
we
hope
have
piqued
your
interest
where
you
might
be
interested
in
using
this
with
some
of
your
open
ship
deployments.
What
I'd
love
to
be
able
to
do
now
is
open
it
up.
C
A
Right
Lee,
thank
you
very
much.
I'm
gonna
get
you
to
pop
back
into
your
side
deck
so
that
people
can
find
the
links
to
get
ahold
of
you
and
the
resources
there.
You
have
there's
one
question:
that's
just
come
in
that.
How
does
spinach
spinach
compare
with
open
ships,
tectonic
pipelines
and
I?
Think
there's
also
there's
a
number
of
in
the
CD
foundation,
there's
a
number
of
tools
that
do
CD
so
and
they
all
have
their
benefits
and
value
propositions.
C
Sure
so
Tecton
is
a
great
project
and
we
actually
work
with
a
lot
of
the
engineers
at
Google
that
and
IBM
and
Red
Hat
that
are
actually
working
on
Tecton
and
one
of
the
things
that's
really
important
to
understand
is
spinnaker
not
only
supports
your
open
ship
deployments,
but
it's
going
to
support
those
deployments
outside
of
OpenShift
as
well.
So
you
may
have
some
legacy
deployments
that
you're
deploying
to
let's
say
vCenter,
or
maybe
it's
an
ec2
image
or
maybe
you're
deploying
lambdas.
C
It
doesn't
really
show
you
some
of
the
details
like
we
have
inside
a
spinach,
where
you
can
actually
drill
into
the
details
to
actually
get
a
lot
of
the
data
back
now.
We
believe
that,
eventually,
what
will
end
up
happening
is
there
will
be
a
plugin
that
will
exist
because
the
orchestration
engine
that
exists
into
spinnaker
is
built
off
of
a
lot
of
the
different
spring
technologies.
So
it's
using
quartz
for
scheduling
it's
using
other
things
for
basically
doing
all
of
the
different
tasks
that
are
necessary
underneath
a
specific
stage.
C
So
there's
a
lot
of
work
when
you
look
at
the
technical
community,
which
I
know
they're
gonna
get
there
and
kubernetes,
and
some
of
those
things
are
still
evolving
to
the
size
of
deployments
and
scale.
Those
are
the
things
that
are
really
important
to
our
customers
today
and,
like
I
said,
we
want
to
be
able
to
work
with
the
tech
time
community
in
the
future
to
be
able
to
allow
our
plugins
and
their
plugins
to
be
able
to
be
used
in
the
same
way.
A
All
right,
I
think
that
was
that
was
I
think
what
well,
especially
with
the
CD
foundation.
What
we
are
seeing
is
a
lot
of
collaboration
between
all
of
the
different
seed
projects
out
there.
So
I
think
you'll
see
a
lot
of
a
lot
of
good
insights
from
both
sides
going
back
and
forth.
One
of
the
things
you
did.
We've
talked
quite
a
lot
about
the
spinnaker
operator
and
I
think
SK.
If
I
I
remember
the
conversation
earlier,
you
were
one
of
the
people
that
worked
on
the
operator
itself,
he's
also
in
the
chat
here.
D
D
We
have
done
a
lot
of
extensive
usage
of
operator
on
kubernetes
a
little
bit
only
an
open
shift.
We
know
we
are
aware
that
there
are
a
couple
of
things
that
don't
work
in
the
open
shift
platform
and
we'll
be
looking
to
get
those
fixed
even
for
our
certification
process
come
on.
Do
you
want
to
talk
a
little
bit
about
the
specific
things
that
maybe
we
still
need
to
work
on
for
the
open
shift
platform?
D
B
Actually,
today,
if
you
follow
the
QuickStart
instructions
or
the
operator
one
star,
because
on
permissions
issues
in
the
file
system
of
the
pod
of
operator,
this
can
be
fixed
just
by
changing
some
of
the
configuration.
So
you
can
run
the
operator
today
in
open
ship,
but
it's
not
the
process
that
is
out-of-the-box
and
we
work
to
make
this
out
of
the
box
and
to
fix
any
issues
that
arise
in
App,
Engine.
D
A
Now,
that's
actually
really
great
news
and
probably
a
perfect
timing
as
we're
going
into
duquan
in
mid-august
and
so
we'll
be
able
to
revisit
all
of
that
and
maybe
get
a
demo
of
it
running
on
open
ship
via
the
operators.
So
today,
if
you
wanted
to
run
it
on
an
open
shift,
besides
the
uppers
and
a
little
I
have
a
little
confusing
between.
Could
we
have
or
are
people
running
it
using
Haller
Elliot?
Is
that
how
you
Callard
on
OpenShift
now
or
is
it?
Are
we
awaiting
the
operator.
C
Let
you
know
that
I
actually
have
quite
a
few
customers
that
are
using
openshift
with
spinnaker
today
and
we're
continuing
to
grab
enhancements
outside
of
the
operator
which
helps
you
manage
spinnaker
itself.
But
then
also.
How
do
we
deploy
into
openshift
and
that's
where
we
would
love
to
be
able
to
have
the
openshift
community
come
to
our
gardening
days
and
be
able
to
provide
us
feedback
on
to
how
they
actually
use
openshift
in
their
production
environments?
A
That
might
be
a
great
way
to
end
on
here
today
and
and
besides,
which
I
wanted
to
say
how
much
I
love
the
gardening
metaphor
for
the
hackathon.
If
you
want
to
skip
back
to
that
gardening
landing
page
or
the
gardening
slide
that
you
had
there
Lee
or
there
and
I'd
really
highly
encourage
people
to
participate
in
this,
especially
folks
and
from
openshift,
who
are
already
using
spinnaker
to
come
here
and
then
maybe
we
can
move
forward
with
the
operator
and
get
more
feedback
on
this.
A
This
is
a
great
opportunity
and
anytime
someone's
willing
to
help
through
a
hackathon.
We
should
definitely
take
advantage
of
it
across
the
open
ship
community
and
when
you
do
have
the
operator
working
and
certified
for
open
ship,
we'll
definitely
have
you
come
back
and
give
a
demo
of
live,
deploying
it.
So
that
would
be
another
awesome
opportunity
for
us
to
get
more
information
and
get
you
more
visibility
and
feedback
from
our
community
and
we'll
have
to
see
what
you
know.
A
A
Thank
you
Ali.
You
really
did
an
awesome.
You
and
her
mom
did
an
awesome
job
setting
us
up
here,
but
I
really
thank
you
for
taking
the
time
to
do
this
deep
dive
into
spinnaker.
Getting
me
up
to
speed,
and
hopefully
the
rest
of
the
community
as
well.
I,
look
forward
to
to
hearing
more
for
you
guys
in
the
future
and
hopefully
we'll
get
that
Armory
spinnaker
operator
in
operator
help
dot
IO
as
well.