►
Description
Webhooks for Automated Updates [B] - Rajashree Mandaogane, Rancher Labs
In most software projects, there is a tremendous focus on increasing efficiency and reliability. Rolling updates in Kubernetes is a really good example of how real-time updates to applications can be made reliable, without any downtime. Once you have a reliable system, you then need to make your software development process even more efficient. A key component in efficiency is automation. Automated builds on Docker cloud are a great way to efficiently build images when new code is pushed. In this talk we will discuss how we can take automation one step further. We will make use of the Kuberbnetes API calls, along with Docker Hub's webhooks feature, to automatically start rolling updates of deployments when a new image/tag is pushed to Docker Hub. We will demonstrate how you can write a micro-service that will make these calls after consuming the data pushed by Docker Hub's webhook.
About Rajashree Mandaogane
Rajashree, an NC State graduate is a Software Engineer at Rancher Labs. She loves programming in Golang and working on container orchestration. She lives by the motto, “You’ll never know what you can do, until you try”. This has led her not only to being a developer, but also an amateur writer on Medium, and a recent half marathon runner! Her idea of a good weekend encompasses one where she spends time trying tutorials for any new orchestration tools, and also just binge watching any Netflix shows.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
Hi
everyone
I'm
Roger
stream
and
ovale,
and
the
title
of
my
talk
is
the
box
for
automated
updates.
So
just
a
little
introduction,
I
graduated
last
May
from
NC
State
and
then
I
moved
to
California
to
work
as
a
software
engineer.
So
it's
been
a
year
and
a
half
of
me
working
in
container
orchestration
and
golang
and
I'm
really
liking.
A
So
I've
all
got
this
very
cool.
Startup
called
Rancher
labs
Rancher
is
a
complete
container
management
platform.
Some
of
you
might
have
heard
of
it
before
and
via
fully
open
source.
So
you
can
check
out
our
code
on
github
at
Rancher,
so
the
goal
of
today's
talk
is
to
set
up
a
continuous
deployment
pipeline
to
your
kubernetes
cluster.
So
why
do
we
need
this
now
say
you
are
running
the
v1
version
of
one
of
your
apps
on
your
cluster.
Then
you
made
some
changes
to
your
code
and
now
it's
time
to
update
your
app.
A
So
typically
it
would
involve
a
few
sips
such
as
you
would
have
to
well
get
your
code
pushed
most
once
that
is
done.
You
will
have
to
build
the
new
version
of
your
code
once
that
build
is
successful.
You
will
go
ahead
and
then
update
your
app
in
the
cluster.
So
now,
if
this
process
of
updating
your
app
is
a
frequent
one
doing
all
these
steps
manually
will
get
really
time-consuming,
and
we
don't
need
to
do
that
if
we
can
automate
all
these
steps
with
the
help
of
a
pipeline.
A
You
know
that
looks
something
like
this,
so
this
is
how
it
will
work.
You
do
any
code
changes
and
push
them
to
say
github
now,
that
should,
by
itself
trigger
the
build
of
a
new
image
tag
on
some
image
registry.
Then
this
image
registry
should
be
able
to
notify
us
with
all
the
information
of
the
newly-built
tag.
Now,
usually,
such
notifications
about
some
events
that
have
happened
are
handled
via
web
hooks,
and
so
we
need
to
use
some
image
registry
that
has
this
way
books
feature.
A
Then
we
need
to
develop
some
piece
of
code
that
can
actually
receive
this
way
book
then
retrieve
the
newly-built
tag
from
that
web
of
information
and
then
actually
do
an
update
to
our
app
running
in
the
case
cluster.
So
this
piece
of
code
that
receives
the
web
book
and
updates
our
app
I'm
going
to
refer
to
as
the
book
receiver
for
the
rest
of
the
session,
and
we
will
see
how
we
can
use
it
so
before
that
I
just
want
to
very
quickly
go
over
to
kubernetes
resources
that
I'll
be
using
for
this
demo.
A
The
first
one
is
a
pod.
A
pod
is
the
smallest
deployable
unit
in
kubernetes,
and
it
consists
of
one
or
more
containers
that
are
tightly
coupled.
Each
pod
gets
assigned
a
unique
IP
address
that
is
shared
by
the
containers
within
it,
but
pods
are
ephemeral,
meaning
if
a
pod
goes
down
or
if
the
host
it
is
scheduled
on
goes
down.
Then
kids
won't
know
that
it
has
to
reschedule
it
again
and
that's
why
we
don't
run
our
applications
directly
on
a
pod
in
the
cluster.
A
So
we
need
to
choose
one
of
these
strategies
and
that's
why
we
are
going
to
take
a
look
at
some
of
them.
The
first
one
is
Bluegreen
strategy.
Now
in
this.
If
you
want
to
update
your
app
to
a
newer
version,
you
have
to
bring
up
an
identical
production
environment
for
the
new
version
of
your
code,
and
once
this
new
environment
works
as
expected,
you
can
just
get
rid
of
the
older
one.
So
this
strategy
guarantees
zero
downtime
during
the
update,
and
it
also
provides
a
way
to
rollback.
A
Let's
see
how,
in
this
strategy,
only
one
environment
will
be
lives
and
handling
all
the
requests
at
any
time.
So
at
first
the
blue
environment
is
the
live
environment.
Then
we
did
some
code
changes.
So
it's
time
to
update
to
the
newer
version
and
that's
why
we
bring
up
the
green
environment
to
run
the
new
version.
Now,
once
this
green
environment
is
fully
deployed
and
tested,
we
can
start
using
it
by
just
configuring,
the
load
balancer
to
start
sending
requests
with
that.
A
A
So
at
first
we
have
three
instances,
both
running
version
v1
and
now
it's
time
to
update
to
the
version
v2
new
code,
so
all
three
instances
undergo
the
update
at
the
same
time.
So,
as
you
can
see,
there
are
no
instances
available
to
serve
any
request,
which
means
during
this
update
there
will
be
downtime
incurred
and
once
the
update
is
done,
we
go
to
version
v2
and
the
instances
are
up
and
running
again.
A
A
Now
even
rolling
update,
just
like
the
blue-green
deploy,
Bluegreen
strategy
guarantees
zero
downtime
and
it
does
so
by
only
updating
a
certain
percentage
of
instances
at
any
given
time.
So
always,
there
are
a
few
instances
that
are
running
the
older
version
of
your
code
and
yeah
for
using
this
strategy,
your
app
must
be
able
to
support
the
old
and
new
versions
of
the
code
at
the
same
time,
but
unlike
the
Bluegreen
strategy,
rolling
update
does
not
require
any
additional
instances
for
zero
downtime,
because
this
is
how
it
works.
A
So
at
first
we
have
two
instances,
both
running
version
v1
and
now
it's
time
to
update
to
V
2,
so
the
instance
2
undergoes
the
update
first
and
in
the
meanwhile
instance,
1
is
still
up
and
running
the
old
version
of
your
code
and
serving
all
the
requests.
Once
instance,
2
is
done.
Updating
to
V
2
instance
1
undergoes
the
update
and
again
we
have
instance
to
have
been
running
this
time.
The
new
version
of
our
code.
A
A
So
how
do
we
use
these
strategies
in
our
like
gates
cluster,
so
the
deployment
resource
that
we
looked
at
earlier
lets
suspec
I
one
of
these
strategies
right
now
it
has
two
options:
one
for
rolling
update
and
one
for
recreate.
Now,
for
my
app
I
want
to
choose
the
rolling
update
option.
This
is
because
not
only
does
it
guarantee
zero
downtime,
but
I
just
need
to
specify
the
rolling
update
option
in
my
deployment
resource.
Peck
and
kubernetes
will
take
care
of
the
entire
orchestration
logic
of
that
update.
A
A
Spec
is
what
accepts
the
desired
state
of
your
app
under
that
you
can
see
strategy
and
have
provided
type
as
rolling
update,
and
you
can
slightly
manage
this
by
these
two
fields,
max
unavailable
and
Max
souls,
so
max
unavailable
as
the
names
such
as
is
the
maximum
number
of
ports
that
are
allowed
to
be
unavailable.
During
this
update,
which
we
want
to
be
say,
1
and
max
search
is
the
maximum
number
of
ports
that
are
allowed
to
be
scheduled
above
the
desired
number
of
ports.
A
A
It
will
update
that,
but
again
running
these
commands
manual.
Even
you
want
to
update
your
app.
We
don't
want
that
because
you
want
to
update
sorry
I
mean
automate
our
continuous
deployment
pipeline.
So
let's
automate
it
the
way
book
received
code
that
I
spoke
about
earlier.
When
I
was
showing
the
pipeline
diagram.
We
are
going
to
use
that
to
automate
this
process
as
well.
So
let's
go
back
to
our
pipeline
diagram
and
get
the
different
components
in
place.
A
The
image
registry
that
I'm
using
is
docker
hub
because
docker
hub
has
the
automated
builds
feature,
meaning
I
can
integrate
it
with
any
of
my
code
repositories
and
when
some
code
is
pushed,
it
will
trigger
the
build
of
a
new
image
tag.
Docker
hub
also
has
the
way
books
feature
that
is
needed
for
our
way
book
receiver
pod.
A
So
what
exactly
will
this
webbook
receiver
do
and
where
will
it
run
so
the
web
app
receiver
will
consume
all
the
information
that
is
sent
to
us
by
the
docker
hub
the
book
from
that
it
will
find
the
image
tag
that
was
just
pushed
and
then
using
this
image
tag.
It
will
patch
arcade's
deployment
resource
via
an
api
call.
So.
A
I
hope
you
can
see
the
screen
yeah,
so
the
docker
have
a
book
called
it's
an
HTTP
POST
request
with
a
JSON
payload
that
looks
like
this.
So
in
our
book
receiver
code,
we
need
to
expose
an
API
endpoint
that
can
accept
this
post
request
and
the
JSON
payload
with
it.
Now
from
this
alpha
book
receiver
needs
only
two
fields
to
know
which
image
was
pushed
image
was
built
any.
A
So
now,
where
will
we
run
this
for
a
book
receiver
code?
It
can
be
run
anywhere
like
you
can
have
it
running
on,
say
AWS
lambda
or
you
can
sum
out
and
within
the
cluster
or
you
can
create
a
separate
micro
service
which
can
do
this
for
you,
but
Rancher
already
has
a
framework
for
such
webbook
receivers
in
place
and
it's
a
go
micro
service.
A
So
it
provides
with
the
book
callback
URLs
which,
when
triggered,
do
some
predefined
actions
and
the
reason
I'm
going
to
use
the
ranch
was
existing
framework
is
that
it
runs
out
of
the
que
it's
cluster.
So
that
means
I'll.
Even
if
I
have
multiple
gates
clusters
running
I
can
create
the
callback
URLs
for
each
of
them
with
using
the
same
micro
service.
A
So
this
is
what
the
framework
looks
like
in
the
code.
We
are
referring
to
the
receivers
as
drivers
and
every
receiver
or
driver
that
we
add
needs
to
implement
the
webbook
driver
interface.
Now
these
functions
are
just
to
make
sure
that
the
way
book
is
fully
functional.
For
example,
validate
payload
will
take
as
input
in
our
case.
What
deployment
I
want
to
update
and
execute
will
actually
execute.
The
API
calls
to
update
the
deployment
after
it
receives
the
daughter
of
a
book
and
yeah.
A
A
So
now,
let's
go
back
to
this
diagram
and
see
what
we
have
fuse
in
the
web
book.
So,
first
of
all,
the
user
will
make
a
request
to
get
a
callback
URL
and
all
of
your
books
framework
or
the
book
receiver
will
give
this
generated
callback
URL.
The
user,
will
then
add
it
to
docker
hub
as
a
web
book.
Now
going
back
to
the
continuous
deployment
once
this
initial
setup
is
done,
user
will
make
some
code
changes
and
push
them
to
get
her.
A
A
A
Okay,
so
if
you
scroll
up
the
image
that
I've
provided
for
my
app
is
M
largest
riku
and
I'll,
show
you
what
that
app
is
doing
and
I've
exposed
for
9001
now
under
strategy
after
wydad
type,
is
rolling,
update
and
max.
So
just
one
max
unavailable
is
one
meaning
at
the
most.
Only
one
part
will
be
unavailable
and
at
the
most
four
thoughts
can
be
scheduled
during
the
update.
A
You
can
see
these
are
the
three
pods
running
for
it
and
we
are
the
status
is
running
and
they
were
all
created
some
time
back
like
three
hours
back
so
now,
when
I
actually
update
my
app
new
parts
should
have
been
created
in
their
place
and
when
we
do
the
cube
cut'
will
get
pots
again.
We
will
see
that
they
are
quite
new.
So
let
me
just
show
you
what
my
app
is
doing,
along
with
the
deployment
I
had
also
created
a
service
to
expose
it.
So.
A
So
my
app
is
like
a
very
simple
golang
at
all.
It
does
this
print
some
message
and
right
now,
it's
printing
this
message:
this
is
an
older
release,
so
my
goal
is
to
like
do
that:
initial
setup
with
my
books
and
finally
I'll
just
change
this
message
in
my
editor
and
do
a
git
push
and
that
should
by
itself
update
my
app
in
the
K
it's
cluster.
So
for
that
we
need
to
set
up
the
automated
builds
and
docker
hub.
You
can
do
that
by
just
going
to
create
an
automated
build.
A
A
A
So
I
am
going
to
provide
the
name
and
a
namespace
of
my
deployment
that
I
want
to
update
and
this
environment
ID.
It's
nothing
it's
so
within
Rancher.
There
are
different
environments
for
different
clusters,
so
since
I
am
using
the
existing
framework,
I'll
be
providing
that
environment
ID
to
know
which
cluster
I
am
working
on,
so
let
me
create
it
and,
although
okay
so
I'm
in
this
environment,
if
I
go
to
the
WebEx
page,
it
will
show
me
that
this
is
the.
Where
book
that
I
just
created.
Okay,
it's
coupon!
A
A
A
Okay,
so
the
good
push
has
taken
place
and
if
a
pipeline
is
working
correctly,
I
will
need
to
do
anything
else
for
my
app
in
the
case
cluster,
to
get
updated.
So,
let's
go
to
our
docker
hub
automated
build
and
under
build
details.
You
can
see
that
it
has
already
started
building
a
new
tag
if
I
click
on
it,
it
is
using
this
docker
file.
Now
this
automated
build
is
only
possible
if
you
are
providing
a
docker
file
in
your
repository.
So
in
this
I
am
just
using
the
goal
and
Alpine
image.
A
It's
relatively
lighter
and
I'm
copying.
My
code
and
I
am
building
the
code
using
the
docker
file
itself,
because
I
don't
want
any
compatibility,
mismatch
issues
like
some
OSX
binary
running
on
Linux
or
so
on.
Also
I
am
going
to
run
this
run
this
command.
It
just
keeps
doing.
It
just
keeps
running,
get
ports
every
point,
five
seconds,
the
reason
I'm
doing
this
is
I'm
hoping
we
will
be
able
to
see
the
rolling
update
take
place
like
one
board,
getting
terminated,
one
board
getting
created
in
its
place
and
so
on.
A
Usually,
these
updates
take
place
very
fast
within
a
case,
so
we
oh
I,
was
thinking
we
might
not
be
able
to
catch
those
actions
using
this
command,
but
we
can
so,
as
you
can
see
this
pod,
which
was
running
earlier,
it's
getting
terminated
now
and
in
its
place
we
can
see
well,
two
pods
are
in
container
creating
state.
That's
because
we
saw
that
four
pods
are
allowed
at
the
max
to
be
scheduled.
A
So
one
of
these
pods
is
going
to
take
the
place
of
this
lv
wg7,
pod
and
thing
this
goes
on
for
a
while
yeah
right
now
we
have
four
boards
running
and
then
two
pods
are
getting
terminated,
so
this
process
will
go
on
I'm,
just
going
to
run
my
queue.
Cuddle,
get
pods
command
again,
okay
and,
as
you
can
see,
all
three
previous
pods
have
been
deleted
and
their
place
has
been
taken
by
these
three
new
pods.
A
All
of
them
are
running
now
and
they
have
just
been
created
a
few
seconds
back,
so
they
are
new
pods
with
the.
So
this
is
done.
We
saw
the
rolling
update
actually
take
place,
one
pod
terminating
one
pod,
creating
and
to
make
sure
that
our
app
is
actually
updated.
I
am
just
going
to
go
to
the
browser
and
I'm
going
to
refresh
this
and
I
hope,
and
it
prints
the
new
message
that
I
changed
and
it
does
so.
A
A
B
A
So
yeah
Jenkins
yeah
Jenkins
has
continuous
regular.
It
will
build
your
new
image
and
all
and
I
think
you
can
also,
like
you
were
saying-
maybe
add
scripts
to
do
that,
but,
like
I
was
using
this
book
receiver
because
you
will
need
to
like
specify
what
deployment
you
are
dealing
with.
You
need
to
specify
your
Kube
config,
maybe
every
time
the
job
is
being
built
and
so
an
easier
way
to
do.
This
is,
if
you
are
just
running
a
micro
service
which
already
takes
like
accepts
your
cube
convict.
A
B
A
So
yeah
I'm
familiar
with
Jenkins
like
you,
can
have
automated
bills
and
you
can
have
books
as
well
like
they
will
notify
you
when
something
has
happened,
but
for
the
receiver
part
I
was
not
sure
if
you
can
provide
your
cube
config
and
like
exhibit
all
those
commands
but
yeah.
The
idea
is
to
just
have
this
automated,
like
deployment
pipeline
in
place.
You
can
replace
these
components
with
anything.
So
that's
why,
at
the
beginning,
I
just
shown
some
image
registry
and
something
to
trigger
trigger
that
update.
So
this
is
one
way
to
do
it.
A
B
A
A
A
A
A
A
A
A
A
All
right,
I,
I,
think
I
I
think
I
forgot
to
cover
that
so
I
was
just
going
to
go
over
this
yeah,
so
like
I,
think
yeah,
as
you
can
see
over
your
doorknob
itself
tells
us
that
this,
like
just
leaving
it
blank,
will
target
all
tags
yeah.
So
the
tag
name
is
just
prepended
with
release
and,
as
you
can
see
over
your
the
tag
that
I
had
pushed
was
Q
Khan
yeah,
and
so
it
tagged
it
as
yeah
yeah.
It
just
use
that
it
uses
that
I.