►
Description
In this briefing Veer Muchandi, PaaS Architech and Evangelist at Red Hat, goes through the basics of Blue-Green & AB deployments, and how to use OpenShift's flexible architecture to achieve zero downtime deployments.
For the latest information on OpenShift 3 and available briefings, please visit http://commons.openshift.org or subscribe to the OpenShift Blog (https://blog.openshift.com).
The OpenShift Commons exists to provide a platform for customers, partners, developers and other open source technology initiatives to collaborate, share and accelerate the pace of innovation and adoption of OpenShift globally. The OpenShift Commons represents a new open collaborative community model designed to facilitate communication and sharing of best practices, feedback and development across the many open source initiatives that integrate with OpenShift. The best way to get involved is to join the conversation today at http://commons.openshift.org
A
Good
morning
everybody
and
well
people
are
popping
in
and
joining
us
I'm
going
to
just
let
everybody
know
that
this
is
an
open
shift.
Commons
briefing
and
I'm
really
pleased
at
the
number
of
participants
that
are
jumping
in
and
joining
us
this
morning.
So
it's
a
a
tribute
to
veers
popularity
and
as
well
as
to
his
expertise
and
so
veeram.
A
If
John
Dee
is
our
sake,
platform
architect
and
an
evangelist
for
us
at
red
hat,
but
he
is
also
much
much
more
heat
than
lots
of
work
on
client
deployments
and
helping
customers
and
folks
get
on
all
the
efficiencies.
They
cannot
have
open
shift,
and
today
he's
going
to
talk
to
us
a
little
bit
about
implementing
blue
green
and
a
bead
appointments,
which
I
think
is
near
and
dear
to
a
lot
of
our
hearts.
A
So
I'm
going
to
let
beer
introduce
himself
with
a
little
bit
about
his
background
and
then
just
kick
this
off
and
look
at
the
top
for
about
a
half
an
hour
and
then
we'll
do
some
Q&A.
You
want
to
enter
questions
and
answers
through
the
chat.
Please
do
so
I'll
read
them
off
and
then
we
can
have
a
conversation
afterwards
about
on
whatever
you,
whatever
feedback,
you're
going
to
give
him
or
any
other
questions
you
want
to
ask
here
if
you
get
them
for
a
full
out,
so
take
it
away.
Beer
thanks
thanks.
B
Dragon,
hello,
everyone,
my
name
is
a
weed,
much
ND
I'm,
a
platform
as
a
service
architect
or
an
evangelist
I
am
also
called
a
middleware
specialist.
My
job
is
to
work
with
the
our
potential
Red
Hat
customers
who
are
interested
in
platform-as-a-service
openshift
right
and
then
help
them
help
they're
not
adopt
open
shift
in
their
enterprises,
so
I
go
in
in
stages
where
open
shift
is
is
new
for
them.
B
They
are
trying
it
out
getting
their
hands,
wet
I,
I,
I,
help
them
set
up
open
shift
in
their
enterprises
and
then
coach
them
on
how
to
use
open
shift
kind
of
things
right.
So
in
that
process,
I
also
come
across
a
lot
of
situations
where
I
am
from
Red
Hat's
perspective
right,
I
I
come
to
know
about
what
customer
situations
are
on
or
what
they're
asking
for,
or
what
the
expectations
from
pass
our
first
hand.
B
So
that's
there's
a
good
part
of
my
job
that
I
am
exposed
to
what
customers
are
wanting
from
a
tool
like
open
shift
right.
So
that's
that's
about
me.
So
the
topic
for
today
is
a
blue,
green
and
a
B
deployments.
So
what
are
these
and
where
are
they
coming
from?
Let's
talk
a
little
bit
about
that
before
we
get
into
how
to
do
this
right
now,
blue,
green,
the
when
it
comes
to
deployments
using
open
shift
application
deployments
using
open
shift.
B
One
of
the
questions
that
comes
up
from
the
customers
who
my
meat
is:
how
do
I
achieve
efficiencies
in
terms
of
deploying
newer
versions
of
applications?
Yeah
we
admire
my
team
is
always
changing
applications
right
and
as
the
applications
change
they
they
have
their
hand
over
from
development
to
QA
QA
production
right
when
it
comes
to
especially
to
production.
B
The
operations
teams
are
in
traditionally
they
have
been
like
working
or
the
weekends
or
taking
some
time
in
the
nights
where
the
application
can
be
taken
down
and
a
newer
version
has
to
be
deployed,
and
that's
that's
painful
as
well
as
time
consuming
and
it
thinks
fail.
Then
they
have
to
roll
back.
All
these
issues
would
be
there
right.
So
how
do
we
reduce
the
the
downtime
of
applications
number
one,
or
how
do
we
probably
achieve
zero
downtown
deployments
right
and
that's?
The
kind
of
question
comes
up
in.
B
There
are
patterns
that
have
come
up
in
the
industry
in
the
past
few
years
and
which
enable
this
minimal,
downtime
or
sometimes
zero
downtime
deployments,
and
these
are
those
patterns.
The
blue,
green
deployments
and
ABI
deployments
are
kind
of
those
patterns,
they're
more
or
less
the
same,
but
there
are
some
minor
tweaks
minor
differences,
so
we
are
going
to
discuss
what
this
pattern
surf
and
how
openshift
enables
this
patterns
with
the
kind
of
flexible
architecture.
Open
shift
has
how
those
patterns
can
be
achieved
using
open
shift
or
I.
B
I
do
have
a
couple
of
applications
that
are
already
deployed
for
these
patterns.
I
pre
deployed
them
in
for
the
sake
of
time,
because
this
is
just
a
half
hour
and
if
I
try
to
build
and
deploy
during
this
call,
it's
going
to
take
a
lot
of
time.
So
I
I
have
these
examples
ready,
and
I
will
show
you
how
to
how
to
achieve
this
patterns.
B
But
let's
talk
about
what
this
patterns
are:
first,
we'll
address
Bluegreen
deployments
so
in
case
of
blue-green
right,
what
does
blue
and
green
represent
blue
is
the
version
of
application
that
is
running
right
now.
Let
us
say
it
is
version,
one
of
your
application
right.
It's
think
of
it
as
blue
color
blue
is
what
should
one
and
let's
say
blue,
has
some
problems
and
green
is
version
2,
which
is
which
is
with
the
changes,
so
the
newer
version
of
application,
let's
think
about
it
as
green
right,
so
you
want
to
move
from
blue
to
green.
B
But
if
you
look
at
how
the
blue
version
of
application
is
running
today,
you
have
the
app
running
and
there
could
be
one
or
more
than
one
instances
of
app,
which
is
of
blue
version
right
so
in
terms
of
openshift
I'm,
making
an
assumption
here
that
people
who
are
on
this
call
have
no
little
bit
about
openshift
already.
They
know
what
the
what
a
party
is,
what
is
services
and
all
that
so
I,
don't
want
to
explain
all
those
things
at
this
point.
B
I
am
just
directly
jumping
into
how
to
do
blue
green
without
assuming
by
assuming
that
you
know
all
this
basic
stuff
about
open
check
right.
So,
let's
say,
if
you
have
multiple
instances
of
your
application
running,
you
may
have
multiple
parts,
which
are
the
running
instance
of
your
application
right
so
and
all
these
parts
are
all
these
instances
of
your
application.
Our
front
ended
by
a
router,
and
the
router
is
the
one
that
is
load
balancing
and
distributing
the
traffic
across
all
these
instances
of
your
app
right.
B
How
do
we
make
a
quick
switch
from
blue
to
green
without
incurring
a
lot
of
downtime
right,
so
in
in
that
case,
what
you
would
do
is
rather
than
tearing
down
the
blue
version
of
application
in
case
of
open
shift
since
applications
run
as
parts
you
can
spin
up
a
new
app
right,
perhaps
within
the
same
project,
spin
up
a
new
app
with
the
green
version
of
application.
That
means
a
green
part
gets
spun
up
so
now
blow
both
blue
and
green
are
running.
B
You
can
also
test
your
green
app
in
advance
and
make
sure
it
is
running,
and
after
that
you
can
disconnect
the
route
from
the
router
to
the
blue
version
of
application
and,
at
the
same
time
enable
the
route
to
the
green
version
of
application.
I
will
show
you
exactly
how
it
is
done
right
now
what
happens
in
case
where
your
green
version
is
bad.
You
can,
since
your
blue
ocean
is
already
running,
you
can
quickly
switch
over
or
roll
back
to
the
older
version.
If
you
have
to
right,
that's
blue
green!
B
B
What
you
will
see
here,
I
have
a
project
with
name
Bluegreen
demo
right
and
in
this
project.
I
have
two
applications
running
or
two
different
versions
of
applications.
Running
right,
I
have
a
blue
application
right,
and
this
is
running
with
just
one
partier
and
there
is
a
green
application.
That's
running
with
another
pot,
and
both
these
applications
have
their.
B
B
B
Though
it's
showing
a
bureau's
right
now,
let's
say
we
want
to
switch
over
from
this
this
route
from
the
blue
version,
2
green
version.
Let's
see
how
easy
it
is
to
do
this
right.
I'll
bring
up
the
go
to
the
project.
First,
oh
I'm,
getting
into
the
blue
green
project.
If
I
look
at
routes,
I
have
this
route.
B
B
And
get
down
here,
you'll
see
that
the
host
name
is
the
URL
and
it
is
pointing
to
the
service
with
name
blue
I'll
change
this
to
green
right.
This
is
the
green
service
and
I'll
just
save
this
file
instantly.
You
have
seen
that
this
URL
now
moved
from
blue
to
green
right.
Now,
let's
go
back
and
see
what
happened
to
the
application
itself.
B
There's
a
green
rose
right,
so
that's
a
quick
switch
or
of
app
from
blue
to
green.
So
when
you
want
ur
the
deck
newer
version
of
application
to
be
deployed,
all
you
have
to
do
is
just
switch
over,
so
this
can
be
done
at
any
point
of
time.
You
don't
have
to
be
in
the
night
to
do
it
right
so
think
of
the
amount
of
ease
with
which
operations
can
handle
this
kind
of
task.
That's
that's
the
advantage
of
blue
green.
B
B
Expectant
is
a
B
deployments
and
AV
deployments
is
more,
although
it
is
very
similar
to
blue
green.
This
is
a
little
different
model
in
the
sense
that
the
lot
of
people
ask
like
I.
I
have
a
new
version,
but
I
want
to
I,
don't
want
to
switch
over
completely
to
the
from
the
older
version
to
newer
version,
I
want
to
test
it
out,
slowly
and
and
and
and
slowly
move
my
deployments
from
from
from
the
old
version
to
new
version
right
now
by
default.
B
Let's
say
you
have
n
number
of
parts
of
your
application
running
in
in
in
production.
Let's
say
you
have
you
have
your
app
and
in
this
case,
since
we
are
calling
a
B,
let's
call
the
first
version
as
app
a
now.
Your
app
version,
a
has,
let's
say
a
hundred
parts
or
100
instances
running
right.
If
you
are
doing
a
deployment
with
open
shift
by
default,
open
shift
does
a
rolling
deployment,
which
means
that
each
part
will
be
taken
down.
B
When
you
do
when
you
change
the
version
from
a
version
to
be
version,
a
part
is
taken
down
and
the
new
part
is
put
in
its
place
and
it
it
repeats
for
for
all
100.
You
can
also
change
it
to
update
by
certain
percentage,
which
means
you
can
say
that
I
have
100
pots.
I
want
to
take
down
or
change
ten
percent
at
a
time
which
means
10
parts
are
taken
out.
They
are
replaced
by
newer
version
of
your
application.
B
Like
means
out
of
hundred
till
will
be
new,
90
will
be
old,
and
then
it
keeps
repeating
that
until
it
reaches
100
right
that
that
can
be
that's
that
functionality
is
there
automatically
like
you?
Have
you
have
the
rolling
deployments
configured
automatically
when
you
try
to
do
deployments
with
open
shapes
right?
You
can
change
the
strategy
or
at
any
point
of
time,
but
it's
configured
by
default,
but
some
of
the
customers
ask
for
yeah.
You
will
do
our
automatic
rolling
deployments,
but
I
don't
want
it
that
way.
I
want
that
to
be
controlled.
B
I
want,
like
you,
have
ten
instances
or
instances
of
my
app
running
10
pots
running,
but
I
want
to
decide
when
I
want
to
increase
the
number
of
instances
of
app
B,
which
is
the
new
version
and
reduce
the
number
of
instances
of
app
a
the
old
version.
So
they
want
to
have
a
complete
control
on
increasing
the
number
of
instances
and
reducing
the
number
of
instances.
Let's
look
at
what
what
it
looks
like
right.
You
have
the
same
model.
You
have
a
router.
B
B
If
you
are
happy
with
the
performance
of
a
B,
you
start
increasing
the
number
of
instances
of
happy
and
reduce
the
number
of
instances
of
a
pea
right,
and
this
continues
until
the
app
a
version
is
completely
taken
off
there.
You
don't
run
any
instances
of
I
pay.
You
only
run
instances
of
happy
right,
so
this
kind
of
a
model
where
you
gradually
shift
your
workload
from
app
a
to
a
be
is
called
a
B
deployments.
Now,
how
do
we
achieve
this?
Using
open
shift
in
open
shift?
B
B
Av
deployment
members
right,
so
I
set
a
flag
called
a
B
member
equal
to
true,
and
it
applies
to
all
the
parts
here
and
then
I
also
define
a
service
that
that
front
ends.
Any
parts
that
have
this
label
called
a
B
member
equal
to
true
right,
which
means
whether
it
is
the
blue
application
or
green
or
red
or
whatever
it
is
that
any
part
that
has
a
B
member
equal
to
true
will
be
front
ended
by
this
service.
B
B
Now,
as
we
move
along,
we
add
app
be
with
the
same
label
so
now
they're
out
that
the
load
that
is
coming
in
gets
distributed
across
blue
as
well
as
green.
At
the
same
time,
right
this
is
what
we
the
dispute.
This
is
what
we
do
in
order
to
achieve
the
a/b
process
and
then,
over
a
period
of
time,
the
Blues
will
go
away
in
and/or,
a
application,
a
will
go
away
and
application
be
will
remain
right.
B
I
have
an
app
a,
and
there
are
six
parts
of
app
a
running
here,
and
I
also
have
an
appt
be,
and
there
are
currently
there
are
no
parts
for
this
and
both
app
a
and
I
BR
fronted
by
a
service.
This
service
is
not
relevant
because
we
are
not
going
to
use
it.
However,
there
are
six
parts
here
for
app
a,
and
there
are
0
parts
for
app
be
right
now.
B
What
is
getting
displayed
here?
It
just
says:
I
am
version
1
and
my
part
of
IP
is
so,
and
so
right
now,
let's
see
and
you'll
see
that
there
are
six
parts
running
and
all
these
six
parts
belong
to
app
a
and
just
have
a
look
at
this
IP
addresses
right
this.
These
are
IP
addresses
of
each
of
these
parts.
Now
let
me
run
a
loop
here.
The
reason
I
am
doing
it
from
command
line
is
because.
B
B
B
It's
going
to
say
the
same
thing:
I
am
version
1,
but
look
at
the
part
I
piece
here:
1
62,
63,
206
to
27
24,
seven,
two
four
six
and
then
again
162
163
right,
so
the
six
of
them
are
Robin
and
then
they
repeat
again
and
those
are
the
six
of
these
right
and
these
all
the
six,
our
version
1,
which
is
app
a
now.
What
we'll
do
is
we'll
scale
up
app,
be
and
will
scale
down
at
a
so.
B
B
Once
I
make
this
change,
let's
come
and
have
a
look
at
it.
It's
creating
a
new
version
of
FB
you'll,
see
that
there
were
zero
here
and
now
it's
spinning
up
a
new
part.
It's
already
done,
and
also
the
number
of
parts
of
app
a
have
been
reduced
from
six
to
five
right
now,
under
this
service,
a
B
now
you'll
see
that
there
were
one
two
three
four
five
powers
of
app
a
and
one
part
of
AB
B
got
added
here,
because
this
guy
is
servicing
both
app
a
and
I
be.
B
You
see
that
there
are
five
parts
of
app
a,
and
there
is
one
of
app
be
so
I
of
them
are
five
of
the
requests
are
coming
back
with
version
one,
and
one
of
them
is
coming
back
with
version
two,
so
just
introduced
version
2
of
the
application
with
one
part
and
that's
being
hit,
and
then
it's
round
robin
right
now,
let's
go
further
and
make
them
equal
right.
So
three
of
happy
and
30
happy.
B
B
B
B
Everything
is
version
2,
so
this
is
how
the
gradual
increase
of
your
newer
version
of
application
and
gradual
reduction
of
the
older
version
of
application
can
be
done
now.
Remember
that
there
are
two
versions
of
applications
available
at
any
point
of
time,
if
I
am
not
happy
with,
if
with
the
newer
version
for
any
reason,
I
can
always
scale
back
the
old
version
20
and
switch
over
to
the
new
version
20
and
switch
over
to
the
old
version.
A
There
are
a
couple
of
questions
of
command,
V,
R,
and
thanks
for
that
it
was.
It
was
pretty
pretty
good
enlightening
for
me
in
the
blue
green.
What
happens
when
someone's
got
an
already
open
connection,
and
you
disconnect
to
do
the
to
the
blue?
What
happens
to
that
connection?
Does
it
keep?
Is
it
complete
someone's
running.
B
There
is
some
responsibility
from
the
application
developer
site
on
how
they
take
the
termination
signal,
so
open
shirt
will
send
a
termination
signal
and
your
app
once
it
receives.
The
termination
signal
can
say
that
I
don't
want
to
accept
any
more
new
connections
from
now
on,
but
I'll
service,
my
existing
connections
and
completed
before
moving
on
to
the
before
shutting
down.
B
If
the
app
can
be
coded
like
that,
then
there
will
be
graceful
termination
of
the
of
that
part.
It's
the
all
open
shift
is
doing
is
sending
a
termination
signal
to
your
part,
which
in
turn
ends
up
on
the
app.
So
the
app
should
respond
to
that
in
order
to
achieve
that
effect
of
a
graceful
termination.
A
B
B
B
B
B
When
I
created
both
two
versions
of
applications
using
a
template,
for
example,
this
app
a
service
was
created
and
I
be
service
was
created,
but
this
app
a
be
serviced.
I
had
to
create
myself.
So
I
used
this
command
to
create
the
service,
so
I
said,
expose
DC
app
a
for
example
that
at
the
time
only
app
pay
was
there
and
name.
I
gave
it
as
app
a
B
and
I
said
use
this
selector.
So
this
is
the
key
here,
so
I
am
defining
a
new
service
generator
equal
to
service
right.
B
A
A
B
C
We
have
here
in
your
pod.
We
have
a
convo
lot
of
customers.
Then
often
they
would
imply
that
for
exemption
and
I
guess
the
protein
blue
green
department.
Is
it
the
best
way
for
them
to
go
so
what're
enjoy
a
recommendation?
Recognition
planned
in
the
deployment
would
let's
say,
break
some
compatibility
are
or
manage
the
database.
What
was
the
best
way
to
move
when
changes
will
break.
B
A
It's
close,
I
think
what
least
can
what
Matthias
is
concerned
with
and
I
apologize
for,
the
echo
if
you're
getting
it
too
is.
If
you
have
a
customer
who
deploying
in
blue
green
when
you
that
it
breaks
this,
it
breaks
the
application
and
maybe
a
database
dependency
or
something
else,
but
it's
what's
the
best.
You
know
yep.
What
he's
asking
is:
what's
the
best
way
to
go
when
a
new
deploy
breaks,
the
current
deploy
must
be
some
Center
dependency
between
the
applications
so.
B
The
when
you
are
doing
blue
green,
the
first
type
that
we
discussed
about
right,
you
have
the
blue
version
that
is
currently
running,
let's
say
and
when
you
are
introducing
the
green
version,
it's
it's
a
flip
between
blue
and
green
at
one
instance
right
so
either
the
blue
is
active
or
green
is
active,
not
not
both
at
the
same
time.
Now,
in
such
a
case,
if
the
blue
was
running
okay
and
it
was,
it
was
fine.
B
If
that
is
the
case,
I
mean
this,
which
pattern
that
you
would
apply
depends
on
what
the
changes
can
I
can
I.
Do
a
Bluegreen
in
case
where
there
is
a
rate
of
exchange
is
something
that
you
have
to
think
through
and
then
apply.
So
if,
if
you
are
when
you
are
moving
from
blue
to
green,
if
there
is
you
can
you
can
still
move
from
blue
to
green
by
using
this
pattern,
but
the
being
able
to
roll
back
from
green
to
blue
will
depend
on
what
kind
of
change
you
made.
B
So
you
need
to
tell
your
operations
in
advance
on
this
kind
of
a
change.
You
cannot
flip
back
because
of
because
of
the
kind
of
change
it
is
because
that
the
database
is
completely
different
and
if
I
try
to
switch
back,
there
are
dependencies
that
will
not
allow
me
to
do
it
so
better
transit
application
fully
before
before
you
switch
over
kind
of
thing,
so
the
the
the
rollback
is
still
possible
by
using
the
procedures
that
you
already
use.
B
A
So
Matthias
is
saying
that
blue
green
is
is
like
an
atomic
switch,
but
you
have
to
go
all
the
way.
There's
one
other
question:
there's
a
couple.
Other
questions
that
are
coming
in
in
the
chat
and
peter
is
asking
or
saying
in
the
situation
where
the
app
is
stateful
he's
still
missing
how
openshift
determines
there
are
no
more
sessions
on
a
and
now
a
can
be
stopped.
He's
a
little.
B
Right
so
the,
as
I
said
before,
right
the
app
the
open
shift
will
send
a
termination
signal
to
a
par
when
you
are
asking
it
to
shut
the
power
down,
and
the
termination
signal
is
can
be
listened
to
by
the
application.
Now,
if
you
want
a
graceful
termination,
your
application
should
not
accept
any
new
connections
but
service
the
or
the
existing
connections
before
it
it
shuts
down.
So
there
is
it's:
it's
not
a
complete
open
shifts
a
responsibility.
It's
like
open
shift
will
enable
you
to
like.
B
There
is
a
termination
signal
and
there
is
a
kill
signal
and
there
is
a
gap
in
between
those
two
and
you
can
I
believe
you
can
configure
that.
But
between
this
time
before
the
kill
comes
in,
there
is
a
chance
for
your
application
to
gracefully
shut
down.
So
I
I
think
I
have
to
probably
go
back
and
research
more
on
the
topic
and
probably
come
out
with
an
example
at
some
point
of
time
in
the
future,
but
that
yeah
I
don't
have
a
example
as
an
answer
to
that
question.
A
I
think
that'll
be
another
little
video
reliably
I
can
I
can
see
that
one
coming
distinction
between
termination
and
kill
ya
how
to
handle
that
gracefully
randy
is
asking
what
exactly
needs
to
be
done
to
an
application
to
enable
the
servicing
of
existing
systems
but
not
allow
new
such
new
sessions?
Are
you
suggesting
that
application
should
now
completely
control
session
management?
I
think
this
is
more
to
the
same
topic.
Yeah.
A
So
I
think
that
that's
definitely
a
topic
for
the
next
one
yeah
and
that
people
are
going
back
and
forth,
giving
each
other
suggestions
now
on
how
to
do
this
gracefully.
But
some
some
of
the
burden
here
is
on
the
application
to
be
built,
gracefully
so
that
it
shuts
down
gracefully
I.
Think
that's
it's
pretty
clear
to
everyone
in
the
chat
as
well.
A
A
A
A
A
A
Road
map
and
the
Trello
board.
I
haven't
seen
that
requests
come
in,
but
there
you
go
so
there's
a
couple
of
things.
The
link
will
be
on
for
this.
Recording
will
be
on
the
briefings
page
on
the
commons.
At
openshift.
Org
site
should
be
up
probably
tomorrow
sometime
and
you
can
also,
if
you've
logged
in
through
blue
jeans,
you
can
log
back
in
the
same
way
and
you'll
be
able
to
see
the
video
as
soon
as
I.
It
gets
compiled
and
reposted
back
up
to
blue
jeans
today.