►
Description
You keep hearing about containers and maybe you have even played with Docker. You are now wondering – how do I run and manage this in production? In this session we are going to show you how.
We’ll level set with a quick intro to Docker, then show how Crunchy Data has taken advantage of OpenShift, Kubernetes and Containers to do more with PostgreSQL. Then we will demo bringing these images up to scale and orchestrated with Kubernetes and OpenShift – two open source projects used to deploy, manage and monitor containers.
Demonstration will include the use of Crunchy PostgreSQL Container technology in order to:
— Deploying High Availability PostgreSQL Clusters
— Backup and Restore of PostgreSQL in OpenShift
— Perform Advanced PostgreSQL Monitoring
For the latest information on OpenShift 3.1 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
A
Well,
hello
and
welcome
everybody
to
another
openshift
Commons
briefing
really
pleased
today
to
have
with
us
Jeff,
McCormack
and
Paul
Lawrence
from
crunching
data
and
we've
got
an
interesting
talk,
one
of
our
favorite
databases
and
the
work
with
and
now
that
it's
running
up
and
wonderfully
with
Bishop
three
and
in
containers
and
kubernetes.
Without
me,
punchy
data
folks
to
come
and
talk
about
how
they
made
it
work
so
wonderfully
and
to
do
some
background
on
how
to
use
Postgres
with
open
shipped
as
well.
A
So
do
that
I'm
going
to
let
Jeff
introduce
himself
and
his
team.
If
you
have
questions
on
during
the
presentation,
ask
them
in
the
chat
and
after
the
presentation
and
the
demo
is
done,
we'll
open
it
up
for
Q&A
and
there's
a
couple
of
other
technical
folks
from
crunchy
on
lines
that
they
may
get
answered
in
the
chat,
but
we'll
try
and
reiterate
them
for
the
recording,
as
well,
so
without
further
ado
Jeff.
Why
don't
you
take
it
away?
Yeah.
B
C
Thanks
Jeff,
this
is
Paul
Lawrence
with
crunchy
data,
and
so
crunchy
data
is
a
provider
of
trusted.
Open-Source
Postgres
in
Postgres
support
and
technology,
and
we've
been
working
with
the
Red
Hat
open
ship
team
for
about
two
years
now,
initially
in
version
two
and
then
when
the
the
migration
went
to
version
3
and
all
good
things
with
docker
and
tube
the
kubernetes.
We
kind
of
jumped
on
board
and
have
been
working
with
them
since,
specifically
to
bring
enterprise
Postgres
capability
to
to
the
OpenShift
platform
and
have
been
doing
a
lot
of
interesting
stuff
there.
C
That
were
excited
to
show
that
the
commons
group
today
on
the
at
its
core
crunchy
data,
has
a
Postgres
called
scrunchy
certified
Postgres.
It's
a
hundred
percent
open-source
unmodified
Postgres
9.5
included
in
our
distribution,
is
post
GIS
for
geospatial
data
types
as
well
as
enhanced
audit
logging
capability
through
an
open-source
project
called
PG
audit,
and
then
we
also
have
an
advanced
SELinux
integration
as
an
extension
to
post
for
us
that
enables
multi-level
security,
and
this
is
again
100%
open-source
and
does
note
in
the
bottom,
in
evaluation
for
Common
Criteria
certification.
C
So
not
only
do
you
have
a
post
rest
database,
but
you
have
the
kinds
of
enterprise
capabilities
that
you'd
expect
like
high
availability
pack,
upper
store,
failover
monitoring
and
some
other
DBA
utilities,
and
so
Jeff
with
that.
Do
you
want
to
kind
of
take
folks
through
through
the
various
pieces,
to
what
we've
done
here?
Sure.
B
So
what
I'll
do
is
take
you
through
the
containers,
give
you
a
description
of
those
and
then
at
the
end
of
this
I'll
show
you
some
of
the
demo
material
and
some
of
the
screens
that
are
part
of
that.
So,
but,
first
of
all
just
a
background.
The
number
one
container
we
started
with
was
just
taking
post
grass
and
putting
it
inside
a
container
and
using
that
as
kind
of
the
foundation.
So
what
we
have
is
a
container
base
container
called
crunchy
post
grass.
It
includes
postcards
9.5.
B
We
also
have
a
9.3
version
and
can
spin
up
other
versions
depending
on
what
a
customer
needs,
but
that's
the
main
container
that
runs
our
post
grass
and
when
we
do
a
restore
job,
we're
basically
spinning
up
that
a
base
container.
So
a
lot
of
of
the
other
containers
I'll
talk
about
are
all
interacting
or
dealing
with
management
or
monitoring
of
these
Postgres
containers
and
whenever
we
create
a
Postgres
cluster
or
master/slave,
it's
all,
basically
just
this
crunchy
Postgres
container.
B
So
when
you
look
at
the
examples
we
do
or
ship
with
with
these
containers,
you'll
see
a
whole
bunch
of
persistent
volumes
and
persistent
volume
claims
that
get
built
and
used
whenever
you
do
these
backups
the
examples
that
I
ship
I'll
use
NFS,
but
you
could
certainly
translate
that
into
SEF
or
Gluster,
or
some
other
storage
capability
and
the
cube
openshift
guys.
Is
it
I
think
a
good
job
of
abstracting
that
choice
away?
B
So
it's
pretty
easy
and
straightforward
and
switched
from
NFS
to
Gluster
with
not
a
lot
of
lot
of
changes
now
right
after
I
did
backup.
Obviously,
I
wanted
to
figure
out
a
way
to
do
restore
from
one
of
those
backups
and
that's
really
performed
by
that
same
crunchy,
Postgres
container
and
just
by
passing
in
a
backup
path
into
that
container.
The
Postgres
container
and
passing
some
other
flags
environment
variables.
B
B
One
is
called
crunchy,
PG,
badger
and
I
was
asked
by
a
DBA
if
I
could
run
PG
badger
against,
which
is
kind
of
an
analytical
Postgres
log
analysis
tool,
pretty
good
one,
that
a
lot
of
people
are
used
in
the
Postgres
community,
so
yeah.
What
PG
badger
does
is.
It
has
to
read
the
log
files
from
Postgres,
so
I
created
a
container
that
if
you
drop
it
inside
a
pod
with
a
Postgres
container,
it
basically
lets
PG
badger.
B
Read
those
log
files
through
a
shared
volume
amount,
because
it's
inside
a
pod
you
you're
able
to
do
that
sort
of
thing
and
I
wrapped
a
PG
badger
with
an
HTTP
wrapper
essentially
around
it,
so
that
you
can
do
what
calls
basically
2pg
badger.
You
can
execute
it
and
it'll
spit
back
a
HTML
report
and
I'll
show
you
an
example
that
in
a
minute,
but
that's
a
case
where
I'm
leveraging
the
kind
of
unique
nature
of
what
a
pod
lets
you
do
by
combining
a
bunch
of
containers
together.
B
I'll
give
you
an
example
that
here
in
a
second
but
that's
a
Postgres
utility,
that's
been
out
there
a
long
time.
It's
written
in
Perl
I
think
it's
mostly
a
command-line
tool,
but
by
container
izing
it
wrapping
it
with
a
little
bit
of
a
web
container.
I
think
it
adds
some
some
value.
Crunch
EPG
pool
is
another
case
where
I
take
I've
taken
a
a
pretty
widely
known,
Postgres,
clustering,
utility
and
wrapped
it
inside
a
container,
and
what
PG
pool
basically
does
is
lets
you
proxy
Postgres
connections.
B
From
like,
let's
say
you
have
a
master
and
a
slave
connection,
PG
pool
set
in
front
of
those
running
as
a
standalone
container,
and
if
your
application
connects
to
that
PG
pool
container,
it
looks
like
you
have
just
one
single
connection
to
your
application.
A
PG
pool
is
actually
managing
two
separate
connections
internally
and
it's
sending
sequel
inserts
to
the
master
and
it
seems
sending
selects
to
the
slaves.
B
So
it
knows
kind
of
where
to
direct
certain
types
of
sequel
statements
and
it's
it's
kind
of
a
nice
utility
for
apps
that
really
just
want
to
manage
a
single
entry
point
into
a
cluster
as
opposed
to
managing
separate
connections
to
cluster.
So
in
Postgres
a
master
is
rewrite
and
slaves
are
read-only,
so
that's
the
distinguishing
characteristic
there
and
that's
really
the
value
I'm
getting
on
a
PG
pool
today.
Is
that
unique
feature
PG
pool
lets
you
do
a
lot
of
other
things
and
I
may
expose
those
features
in
that
container
over
the
coming
months.
B
Crunchy
watch
is
a
container
that
really
right
now
is
the
starting
point
for
performing
automated
failover.
So
crunchy
watch
does
is
looks
at
a
master
when
it's
running
and
that's
just
a
Postgres
node
and
it
basically
just
pings
it
uses
a
Postgres
command
called
PG
is
ready
to
just
basically
look
at
the
master
and
do
a
health
check
on
it.
Every
configurable
I
think
it.
The
default
is
like
every
20
seconds,
so
if
let's
set
that
repeating
it,
the
master
goes
down.
B
Containers
metrics
that
are
specific
to
Postgres
in
particular,
are
the
ones
that
I've
targeted
initially
so
there's
lots
of
different
Postgres
and
monitoring
tools
out
there
and
I
just
basically
pick
some
some
basic
one
metrics
that
the
people
are
familiar
with
and
the
the
purpose
of
crunchy
collect
is
to
collect
those
metrics
from
a
running
Postgres
container
and
then
pushes
them
off
to
Prometheus
time
series
data
store
for
storage
and
retrieval,
and
that
occurs
on
a
frequency
as
well.
That's
configurable!
B
So
if
you
have
a
database
that
you
want
to
collect
metrics
from
you,
basically
would
just
take
this
crunchy
collect
container.
Add
it
into
the
pod
that
your
database
is
running
and
it
will
automatically
build
begin
collection
of
those
metrics
and
pushing
them
out.
Basically
again,
it's
another
example
where
I'm
leveraging
that
capability
of
a
pod
to
have
multiple
containers
in
it
crunchy
Griffin
ham.
It's
part
of
this
metrics
collection,
in
that
it
gives
you
a
graphical
dashboard
capability
to
graph
those
collective
metrics
and
push
them
out
until
web.
B
App
and
I'll
give
you
a
demonstration
of
that
here
in
a
minute.
Crunchy
Prometheus.
Is
the
data
store
that
I
chose
for
storing
these
metrics
there's
other
data
stores
out
there,
but
Prometheus
I've
had
good
experience
with
it
so
far,
and
it
really
works
I
think
well
for
this.
This
kind
of
problem
to
solve
it's
nothing,
but
this
crunchy
Prometheus
is
nothing
but
a
wrapper
around
the
Prometheus
database.
B
My
base
images
run
typically
on
Rails
seven
base
images,
so
this
is
Prometheus
running
on
a
rail
seven
base
image
and
has
a
volume
mount
so
that
you
can
obviously
mount
the
data
out
to
some
NFS
or
whatever
persistent
storage
you
want
to
use.
Crunchy
gateway
is
literally
just
a
piece
of
Prometheus
that
they
have,
which
is
a
push
gateway,
so
it
enables
crunchy
collect
to
actually
push
metrics
to
this
gateway
and
then
Prometheus
crates
or
pulls
those
metrics
from
this
gateway.
B
So
a
very
small
micro
service
type
of
DBA
related
tasks.
That
is
an
example
again
of
something
that
we're
routinely.
People
would
want
to
do
against
a
production
level
database,
so
I
started
with
backup
job
and
vacuum.
Job
was
a
second
to
that
and
then
I
was
asked
by
another
client.
Well,
obviously,
we
would
like
to
be
able
to
schedule
these
things
and
we
don't
really
want
to
get
into
cron
schedulers
on
the
Linux
hosts
themselves.
We
want
to
have
a
containerized
way
to
execute
and
schedule
these
backup
vacuum
jobs.
B
So
I
created
a
another
container
called
Crunchie
DBA,
which
has
a
1:1
relationship
with
some
database
container
and
that
DBA
container
is
a
cron
scheduler
and
that
just
sets
out
there
and
says
what
frequency
do
I
want
to
do
these
various
DBA
related
tasks
now
the
ones
it
understands
today
that
you
can
schedule
our
backup
jobs
and
vacuum
jobs.
But
I
wanted
to
point
out
that
you,
if
you
let's
say
you,
have
ten
Postgres
containers,
you
would
in
this
case,
attach
you
know
ten
DBA
is
essentially
to
it.
B
B
Being
attached
to
your
database
and
its
job
is
just
kind
of
do
these
routine
tasks,
so
that's
the
structure
which
I've
set
up
here
and
I
would
envision
customers
using
this
to
write
their
own
DBA
jobs
and
just
using
backup
and
vacuum,
as
kind
of
like
examples
that
they
could
write,
you
know
their
own
custom,
backup
jobs
and
then
there's
just
a
very
little
bit
of
integration.
They
have
to
do
in
the
DBA
container
to
be
able
to
schedule
those
things
out.
B
B
B
So
that's
where
service
accounts
are
vital,
enable
to
be
in
order
to
be
able
to
do
that
kind
of
internal
API
type
or
NFS
volumes
are
used
for
backups
and
restores
again.
I
could
switch
that
out
with
staff
or
Gluster,
but
the
key
there
is
I
need
persistent
storage
for
holding
backups
and
it's
vital
to
have
that
because
you
just
wouldn't
make
sense
to
have
at
any
other.
You
know
non
persistent
backup
type
mechanism.
B
Now
I
can
use
NFS
volumes
or
choose
not
to
use
an
FS
volumes
to
run
my
Postgres
on
and
that's
a
key
point,
but
it
it's
up
to
you.
If
you
want
to
run
Postgres,
not
using
persistent
volumes
to
manage
you
know
doing
backups
and
being
able
to
withstand
losing
your
your
database.
But
if
you
do
use
like
empty
durval
Yume's,
you
do
get
a
nice
performance
increase
for
using
local
io
as
opposed
to
network.
So
you
as
the
deployer
of
this
technology.
B
You
know
you
want
to
really
think
about
your
use
case
and
whether
you
what
types
of
volumes
you
want
to
use-
and
we
could
tire
talk
just
on
that
subject
and
learned.
I've
I've,
learned
a
lot
about
I-
guess
the
hard
way
of
how
to
deal
with
volume
management,
but
I
give
you
the
option
in
a
lot
of
the
different
examples
of
running
these
containers,
of
using
either
NFS
volumes
or
empty
durval
Yume's.
And
if
you
were
to
look
at
the
examples
that
I
ship
with
it
you'll
see
where
I
make
make
reference
to
that.
B
Now,
where
are
we
going
with
this?
There's
a
whole
lot
of
containers
that
have
kind
of
exploded
here,
but
there's
probably
five
or
six
more
on
our
roadmap
to
do
in
the
next
coming
months
and
they're
all
Postgres
related
micro
services
that
either
help
or
or
augment
kind
of
the
experience
of
managing
groups
of
Postgres
containers
in
clusters.
So
there's
a
whole
bunch
of
different
types
of
tasks
that
that
I
we
envision
adding
to
help
a
DBA,
manage
this
and
monitor
and
then
there's
a
several
more
Postgres
cute
illa
teas.
B
The
goal
here
is
to
bring
in
a
lot
of
more
valuable
Postgres,
cute
illa
tees
into
this
container
infrastructure
and,
like
I,
say,
there's
already
five
or
six
that
we
kind
of
have
queued
up
to
do
now.
If
you
have
questions
about
any
of
this,
you
know
our
email
addresses
are
posted
there
at
the
bottom
and
also
our
website,
and
then
the
github,
no
github
x'
mark
private
now,
but
we're
about
to
release
this
at
some
point.
That's
gonna
go
public,
but
that's
the
where
everything
is
that
in
the
github.
B
B
B
These
crunchy
underscore
metrics
are
all
of
the
collected
metrics
that
we
pull
and
I
think
there's
like
30
or
32
of
them,
depending
on
how
you've
exercised
your
database.
Some
of
these
have
values
some
of
them.
You
really
need
to
run
some
load
against
in
order
to
get
something
to
show
up,
like
that's
a
good
example
of
a
metric
that
I'm
just
not
exercising,
but
it
is
also
an
example
where
you
can
combine
metrics
on
a
single
graph
and
gravano
lets.
B
B
Prometheus
is
really
gives
you
a
very
simplistic
graphing
in
query,
console
I
go
ahead
and
expose
that,
because
it's
a
nice
utility
just
for
people
to
do,
but
this
is
a
very
similar
graph
of
that
same
connection
metric,
but
it's
through
the
Prometheus
dashboard,
but
that's
a
good
way
to
test
your
metrics
that
you're
collecting
from
a
base
raw
level
to
say
well.
Is
it
even
store
in
my
in
my
Prometheus
database?
B
Probably
you
would
never
use
this
other
than
just
if
you're
debugging
your
setup,
but
it
is
out
there
and
you
can
kind
of
poke
down
into
individual
metrics
as
they're
being
cued
up
and
collected
PG
Badger.
This
is
the
output
of
the
PG
badger
container,
and
you
know
this
is
a
very
interesting
utility
and
I
can
see
wine
DBAs
like
it,
because
it
packs
a
tremendous
amount
of
log
analysis
into
one
single
webpage
and
you'll
see
up
here
in
the
URL.
That's
the
HTTP
wrapper
that
I've
placed
around
it
this
utility.
B
B
You
can
see
my
screen
just
this
is
going
to
be
hard
to
read,
probably,
and
it
certainly
command
line
stuff
doesn't
demo
particularly
well,
but
I
will
show
you
a
few
things:
I've
interests
from
the
command
line,
so
I
mentioned
the
vacuum
job
I
wanted
to
show
you.
Basically,
if
you
say,
OC
get
job
a
lot
of
folks
aren't
familiar
with
jobs
and
they've
never
run
OC
good
job.
You
know
they're
they're,
not
building
jobs,
but
it's
pretty
nice
and
with
a
job
there's
an
Associated
pod.
B
So
if
you
do,
if
you
look
here,
this
is
the
Associated
pod
with
this
job.
Okay.
So
if
you
look
at
the
output
of
that
vacuum
job,
you
will
see
that
it's
really
nothing
but
the
output
of
a
normal
post
grass
vacuum
sequel
statement,
but
that
gives
you
an
example
a
little
bit
of
how
jobs
look
and
work,
and
it's
it's.
It's
really.
You
know
kind
of
a
micro
service
very
narrowly
focused.
It
does
one
thing
and
that's
it.
You
know
that's
kind
of
the
goal
of
these
DBA
tasks.
B
B
I've
got
a
master
slave
out
there
running
and
basically,
if
I
issue
this
OC
scale,
RC
command
like
this
with
replicas
equals
2.
It's
basically
going
to
tell
kubernetes
and
OpenShift
hey.
I
want
two
slaves
instead
of
just
one
and
that's
a
very
simple
way
to
manually
scale
up.
He
may
cluster
and
you'll
see
here
these
three
lines
right
here,
they've
got
one
master
and
then
I've
got
two
slaves
and
that
master
is
replicating
to
those
two
slaves
and
you
can
just
continually
scale
up
these
kind
of
post-arrest
configurations
like
this.
B
Using
that
OC
scale
command.
Something
I
don't
have
to
demo
today,
but
I
will
in
the
future
is,
is
really
where
based
on
cpu
load.
Kubernetes
can
actually
perform
that
scale
up
for
you
and
that's
something
I'm
working
on,
but
not
quite
ready
to
show
that
yet
and
some
people
may
want
to
be
a
little
bit
more,
have
their
DevOps
seen
in
control
that
scale
up
and
scale
down
as
well.
But
that's
really
as
simple
as
it
can.
You
can
also
do
that
scale
up
command
through
the
web
console
as
well.
B
A
Thank
you
very
much
that
was
actually
quite
amazing
to
see
all
those
different
pieces
and
parts
containerized
and
available.
There
is
one
question:
Diego
Castro
from
get
up
clouds
asking
they
said,
he's
Percy
States.
There
is
no
scheduler
jobs
and
open
ships.
How
do
you
manage
crunchy
VBA
running
as
Kron
and
just
like
you
to
dive
a
little
deeper
in
how
that
all
you.
D
A
B
Sure
I
can
explain
that
so
crunchy
DBA
execute
a
going
version
of
cron
inside
it,
okay,
so
it's
not
hooked
into
any
external
scheduler
either
on
the
linux
host
or
with
an
open
shift
at
all.
It's
actually
taking
a
open-source
version
of
cron
again
written
and
go
lang
just
because
I
code
and
going,
and
it's
actually
executing
that
okay.
So
when
you
run
crunchy
DBA,
it
actually
starts
up
a
in
a
cron
scheduler
inside
the
container
and
it's
using
that
scheduler
inside
the
container.
So
it's
all
self-contained.
B
It
has
no
hooks
into
anything
outside
to
fire
off
this
and
it's
and
it's
doing
really
just
two
things
today:
it's
looking
for
the
scheduled
vacuum
jobs
and
it's
also
looking
for
scheduled,
backup
jobs
and
you
interact
with
crunchy
DBA
through
environment
variables,
there's
an
environment
variable.
Let
me
see
if
I
can
show
you
an
example,
real
quick
of
that.
D
B
B
B
Currently,
that's
a
good
question,
though,
because
what
I'd
like
to
do
is
be
able
to
support
some
kind
of
incremental
backup
and
that's
a
definitely
on
the
roadmap
I'm
looking
to
be
able
to
execute
incremental
backup
jobs
against
you
know
very
large
databases
where
PG
dump
or
PG
based
backup,
wouldn't
wouldn't
be
what
you
would
need.
So
that's
in
the
works,
and
it's
literally
high
on
my
priority,
is
to
implement
some
form
of
an
incremental
backup.
B
A
B
A
A
B
That's
that's
a
good
question.
Our
work
and
one
reason
why
we're
still
kind
of
working
on
this
is
is
exactly
how
to
release
it.
So
you
know
one
thing
we're
considering
doing
is
putting
these
on
a
private
for
like
enterprise
customers
that
want,
you
know,
paid
support.
What
we'll
probably
end
up
doing
is
putting
them
in
on
private
docker
repo
that
we
host,
and
only
you
know,
enterprise
customers
would
have
you
know,
access
to
that
repo
and
they'd
be
able
to
pull
down
pre-built
images.
B
Now
in
the
github,
you
would
have
access
to
all
the
docker
files
and
you'd
be
able
to
build
all
of
the
images
yourself
directly
on
your
infrastructure.
If
you
did
not
want
to
pull
down
pre-built
images,
the
pre-built
images
we
will
probably
build
will
be
rel
seven
base
images,
for
example,
with
the
crunchy
version
or
crunchy
built
post
grass
9.5
in
it.
Now
in
the
github,
you
will
see
there's
other
options
of
what
base
images
and
what
versions
of
Postgres
that
you
want
to
build
into
your
containers.
B
So
I've
tried
to
strap
those
kinds
of
things
out
into
just
build
environment
kind
of
configuration
options,
but
the
public
versions
of
these
will
probably
these
containers
would
like,
perhaps
they'll
be
based
on
CIN
OS
is
the
base
image.
Those
would
probably
be
hosted
just
out
on
docker
hub.
So
when
you,
when
we
make
an
official
release
of
this,
you
don't
always
see
these
two
separate
places
but
Paul
you
may
want
to
jump
in
and
clarify
that.
B
But
anyway,
stay
tuned,
we're
going
to
make
some
releases
of
this
and
announcements
and
there's
some
things.
We're
working
on
with
making
a
lot
of
this
stuff
available
out
there
and
like
the
open
ship
dedicated,
is
something
that
we're
seriously
looking
at.
So
we're
going
to
make
a
lot
of
technology
available,
just
pure
open
source
free
for
everybody,
and
then
there's
gonna
be
some
ways
in
which
you
can
get
this
from
like
a
paid
subscription
model
or
something
like
open
chef
dedicate
is
something
we've
actively
been
working
with
Red
Hat
on.
B
So
you
know
we're
anticipating
here
pretty
shortly,
like
I,
say
in
q2
of
this
year
to
have
this
ready
for
people
to
pull
down
and
consume,
and
there's
five
or
six
more
containers
I'm
trying
to
put
as
much
in
here
as
I
can
before
we
release
it.
But
what
I
also
want
to
do
is
make
sure
that
it's
documented
to
you
know
to
a
standard
that
everybody's
gonna
expect,
and
you
know
full
suite
of
tests
and
hooked
into
you
know
the
CI
build
system
that
you
know
that
will
that
we
have
as
well.
B
So,
there's
still
a
few
more
things
that
I'm
tweaking
and
tuning
before
we
we
put
it
out
there
for
everybody,
but
I'll
also
wanted
to
put
this
out
here
now
and
get
a
little
early
feedback
to
help
us
kind
of
tune
and
tailor
our
roadmap
going
forward
as
well.
But
I
see
this
growing
again
as
a
as
an
ecosystem
of
of
containers
and
micro
services
that
for
people
wanting
to
run
post
grass,
you
know
open
chef
post
grass
on
it,
our
Postgres
in
an
open
shift.
B
You
know
container
environment
trying
to
give
them
really
a
lot
of
tools
at
their.
You
know
at
their
fingertips
as
opposed
to
just
giving
them
a
container
and
saying.
Well
good
luck!
You
know,
so
we're
going
to
try
to
automate
a
lot
of
tasks
and
we're
gonna
try
to
do
it
in
a
real
OpenShift
container
way
and
that's
kind
of
our
philosophy
with
this.
So
any
other
questions,
I,
don't.
A
See
any
right
now,
but
I
actually
think
this
is.
This
has
really
been
very
good
and
very
insightful.
I
think
the
way
that
you've,
wrapped
things
up
and
the
tooling
into
containers
is
really
helpful
for
people
to
see
I
mean
there's
a
lot
of
other
folks
out
there
who
are
trying
to
do
similar
things
with
their
databases
and
their
service
offerings,
and
you
know,
usually
we
do
see
someone
just
create
a
container
with
just
the
database
in
it
and
not
really
anticipating
the
need
for
all
the
tooling,
and
this
is
very
well
thought
out.
A
B
Really
early
I
mean
probably
like
almost
two
years
ago.
Right
is
right,
as
the
the
docker
technology
was
kind
of
chosen
for
the
next-generation
openshift,
so
I
started
out.
You
know,
pre
like
really
early
with
kubernetes,
so
I
was
watching
and
testing
the
growth
of
kubernetes
and
openshift
to
see
you
know
how
could
I?
How
could
I
implement
some
of
these
things?
I
wanted
to
do,
and
you
know
a
year
and
a
half
ago,
two
years
ago
was
impossible.
There
was
not
things
there
like
service
accounts.
B
That
enabled
me
to
do
a
lot
of
of
this
really
low
level
integration
and
dynamics
stuff.
You
know
it
was
all
very
manual
year
and
a
half
ago
so
and
then
I
kind
of
went
through
have
needing
volume
management
and
saw
that
kind
of
evolve
as
well.
So
volume
management
right
now
is
is
really
working
good
enough
and
well
enough
for
us
to
do
some
of
this
database
related
stuff.
We
think
where
people
could
deploy
it.
You
know
really
solidly
as
well.
B
So
service
accounts
the
development
of
that
the
maturing
of
things
like
the
job
concept,
where
you
have
a
one-time
thing
you
want
to
execute,
that's
been
really
helpful
and
then
the
service
accounts
jobs,
volume
management.
All
those
things
have
really
made
it
possible
to
go
ahead
and
add
a
bunch
of
these
features
in
there.
Now
somebody
asked
a
question
I
hear
it
says:
could
other
database
systems
kind
of
do
some
of
these?
These
same
patterns
and
yeah?
We
think
so.
B
You
know
to
me
it's
just
logical
that
if
you
have
a
database,
you
know
in
a
particular
deployment
model
like
this
of
containers,
that
you
would
want
to
try
to
get
those
same
advantages
of
running
a
database
in
in
container
from
some
of
the
you
know,
all
of
the
tasks
around
managing
and
keeping
a
database
healthy.
So
to
me,
there's
some
of
these
patterns-
and
some
of
the
diagrams
I
put
in
here
specifically
are
very
you're.
B
Gonna,
see
those
same
patterns
and
other
in
other
databases
and
I
was
asked
the
same
question
from
another
or
another
company
is
doing
something
similar
and
yeah.
I
would
see
databases
in
openshift
working
a
lot
like
this.
Where
not
only
do
you
get
a
base
container,
but
you
get
a
lot
of
stuff
around
it
that
help
you
kind
of
treat
it
as
a
database
as
a
service
yeah.
So
things
like
building
a
web
user
interface
that
helps
you
manage
all
of
these
database
containers
I
mean
that's
something.
B
Definitely
that
we're
thinking
about
doing,
because
if
I,
deploy
and
spin
up
say
50
databases
and
have
them
all
out
there
now
I'm
going
to
be
looking
for
tools
that
manage.
You
know
that
entire
you
know,
collection
of
database
containers
in
some
smart
way
and
I
think
that
all
the
tools
that
are
now
therein,
OpenShift
and
kubernetes
that
allow
you
to
to
do
pretty
much
anything
that
you
can
think
of.
B
A
Whole
lot
of
work
has
gone
into
this
and
it's
really
much
appreciated
yes,
Paul.
Thank
you
very
much
for
the
second
and
I'm
looking
forward
to
seeing
a
number
of
other
database
systems
come
into
this
containerized
pattern
in
the
not-too-distant
future,
too.
So
I
think
this
is
really
the
crux
of
why
OpenShift
Commons
is
such
a
nice
peer-to-peer
network
because
we're
able
to
share
these
lessons
learned
and
inform
each
other,
and
this
has
really
been
a
very
good
example
of
that.
So
thank
you
very
much
for
joining
us
today.
A
Don't
see
any
other
questions
I
will
share
this
recording
out
through
the
mailing
list
and
on
the
website
shortly
and
will
be
up
next
week
with
some
talk
by
Google
on
kubernetes,
the
future
and
the
present
and
the
upcoming
roadmap.
For
that.
So
that's
a
good
one
to
look
forward
to
next
week.
Well,
thanks
again,
everybody
and
we'll
talk
to
you
all
soon.