►
From YouTube: Continuous Software Delivery Using Spinnaker and Jenkins in Cloud - Irshad A Buchh & Paul Roberts
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
Continuous Software Delivery Using Spinnaker and Jenkins in Cloud - Irshad A Buchh & Paul Roberts, Amazon Web Services
Continuous deployment is the best practice that has kept companies like Netflix and Amazon years ahead of most other software development companies. Spinnaker levels the playing field for smaller companies struggling with manual glue code and error prone processes. In this session Irshad shall discuss how Spinnaker enables companies to deploy software in cloud as rapidly as a web-scale company at a fraction of the cost and effort when integrated with existing CI tools like Jenkins. Irshad shall explain how Spinnaker treats Kubernetes applications as first-class citizens and helps the IT team deploy the application into any version of Kubernetes including Amazon EKS rapidly. Irshad shall also discuss how Spinnaker’s pipelines and strategies make it possible to deploy, scale, and manage individual services that are part of a larger microservices-based application.
A
Hi
good
morning,
good
afternoon,
my
name
is
Paul
Roberts
I'm,
a
Solutions
architect
here
at
Amazon
web
services
today,
I'll
be
presenting
along
with
my
friend
irshad,
and
we're
going
to
be
talking
about
continuous
software
delivery
using
Spinnaker
and
Jenkins
in
the
cloud.
Rashad
and
I
are
both
Architects
here
and
are
really
excited
to
talk
to
you
at
the
Spinnaker
Summit
today.
A
So
the
first
thing
is:
is
that
I'd
like
to
run
through
the
overall
agenda
and
we've?
We
thought
it
would
be
a
lot
of
fun
to
create
a
scenario
here,
and
this
is
the
pet
clinic
scenario
or
theme,
and
you
know
for
context.
I
recently
adopted,
you
know
a
new,
a
new
dog
she's,
a
white
German
shepherd,
and
so
we
wanted
to
get
her
integrated
into
this.
We
think
it's
going
to
be
a
lot
of
fun,
so
the
first
topic
is
going
to
be
talking
about
application.
Modernization
challenges
using
this
pet
clinic
scenario.
A
Next,
you
know
we're
going
to
get
into
a
little
bit
of
an
Amazon
eks
overview
and
just
to
give
you
you
know
some
insight
into
you
know
how
folks
are
you
know,
deploying
their
workloads
for
Spinnaker
inside
of
of
kubernetes
next
we're
going
to
provide
you
an
overview
on
continuous
software
delivery
and
then
we're
going
to
walk
through
infrastructure
as
code
using
the
terraform
cloud.
And
finally,
the
reason
why
you
all
are
here
is
we're
going
to
walk
through.
You
know
an
awesome
demo
that
our
shot
has
put
together.
A
A
You
know
our
website
has
been
a
little
outdated
and
we
we
need
to
go
through
a
modernization
effort
and
through
this
you
know
the
typical
way
of
you
know.
Building
you
know
a
new
website
and
deploying
new
artifacts
is
taking
us.
You
know
many
weeks
or
months
to
actually
get
this
done,
so
what
we
want
to
do
is
we
want
to
figure
out.
Is
there
a
way
that
we
can
use
newer,
Technologies
such
as
Spinnaker
to
help
us
with
this
modernization
effort?
And
so
through
this
we're
going
to
be
modernizing
our
pet
clinic?
A
You
know
live
so
today.
You
know
our
our
website
here.
You
can
see
that
you
know
we
have
this.
This
young
puppy-
and
you
know
this-
this
kitten
here,
which
is
totally
fine
but
as
I
mentioned
earlier,
is
that
you
know
I
recently
adopted.
You
know
a
new,
a
new
pet,
and
we
want
to
make
sure
that
you
know
this
new
pet
is
showing
up
on
the
website
appropriately
and
traditionally,
if
we
were
going
to
go,
go
through
this
effort,
you
know
we'd
have
to
go
edit
a
file
we
might
actually
have
to.
A
You
know
FTP
over
some
new
assets,
and
the
challenge
is,
if
you're
doing
that
it
could
be
very
cumbersome,
it's
prone
to
making
mistakes,
and
really
this
should
be
going
through.
You
know
a
full
CI
and
CD
continuous
integration
and
continuous
delivery
process
that
helps
us
avoid
any
of
these
challenges,
so
we're
going
to
walk
through.
A
You
know,
anytime,
we
make
these
changes.
If
we
have
to
do
this
manually,
we
can
make,
we
can
make
mistakes,
and
you
know-
maybe
we
don't
have
the
correct
image
here
and
that
can
certainly
be
a
problem,
and
you
know
rolling
out
these.
These
updates.
Not
only
is
it
making
the
changes,
as
you
know,
the
our
development
team,
but
then
pushing
out
these
updates
to
the
website.
It
does
take
time
and
as
as
I
said,
you
know,
we
were
historically
using
FTP
to
make
this
happen
and
it
was
really
difficult.
A
The
other
aspect
here,
as
you
know,
for
our
pet
clinic,
is
that
we
don't
have
a
huge
budget
and
you
know
we
we
don't
want
to
pay.
You
know
a
lot
of
money
to
make
this
happen,
so
we
want
to
rely
on
open
source,
and
you
know
there
are
a
few
open
source
technologies
that
can
help
us
do
this
today
and
then,
finally,
you
know
we've
been
reading
a
lot
about.
You
know
how
companies
are
doing
this
at
scale,
and
you
know
hyperscale
companies
such
as
Netflix
or
or
snap.
A
You
know
they
they've
been
using
some
new
technologies
to
make
this
happen,
and
so
we
want
to
look
at
you
know:
what's
the
way
that
they're
doing
this,
because
as
our
business
continues
to
scale
up,
we
want
to
be
able
to
stay
current
with
the
times
and
as
I
mentioned
you
know,
the
whole
theme
Here
is
is
that
you
know
pushing
changes
to
our
web
application.
It
just
takes
a
tremendous
amount
of
time
and
it's
prone
to
issues
and
we
want
to
come
come.
A
A
A
So
first
thing:
what
I
want
to
do
is
I
want
to
talk
about
Amazon,
eks
and
Amazon.
Eks
is
our
fully
managed
kubernetes
service,
and
you
know,
AWS
provides
it's
fully
managed,
kubernetes
service
and
what's
really
great
about
it,
is,
is
that
we
are
managing
the
control
plane
on
the
user's
behalf.
So
the
control
plane
runs
on
you
know
on
within
AWS
resources,
but
the
actual
workloads,
like
your
applications,
run
within
your
account
on
ec2
instances
that
are
in
your
account
that
you
fully
manage.
A
So
we
take
on
the
heavy
lifting
of
making
sure
that
the
API
server
fully
scales
that
etcd
into
the
database
component
fully
scales
and
then
and
then
in
terms
of
the
overall
upgrades.
We
also
have
you
know
a
managed
node
group
feature
which,
if
you
need
to
do
full
life
cycle
management,
let's
say
you
need
to
patch
your
instances.
A
You
know
we
can
handle
that.
So,
if
you
have,
you
know
security
policy,
that's
required
where
you
need
to
push
out
a
new
Army
every
you
know,
30
or
60
days.
A
new
machine
image
of
every
30
and
60
days.
You
can
totally
do
this
with
our
managed
node
group
feature
and
it
really
takes
on
that
heavy
lifting.
So
you
don't
have
to
worry
about
manually
upgrading
your
kubernetes
workers,
so
it's
it's
highly
scalable
very
flexible,
and
this
is
what
you
know:
we're
we're
choosing
to
use
for
our
pet
clinic
application
today.
A
B
B
Thank
you,
Paul
really
appreciate
it.
So
I
just
wanted
to
spend
some
a
few
seconds
on
talking
about
some
of
the
components
that
Paul
touched
upon.
We
will
be
using
in
this
presentation
from
The
Continuous
integration,
a
software
delivery
perspective.
There
are
two
things
that
come
to
outline.
One
is
for
continuous
software
integration.
Now
Jenkins
is
very
popular.
It's
open
source,
it's
got
a
great
developer,
Community
backing
and
then
lots
of
plugins
in
order
to
integrate
Jenkins
with
a
lot
of
other
services.
B
So
Jenkins
works
very
well,
and
it's
easy
to
you
know,
deploy
Jenkins
on
top
of
Amazon
ec2,
which
is
the
elastic
computer
cloud
service,
which
I'm
going
to
show
you
in
the
demo,
which
is
what
we
have
done
for
the
demo
as
well.
Now
what
Jenkins
does,
with
the
help
of
a
concept
of
pipelines
you
can
code,
we
can
codify
the
pipelines
and
make
it
very
easy
for
the
developers
to
focus
on
writing
code
and
then
even
codifying
those
pipelines
which
will
make
it
possible
for
us
to
deliver
software
at
scale.
B
Thank
you,
one
of
her
Partners
Armory
I,
just
wanted
to
spend
some
few
minutes
here.
Recently,
they've
done
an
awesome
job
of
rolling
out
this
new
service
call
continuous
deployment
as
a
service.
It's
a
SAS
service
that
runs
on
top
of
AWS
and
what
we
see
is
it
gives
you
a
easy
to
use
user
experience
for
deploying
your
software
at
scale.
So,
if
you
look
at
the
architecture,
you
know
Armory
continuous
delivery,
continuous
deployment
as
a
services
in
the
middle
and
then
on
the
other
side.
B
We
have
the
the
kubernetes
Clusters,
that's
the
the
environments,
the
Amazon
eks
for
instance.
What
do
we
want
to
deploy
and
deliver
software
at
scale,
so
Armory
city
as
a
service
uses
grpc
HD
V2
protocol
to
register
Amazon
ecas,
so
there's
a
concept
called
remote
Network
agent
when
you
register
Amazon
eks
clusters
via
this
service,
it's
actually
going
to
deploy
an
Asian
which
is
responsible
for
maintaining
the
bi-directional
communication
between
our
very
city
as
a
service
and
Amazon
ecas,
and
on
the
left
side
we
have
the
developers
writing
code.
B
Let's
say
you
know
we
use
GitHub
and
then
Source
control
and
Gita
has
a
touch
Point
using
trust
API
to
communicate
with
CDs
service.
We
have
integration
attachments
with
Jenkins
gitlab,
as
well
as
even
Spinnaker
and
Armory
what
they
have
done
as
well.
You
know
there
are
helping
developers
use
what
is
called
as
Armory
CDs
service
CLI,
which
will
enable
developers
to
use
CLI
in
order
to
deliver
software
at
scale
using
or
when
you
see
as
a
service.
B
B
This
is
a
good
offering
now
it
brings
a
lot
of
different
advantages
to
us
as
as
Builders
and
developers,
for
example,
there's
a
concept
of
organizations
and
workspaces
where
it
becomes
very
easy
for
us
to
manage
different
environments
when
we
deploy
them
on
AWS,
so
we
may
have
a
pre-production
environment
or
a
production
environment.
It
becomes
very
easy
for
us
using
workspaces
to
manage
those
different
environments
from
terraform
cloud.
B
Which
is
very
important
is
the
state
management.
Now
terraform
manages
infra
Provisions
infrastructure
and
it
maintains
what
is
called
as
the
state
of
the
infrastructure.
This
is
like
a
file
now,
if
you
use
open
source
terraform
you
as
a
developer,
you
will
have
to
maintain
and
then
the
the
storage
of
that
it
is.
B
You
know
infra
infrastructure,
state
right
and
becomes
very
difficult
for
you
to
scale
because,
let's
say
you're,
a
team
of
developers
and
you're
running
open
source
terraform
on
your
laptop,
your
other
developers
have
no
baby
visibility,
no
way
of
getting
and
then
using
that
the
state.
So
what
terraform
Cloud
does
it
maintains
the
terraform
state
in
the
cloud
so
for
developers
in
a
team
it
becomes
very
easy
to
work
on
the
same
projects.
B
Also,
it
gives
us
a
rich
user
interface,
it's
a
you
easier,
easy
to
use
interface
or
for
provisioning
infrastructure
and
working
in
a
team,
and
you
will
also
get
access
to
module
registry
where
we
have
built-in
modules.
You
know
that
Community
has
developed
or
you
as
a
team,
have
developed,
and
you
can
share
those
modules
via
teams
across
the
Enterprise.
B
Thank
you.
So
the
workflow
for
the
terraform
cloud
is
you
have
the
private
module
registry
which
are
created
by
the
developers
on
the
on
the
left
and
then
we
as
a
builder
or
or
a
developer.
We
write
infrastructures
code,
so
That
Remains,
the
Same
right.
We
write
hash
excl
files
to
to
provision
infrastructure.
This
would
be
Amazon
eks
or
you
know
different
types
of
compute
services
or
any
services,
and
then,
in
the
middle
we
have
the
using
API
calls.
We
use.
B
B
So,
let's
focus
on
the
architecture,
one
possible
architecture
for
delivering
software
at
scale
that
you
see
here
is
you
know
from
this
demo
that
we
have
prepared.
We
have
three
different
types
of
Amazon
NPS
clusters,
just
to
give
you
the
visualization
of,
if
you're
doing
it
in
in
production
or
pre-production.
So
we
have
two
different
clusters:
uat
cluster.
A
B
Or
or
you
know,
it's
an
interface
that
you
use
in
in
AWS,
it
runs
on
top
of
PC
too,
so
a
developer
using
a
AWS
Cloud9.
It
will
have
source
code
in
GitHub,
for
example,
that's
the
Version,
Control
right
and
then
writing
code
writing
features
and
then
pushing
those
changes.
Sourceful
changes
into
GitHub,
Source
control
and
what
all
that
does
is
that
triggers
Jenkins
Jenkins,
which
I
talked
earlier
from
continuous
integration
perspective.
B
B
It's
a
life
cycle,
so
what
that
will
do
is
that
those
pipelines
will
deploy
software
into
uat
cluster
and
then
once
the
software
gets
deployed
into
uat
cluster.
There
is
an
end
user
sitting
and
testing
that
software.
If
all
goes
well,
it
looks
good.
The
changes
look
good,
based
on
what
the
intent
was.
B
Then
there's
a
manual
approval
that
you
see
maybe
an
administrator
sitting
on
top
of
the
Spinnaker
Pipeline
and
then,
if
all
goes
well,
the
testing
goes
well,
then
that
approval
gets
approved
and
then,
ultimately
that
software
gets
to
deployed
using
Spinnaker
to
production
cluster.
So
that's
like
an
end-to-end
architecture
of
enabling
you,
as
Builders
and
developers,
to
deploy
software
at
scale
in
AWS,
using
a
number
of
the
tools
that
we
are
already
talked
about
all
right
at
this
point.
B
All
right
here,
I
am
logged
into
my
Jenkins
user
interface
and
I
have
a
job
which
is
already
pre-configured
to
run
a
pipeline
and
on
the
left,
you'll
see
the
build
history
and
on
the
right
side,
you
will
see
the
different
stages
of
this
pipeline
and
if
I
go
into
the
the
Jenkins
pipeline,
which
I
have
codified
you'll
see
the
the
code.
Here.
B
This
pipeline
comprises
of
comprises
of
a
number
of
stages
stating
start
starting
ground,
build
application,
and
then
we
have
test
application,
and
then
we
have
a
build
Docker
image
at
the
third
stage,
and
then
we
have
a
push
Docker
image
and
finally,
at
the
bottom,
you
will
see:
remove
local
images
just
to
free
up
all
the
space
from
those
Docker
images.
Now
all
of
these
stages
will
have
steps
which
we
have
codified
so
for
a
developer.
B
It's
one
time,
one
time
tasks
to
write
the
code
for
the
Jenkins
pipeline,
and
then
you
know
going
back
into
the
Jenkins
dashboard.
You'll
see
these
individual
stages
laid
out
for
you
in
the
stage
View,
and
these
are
some
of
the
the
previous
executions
that
I
have
executed
and
when
I
log
into
my
Spinnaker
console
I
I
see
here
three
pipelines,
Spinnaker
pipelines
as
you
can
see,
deployed
to
uat,
deploy
to
prod
and
then
manual
approval.
The
user
interface
lets
you
to
configure
these
individual
pipelines
so
I
have
to
deploy
to
uat.
B
B
Similarly,
I
have
the
deploy
to
a
crime
Spinnaker
pipeline,
which
looks
very
similar,
except
that
it
deploys.
It
gets
triggered
from
a
manual
approval
pipeline,
which
I
will
talk
about
next
and
it
deploys
to
a
production,
Amazon
and
gas
cluster.
Now
you
can
customize
these
Pinnacle
pipelines
depending
on
the
requirements
that
we
have
for
every
individual
environment,
so
pre-production
uat
may
be
different
than
a
production
environment,
and
once
we
do
that,
then
we
can
connect
these
pipelines.
So
we
have
the
manual
approval
pipeline,
which
is
like
an
approval
process.
B
This
gets
actually
triggered
by
the
deploy
to
uat
Pipeline
and
here
we're
asking
for
a
yes
or
no
or
an
approve,
or
a
reject
sort
of
a
kind
of
an
approved
process
that
if
uat
gets
deployed
okay,
should
we
go
ahead
and
deploy
to
production
environment?
So
this
is
a
good
way
of
connecting
different
Pipelines
in
a
chain
and
then,
if
we
come
to
the
load,
balancers
you'll
see
here
uat,
you
know,
I
have
an
Ingress
endpoint,
which
is
the
load
balancer
endpoint.
B
Similarly,
for
in
a
production,
environment,
I
have
a
load
balancer
as
well,
and
these
are
the
endpoints
of
the
application.
Here
we
have
the
application
running
in
uat
through
that
load
balancer
in
similar
the
other
pad
this
one.
This
is
running
in
production,
so
I
have
two
different
instances
of
the
application
running.
Just
to
give
you
an
illustration
of
how
you
can
have
the
you
know,
going
code
change
is
going
from
one
environment
to
the
other
environment,
so
let's
go
and
and
then
speak
from
a
developer
endpoint
perspective.
B
So
I
have
a
Cloud9
instance
that
I
talked
earlier
and
I
have
the
a
file
called
welcome.xg.com.
All
I'm
doing
is
I'm
updating
the
image
on
that
that
front
page.
They
welcome
HTML.
So
after
modifying
the
image,
I
save
the
changes
and
as
a
developer,
what
I
will
do
is
I
will
commit
these
changes
using
the
CLI
and
use
and
used
to
using
as
a
developer,
so
I
get
to
know.
B
The
welcome.html
file
has
changed
and
as
part
of
the
git
workflow
you
know,
I
will
be
now
pushing
these
changes
into
the
source
control
now
you'll
see.
Then
these
changes
get
push
to
the
self-control.
All
these
changes
are
documented
as
part
of
the
dead
workflow
process
right
and
immediately
after
I,
store,
updating
or
or
commit
these
changes
into
the
source
control.
What
will
happen
is
you'll
see
that
this
will
trigger
the
Jenkins
job.
B
So
here,
I
have
14
runs
that
I
have
done
as
part
of
the
bill
of
history
on
Jenkins,
so
dashboard
and
within
a
matter
of
few
seconds,
you'll
see
a
job
gets
triggered.
This
is
because
Jenkins
has
picked
up
the
change
from
The
Source
control
when
I
push
the
change,
so
that
triggers
the
whole
pipeline
in
the
individual
stages
that
you
have
your
access
to
the
logs
from
Jenkins
as
well
into
the
individual
stages.
B
And
finally,
we
removed
yesterday
the
space
from
Champion
instance
to
the
local
agencies.
Now,
if
I
go
back
into
this
Pinnacle
UA
user
interface,
you
will
see
here
are
the
three
pipelines
now
in
a
in
a
matter
of
few
seconds,
you'll
see
that
deploy
to
uat
Spinnaker
pipeline
really
get
triggered
now
this
gets
triggered
when
a
new
tag
of
the
docker
image
gets
pushed
into
the
docker
registry,
and
that's
intentional
obviously,
because
the
code
has
changed.
B
There's
a
new
container
image
in
the
container
registry
and
that
gets
picked
by
deploy
to
uat
pipeline.
So
you'll
see
this
pipeline
getting
executed
with.
It's
got
two
stages
that
you
see
here
and
then
after
this
gets
executed,
then
you
know
it
gets
dropped
into
the
manual
approval
process,
which
obviously
gives
me
two
options
approve
our
reject,
so
let's
hold
on
to
the
manual
approval
yet
because
it
keeps
on
waiting
for
the
manual
intervention
and
meanwhile,
what
we
will
do
now
is
go
back
and
log
into
the
uat
application.
B
This
is
the
endpoint
for
the
uat
and
what
I
would
be
doing
is
I'll,
be
refreshing.
The
page
and,
let's
see
what
happens,
we
get
the
code
change
that
we
did.
We
get
that
reflected
in
the
application.
So
this
is
continuous
integration
and
continuous
delivery
in
in
Prague.
Now,
if
I
go
back
into
production,
I
don't
see
any
changes
yet
because
I
have
not
committed
pushed
those
changes.
B
It's
still
waiting
for
the
manual
approval
here
so
because
it's
waiting
now
I
go
and
then
probably
approve
this
or
looks
good,
and
then
this
will
trigger
the
deploy
to
produce
Pinnacle
pipeline.
What
this
will
do
is
this
will
deploy
the
code
changes
into
production,
Amazon
eks
cluster
once
it
runs
all
of
these
stages.
So
you
will
see
the
indication
from
the
user
interface
very
friendly
interface
that
Spinnaker
offers
right
so
and
then
you
will
see
like
I
said
earlier.
You
have
two
Ingress
endpoints
one
for
each
environment.
B
You
know
all
of
this
is
end
to
end,
and
it
has
built-in
automation
for
the
infrastructure,
using
terraform
cloud
and
of
automation
from
The
Continuous
integration,
using
Jenkins
pipelines
and
also
from
The
Continuous
delivery
perspective
using
Spinnaker
Pipelines.
All
right,
thanks
for
watching
the
demo
and
the
presentation
at
this
point.
What
Paul
and
I
were
ready
to
take
your
questions
here
are
our
contact
details.
These
are
our
email
addresses
and
our
Twitter
handles.