►
Description
This third video in the series takes an example three different microservices that come together to form an application. While each microservice is written in a different language, it show cases how developers will build micro services with their code in a git repository.
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
Hello
welcome
to
the
third
video
on
building
and
running
micro
services
and
OpenShift.
In
the
last
two
videos,
we
talked
about
how
application
components
are
run
on
OpenShift,
how
they
are
made
up
of
parts,
services
and
routes
coming
together
in
the
second
video
we
covered
how
micro
services
run
an
open
shift
and
what
the
micro
services
made
up
or
are
made
up
of,
and
how
openshift
supports
has
a
platform
for
micro
services.
A
In
this
video,
we
will
look
at
a
developer
standpoint
on
how
to
create
micro
services
on
urban
shift
as
a
platform,
and
in
the
next
video
we
will
cover
from
the
deployment
standpoint.
Our
example
has
a
three
different
micro
services.
The
first
one
is
an
email
service
and
this
will
be
used
by
the
actual
application
it's
written
in
Python.
This
is
a
polyglot
setup.
A
Each
service
is
written
in
its
own
language,
write,
the
email
service
runs
in
its
own
pod,
it
has
its
own
service
and
you
could
expose
email
by
using
a
URL
or
you
can
use.
If
the
client
is
internal,
you
can
just
use
the
local
restful
interface
to
talk
to
the
email
service
directly.
We
also
plan
to
introduce
my
sequel
database
to
store
the
email
logs,
but
this
part
is
not
built,
yet
it's
still
working
progress.
The
next
service
is
a
it's
a
combination
of
two
services
that
come
together.
These
are
two
different
micro
services.
A
First,
let's
look
at
the
right
side.
This
is
a
user
registration
service.
This
is
simple
registry
for
a
simple
user
registration
part
where
a
user
would
come
and
self
register
oneself
providing
their
personal
details
and
the
pod
will
receive
those
details
and
this
it
will
write
into
a
MongoDB
database.
A
The
MongoDB
is
a
separate
part
that
where
where
the
data
is
written
into
write,
so
we
have
in
this
case
this
is
like
a
multi-tiered
architecture
where
there
is
a
database
as
one
tier,
and
there
is
a
business
logic
in
another
layer
which
exposes
a
restful
interface
using
which
you
can
register
users
get
the
list
of
users,
and
things
like
that
now.
This
will
also
have
has
a
required
interface
for
email
service,
the
other
service
we
talked
about
in
the
previous
slide
when
the
that
gets
registered.
A
It
sends
out
an
email
that
the
job
is
done
right,
so
email
service
is
generic.
It
doesn't
doesn't
care
what
kind
of
email
it
is
sending
as
long
as
it
knows
that
it,
it
has
to
send
an
email
to
this
address.
It
will
just
go
edit,
send
it
so
email
service
could
be
used
by
other
services
as
well,
so
each
micro
service
is
doing
just
one
job
and
each
micro
service
is
written
in
a
different
language.
For
example,
the
email
service
was
in
Python.
A
This
guy
is
in
node.js
and
using
a
MongoDB
on
the
left
side.
You
will
see
another
micro
service,
and
this
this
micro
service
is
a
PHP
client,
and
this
PHP
is
producing
plain
old,
HTML
pages
that
will
get
back
to
the
browser
and
from
the
browser
you
would
be
making
Ajax
calls
to
the
user
registration
micro
services.
So
the
job
of
this
micro
service
is
just
to
produce
that
UI.
That
is
required
to
show
the
application
that
HTML.
So
how
do
these
all
come
together?
So
you
have
the
browser,
which
is
the
client
right.
A
The
user
goes
to
the
browser
and
accesses
the
user
registration
micro
service
this.
This
has
PHP
running
in
it
and
it
produces
the
HTML
pages
that
are
that
get
displayed
in
the
browser.
The
user
fills
in
the
details
and
then
says
I
want
to
register
at
that
point
of
time
it
the
browser,
makes
Ajax
calls
to
the
user
registration,
API
micro
service
right.
A
This
is
the
back
end,
and
this
guy
goes
and
registers
the
user
and
saves
the
user
details
in
the
user
database,
and
then
it
can
also
give
back
the
list
of
users
available
if
the
browser
asks
for
it.
At
the
same
time,
when
the
user
gets
registered,
it
will
also
send
out
an
email
by
making
a
call
to
this
email
micro
service.
This
is
a
completely
independent
micro
service,
running
separately,
as
I
said
before,
the
email
log
part
is
yet
to
be
built.
A
A
There
is
a
UI
frontend
for
user
registration,
which
is
the
PHP
application,
and
there
is
a
Python
application
that
does
email
API,
so
three
different
microservices,
and
if
you
look
at
the
readme,
it
will
also
talk
to
you
about
how
to
create
these
micro
services
in
your
OpenShift
environment.
So
first
I'll
create
a
project
to
deploy
this
microservices
to
I'll
call
it
miz-dow
to
represent
micro-services
development
and
I'll
say
create
now
that
the
project
is
created
and
for
now
I'll
use
command
line.
A
First,
I'll
export
a
couple
of
environment
variables:
I
have
logged
in
I'm,
changing
into
the
project,
so
I'm
using
the
micro
services
development
project.
Now
I
want
to
create
that
email
service.
This
is
the
same
service
that
we
discussed
before.
This
is
the
first
service
that
we
are
going
to
deploy.
The
this
part
is
not
built,
yet
the
code
only
has
the
the
email
service.
I
am
pointing
to
the
git
repository
that
I
showed
you
before.
We
are
selecting
that
particular
context,
territory,
which
is
Python
email
API.
A
This
has
that
the
core
for
the
email
service,
I,
am
naming
this
application
as
email
service
and
then
I'm
choosing
Python
2.7
as
the
image
stream
to
use.
This
is
the
docker
image
that
it
will
be
using
and
I'm
also
adding
a
label
to
this
application.
That
says
this.
The
name
of
this
micro
service
is
so,
and
so
you'll
see
why
I'm
doing
that
later
now
this
ends
up
creating
an
image
stream,
we'll
configuration
deployment
configuration
service.
And
now,
if
you
look
at
the
web
console,
you
just
started
a
build
for
the
email
service.
A
This
bill
will
run
for
some
time
and
it
will
deploy
the
email
service
part
note
that
we
have
not
created
any
route
for
this
application.
We
are
just
going
to
use
this
email
service
as
an
internal
service,
and
it
it
doesn't
require
a
route.
We
are
not
going
to
use
her
out
in
this
case.
Next,
let
us
deploy
the
user
registration
micro
service,
and
this
is
the
back-end
service
that
does
the
user
registration.
A
A
So
now
we
are
deploying
a
MongoDB
I'm,
just
pointing
to
the
MongoDB
image
to
deploy
and
I'm
also
passing
some
parameters,
which
is
the
username
password,
the
MongoDB
database,
name
that
he
has
to
create
the
password
to
use
in
hala
and
then
I'm
naming
this
application
component
as
MongoDB
I'm,
also
labeling
the
SAS
user
registration
service.
So
everything
in
this
service,
we
will
call
it
user
registration
service.
A
Now
this
guy
has
created
an
image
stream
for
MongoDB,
a
deployment
configuration
for
MongoDB
and
a
service
for
MongoDB,
and
it
will
end
up
deploying
a
MongoDB
service
in
the
same
project.
Now
the
MongoDB
is
now
deployed.
There
is
one
instance
of
MongoDB
running
and
there
is
a
service
that
is
front
ending
the
MongoDB,
and
if
you
look
at
the
labels,
it
shows
that
for
this
service,
the
label
that
we
assigned
is
here
next
we'll
deploy
this
button,
which
is
the
node.js
code
that
can
do
the
user
registration.
A
So
I
am
now
deploying
from
the
same
git
repository
a
different
context
directory
this
thing
is
the
node.js
application
that
does
user
registration
I'm,
giving
it
a
name.
User
registration
service
and
I
am
assigning
it.
The
same
label,
user
registration
service
that
and
the
same
label
was
assigned
to
the
MongoDB
part
as
well,
so
both
are
being
tagged
as
micro-service
equal
to
user
registration
service.
A
Now,
I'm
also
passing
some
parameters
here,
which
allows
this
service
to
connect
to
the
database,
the
MongoDB
database
name,
password
username
and
all
that
stuff
which
are
required
to
talk
to
the
MongoDB
and
the
way
in
which
this
gets
connected
to
the
MongoDB
is
by
using
this
database
service
name
called
MongoDB.
In
addition
to
that,
we
know
that
this
part
of
the
application
has
a
dependency
on
the
email
micro
service,
so
the
email
micro
service
service
name
is
what
I
am
passing
here.
A
So
this
email
service,
:
port
8080,
is
that
there's
the
services
name
OpenSocial
result
is
service
name
into
the
IP
address
of
that
service
internally
by
using
the
sky.
So
now
this
has
created
the
build
configuration
for
user
registration
service
and
it
will
pull
the
code
from
this
git
repository
from
this
particular
context.
Right
and
it'll,
deploy
that
as
the
user
registration
service
part
and
then
it
will
front-end
with
this
user
registration
service.
Now,
if
I
look
at
the
services
that
are
running
in
this
project,
there
should
be
three
of
them.
A
One
is
the
email
service,
the
second
one
is
MongoDB
and
the
third
one
is
this
user
registration
service.
Since
this
service
is
going
to
be
accessed
using
restful
api,
so
we
will
expose
this
service.
The
service
is
exposed
with
a
route
now
I
should
see
the
route
for
this
service.
So
OpenShift
has
assigned
this
route
name
to
the
service
when
you
are
creating
an
application
as
a
developer,
you
are
building
the
application
with
each
of
these
individual
places
and
you
are
putting
them
together.
A
Now,
let's
see
what's
going
on
in
the
web
console
the
email
service
is
now
it's
built
and
deployed
successfully.
The
MongoDB
is
running
and
the
user
registration
service
that
we
just
created.
It's
the
build,
is
running
on
this
guy,
so
it
will
download
that
node.js
code
build
the
code
and
deploy
that
as
a
part,
this
service
also
has
the
same
label.
Microservices,
user
registration
service
and
MongoDB
also
has
the
same
level
of
microservices
user
registration
service.
A
Now
the
reason
why
we
are
doing
it
is
to
say
that
these
two
are
part
of
the
same
micro
service.
We
are
going
to
group
them
together
later.
Next,
we
are
going
to
deploy
this
front-end
micro
service.
This
is
PHP
code
that
generates
HTML.
So
in
this
case
again
we
are
going
back
to
the
same
git
repository
and
we
are
going
to
that
PHP
you
user
interface
code,
and
we
are
deploying
that
as
an
application.
A
In
this
case,
I
am
labeling
it
as
front-end
micro
service
and
I'm
calling
this
as
user
rich
used
for
user
registration.
This
particular
application
would
have
to
link
to
the
other
back-end
service
right,
so
we
are
providing
an
environment
variable
that
connects
to
that
back-end
service
by
default.
When
you
created
the
route,
the
route
would
have
the
application
components
name
followed
by
the
project's
name,
followed
by
the
domain
name,
that's
how
OpenShift
names
the
routes
by
default.
A
So
that's
the
reason
why
we
exported
these
variables
in
earlier,
so
that
is
easy
for
us
not
to
type
all
these
values
here,
it's
just
for
the
sake
of
convenience.
So
now
I'm
deploying
the
service.
The
front
end
service
is
now
getting
deployed.
If
you
look
at
services
again,
you
would
have
a
service
for
this
front
end
service
as
well,
since
we
want
to
use
this
front
end
service
from
the
browser.
You
would
need
to
expose
this
as
a
route.
So,
let's
expose
the
service.
A
Now,
if
we
look
at
the
routes,
there
are
two
routes:
one
is
the
route
for
accessing
the
PHP
application
and
the
other
one
is
the
one,
the
the
back-end
service
that
exposes
restful
api.
So
we
need
both
of
them,
and
this
is
the
one
that
we
configured
for
the
front-end
to
use.
So
so
far
we
have
deployed
the
email
service.
We
deployed
this
entire
micro
service
in
two
pieces,
the
MongoDB
and
the
user
registration
service
and
for
the
user
registration
service.
A
We
said
that
it
would
have
to
talk
to
the
email,
so
we
provided
the
service
name
for
the
email
service,
and
then
we
deployed
the
micro
service
for
the
front-end
part,
and
we
expose
the
route
to
this.
The
front-end
application
is
now
being
built.
It'll
take
a
couple
of
minutes
for
it
to
get
built
and
deployed.
So
let's
give
it
a
moment,
so
you
can
see
that
the
user
registration
service
is
now
built
and
deployed.
It
also
has
a
route.
So
let's
click
on
this
route
and
the
screen
came
up.
A
So
this
is
the
registration
page
for
myself,
say
I'm,
saying
register.
Now
it
says
registration
is
successful
and
I
can
just
add
one
more
user,
so
I
had
to
users
and
login
just
using
this
micro
service
right.
So
this
guy
get
the
list
of
friends,
and
this
friends
list
shows
the
two
users
that
I
serve
micro
service.
It
generated
this
UI.
Let
me
show
you
the
source.
If
I
look
at
the
page
source,
it
has
some
forms
using
which
I
filled
it
and
it's
going
back
to
the
script.
A
The
script
is
actually
making
a
call
to
the
back-end
service,
and
this
back-end
service
is
nothing
but
this
service.
It's
making
restful,
calls
to
add
the
users
and
also
get
the
users
list.
I
simple,
as
that
very
simple,
silly
set
of
micro
services
I
also
received
an
email
that
the
signup
is
come.
So
in
this
example,
we
saw
how
a
developer
uses
OpenShift
as
a
platform
to
deploy
micro
services.
A
So
we
saw
how
we
can
create
an
app
create
an
application
to
deploy
the
email
service,
and
then
we
deployed
the
second
micro
service,
which
included
both
these
components
and
we
label
them
as
the
same
right
and
we
have
deployed
each
one
individually
and
then
we
also
saw
how
how
to
deploy
the
the
front-end
micro
service
separately.
So
there
are
different
micro
services
here
that
that
were
deployed
at
different
points
of
time.
A
Now
the
developer
can
make
changes
to
these
micro
services
and
rebuild
and
redeploy
into
this
development
project,
as
many
number
of
times
has
the
developer
wants.
So
this
is
the
development
platform
for
Microsoft.
In
the
next
video,
we
will
see
how
to
take
these
micro
services
that
are
deployed
as
individual
features,
I
catch
them
together
and
move
them
into
production,
as
I
grew.