►
From YouTube: Argo for Spinnaker [Sponsored by OpsMx]
Description
*cdCon + GitOpscon May 8 - 9, 2023*
Register now ➡️ https://events.linuxfoundation.org/cdcon-gitopscon/
*CD Foundation Links*
Spinnaker: https://spinnaker.io/
CD Foundation Website: https://cd.foundation/
Slack: https://join.slack.com/t/cdeliveryfdn/shared_invite/zt-nwc0jjd0-G65oEpv5ynFfPD5oOX5Ogg
Contact us: https://cd.foundation/about/contact/
Speaker: Gopinath Rebala
Gopinath is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures of OpsMx Enterprise for Spinnaker. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well known leader in continuous delivery and in the Spinnaker community.
LinkedIn: https://www.linkedin.com/in/gopinathrebala/
A
Thank
you,
hi
everyone.
Thank
you
for
joining
this
webinar,
which
is
brought
to
you
by
the
CD
foundation
and
presented
by
opsmx,
one
of
the
sponsors
of
connector
Summit
2022..
The
next
Pinnacle
Summit
is
happening
next
month,
May,
8th
and
9th
in
Vancouver
Canada.
If
we
be
co-located
with
silicon,
and
we
can't
wait
to
see
you
an
entire
Community
there,
my
name
is
I
work
at
the
Linux
Foundation.
As
the
executive
director
of
the
city,
Foundation.
A
Deliver
software
security
and
speed,
we
help
you
figure
out
the
best
day
of
spread
towards
becoming
a
high
performing
team
using
open
source.
Today
copy
nutribala
joins
us
to
present
the
webinar
with
the
title.
What
clinical
users
should
know
about
Argo
CD?
This
was
pre-recorded,
but
coconut
and
optionic
socks
are
in
the
chat
for
the
premiere
today.
So
please
ask
your
questions
as
like.
They
come
to
you
and
coconut,
and
his
colleagues
could
answer
those
questions
as
he
presents
topic.
Coffee
nut
I
hand
it
over
to
you
so
tell
us
more
about
CB.
A
B
Let
me
just
share
my
screen:
I'm
Gopi,
Ebola,
I'm
CTO
of
optimix
and
I'm,
also
a
technical
oversight,
company
member
for
Spinnaker,
and
we
work
with
lots
of
organizations
that
use
Spinnaker.
We
are
one
of
the
largest
contribution
contributors
to
Spinnaker,
so
we
wanted
to.
We
heard
we
see
Argo
coming
up
and
we
wanted
to
have
a
conversation
with
Alcoa
and
Spinnaker
together.
B
Thanks
for
everyone
for
joining
us
today,
brief
overview
on
optimax,
we
are
a
continuous
delivery
company.
We
work
with
Spinnaker
and
Argo.
Our
goal
is
to
ship
better
software
faster.
We
do
it
by
enhancing
this
automation
intelligently
and
importing
everyone
in
the
process.
We
work
with
large
number
of
organizations
in
configuring,
their
Delivery
Systems.
Let's
try
to
jump
right
into
it.
B
There
are
a
lot
of
organizations
that
run
thousands
of
pipeline
executions
a
day
using
Spinnaker
to
deliver
with
software
to
various
environments.
It
supports
multi-cloud
environments,
all
public
clouds,
kubernetes
serverless,
and
there
are
extensions
that
are
done
to
the
Spinnaker
that
support
not
as
much
well-known
environments
like
Dell
boomi
or
a
few
other
things
there's.
So
it's
a
very
widely
used
for
delivering
to
these
large
number
of
environments
and
it's
pipeline
structure.
It's
a
visual
pipeline
that
enables
a
collaboration
between
all
the
stakeholders
in
the
delivery.
B
It
essentially
gives
you
visual
representation
of
what
is
going
on
in
the
delivery
and
also
presents
the
target
cluster
view.
What's
currently
running
allows
you
to
diagnose
faster
share
the
information
recover
from
problems
a
lot
faster,
so
these
are
all
real
strengths,
and
since
the
Enterprises
have
their
own
policies
for
delivering
for
production
environments
and
highly
secure
environments,
they
there
are
enough
Integrations
that
are
already
done
with
the
devops
tools,
for
example,
alternative
analysis
tools
or
policy
verification
tools
are
other
Enterprise
application
systems.
B
Now,
looking
at
the
power
of
our
goal,
Argo
is
primarily
designed
for
kubernetes
as
a
guitars
controller.
It's
a
kubernetes
native
controller.
You
configure
an
application
that
represents
the
GitHub
project
and
a
Target
namespace
in
a
cluster.
It
runs
in
the
kubernetes
looking
for
any
drift
or
changes
in
the
kit
can
be
drift
in
the
Target
environment
and
keeps
them
in
sync:
it's
a
purely
based
on
github's
model
because
of
the
nature
of
kubernetes.
B
With
the
declarative
structure,
it
can
apply
the
declarative
manifest
to
it
and
then
verify
if
the
state
is
reached
or
not,
and
look
for
changes
in
the
gate
in
the
declarative,
spec
and
keep
them
together.
It
has
a
strong
Progressive
Integrations
it
basically
rollouts
is
again.
Another
controller
allows
you
to
declare
it
to
specify
what
the
target
structure
needs
to
be
and
allows
imperative
spec
on
what
steps
need
to
be
taken.
B
The
strength
here
is:
it
has
a
previous
Integrations
to
service
mesh
like
istio
and
the
routers
to
control
the
traffic
and
any
failure
that
can
be
detected
and
automated
rollbacks.
We'll
talk
a
little
bit
more
on
that
that's
one
of
the
core
strengths
that
we
usually
exploit
from
Argo.
It
also
supports
application
sets,
which
is
essentially,
if
you
are
rolling
out
to
the
multi-cluster
different
regions.
B
Same
application
going
to
n
number
of
clusters,
then
it
supports
that
structure
with
the
select
statements,
so
one
of
the
drawbacks
there
is,
it
did
not
have
much
control
on
the
Progressive
deployments
to
all
these
clusters.
All
the
Clusters
are
treated
the
same
and
gets
deployed,
and
so
now
that
we
understand
it
a
bit
more
about
what
are
the
strengths
of
Argo
and
Spinnaker,
and
you
know
let's
get
into
how
these
things
are
being
used
together
today
and
whatever
you
have.
B
Each
one
enhances
the
other
one,
as
we
saw
there
is
a
progressive
rollout
of
a
deployment
in
kubernetes
is
a
strength
of
our
goal
and
in
Spinnaker
you
can
achieve
that.
But
you
need
to
use
multiple
stages
and
you
may
have
to
write
your
custom
stages
for
doing
that
and
that
you
get
it
automatically
if
you
use
the
rollouts.
So
that's
one
of
the
places
that's
fairly
strong
Synergy
between
Marco
and
Spinnaker,
that
you
can
use
the
rollout
or
Google
roll
out
with
Spinnaker
deployment
per
kubernetes.
B
Of
course,
the
other
place
is
the
staged
and
delivery
is
the
typical
workflows
always
involve
some
kind
of
a
test
environment
and
then
pre-production
or
staging
and
then
going
to
the
production,
because
Argo
is
more
of
a
git
Ops
model.
Each
of
these
environments
have
their
own
git
repositories
and
the
promotion
across
these
environments
is
usually
manual
and
automating
that
and
having
a
structure
that
can
support.
That
is
what
Spinnaker
brings
to
it,
because
Spinnaker.
A
B
Always
been
used
to
automate
this
delivery
across
different
environments
and
the
other
one
that
we've
seen
is
the
progressive
delivery
across
multiple
clusters.
In
the
same
application,
there
are
a
couple
of
different
use:
cases
that
are
most
common.
One
is
having
this
application
run
in
multiple
clusters
and,
while
delivering
to
these
clusters,
you
want
to
have
some
kind
of
a.
B
Delivery,
you
deployed
one
cluster
first
verify
everything
is
good
and
then
go
to
the
others,
kind
of
and
and
then
only
on
success.
You
deployed
everyone.
The
other
use
case
that
we
see
here
in
the
multi-cluster
is
in
the
SAS
environment.
There
are
sometimes
a
common
sense
structure
and
there
is
per
customer
or
per
application.
You
have
a
separate
system,
that's
dedicated
for
that
customer.
In
that
case,
you
end
up
with
n
number
of
clusters
that
you
need
to
deploy
to
with
a
slight
variation
in
configuration.
B
B
B
It
works
as
a
controller
with
a
looking
for
a
custom
resource
definition
and
when
say,
deploy
the
custom
resource.
It
picks
it
up
and
then
executes
that,
and
so
it
basically
enables
Advanced
deployment
strategies
like
Canary
or
blue
green.
It
supports
traffic
shaping
independent
of
scaling
the
instances,
so
you
can
control
yeah
I
can
have
a
grinder
control
in
your
delivery
process.
Deployment
process,
the
abstraction
it
provides
in
terms
of
the
spec,
also
makes
it
easy
to
use,
and
it's
already
currently
being
used
by
large
number
of
organizations.
B
So
how
does
this
blue
green
work?
I
mean
this
is
a
fairly
generated
concept,
but
just
wanted
to
touch
on
the
the
rollouts
with
the
blue
green
with,
so
we
can
discuss
how
these
strategies
are
set.
It
supports
blue
green
canon
in
the
blue
green
you're,
looking
at
bringing
up
a
new
instance
with
a
similar
number
of
instances
of
the
new
version
as
that
of
the
old
version.
So
these
are
the
cases
where
you
use.
You
don't
have
to
do
the
test
in
the
production.
B
You
essentially
bring
up
the
new
instances
and
then
switch
traffic
to
it.
All
the
production
traffic
goes
to
the
new
version,
and
the
advantage
of
the
blue
green
is
that
you
have
the
old
version
running
in
case.
Something
doesn't
work.
You
can
switch
back
to
the
old
version
almost
instantaneously,
so
there
is
the
you
can
reduce
the
amount
of
downtime
you
have
and
once
you
switch
to
the
new
version,
all
the
traffic
will
be
sent
to
the
new
version.
B
It's
a
there
are
cases
where
the
blue
green
is
the
most
suited
structure,
particularly
when
there
are
other
dependencies
behind
which
are
related
to
your
database
or
third-party
services.
This
structure
works
the
best,
but
it
has
its
disadvantages
in
that
in
the
production
you
won't
be
able
to
test
it.
So
the
rollback
for
the
blue
green
works
by
simply
switching
the
traffic.
So
how
do
we
determine
the
failure?
B
How
quickly
you
can
determine
or
either
manual
or
you
can
automate
it
through
the
steps
with
automatic
verification,
yeah
we'll
look
into
that
a
little
bit
later
and
the
Kennedy
deployment
here
it
works
with
ability
to
test
in
production,
so
you
bring
up
a
new
instance
of
of
a
new
version
in
parallel
to
the
existing
versions.
Here,
if
you
want
to
test
it,
you
could
set
up
based
on
the
header
based
routing
the
test
traffic.
That's
going
to
Canary
or
you
can
have
the
production
traffic
going
to
Canada.
B
In
fact,
the
advantage
here
with
the
canary
instances
is
that
the
blast
radius
is
small
in
case
of
failure.
You
will
have
the
production
instance
working
in
parallel
to
the
existing
current
version.
That's
running
in
the
production
in
small
amount
of
traffic
goes
to
the
new
version
and
if
everything
looks
good,
you
can
increase
the
traffic
and
the
number
of
instances
for
the
Kennedy,
and
if
you
find
something
is
not
working
well,
the
the
blast
radius
is
small
and
you
can
roll
back
fairly
quickly
and
switch
all
the
traffic
back
to
the
existing
version.
B
So
there
are
advantages
of
Blue,
Dream
and
Canary
in
the
blue
green.
You
can
still
do
testing,
but
you
essentially
bring
up
a
separate
service.
It's
not
simply
routing
the
existing
traffic,
but
you
actually
bring
up
a
separate
service
and
have
a
test
traffic
go
to
it,
and
if
everything
looks
good,
then
you
can
have
switch
the
production
traffic
to
that
instance,
and
then
you
have
to
take
down
the
in
the
instance.
B
You
brought
up
for
a
test
for
the
service
routing
and
so
there's
a
little
bit
more
complexity
there,
but
all
of
these
are
supported
by
our
rollouts
will
quickly
show
some
of
the
specifications
how
we
can
set
it
up
with
the
our
rollout
specification
and
then
how
to
specify
the
rollback
conditions.
The
rollback
conditions
can
be
manual
are
automatic.
Today
we
will
look
at
the
specification
on
how
to
do
either
one
of
them
yeah
it's.
So
it's
a
quick
view
of
how
the
our
loudspec
is
specified.
B
The
things
to
look
at
here
is
it's
a
rollout
type.
Basically,
as
you
know,
it's
a
custom
resource
that
we
apply
and
there
is
a
controller
operator
model.
It
picks
up
the
custom
resource
and
who
works
on
it.
This
works
completely
independent
of
Oracle
CD,
as
we
discussed.
So
if
you
are
working
with
August
CD,
since
Argo
CD
is
always
trying
to
synchronize
with
the
git.
B
Essentially,
what
happens
is
the
Argo
roll
out
sends
a
notification
to
Hardware
CD
saying
it
is
in
progress
and
the
Argo
CD
stops
its
synchronization
because
the
process
here
it
takes
time
to
synchronize
and
Oracle
CD
would
at
that
point
see
it
as
not
in
sync,
which
is
incorrect
and
also
we
don't
want
the
override
to
happen
so,
but
in
in
this
case,
with
this
vinegar,
we
are
not
using
Auto
CD.
We
are
simply
using
our
Google
loud
as
part
of
a
Spinnaker
stage
to
deploy
yes.
B
So
the
second
thing
to
note
here
is
this
workload
reference
here.
What
you
are
looking
at
is
the
deployment
and
deployment
name.
This
is
most
useful
when
you're
converting
an
existing
deployment
to
a
roller.
Let's
say
you
already
have
services
that
are
running
in
production
with
the
deployment
names
you
want
to
start
doing
a
rollouts
on
top
of
those
deployments
and
you
essentially
are
replacing
your
deployment
type
with
that
of
rollout.
So
you'd
scale
down
your
deployment
number
of
instances
and
then
kick
out
kick
off
a
roll
out
with
the
reference
to
the
deployment.
B
So
rollout
essentially
goes
and
looks
at
the
deployment.
That's
currently
running
picks
up
the
spec
for
that
deployment
and
then
does
that
does
the
deployment
with
kubernetes
with
the
strategy
that
is
defined
here.
So
this
actually
is
one
spec
and
the
strategy
then
specifies
how
the
rollout
happens
in
kubernetes
we
have
a
rolling
update
as
a
default.
So
essentially
this
one
is
adding
other
strategies
to
that
ruling
update
as
a
canary
in
the
canary
Services.
Now
you
can
specify
the
steps
here.
B
Weight
is
initially
has
the
Integrations
internally
to
go,
update
the
the
Ingress
weight,
further
traffic
shaping,
and
so
it
allows
the
traffic
to
automatically
apply
to
the
new
version
with
the
20,
40,
60
and
specific
duration
here.
So,
as
you
can
see,
this
is
a
simple
spec
of
the
rollout
that
can
be
used
in
Spinnaker
pipeline
directly
as
a
rollout
manifest
deploy,
but
the
pause
and
duration.
Here.
As
you
see
it's,
it's
not
doing
anything
other
than
waiting
for
some
amount
of
time
and
then
changing
it.
B
B
If
you
are
familiar
with
kayanta
in
Spinnaker,
you
can
use
that
for
this
automatic
verification.
With
with
your
metrics
that
you
are
deploying
some
of
the
complexities
that
we
face
in
the
deployment
there
or
when
you
do
a
new
version
deploy,
you
need
to
specify
what
is
the
ability
for
querying
for
the
metrics
for
the
new
and
old
version,
so
that's
solved
by
rollouts
in
an
interesting
way
here.
It
computes
the
odd
hash
values
to
further
manifest
for
the
existing
V1
and
V2
and
applies
them
as
a
label.
B
B
The
other
thing
to
note
here
is
this
experiment
under
the
canary
steps,
so
the
when
we
roll
out
a
new
version,
there
can
be
characteristics
based
on
this
application
that
makes
the
performance
of
the
new
version
different
from
the
existing
one.
It
could
be
because
there
are
caching
that
is
being
done,
makes
it
more
performant.
At
the
same
time,
it
also
uses
more
memory
and
then
the
freshly
deployed
one.
So
what
to
eliminate
those
kind
of
differences?
B
B
B
So,
just
to
recap,
the
rollout
spec
is,
is
a
kubernetes
manifest.
You
can
simply
use
it
as
a
deploy
manifest
in
a
kubernetes
and
deploy
stage.
The
the
only
drawback
without
any
changes
we
use.
That
way
is
that
rollout
does
happen,
but
the
status
of
the
rollout
with
individual
steps
and
their
feedback
is
not
presented
to
the
UI
in
Spinnaker.
So
for
this
we
have
an
extension
in
Cloud
driver
for
kubernetes.
B
There
is
extension
classes
that
allow
extend
to
support
different
custom
resources
so
extending
that
to
support
the
rollout
feedback,
allows
us
to
have
those
displayed
in
the
UI
and
also
helps
us
give
the
feedback
in
place
in
this
Pinnacle
ruler.
That's
the
only
extension
that
you
would
need,
and
once
you
have
that
you
can
use
the
our
Guru
all
out
for
kubernetes
for
kubernetes
deployment
with
Spinnaker
pipeline
is.
This
is
one
of
the
interesting
use
cases
that
are
being
used,
so
the
next
use
case
is,
with
this
staged
delivery
across
the
environment
right.
B
So
when
in
a
continuous
deployment,
we
want
to
be
able
to
automate
the
test
to
pre-production
staging
to
production
as
cleanly
as
possible
is
to
do
this
typically
in
applications
when
you're
deploying
to
kubernetes,
you
have
a
two
gig
repositories,
one
with
the
deployment
manifest
and
the
other
one
with
the
source
code
that
actually
builds
up,
Docker
artifacts
and
that
gets
deployed
in
Argos
is
typically
the
way
it's
configured
is
using
in
another
controller
called
image.
Updater
that
runs
in
the
kubernetes
namespace.
B
After
the
testing
is
done,
this
Auto
promotion,
what
it
does
is
it
takes
the
repository
from
staging
the
changes
emerges
into
the
production
environment,
including
the
changed
image
tags,
so
that
allows
this
automated
promotion
cleanly
without
manual
intervention
for
these
and
generates
a
rollout
to
the
production
as
soon
as
the
staging
verification
is
done.
So
this
is
a
fairly
strong
use
case.
That's
used
to
to
promote
lower
environment,
you
know
testing
to
the
production
environment,
so
this
is
very
useful
here.
B
One
of
the
interesting
things
that
you
can
do
is
also
as
the
pr
generated
for
the
staging
you
can
test
it
and
then
merge
only
of
the
test
succeeds
and
then
that
gets
promoted
to
production.
So
this
is
a
fairly
common
use
case
that
is
used
and
the
last
one
is
the
progressive
delivery
to
multi
a
cluster
environments.
Again,
as
we
saw
there's
a
progressive
delivery
to
one
deployment
with
our
Guru
launch
that
works
in
one
cluster
for
that
one
particular
application.
B
But
we
have
these
cases
where
these
applications
are
deployed
in
N
number
of
these
clusters
and
some
of
these
clusters
cater
to
low
priority
use
cases
and
then
some
of
them
much
higher
reliability
requirements
so
delivering
to
these
can
also
be
done
through
a
Spinnaker
pipeline.
You
essentially
roll
it
out
to
Cluster
one
which
is
like
a
pilot.
Customers
are
low.
Priority
use
cases
then,
once
that
rollout
is
successful,
then
you
kick
off
the
second
stage
in
Spinnaker
pipeline
that
deploys
to
second
set
of
regions.
B
Second
setup
customers
or
regions,
use
cases,
and
then
once
that
is
successful,
then
you
automate
the
rollout
to
higher
load
regions.
So
this
typically
is
done
manually
today
and
but
the
Spinnaker
pipeline,
in
conjunction
with
this
rollout,
really
automates
this
and
makes
it
a
clean
delivery
mechanism
going
all
the
way
they
do
all
their
clusters
from
low
use
case
to
high
load
regions.
B
So
this
is
a
very
high
level
overview
of
how
the
Argo
and
Spinnaker
are
being
used
and
in
the
Enterprises,
where
they
have
large
number
of
groups,
and
some
of
these
groups
are
using
Spinnaker
exclusively
in
some
of
these
groups.
You're
using
Argo
and
with
a
Spinnaker,
so
I
hope
this
gives
you
a
good
overview
of
how
these
are
currently
being
used
in
these
environments
and
please
reach
out.
If
you
have
any
questions,
we
will
be
available
on
the
YouTube
channel.
At
the
time
of
this
presentation
and
back
to
your
father.
A
Thanks
a
lot
for
a
great
presentation
and
thank
you,
everyone
for
joining
us
for
more
continuous
content.
Please
follow
the
CD
foundation
on
YouTube
and
Twitter
and
visit
our
website
https
cd.com
Foundation.
You
can
also
join
CD
foundations
like
as
a
sign
up
to
our
mail
list
to
take
part
in
conversations
and
contribute
all
the
links
are
in
the
description
below
don't
miss
our
Flagship
event
coming
up
silicon
and
githubscon,
which
we
are
co-hosting
with
the
cloud
native
Computing
Foundation.