►
Description
n the previous video we talked about how a developer creates micro services and how OpenShift builds the docker images for the microservices and deployer them. This video addresses how to package these micro services as units that can be deployed across environments.
OpenShift templates are used as a packaging format to group an entire micro service (including all tiers) together. Once packaged, we will see how we can use it to deploy each micro service a unit into a different project.
This series of videos was created in collaboration with Chakradhar Jonagam, a Solution Architect at Red Hat.
NOTE: For the latest information on OpenShift 3.1, please visit https://enterprise.openshift.com or subscribe to the OpenShift Blog (https://blog.openshift.com).
A
In
the
last
video
we
saw
how
developers
can
point
to
the
code
in
the
git
repository
and
deploy
micro
services
in
their
development
project.
Now,
in
this
video
we'll
see
how
to
group
these
into
micro
services
as
a
template
and
deploy
these
micro
services
as
as
that
template
into
other
areas.
So,
for
example,
when
you
create
this
micro
services
in
the
development
project,
you
are
getting
your
getting
build
configurations
for
each
of
this
areas
right
so
for
your
email
service,
you
have
a
build
configuration
for
your
user
registration
back-end
service.
A
There
is
a
bill
component
for
the
front-end
micro
service.
There
is
a
bill
component
for
MongoDB.
There
is
none,
because
there
is
nothing
to
build
there,
but
the
rest
of
the
things
are
built
based
on
the
core.
So
there
are
build
configurations.
However,
when
you
are
moving
to
other
environments,
let's
say
when
you
are
deploying
into
production.
These
builds
are
not
even
relevant
because
you
are
not
going
to
have
builds
in
the
production
project
you
are
going
to
deploy
whatever
you
have
built
in
your
development
project
into
production
right.
There
are
other
things
like
deployments.
A
The
deployment
configurations
there
are
routes
that
we
created.
There
are
services
that
we
created,
so
there
are
so
many
different
objects
that
get
created
and
we
followed
step
by
step
approach
to
create
this
micro
services
right.
So
how
do
we
group
them
as
independent
packages
of
micro
services
that
go
together?
If
you
remember
from
the
last
video,
we
used
labels
to
tag
this
micro
services
when
they
were
getting
created
in
that
development
project.
A
Let
us
say:
if
we
want
to
get
the
service
deployment
configuration
and
route
based
on
the
label
micro
service
equal
to
email
service,
then
we
will
see
all
those
components
that
are
available
in
that
project
with
that
label.
So
we
can
group
together
the
relevant
components
based
on
the
labels,
as
you
can
see,
and
we
can
do
the
same
thing
with
the
user
registration
service
and
the
front-end.
A
So
there
is
a
way
to
get
the
relevant
components
together
by
using
this
labeling
and
that's
the
reason
why
we
tagged
the
micro
service
components
by
using
the
label.
So
if
you
look
at
the
user
registration
service,
we
are
seeing
both
MongoDB
and
user
registration
service
having
the
same
label
and
that's
the
reason
why
they
are
grouped
together
right
now.
A
If
we
see
the
packaging
structure,
we
need
to
deploy
this
entire
unit
as
a
micro
service
that
has
this
database
and
and
the
business
logic
layer,
including
the
parts
and
services
and
this
particular
route,
and
in
in
case
of
the
user
registration
front-end.
We
again
need
that
PHP
part
plus
service
plus
the
route
to
be
packaged
together.
So
the
reason
why
we
did
the
labeling
earlier
was
to
apply
those
labels
to
all
the
relevant
pieces
so
that
we
can
group
them
together
into
one
package
and
that
package
in
case
of
openshift
is
a
template.
A
So
let
us
see
how
to
create
that
template
so
that
we
have
a
deployable
unit
which
contains
all
the
relevant
components
together
as
a
group
to
promote
to
a
different
environment.
Now
before
we
create
those
packages
to
deploy.
There
is
another
thing
that
we
would
want
to
think
about
right.
You
may
want
to
run
n
number
of
instances
of
your
application
parts
in
production,
so
when
you
deploy,
maybe
you
want
three
instances.
You
four
of
your
back-end
service
spot
to
run
by
default,
and
maybe
you
want
five
instances
of
your
front-end
to
run
by
default.
A
Can
you
configure
that
in
advance?
So
let's
increase
the
number
of
instances
of
your
back-end
to
three
and
let's
increase
the
number
of
instances
of
here
front-end
component
to
five.
Now,
when
I
made
this
change,
it
went
ahead
and
changed
the
deployment
configurations
to
replicas
equal
to
three
or
replicas
equal
to
five.
Also,
the
application
was
built
based
on
the
code,
if
you
remember,
and
the
code
can
change
a
number
of
times.
So
when
we
are
deploying
this
application
into
a
different
environment,
let's
say
you
want
to
promote
it
to
production.
A
You
want
to
know
which
particular
version
of
image
you
are
promoting
right.
So
let's
assume
that
the
current
versions
of
our
images
and
we
want
they-
are
ready
to
be
promoted,
projection
production
and
let
us
tag
those
images.
First,
you
have
to
track
those
images.
Let's
get
the
image
streams.
First,
let
us
tag
the
email
service
image.
The
latest
image
is
this
one
and
we'll
use
OC
tag
the
hash
tag
for
the
image
and
what
we
are
going
to
tag
it
as
I'm
going
to
give
it
a
tag
promote
now.
A
If
I
describe
this
image
again,
I
have
the
image
with
the
promote
tag.
This
is
the
one
we
are
going
to
use
to
promote
into
production
project
and
let's
do
the
same
thing
for
the
other
two
images
as
well:
the
user
registration
service
and
the
user
registration.
Front-End
I
am
tagging
the
user
registration,
front-end
and
I
have
tag
they
use
the
registration
service
as
well.
So
now,
all
the
three
images
that
we
have
developed
in
the
development
project
are
tagged
as
ready
to
promote
to
the
Troxel
environment.
A
Now
we
are
ready
to
export
those
packages
that
can
be
deployed
as
micro
services
as
a
unit,
so
we
are
using
the
OC
export
command.
This
is
the
one
used
to
create
a
template,
and
what
are
we
interested
in
when
we
are
trying
to
deploy
into
production
right?
We
are
interested
in
a
deployment
configuration
that
says
how
the
pod
should
be
created.
We
are
interested
in
the
service
and
the
route,
and
these
these
three
components
if
they
get
deployed
your
service,
is
ready
and
running.
A
The
first
thing
that
we
will
do
is
group
all
these
together
into
one
package
for
your
user
registration
service
back-end
and
will
export
it
as
a
template
and
I
am
giving
it
a
name.
User
registration,
service
micro
service
I
want
the
output
format
as
JSON.
It's
easy
to
edit
and
see
and
I
am
saving
it
into
a
file.
Now
the
service
is
created,
I'll
open
this
service.
We
need
to
make
some
minor
changes
to
this
service,
so
this
this
micro
service
is
a
template.
Now
it's
it's
a
whole
package
where
all
the
objects
are
together.
A
There
is
a
deployment
configuration
object
and
this
is
for
DB
and
this
DB
deployment
configuration
object,
has
the
environment
variables
for
username
password
and
all
that
stuff,
and
it
has
the
values
that
we
gave
in
development.
If
you
want
to
change
it,
you
can
change,
you
can
parameterize
it,
so
you
can
replace
this
with
some
parameter.
Name.
Dollar
database
password,
for
example,
and
provide
those
parameters
at
the
end
of
this
template.
A
If
you
wanted
to
I'm
not
going
to
show
how
to
do
that,
it's
it's
pretty
easy,
but
we
can
cover
that
in
a
in
a
different
session.
There
is
a
deployment
configuration
for
your
user
registration
service
and
then
this
also
has
the
same
exact
parameters:
to
be
able
to
connect
to
the
MongoDB.
It
has
that
email
application
domain
parameter
which
expects
to
talk
to
the
email
service
right.
It
has
this
the
services
for
the
for
the
database
as
well
as
the
as
well
as
the
business
logic
layer
as
well
as
it
has
a
route.
A
Let's
make
a
small
change.
This
route
has
a
host
name
and
this
host
name
it
just
borrowed.
Whatever
the
host
name
was
there
in
development,
we
will
remove
this
host
name
because
we
want
openshift
to
assign
a
hostname
based
on
whichever
project
is.
It
is
deployed
in
to
this.
In
the
deployment
configuration
for
your
user
registration
service,
it
is
pulling
it
from
the
user
registration
service
latest
tag,
and
but
we
wanted
to
use
that
remote
tag
right.
A
Let's
replace
that
as
well
as
we'll
also
add
an
additional
parameter
called
namespace
here
and
we'll
set
it
to
development
project.
The
reason
being
you
were
image
stream,
where
this
image
with
promote
tag
is
stored,
is
in
the
is
in
your
development
project.
So
when
you
are
deploying
in
your
production
project,
you
want
to
pull
the
image
from
the
development
project
and
deploy.
A
So
that's
the
reason
why
we
have
to
provide
this
namespace
as
well
I'm
going
to
say
this
next
will
create
the
same
exact
thing
for
the
email
service,
email
service
microservice
will
export
the
deployment,
configuration
and
service.
In
this
case
the
route
is
not
relevant
because
we
didn't
expose
her
out
for
the
email
service.
It
is
not
externally
facing
and
I'll
edit
this
email
service
for
the
same
exact
reasons
I'm
going
to
the
triggers
I'm
changing
it
so
that
it
picks
the
image
with
promote
tag.
A
I
have
added
a
namespace
label
that
points
to
the
development
project.
Next,
we'll
deal
with
the
third
macro
service,
which
is
the
user
registration
front-end.
This
time
we
are
picking
up
based
on
the
label.
Microsoft
is
equal
to
user
registration
front-end
and
again
we
are
exporting
this
as
a
template.
In
this
case,
we
have
the
router
so
have
I
selected
deployment,
configuration
service
and
route
I'll
edit.
A
This
file
as
well
I
remove
the
hostname
so
that
we
get
a
value
assigned
by
OpenShift
when
it
when
it
gets
deployed
and
I'm
getting
into
the
trigger
section,
changing
it
so
that
it
uses
the
user
registration
image
with
promote
tag
and
I
added
my
project
name
as
an
in-space.
Now
we
have
three
templates
already,
and
these
are
the
packages
for
deploying
micro
services
into
my
production
project.
Now
let
us
create
another
project
for
production.
A
I'm
going
to
call
it
premise,
prod,
say:
create
go
back
to
my
command
line
and
I'll
assign
the
image
puller
access
to
that
production
project.
The
image
pull
of
access
is
assigned
to
the
product
production
project
from
the
namespace
micro
services,
develop
I'll
switch
over
to
the
production
project.
Let
us
look
at
all
the
micro
service
templates
that
we
created
the
packages
and
we'll
process
each
one
of
them
to
deploy.
So
first,
the
production
project
is
now
empty.
A
Let's
deploy
the
email
service
always
saying,
is
process
this
template
and
use
the
result
to
create
whatever
the
objects
are
there
in
this
template
in
it
has
a
deployment
configuration
and
a
service,
the
email
project
will
be
deployed.
So
if
you
go
back
and
look
at
what's
happening
behind
the
scenes,
it's
in
the
production
project,
it
is
pulling
the
email
service
from
the
development
project
and
it
is
creating
a
pod
and
deploying
it.
It
has
already
created
a
service
now
in
the
same
way,
let
us
deploy
the
user
registration
backend
service.
A
Remember
we
set
the
number
of
replicas
to
more
than
one.
It
would
create
those
many
instances
of
the
parts
when
it
processes
this
template.
So
now
it
has
created
a
deployment
configuration
for
MongoDB,
the
user
registration
service,
business
logic,
a
service
for
MongoDB,
a
service
for
the
business
logic,
layer
and
a
route
all
together
with
just
this
one
command.
So
you
are
taking
this
package
and
deploying
this
whole
together
into
production,
and
all
these
things
are
created
now
it's
actually
creating
two
different
parts
for
the
same
service.
A
You
are
saying
that
the
service
deployed
there's
a
route
already
assigned,
and
the
part
is
also
deployed
so
compared
to
what
we
did
in
development.
Look
at
what
all
is
happening
here.
It's
doing
a
bunch
of
things
at
the
same
time.
Next
will
why
the
frontend
service
will
just
process
that
micro
service
package
template
and
it
creates
the
deployment
configuration
in
the
survey
center
out.
Now
we
go
back
and
see
it's
deploying
the
front-end
components.
It
will
spin
up
a
bunch
of
parts
for
the
front-end
component.
A
So
now
it
is
spinning
of
five
instances
of
the
front-end
two
instances
of
the
backend
and
a
MongoDB
and
an
instance
of
email
service
altogether.
So
all
we
needed
was
to
create
that
packaging
format
using
templates
and
have
the
deployment
configuration
service
and
the
routes
for
the
relevant
parts
and
put
them
together
into
a
package
and
then
use
that
to
deploy
into
production.
So
when
we
are
doing
in
development,
you
would
need
the
build
configuration
when
you
are
in
production.
You
would
only
need
those
relevant
pieces
that
need
to
go
to
production.
A
So
when
you
handover
from
one
group
to
another,
you
can
just
hand
over
that
package,
so
you
have
seen
how
to
build
micro
services
in
a
development
project,
how
to
package
them
together
using
templates
and
how
to
deploy
them
into
production.
I
hope
you
enjoyed
this
video
series
thanks
a
lot
for
watching.