►
Description
In this session, we will discuss how Minishift can be used as a local development environment for OpenShift and demonstrate one approach to developing Node.js applications with OpenShift/Minishift.
A team was assembled and tasked with evaluating Minishift as a local development environment for clients moving to OpenShift. The goal was to create a local environment that mirrored production as much as possible and to upskill people on Openshift at the same time.
A good local development workflow has quick feedback loops, meaning code changes are reflected instantly. OpenShift’s build and deploy process can be too slow in that context, so we set out on a journey to optimise this process.
The end result was a Node.js app running in a local OpenShift cluster that could be live reloaded without rebuilding containers. Along the way we learned about many of the core benefits of OpenShift such as the integrated build system, integrated docker registry, the powerful web console and templates.
We will discuss the various challenges encountered and provide some useful tips to those starting with Node on OpenShift. We’ll also do a live demo of the workflow and discuss some of the material in our open GitHub repo.
Speakers:
Dara Hayes, DevOps Engineer.
Conor O’Neill, Chief Product Officer
A
Hello
and
welcome
again
to
another
urban
Commons
leapin,
this
time,
we're
going
to
do
some
nodejs,
stuff
and
I
know
you
all
know
that
I
love
python,
but
I
also
love
it.
So
I
really
feel
your
form
here
coming
and
talking
about
their
experience
with
shifted,
using
mini
shift
in
specific,
specifically
and
creating
development
environment.
B
Previously
I
was
with
red
hat
mobile
for
any
Red
Hatters
watching
this
video
and
tell
you
a
little
bit
about
the
company.
It
was
set
up
only
in
2011
and
unusually
it's
paced,
and
a
kind
of
tiny
little
seaside
town
called
tram
or
in
the
southeast
of
Ireland
and
weirdly.
This
little
bit
of
Ireland
is
probably
known
central
for
most
of
Europe
between
all
of
the
note
people
in
their
form
and
the
guys
in
red
at
Mobile
is
wow,
so
just
attrition
all
those
interesting
little
quirks
of
geography
and
the
company
itself.
B
It's
a
little
over
a
hundred
people,
but
they're
spread
across
around
the
world.
It's
it's
a
very,
very
distributed
organization,
and
really
the
bulk
of
what
we
do
is
build
full
stack
solutions
for
large
organizations.
So
you
know
a
huge
amount
of
what
we
do
is
is
professional
services
and
we
work
these.
You
know
you
know:
people
like
Conde,
Nast,
McKenzie
consulting
you
know,
ADP,
so
I
think
pretty
much.
Every
person
in
the
u.s.
B
What
we
do
see
is
a
strong
commonality
in
the
tech
stack
that
we've
been
using
kind
of
recent
years.
So
that's
very
much
things
like
react
on
the
front.
End
note
on
the
back
end
happy
as
the
kind
of
web
framework,
obviously
deploying
into
things
like
AWS
and
then
using
tools
like
terraform
a
danceable,
and
then
you
know
kind
of
getting
closer
to
what
we're
going
to
be
talking
about
today.
B
Various
open
source
communities
I
have,
but
particularly
the
node
community
were
major
contributors
to
node
court
and,
in
fact,
James
Snell,
who,
this
week
just
landed,
HTTP
to
support
or
early
HTTP
to
support
in
node
core
is
the
technical
steering
committee
director
and
Finance
was
the
other
thing,
we're
very
well
known
for
our
conferences,
particularly
nocon
for
you,
which
is
sort
of
the
European
version
of
node
conf.
So
that's
going
to
be
out
of
this
hearing,
take
a
knee
in
Ireland
in
November
and
is
sort
of
one
of
the
highlights
of
the
node
conference
season.
B
Shall
we
say,
and
now
on
to
the
briefing
itself
before
I
just
hand
over
to
Tara.
It
came
about
because
of
a
relatively
new
initiative
that
we've
kicked
off
inside
near
forum.
So
we've
done
is
we
put
together
this
loading
team?
They
work
very
much
like
kind
of
pathfinders
trying
out
new
tools
and
technologies,
and
the
idea
is
people
come
in
and
I,
usually
just
for
a
couple
of
weeks.
B
I'm
work
in
areas
where
that
we're
interested
in
learning
more
about
talking
more
about
letting
people
know
what
we
do
and
you
know
just
kind
of
general
communications.
It's
totally
sprint
based.
So
it's
once
a
week,
we,
you
know
everything's
done
in
blocks
of
the
week.
You
have
a
demo
and
a
deliverable
at
the
end
of
every
week,
and
you
know
that
the
work
can
vary.
Anything
from
evaluating
your
DevOps
tools.
B
Try,
for
example,
one
of
the
things
working
on
now
is
trying
out
different
approaches
to
some
of
the
react,
tooling
and
really,
and
that
knowledge
is
distributed
internally
and
then
externally,
via
blog
posts
and
obviously
webinars
like
this,
and
what
Dara
is
going
to
talk
about
is
one
of
those
types
of
projects
that
have
been
told,
I,
hope
the
spaces
every
week
by
him
and
several
others
in
the
near
forum
team,
so
I'll
hand
over
to
Jerry.
Now
and
he'll
talk
about
the
nuts
and
bolts
of
the
session
right.
C
Thanks
very
much
for
that
Connor,
that's
a
great
intro
and
also
thanks
everybody
for
taking
the
time
to
listen
to
us
today.
My
name
is
Dara
ace
and,
as
Connor
was
talking
about
that
sort
of
working
group
that
we
have,
that
kind
of
does
this
research
he
kind
of
stuff.
One
of
the
things
that
we
did
was
looked
at
mini
shift
and
tried
to
figure
out.
How
can
we
make
many
shift
into
a
development
environment?
C
That's
actually
pretty
useful
for
nodejs,
and
so
before
I
jump
into
the
specifics.
I
just
wanted
to
talk
a
little
bit
about
you
know
near
forms
experience
with
container
technologies,
so
we've
been
working
with
docker
for
like
three
years,
so
we've
been
using
it
since
docker
was
quite
young
and
back
in
those
days
we
did
loads
of
crazy
work,
trying
to
build
like
custom
tools
to
deploy
a
docker
and
yeah.
They
were
like
the
dark
ages
for
them
in
more
recent
times
like
we're
starting
to
look
at
kubernetes.
C
C
So
this
was
just
one
of
the
initiatives
that
we
sort
of
came
up
with,
and
so
just
in
case
anyone's
not
familiar
with.
What
many
shift
is
it's
a
tool
that
helps
you
run
all
of
OpenShift
in
a
single
virtual
machine
on
your
laptop.
So
it's
a
really
nice
way
to
get
familiar,
we're
open
shipped
for
free
and
it's
pretty
much
compatible
with.
You
know
any
operating
system
and
it
can
run
on
a
bunch
of
different
hypervisors.
C
So
you
know
it
was
originally
a
fork
of
mini
cube,
but
it
really
is
its
own
project
now
with
its
own
community,
and
so
that's
what
we
started
looking
at
right,
and
why
did
you
know
as
a
company?
Why
are
we
getting
interested
in
mini
shift
and
a
an
open
shift?
I
suppose,
as
I
said,
we
have
a
lot
of
customers
already
that
are
using
kubernetes
and
we've
been
speaking
with
a
lot
of
potential
customers
as
well
and
there's.
C
You
know,
there's
a
growing
interest
in
open
shift
and
you
know
how
that
can
potentially
solve
their
problems
and
then
again,
as
Connor
said,
we
kind
of
do
these
initiatives
to
have
scale
of
some
people.
You
know
in
our
company
and
help
increase
awareness
of
some
of
the
stuff
that
we're
looking
at,
and
then
this
last
point
here,
like
a
technical
reason
for
looking
at
mini
shift,
were
really
interested
in
this
idea
of
how
your
dev
environment
could
be
really
similar
to
your
production
environment.
C
So,
like
the
idea
of
running
you
know
a
full-fledged
installation
of
open
shift
on
your
local
machine
where
it
would
be
really
similar
to
the
way
it
would
be
running
production
like
you
know,
in
terms
of
the
build
process
and
the
deployments,
and
even
just
the
sort
of
foils
that
we
use
to
define
our
system
all
that
kind
of
all
those
resources.
The
idea
that
you
know
that
could
be
really
similar
to
our
production
environment
was
really
interesting
to
us,
so
we
wanted
to
investigate
that
I
suppose
and
then
yeah
so
to
us.
C
So
this
was
a
really
big
challenge
with
OpenShift,
because
it's
scott
full-fledged
build
and
deploy
cycles,
and
we
wanted
to
figure
out
how
we
can
make
those
changes
that
we
make
locally
more
instant
in
a
running
instant
instance
of
open,
shipped
and
then
lastly,
again
on
the
idea
of
having
your
dev
environment
similar
to
production,
this
kind
of
idea
of
production
priority-
that's
really
interesting
to
us.
So
what
we
did
was
we
looked
at
mini
shift
and
try
to
figure
out.
C
How
can
we
have
this
environment
where
we
looked
at
it
and
we
tried
to
focus
on
the
instant
feedback
loops,
particularly
because
we
wanted
to
solve
the
problem
of?
How
can
we
make
changes
to
our
code
locally
and
have
them
reflected
in
OpenShift
instantly,
because
by
default
you
know,
there's
an
old,
build
and
deploy
process
that
actually
takes
quite
a
bit
of
time
and
the
end
result
of
our
work
was
this
little
demo
project
here
where
we
have
a
little
server
running,
and
it
just
gives
you
this
hello
world
message.
C
C
This
little
voice
second
gif
here,
like
the
result
that
you're
seeing
here
actually
took
quite
a
bit
of
work
right
to
get
to
that
stage
right.
So
we've
got
a
little
repo
here
at
sneer
form
for
it
slash
mini
shift
demo.
If
you
want
to
go
and
take
a
look,
you
know
and
follow
along
that
way.
You
know
you're
totally
come
to
do
that
or
you
can
just
sit
back
and
relax
and
enjoy
while
they
talk
about
it.
C
So,
as
I
said,
it
took
a
bit
of
work
and
there
were
a
few
pieces
of
the
puzzle
to
get
to
that.
You
know
solution
that
I
just
showed
you
there
and
I'd
like
to
talk
about
those
few
bits
that
take
you
on
like
a
story
of
how
we
got
there,
so
the
whole
strategy
really
kind
of
revolves
around
using
volumes.
Anyone
that
use
docker
compose
as
the
development
tool.
Probably
like
knows
exactly
where
this
is
going.
C
The
whole
idea
was
that
we
would
get
around
the
build
process
in
OpenShift
by
mounting
the
local
code
directly
into
a
Roenick
container.
So
the
idea
is,
is
that
any
changes
we
make
locally
are
already
reflected
inside
there
on
a
container.
These
are
just
two
small
little
snippets
taken
from
the
foyer
that
defines
our
system
and
what
we're
doing
is
defining
a
volume
at
this
folder,
which
is
where
you
know
our
lives
and
it's
what's
called
a
host
Pat
volume
and
a
host
pad
volume.
C
C
So,
to
recap:
we
have
the
code
is
mounted
into
a
running
container
and
we
can
use
an
old
London
to
detect
any
changes
when
they're
made
and
that
for
yourself,
those
two
elements
really
makes
up
the
majority
of
the
actual
solution,
or
there
were
a
couple
of
snags
that
we
ran
into
like
a
couple
of
challenges
that
made
this
a
little
bit
more
difficult
and
so
I'm
just
going
to
talk
about
those
a
little
bit.
So
the
first
one
was
permissions
in
open
shipped
by
default.
C
So
the
openshift
security
model
is
built
around
these
things
called
security
context
constraints
and
what
they
are
is
these
sort
of
policies
that
define
permissions
and
you
can
and
then
those
policies
are
attached
to
service
accounts
or
to
users
accounts
that
kind
of
thing
and
then
the
other
side
of
it,
then,
is
a
service
account.
There
is
a
service
account
associated
where
all
the
components
in
open
shifts
or
like
the
Builder,
the
registry,
the
deployer
and
indeed
your
own
containers
that
you're
on
or
on
under
a
service
account
and
boy
default.
C
C
We
can
see
some
service
accounts
here
that
are
created
so
like
this
default
service,
account
is
what
your
containers
were
run
with,
and
then
you
can
do
I'll
see
you
get
sec.
This
is
gonna.
Give
me
a
bunch
of
different.
You
know.
Pre-Made
policy
objects
that
exist
that
we
can
attach
to
service
account,
sent
to
users
and
stuff.
So
what
we
added
simply
is
the
host
access
one,
and
that
gives
your
container
that
one.
The
effects
of
that
is
is
that
your
containers
and
they
will
have
access
to
the
file
system.
C
So
our
strategy
of
mounting
your
entire
local
code
into
the
container
doesn't
really
work
if
you're,
because
of
native
dependencies
so
like,
if
you
mount
your
all
your
code,
including
your
node
modules,
if
you're
running
OS
X
and
that
code
gets
mounted
into
a
Linux
container,
a
nanny
native
dependencies
are
gonna
break
because
they're
compiled
for
the
wrong
platform,
and
so
we
came
up
with
a
solution
and
I
still
think
it's
a
little
bit
hockey.
But
it's
the
only
thing
we
could
come
up
with.
C
So
if
anyone
has
any
suggestions
for
a
better
way,
I
would
be
so
happy
to
to
hear
those
suggestions.
But
what
we
did
was
we
installed
the
node
modules
outside
of
the
application
folder
in
the
in
the
docker
image,
and
then
we
just
linked
to
those
node
modules.
So
I
can
just
show
you
what
the
docker
file
looks
like.
We've
got
two
folders
here
been
on
Lib
and
bin.
That's
where
the
app
is
gonna
be,
and
then
this
Lib
folder
is
where
the
external
node
modules
folder
is
going
to
be.
C
C
It
reads
up
environment
variable
and
if
there's
anything
there,
it
knows
to
also
search
in
this
folder
for
dependencies,
as
well
as
the
order
default
ones,
and
then
lastly,
we've
just
added
this
folder
here
to
the
path
and
what
this
guy
does
is
and
yeah
like
binaries
and
CLI
tools
that
you've
installed
as
part
of
the
application
penance
ease
will
be
available
on
your
paths
of
like
node
land,
for
example.
We
can
use
no
not
now
because
of
this,
so
there
is
it's
kind
of
hacky,
like
I'll,
admit
I'd
love.
C
If
there
is
a
better
way
to
do
it,
and
maybe
reader
is
but
the
result
of
that
is
is
that
the
native
dependencies
are
applied
for
the
right
platform
they're
just
in
an
order
folder.
So
when
we
mounted
in
the
order
code,
you
know
they're
still
there
and
then
one
caveat
obviously
is
if
your
dependencies
change,
you
know
if
your
dependencies
change,
you're
gonna
have
to
rebuild
that
container.
C
So
yeah,
that's
that's
all
of
the
elements
of
how
we
got
it
to
work
and
now
I
might
as
well
just
show
you
the
demo,
because
you'll
get
a
much
better
understanding,
I
think
right.
So
if
we
start
off
with
our
head
of
server,
our
log
server
is
the
piece
of
software
that
we
used
to
demonstrate.
This
whole
thing,
there's
a
guy
that
you
saw
on
the
gif
and
what
it
is,
is
it's
basically
a
tiny
little,
a
PID.
C
So
that's
why
that's
there
so
this
endpoint,
we'll
just
use
you
know,
cause
level
to
save
some
data
in
a
database,
so
you
can
just
tell
that
the
dependencies
are
working
and
then
that's
the
dockerfile.
That
I
showed
you
in
the
slides
a
second
ago.
So
that's
the
server
and
then
what
we
have
is
this
one
file.
This
is
the
manifest
file.
This
manifest
file
specifies
all
the
objects
required
to
actually
get
the
the
software
to
run
within
our
OpenShift
closer
for
anyone.
That's
not
familiar
with
this.
C
It's
really
similar
to
the
way
you
define
objects
in
kubernetes
or
there's
just
a
couple
of
extra
features.
So,
for
example,
this
this
file
here
is
what's
known
as
a
template
for
how
mother
does
is
it
allows
you
to
pass
in
parameters
and
then
that
renders
the
foil
with
those
parameters,
and
you
can
passing
like
default
values
and
stuff
as
well,
which
is
kind
of
cool.
C
So
we've
got
a
couple
of
parameters
here,
like
naming
memory
limits,
health
checks,
you
know
some
environment
variables,
that
kind
of
thing
and
then
what
we
have,
then
is
the
actual
objects.
So
I
can't
go
into
massive
detail
because
about
like
all
the
kubernetes
and
the
open
chef
concepts,
because
that
would
be
a
talk
in
itself
what
I'll
just
brush
over
it
really
quickly.
So
what
we
have
is
a
build
config
which
defines
how
we
build
the
application.
C
To
put
you
know
the
resulting
build
the
way,
in
our
case
we're
going
to
build
a
docker
image
and
we're
going
to
publish
it
to
an
image
stream
tag,
which
is
essentially
the
OpenShift
sort
of
abstraction
for
our
docker
registry
right
and
then
what
we
have
is
a
service,
so
a
service
just
groups,
all
of
our
running
instances,
of
an
application
together
and
exposes
them
under
a
single
name
and
at
low
balances.
Requests
to
those
service
only
exposes
your
sir,
your
application
internally
within
a
cluster.
C
So
then
we
use
what's
called
a
route
which
will
create
like
a
publicly
accessible
endpoint
from
which
we
can
access
the
application
and
then,
lastly,
we
have
this
big
object
here
called
a
deployment
config
and
the
deployment
config
has
a
big
specification
for
the
container,
how
its
run
and
the
environment
variables
have
checks,
volumes
and
a
bunch
of
other
things.
So
that's
really
the
biggest
want
to
understand.
Now,
as
I
said,
I'm
not
gonna,
go
massive
into
detail
on
that,
but
I
definitely
encourage
if
you're
interested
in
doing
this
definitely
encourage
just
to
go.
C
Take
a
look
at
it
in
our
repo
and
definitely
read
through
the
open
ship
documentation,
because
it
would
really
help
you
understand.
What's
going
on
the
open
ship,
documentation
is
actually
really
good.
So
that's
the
that's.
The
the
manifest
I
guess
file
that
describes
the
old
system
and
then
what
we
have
is
just
a
single
script
that
will
help
us
get
everything
up
and
running.
So
this
script,
it's
just
a
little
bash
script
and
what
it
does
is
it
does
that
ask
permission
stuff
for
us
that
I
mentioned
earlier?
C
C
To
make
sure
right
so
yeah,
but
we've
got
a
nice
clean
slate
to
start
from
so
I'm
gonna
get
going
now
all
right.
So
we've
you've
got
the
scripts
folder
here
which
contains
that
script.
We're
gonna
run
that
script
create
project,
that's
going
to
apply
the
correct
permissions,
create
a
project
for
us
and
then
it's
going
to
go
and
create
those
resources
within
openshift,
and
then
it's
gonna
kick
off
the
first
build
when
that
build
is
complete.
That's
gonna
trigger,
like
the
deployment
of
our
software,
so
the
first
build
is
obviously
gonna.
C
A
C
B
C
Yeah
one
thing
we
didn't
look
at
because
I
guess
just
as
a
response
to
Chris's
link
as
well.
That's
a
great
suggestion,
I
suppose,
because
of
our
strategy,
you've
tried
to
avoid
doing
bills.
I
guess
we
didn't
look
at
the
CEO
tools
and
the
Jenkins
kind
of
sort
of
thing
as
much
as
we
could
have
so
yeah,
that's
just
the
wouldn't.
We
should
have
looked
at
it,
but
our
strategy
kind
of
involved
avoiding
building
as
much
as
possible,
I
guess
and
so.
C
My
machine
is
starting
to
get
angry.
Now
it
doing
a
video
call
and
running
many
shifts
at
the
same
time,
but
so
we
can
see
here,
we've
got
a
we've
got
a
roof,
so
this
is
the
end
point
that
our
application
will
be
available
at
we
can
actually
see
the
bill
is
running,
so
we
can
go
in
and
take
a
look
and
that's
just
gonna
show
us
the
list
of
bills.
So
we
can
go
into
this
build
and
we'll
be
able
to
see
the
log
of
know
exactly
what
we're
seeing
in
the
console.
C
You
get
the
point,
there's
no
point
in
waiting
for
that
to
load,
but
what
else
can
I
show
you
real,
quick,
so
I
have.
My
machine
is
getting
a
little
bit
slow
now
right,
so
the
build
is
complete
and
now
our
first
deployment
is
running,
so
we
can
just
go
in
and
take
a
look
at
the
deployment
config
just
to
show
what
that
looks
like.
C
You
can
see
a
you
know,
you
can
see
the
command
here,
the
start
dev
command.
You
can
see
the
image
and
see
the
build.
It's
related
to
it's
actually
running
now
as
well.
One
thing
that
I
should
mention
just
real,
quick
as
well,
so
we've
got
the
app
volume.
That's
the
volume
where
our
local
code
is
mounted
got
this
level
level
DB
volume
which
just
creates
an
empty
volume
where
level
DB
can
write.
Information
to
you've
got
this
empty
node
modules
volume
and
what
that
does
is
because
we're
mounting
our
entire
application
code.
C
The
node
modules
folder
within
the
application,
folder
itself
is
still
actually
being
mounted
as
well,
and
node
will
always
take
preference
for
that,
as
opposed
to
any
order
ones
that
you've
specified
through
that
node
path,
environment
variable.
So
what
we've
done
as
a
little
hack
is
just
to
put
an
empty
value
in
the
default
folder
so
that
it
won't
see
anything
there
and
then.
Lastly,
we
have
this
little
volume
here.
C
So
apparently,
node
man
needs
a
file
called
config
for
it
to
work,
so
you
had
to
create
a
file
there
for
it
to
be
able
to
write
to
so
just
to
explain
if
anyone
what
comes
along
and
looks
at
this-
and
there
was
what
the
hell
are
all
of
these-
that's
what
they
are,
and
now
we
can
see
in
the
logs.
We
can
see
that
our
server
is
running.
We
go
back
here.
C
C
It
save
we
hit
refresh
there.
It
is
so
you
have
successfully
gotten
instant
feedback
working
right.
It's
it's
pretty
nice.
If
we
just
go
in
and
take
a
look
at
the
application
again
go
down
into
the
running
pod
and
just
look
at
the
logs,
you
can
see
you
know
no
long
did
its
job,
it
restarted
the
application.
C
So
that's
pretty
cool
and
that's
you
know
that's
kind
of
the
main
thing
we
worked
on
and
that's
what
you
see
in
the
master
branch
of
the
repo
right,
but
just
for
this
demo
all
right
for
this
talk
today,
you
have
actually
gone
and
done
some
additional
work
hasn't
been
merged
to
master
yet
on
the
the
mini
ship
demo
repo.
But
it's
still
like
to
show
it
to
you
because
I
think
it's
interesting.
C
It
expands
on
what
we've
done
here
so
having
a
hello
world
server
is
pretty
good,
but
by
itself
you
know
it's
not
that
meaningful.
So
we
wanted
to
do
something
a
little
bit
more
involved.
So
what
I
tried
to
do
was
to
get
a
database
running
of
some
sort
and
have
an
application
that
can
connect
to
a
database.
So
I'm
just
going
to
go
and
show
that
to
you
guys.
So
if
I
go
back
into.
C
Now,
if
I
come
back
to
my
editor,
what
I
have
now
is
two
new
files
as
well
as
the
original
mini
shift
demo
file.
We
have
two
new
guys.
You
we
have
the
post
grades
file,
which
defines
some
objects
to
get
post
grades
up
and
running.
What
we
did
was
we
got.
Post
grades
were
running
from
the
default
post
grades,
image
from
the
public
dock
registry
right,
so
we
didn't
use
like
an
oaken
shift
or
a
red
hat
specific
version
of
the
postgrads
docker
image.
C
We
just
wanted
to
use
the
vanilla
one,
so
there
was
a
bit
of
work
there.
But
what
we
have
is
this
persistent
volume
claim
which
defines
like
some
storage.
You
know
that
will
outlive
an
Iranian
container
and
then
we've
got
some
stuff
here
to
define
where
the
image
comes
from,
and
you
know,
we've
got
the
service
and
the
point
config
very
similar
to
the
order
to
the
order
manifest,
but
it's
gonna
run
those
guys
and
then
also
what
we
have
is
this
guy
called
users
API.
C
C
I
was
a
little
bit
lazy
and
I
don't
have
the
cold
included
in
the
repo
I
have
a
elsewhere
in
my
own
git
repo,
and
so
instead
of
building
from
a
source
we're
building
from
a
get
our
instead
of
building
a
binary
source,
we're
building
a
good
source
instead.
So
that's
a
really
nice
feature
of
openshift
actually
is
to
just
run
an
application
straight
from
a
git
repository,
and
you
just
have
a
docker
and
I've
got
a
specific
docker
file.
C
C
That's
gonna
go
off
and
create
both
grades.
I'll
just
show
that
real,
quick
in
the
console,
but
postgrads
is
we
can
see
this
stuff
here
and
now
it's
gonna
start
a
deployment
of
course
grades
and
I
should
be
off
any
minute
now
and
now.
In
the
meantime,
we're
going
to
go
and
create
the
application,
so
I
have
one
tiny
order,
a
little
script
here
that
will
just
create
the
application
kind
of
in
the
same
way
as
the
other
one.
C
C
A
C
C
Yeah,
oh
yeah,
I
agree
what
you
Diana
to
it
is
a
cool
environment
for
learning
mode
and
it's
definitely
a
really
cool
environment
for
just
learning,
about
OpenShift
as
well
and
about
how
deployments
sort
of
work-
and
you
know,
and
the
kind
of
kubernetes
and
the
open
shift
concepts
that
are
involved.
So
it's
a
really
nice
way
to
bring
those
concepts
to
the
local
environment,
I
suppose
and
that's
kind
of
cool,
because
de
and
it
gets
to
like
if
you've
got
developers
and
you've
got
ops
people,
it's
sort
of
guess.
C
The
developers
thinking
along
the
same
lines
as
the
ops
people,
and
it
gets
kind
of
at
least
I-
would
think
that
it
hopefully
kind
of
reduces
friction
between
those
teams
because
and
we're
kind
of
breaking
down
the
barriers
between
them.
In
my
own
experience,
I've
kind
of
found,
sometimes
the
developers
really
don't
care
about
how
the
ops
people
you
know,
get
the
software
running
in
real
life.
They
just
want
to
be
able
to
run
it
locally.
C
So
it's
kind
of
cool
that
we
have
this
possibility
of
an
environment,
a
local
environment,
that's
really
similar
to
a
production
environment.
It's
yeah,
look,
it's
been
very
slow,
so
I'm
actually
going
to
just
stop
it.
Now
you
get
the
idea
like
at
the
end,
you'll
be
able
to
access
an
application.
That's
reading
data
from
Postgres
and
you
can
like
kill,
post
graze
and
bring
it
back
off,
and
the
data
will
still
be
there
and
it's
yeah.
It's
pretty
nice,
but
I'm
gonna
skip
pass
it
there,
because
it's
just
it's
being
too
slow.
C
That
should
hopefully
free
up
my
machine,
though,
that
the
fans
are
already
after
getting
quiter
yeah
all
right.
So
that's
the
demo
I'm,
sorry
that
the
order
got
the
other
piece
didn't
really
work.
I
would
love
if
you
go
check
it
out,
though
you
know,
it's
got
a
lot
of
of
there
to
look
at
you
know
when
we
went
and
did
this
for
the
first
time
there
wasn't
a
whole
lot
of
material.
We
could
actually
find
online
to
help
us.
C
C
One
of
our
colleagues
asked
us
after
we
demoed
this
for
the
first
time
internally,
he
said
yeah
how
many
services
can
you
run,
and
it's
quite
funny
now,
because
you
know
it
kind
of
crashed
out
on
me
just
in
this
call,
but
there
is
a
way
to
scale
it
with
some
tweaks
and
we
did
manage
on
a
single
machine
to
get
it
up
to
about
40
or
50.
You
know
the
results
vary
depending
on
your
machine.
C
I
was
able
to
get
it
up
to
40
colleagues,
I
got
it
up
to
50,
and
even
more
so
you
know,
has
the
potential
to
run
quite
a
lot
of
services
and
I
think
you
know
if
he
tried
to
run
50
services
on
an
e
going.
The
development
environment
you're
definitely
pushing
the
limits
anyway,
so
for
sure,
but
I.
Just
if
you're
interested
you
can
run
this
command.
Oc
described
node,
and
that's
going
to
give
you
back
information
about
how
much
you
know
how
much
resources
are
available
to
your
to
the
cluster.
C
That
you're
running
and
it'll
also
give
you
a
figure
of
how
many
pods
it
will
actually
allow
you
to
run
and
by
increasing
the
memory
and
CPUs
that
will
go
up,
and
on
top
of
that,
then
you
can
kind
of
port
restrictions
in
place
on
the
individual
containers.
Like
you
can
limit
the
amount
of
memory,
views
and
I
should
be
able
to
help
you
kind
of
scale
up
a
little
bit
more
so
I
guess
some
of
the
conclusions
coming
out
of
it
is.
C
It
does
have
the
tential
to
be
a
great
development
environment
when
we
first
set
out
to
do
this,
so
it
was
a
little
bit
skeptical,
because
the
idea
of
running
a
virtual
machine
was
a
bit
crazy
to
me.
But
after
having
a
bit
of
experience,
whether
I
think
it
is
definitely
good.
It
has
a
really
nice
UI
and,
like
experience,
the
the
CLI
as
well
is
just
fantastic.
C
The
OpenShift
CLI
I
spoke
about
this
a
little
bit
I,
really
like
the
idea
that
if
we
have
people
using
mini
shift
as
a
development
environment,
you
have
your
people
thinking
in
terms
of
open
ships
and
in
terms
of
deployments
and
in
terms
of
all
those
concepts
that
are
there.
I
think
that
that
would
definitely
enable
us
to
break
down
barriers
between
dev
and
ops
people,
because
you
have
them
thinking
on
the
same
page,
almost
right.
So
I
really
like
that
idea,
and
then.
C
Lastly,
this
idea
of
a
universal
dev
environment
that
that
sounds
crazy
at
face
value.
But
imagine
if
you
work
on
it
like
a
bunch
of
different
projects
like
the
idea
that
you
could
have
just
this
one
mini
shift.
Installation
where
you
could
have
you
know
potentially
have
multiple
projects
going
on
in
there
at
the
same
time,
and
it
just
becomes
this
one
kind
of
unified
place
where
you
can
manage
all
of
your
different
software
projects.
C
C
It
uses
quite
a
lot
of
resources
on
your
machine.
It
takes
up
a
lot
of
battery
as
well
it
drains
battery
very
quickly
and
then
there's
some
more
kind
of
higher-level
questions
and
work.
That
still
needs
to
be
done.
So,
for
example,
I
just
showed
you
today
a
single
codebase
and
it
was
a
very
small
codebase.
But
how
would
we
organize
this
if
we
had
multiple
code
bases
for
one
project
so
say
if
we
had
a
project
that
had
you
know,
10
micro
services?
C
How
do
we
structure
our
repos
to
facilitate
a
mini
shift
development
environment
and
you
know
so
that's
one
question
we
need
to
ask
and
we
need
to
figure
out
and
then
the
next
one
we
if
we
were
to
have
this
sort
of
universal
dev
environment.
How
would
we
actually
coordinate
that
across
multiple
projects
and
then
the
other
question
is:
can
we
turn
it
into
a
general
solution?
C
So
what
I
mean
by
that
is
I
showed
you
guys
some
like
manifest
files
today
and
some
scripts
to
get
it
all
up
and
running,
but
they
are
kind
of
specific
to
the
one
project
and
they're
kind
of
they're,
not
perfect,
either
they're.
You
know
they're
just
enough
to
get
the
job
done,
but
is
there
a
way
we
can
make
those
better
and
you
know,
use
them
across
projects
as
well.
C
If
we
had
just
a
single
tool
that
can
help
us
get
a
project
running
a
mini
shift,
that
kind
of
thing
that
would
be
really
nice
and
then.
Lastly,
what
is
a
pathway
from
going
to
a
local
open,
shipped
to
a
production?
Open
shift?
That's
a
really
big
question
for
us,
particularly
on
your
form,
we're
actually
we're
still
very
new
to
open
shift,
but
we're
actually
doing
a
lot
of
work
now
in
getting
open,
shipped
up
and
running
and
then
actually
trying
to
figure
out
those
pathways.
And
hopefully
you
will
have
content
on
that
soon.
C
It
is
work
that
we're
actively
pursuing.
So
there
is
like
some
of
the
questions
that
still
are
left
unanswered.
For
now
we
don't
have
all
the
answers.
Yes
and
the
other
thing
is
I'm
very
aware
that
there
are
people
listening
here
today
that
probably
have
a
lot
of
knowledge
around
open
ships,
and
it
would
be
really
really
happy
to
hear
your
suggestions,
and
here
you've
got
to
get
your
contributions.
C
My
name
is
Derek
Hayes.
Those
are
my
contact
details.
If
you
want
to
get
in
touch
with
me
via
email
or
Twitter,
Conor
only
use
these
there
as
well.
You
know,
please
feel
free
to
get
in
touch
with
us
and
thanks
very
much
for
listening
to
me
today,
I'm,
you
know
I'm
really
honored
to
to
come
here
and
speak
to
you
guys
right.
So,
thank
you
very
much.
Well,.
A
A
A
C
Running
an
early
2015
Mac
with
8
gigabytes.
So
it's
definitely
nowhere
near
like
top-of-the-line
in
term
in
terms
of
Mac,
looks,
go
I
have
other
colleagues
that
are
running
much
more
powerful
machines
and
they
were
able
to.
You
know
they
were
able
to
run
this
much
more
comfortably
but
still
of
mind
that
I'm
still
aware
and
kind
of
conscious
of
the
fact
that
it
does
take
off
a
lot
of
resources.
And
that's
you
know
just
the
downfall
of
running
a
virtual
machine.
A
There
are
no
other
questions
and
I
have
a
so.
There
are
some
questions
that
you're
asking
any
in
your
conclusions.
There
are
a
lot
of
answers
out
there,
some
of
it
jaqen
space.
Some
of
it
may
be
solved
with
open,
shipped
io
on
premise:
there's
there's
a
lot
of
different
approaches
to
solving
some
them
and
we'll
probably
grab
you
and
another
time,
and
then
we
can
walk
through
some
of
them.