►
From YouTube: The Level Up Hour (E48): Red Hat on Red Hat
Description
At Red Hat, we run many of our products in production on Red Hat Enterprise Linux, Red Hat OpenShift and utilize many of our product features on a day-to-day basis. In this episode, we'll take a look at Red Hat on Red Hat.
Learn more: https://www.redhat.com/en/about/red-hat-on-red-hat
Follow us:
Scott McBrien https://twitter.com/stabby_mc
What is the Level Up Hour?
Every Wednesday at 9am ET we stream live demos on how Red Hat Enterprise Linux (RHEL) users and admins can benefit their organizations and improve their careers by learning how to use containers, Kubernetes, and Red Hat OpenShift.
Learn more at:
https://red.ht/leveluphour
http://red.ht/3ayHlHI
How to participate in the The Level Up Hour:
Watch on YouTube every Wednesday at 9amET
Chat with us on Discord https://discord.gg/5VMVGJt
Check out our GitHub repo https://github.com/level-up-hour/
About OpenShift:
Red Hat OpenShift is an open source container application platform based on the Kubernetes container orchestrator for enterprise application development and deployment.
https://www.openshift.com/
https://github.com/openshift/
#RedHat #OpenShift #tluh
A
A
A
A
A
you'll
recall
that
it
was
quite
embarrassing
when
my
live
demo.
What
could
possibly
go
wrong
went
completely
pear-shaped
and
thanks
to
a
little
bit
of
troubleshooting
after
the
show,
I've
got
some
some
additional
information
to
clarify
what
went
on
there.
So
the
first
thing
is
that
when
I
was
doing
my
containerized
application,
I
said
you
know
what
I've
done.
This
is
root,
but
I'm
going
to
go
ahead
and
do
it
as
rootless
live
without
any
practice
or
validation,
and
that
was
my
undoing.
A
So
one
of
the
things
I
attempted
to
fix
was
by
pulling
a
multi-service
image
from
ubi
and
that
actually
fixed
the
problem.
Although
we
didn't
know
it,
the
other
solution
was
from
our
audience.
Jonathan
tucker
had
suggested
that,
instead
of
making
a
call
to
init
is
the
initial
process
for
the
container.
A
We
should
directly
call
apache
and
it
turned
out
that
also
fixed
the
problem,
but
we
didn't
know
it
because
the
other
thing
that
was
happening
was
firewall
d,
so
without
punching
a
hole
through
the
firewall
to
allow
port
80,
not
a
whole
lot
of
web
application.
Stuff
is
going
to
be
going
there.
So
what
did
we
learn?
One
test,
your
demos
before
you
go
live
with
them.
Two
always
check
other
components
like
firewalling
to
make
sure
that
your
traffic
can
pass
through
all
right.
A
B
C
Hey
I'm
a
platform
architect
within
red
hat.
I
t
focus
on
containers
and
platform
as
a
service,
and
I
work
a
lot
with
brian
on
producing
internal
platforms
for
our
developers
to
use
to
deploy
to
to
build
their
applications
on
and
and
ultimately
host
a
lot
of
the
red
red
hat
applications
that
we
use,
both
internally
and
and
externally,
for
our
customers.
A
B
You
know:
middleware
openshift,
rail,
rev,
openstack,
really,
the
entire
suite
of
red
tap
products
we
run
internally
to
serve
our
customers
and
obviously
our
iq
shop
is
is
mostly
rel.
We
have
about
95
of
our
os
images
or
containers
are
rail-based,
and
so
we
just
have
an
enormous
platform
for
our
users
to
actually
utilize
and
develop
on
red
hat
products
and
obviously
open
shift
is,
is
very
critical
to
that
strategy
and
I'll.
Let
then
tell
you
a
little
bit
about
that.
C
Yeah,
absolutely
so
as
part
of
red
hat
on
red
hat.
We
talk
a
lot
about
our
internal
container
and
open
shift
usage,
and
this
is
really
useful
for
other
it
organizations
across
other
companies
to
really
just
see
and
practice
red
hat
products,
as
as
we
use
them
day
to
day
how
we
design
them,
how
we
implement
them,
how
we
maintain
them
long-term
operations
and
and
ultimately
cover
the
full
life
cycle
of
how
we
run
red
hat
products
internally,.
A
C
C
Actually
our
history
with
openshift
goes
way
back
as
well,
and
when
I
joined
it,
we
were
running
production,
openshift,
2
platforms
as
well,
so
yeah,
it's
kind
of
our
history
and
and
how
we
offer
openshift
as
a
internal
cloud
platform
for
again
our
red
hat
developers
to
come
and
build
and
deploy
mainly
rail
applications
but
yeah.
We
also
interface
with
other
types
types
of
container
images.
A
And
ben,
were
you
talking
about
building
rel
for
deployment
you're
talking
about
container
images
right,
correct,
yes,
okay,
and
do
you
guys
build
or
they
roll
back?
Do
you
recommend
that
people
build
their
own
container
images
off
of
the
rail
sources,
or
do
you
guys
start
with
something
like
the
universal
base
image
like
where's
the
entry
point
there.
C
Kind
of
depends
on
the
use
case
it
depends,
is,
is
the
answer,
but
for
a
lot
of
our
custom
applications
absolutely
we.
We
recommend
that
you
use
like
the
the
red
hat
registry
services
to
effectively
get
the
great
work.
That's
already
been
being
done
and
maintaining
kind
of
those
base.
Rel
images
we
don't
want
to
have
all
of
our
develop
developers,
start
from
scratch
where
they
don't
need
to
and
there's
a
lot
of.
C
You
know
security
updates
and
vulnerability,
fixes
that
are
maintained
in
the
images
that
are
hosted
like
at
the
red
hat
our
registry
services.
So
we
recommend
for
for
developers
start
where
you
need
to
and
if,
if
there's
great
work
already
being
done
and
maintain
maintain
sorry,
maintaining
some
of
those
base,
images
feel
free
to
use
that.
With
that,
you
know.
C
A
Excellent
and
just
to
set
the
audience
like
concepts
of
containers
and
what
we
offer
from
red
hat's
registries
a
little
bit.
So
there
are
basically
two
piles
of
container
images
that
red
hat
maintains:
there's
the
rel
ones
which
require
well
subscription
and
have
access
to
the
full
repository
of
software
that
is
distributed
with
rel.
A
C
Absolutely
yeah,
so
what
we
strive
for
internally
within
red
hat,
I
t
is:
we
want
to
have
automated
life
cycle
management
of
our
applications
as
we
build
deploy,
monitor
test
validate
effectively
all
all
that
stuff.
We
want
a
machine
to
do.
We
don't
want
a
person
to
necessarily
have
to
go
in
and
kind
of
do
all
those
activities
and
build
is
an
important
part
of
that
too.
C
Policies
we
have
internally,
you
know
we
like
app
teams
to
build
rebuild
weekly.
Actually,
this
also
just
makes
sure
we
have
good
grooming
of
of
the
application
we
can
successfully
and
healthily
redeploy
it
in
that
everything's
working
as
intended,
and
so
really
just
kind
of
that
that
practice
of
the
life
cycle
management
is
a
good
thing
to
be
doing
regularly
and
and
again
we,
we
kind
of
like
our
app
teams
to
be
doing
that
weekly
yeah.
C
A
C
Ideally,
it's
it's
as
hands-off
as
possible,
although
you
know
in
practice,
there's
still
some
manual
steps
like
uat.
Sometimes
you
have
to
jump
in
and
kind
of
manually
test
some
things,
but
for
the
most
part,
as
you're
coding
and
you're
committing
that
code
to
say
your
main
line
branch,
you
want
automation
to
kind
of
pick
that
up
automatically
build
and
redeploy
your
application.
C
B
You
know
eight
gigs
of
ram
and
so
on
to
virtual
machines,
just
because
we
don't
want
to
overload
the
openshift
environments
and
we
we
didn't
want
to
have
to
provision
very
large,
vms,
underneath
openshift.
However,
with
with
recent
openshift
versions,
that's
obviously
changing
a
lot
and
lets
us
support
much
larger
containers.
B
A
B
Do
a
live
migration
of
that
vm
across
hypervisors,
as
we
we
down
the
hypervisor
versus
and
in
the
container
world
having
to
spin
down
that
container
and
restart
it
on
different
node,
so
kind
of
that
those
legacy
applications
that
that
can't
go
down
because
they
run
some
business.
Critical
resource
and
they're
just
have
a
legacy
architecture.
Those
still
very
much
live
in
in
the
vm
realm,
but
obviously,
as
as
newer
applications
come
along.
A
Yeah
and
yesterday
in
our
pre-show
meeting,
we
were
talking
a
little
bit
about
automation
and
I
know
that
like
we're
just
talking
about
removing
people
from
the
equation
for
deployments
and
things
like
that,
but
there's
a
differential
between
automation
and
orchestration.
So
what's
the
difference
there
and
how
do
you
utilize?
It.
B
So
I
usually
think
of
orchestration,
as
in
I'm
orchestration
orchestrating
a
release,
I
need
to
pull
some
nodes
from
a
load.
Balancer,
basically
right,
write
logic
that
that
can
systematically
roll
out
the
application
without
any
real
user
facing
impact,
whereas
automation-
it's
just
hey.
I
want
to
automate
this
process
that
you
know
goes
and
creates
a
ldap
user.
B
C
Yeah,
absolutely
so,
I
think
we
we
start
to
see
automation
realized
in
openshift,
especially
recently
with
operators,
and
this
is
something
I'm
really
excited
about
as
well.
How
can
we
start
to
automate
external
and
internal
dependencies
to
an
application
via
how
you
can
control
for
a
piece
of
automation
in
an
operator
to
say
reach
out
to
an
external
service
and
when
you
create
an
openshift
route,
create
an
analogous
monitor
synthetic
monitor
along
with
it,
and
that's
a
great
example
of
how
we
can
automate
particular
activities
from
our
cloud
platform
in
openshift?
C
How
an
application
kind
of
takes
that
piece
of
automation
and
realizes
it
in
their
lifecycle
management
is
kind
of
more
aligned
with
the
orchestration
so
using
our
pipeline
tooling.
Our
continuous
deployment
tools,
as
well
to
say
hook
into
that
piece
of
automation
in
this
example
like
an
operator-driven,
a
piece
of
automation
and
kind
of
build
their
whole
application.
A
C
I
would
add
to
that
that
it
could
be
useful
just
to
get
something
kind
of
quickly
solved
for
like
in
your
particular
use
case,
and
that's
where
you
know
the
the
shell
scripts
kind
of
more.
The
like
tactical
ansible
playbooks
can
be
really
helpful,
like
I
have
a
problem
to
solve,
and
I
can
do
it
quickly
using
like
ansible
or
scripting
to
kind
of
solve
for
that.
But
once
you
need
that
to
be
solved
across
many
applications
or
across
a
platform.
A
B
C
B
C
B
C
B
A
So
brian,
I
have
to
say,
I'm
feeling
a
bit
attacked
because
I
found
out
17
years
later
that
a
piece
of
pearl
that
I
had
written
in
a
weekend
was
still
production,
and
I
found
that
out
because
somebody
was
like
hey.
This
needs
to
be
updated,
but
you
were
the
last
one
to
work
on
it.
Can
you
update
it?
I
was
like
what
yeah.
A
Pearl
so
cool,
so
I've
seen
a
lot
of
organizations
around
like
they
don't
always
think
about
maintenance
or
longevity
of
their
applications
right,
and
this
is
kind
of
tying
into
what
we're
just
talking
about
where
it's
like.
I
just
want
to
get
it
done.
I
just
want
to
do
it
and
I
find
that
a
lot
for
application
development
as
well.
It's
like
I
have
to
have
this
thing
deployed
by
thursday
and
then
after
thursday,
I
never
have
to
think
about
it
again
and
in
reality,
that's
not
true.
C
I
think
the
first
thing
that
comes
to
mind
is
generally
we're
talking
in
the
onboarding
process
or,
like
you
said,
as
the
the
application
is
being
developed,
my
I
would
say
to
app
teams
think
about
the
day
when
this
application
is
turned
off
and
that
that
might
be
really
hard
to
think
about,
because
that
could
be
like.
We
just
said
there
could
be
something
running
for
17
years.
So
how
do
you
think
about
that
date?
B
C
B
Without
you
know
a
app
being
tightly
coupled
to
the
middleware
being
tightly
coupled
to
the
database,
which
just
becomes
a
very
rigid
thing
to
to
have
to
and
brittle
thing
to
have
to
migrate
later
on,
because
it
will
need
to
be
migrated
at
some
point
or
will
kill
it,
but
either
either.
One
of
those
activities
will
require
a
substantial
amount
of
work
and
kind
of
how
much
work
depends
on
your
initial
architecture.
A
Yeah,
I
remember
working
on
a
on
a
project
and
the
vice
president
of
this
department
was
like
really
frustrated
because
he
expected
that
after
thursday
we
would
never
have
to
work
on
this
thing
again
and
he's
like,
but
wait.
We
have
to
like
keep
doing
work
on
it.
You're
gonna
want
new
things
in
it,
and
we're
gonna
have
to
revisit
it
over
and
over
again,
and
that's
probably
also
tied
into
ben.
What
you
were
saying
earlier
about.
A
A
C
We
always
want
applications
to
think
about
re-architecture
about
driving
cloud-native
practices
as
they
deploy
two
container
platforms
and
and
within
a
hybrid
cloud
I
will
say
there
are
programs,
there's
projects
that
sometimes
mean
we
need
to
make
choices
about
what
we
re-architect
at
certain
points
of
the
life
cycle.
So
there
are
some
applications
that
we
will
we'll
say:
okay,
we'll
kind
of
do
more
of
a
lift
and
shift
model
with
this
application.
C
At
this
point,
we'll
we'll
simply
take
the
bits
put
it
in
a
container
and
put
it
on,
say
this
particular
open
shift
deployment,
but
we
also
need
to
track
again
the
life
cycle
of
how
are,
we
think,
rethinking
you
know,
say
our
network
dependencies
or
how
we're
breaking
this
out
into
more
of
a
microservice
model
over
time.
Given
that
we
do
that
initial
onboarding
say
that's
more
driven
from
like
a
a
lift
and
shift
practice.
C
So
sometimes
it's
you
know
we
got
a
pick
and
choose
kind
of
where
we
change
an
application
at
particular
points
in
this
life
cycle.
But
it's
important
that
we,
like
you,
said,
consider
just
because
it's
deployed
in
a
container
on
openshift
doesn't
mean
we're
done.
There's
always
improvements
breaking
down
into
more
of
a
micro
service
architecture
that
that
we
can
be
thinking
about.
B
C
C
A
And
I
know
that
in
the
last
two
and
a
half
years,
or
so
we
at
the
real
side
of
things,
I
think
we
made
some
decisions
at
the
product
layer
to
react
to
some
of
the
things
that
you
guys
are
seeing
in
the
operations
field.
So
with
rel
eight,
we
started
the
predictable
release
cycle
cadence,
which
means
every
six
months.
We
have
a
new
dot
release
every
three
years.
We
have
a
new
major,
so
you
know
at
this
point
we
should
expect
rel
nine
coming
out
next
year.
A
Because
it's
it's
imminently
coming
out
in
the
next
year
and
then
the
other
piece
of
that
is
like
we've
now
forecast
the
life
cycle
right
used
to
be.
You
didn't
really
know
when
things
were
going
to
change,
and
now
we
have
a
documented
here's
when
it
ends.
Here's
when
it
goes
into
maintenance,
mode
or
maintenance
phase,
so
that
you
guys
can
have
those
better
conversations
with
people
as
they
get
onto
the
platform.
B
You
know
when,
when
they
need
to
be
adopting
real
nine,
and
so
we
kind
of
take
the
the
official
product
life
cycle
that
that
we
publish
and
and
kind
of
what
we
expect
coming
down
the
pike
and
as
well
as
combine
our
security
standards
with
that
and
the
end
result
is
we
could
give
our
our
customers
a
very
predictable
set
of
standards
that
they
could
say.
Okay.
B
Well,
you
know
rail
eight
will
officially
be
d
supported
by
it
at
this
date,
so
I
need
to
be
on
real
nine
by
then,
obviously
with
containers
that
makes
that
transition
a
lot
easier
as
well.
I
don't
have
to
rebuild
the
vm
and
so
on
so
that
yeah.
I
definitely
really
appreciate
that
the
work
red
hat's
done
to
be
more
predictable
in
releases
and
and
how
long
these
are
maintained
for.
A
You
at
least
now
know
when
you
have
to
not
forget
it
anymore
right
because,
like
in
eight
seven
or
eight
years,
you
need
to
think
about
where
your
next
step
is,
which
means
you
may
have
to
get
budget
for
bringing
developers
on
to
do
your
updates
and
migration
to
get
to
that
next
release.
But
anyway,.
B
A
C
I
would
say:
read
the
documentation,
understand
what
we're
offering
kind
of
from
a
platform
perspective
and
see
how
you
can
use
the
tooling
that's
already
there
and
then
give
the
feedback
where
it
may
not
meet
your
use
cases,
because
one
of
the
things
that
that
we
sometimes
see
when,
when
we
offer
a
platform
and
for
context
the
platforms
that
the
openshift
platforms
we
we
run
internally
are
our
main
production.
Hybrid
cloud
platform
supports,
I
think,
180
different
applications
on
it,
and
these
are
all
like.
C
How
do
you
monitor
that
the
pipeline
is
running
successfully?
How
do
you
who's
going
to
be
on
call
when
a
pipeline
breaks
down?
You
know
that
type
of
thing
as
we
introduce
new
tools,
we
need
to
think
about
how
we
support
them,
and
so
that's
why,
from
a
from
a
platform
perspective,
when
we
have
kind
of
standardized
integrated
tooling
that
we
know
we
can
support,
my
request
would
be
try
those
out
first
and
where
they
don't
work.
Let's
talk
about
the
the
updates
or
the
the
rfes
that
need
to
be
associated
with
those.
B
Yeah
there
there's
always
going
to
be
the
20
percent
use
case.
You
know
20
of
the
app
teams
who
who
can't
take
advantage
of
of
whatever
tooling
we're
providing
because
of
x
and
being
able
to
communicate
that
clearly
and
what
what
success
looks
like
to
us
is
enormously
helpful
and
at
the
end
of
the
day,
most
apps
don't
fall
into
that
20
category,
although
they
do,
they
think
they
do,
and
usually
we
have
solutions
to
to
meet
whatever
need
they.
B
They
have
so
it's
important
to
for
app
teams
to
be
willing
to
collaborate
with
with
the
platform,
owners
and
infrastructure
teams
on
on
what
their
application
really
needs
versus.
What
maybe
somebody
knows
you
know
we
we
do
see
developers
coming
in
and
saying
I've
always
done
it
this
way.
So
I
want
to
keep
doing
it
this
way
and
it's
like
well.
Actually,
we
have
better
tooling
for
that
now.
So
how
about
you?
You
look
over
here
and
that
that
usually
goes
pretty
well,
so.
A
So
one
of
the
things
that
we
see
a
lot,
especially
from
like
operation
side
like
we're,
really
adept
at
standing
up,
openshift
or
standing
up,
rel
container
hosts
or
whatever
the
case
may
be,
but
then
we
lack
onboarding
to
help
the
dev
teams
get
onto
those
platforms,
and
so
what
we
end
up
with
is
like
an
infrastructure,
that's
running
without
anything
running
in
it.
I
know
that
you
guys
do
a
tremendous
amount
of
coaching
and
helping
onboard
people
and
teams
to
your
platforms.
C
Yeah
this
is
this
is
something
I
think
our
team
spends
a
lot
of,
probably
underestimated
time
on
is
how
do
you
successfully
drive
applications
to
adopting
container
platforms,
so
some
of
the
things
we've
done
internally?
Is
we
try
to
make
it
clear
when
it's
when
you're
a
good
fit
for,
say
our
internal
openshift
platforms
versus
where
you
may
want
to
go
to
say
a
virtualized
workload
kind
of
how
we
were
talking
about
making
that
that
decision
making
process
earlier?
C
B
Yeah
and
I
think
also
providing
teams
with
with
clear
patterns
of
hey.
Your
application
looks
like
this.
Okay,
here
are
the
the
set
of
of
tools
and,
and
you
know,
patterns,
and
even
you
know,
templates
the
ammo
files
that
that
they
could
quickly
adopt
for
for
how
their
applications
architected
goes
a
long
way
towards
helping
them
get
on
the
platform
there's
very
little.
A
B
C
A
A
C
I
would
say-
and
this
is
from
experience-
although
kubernetes
has
come
a
long
way
since
I
think
we
ran
production
kind
of
vanilla,
kubernetes
within
red
hat.
I
t
this
goes
back
to
like
2015.,
but
a
lot
of
the
challenges
we
are
trying
to
solve
with
a
kind
of
vanilla,
kubernetes
distribution
is
authentication
authorization.
C
C
So,
from
an
operations
perspective
around
a
container
platform,
we
were
having
to
solve,
for
particular
things
in
kubernetes,
specifically
around
our
back
and
ingress,
that
we
could
spin
up
openshift
and
we
had
apis
in
which
to
work
and
kind
of
manage
this
stuff.
More
natively
to
you
know,
container
namespaces,
as
I've
said,
kubernetes
has
come
a
long
way
since,
but
I
think
what
what
openshift
offers
still
aligned
with
what
we
saw.
B
Yeah,
I
would
also
add
that
we
run
openshift
everywhere
and
increasingly
more
and
more
that's
running
openshift
in
in
public
cloud
providers,
but
also
running
it
in
three
node
bare
metal
servers
in
the
closet
and
some
office,
someplace,
so
being
able
to
kind
of
leverage
a
consistent
platform
really
everywhere
and
and
give
the
developers
both
build
tools.
Pipeline
deployment
tools,
as
well
as
obviously
the
container
runtime
is,
is
critical
for
that
that
seamless
experience
and
and
letting
customers
run
their
their
workloads
really
anywhere.
B
It
makes
sense,
so
openshift
has
become
our
abstraction
layer
and
we
we
don't
want
app
teams
running
on
the
underlying
infrastructure.
That
itself.
We
we
wanted
to
to
run
on
openshift,
obviously
kubernetes
has
been
mentioned,
has
come
a
long
way
as
well
and
and
there's
you
know,
depending
on
on
what
kubernetes
solution
you
look
at,
it
supports
different
kind
of
footprints,
but
openshift.
You
really
have
that
that
seamless
platform
that
stretches
really
anywhere
you
need
to
deploy
it.
A
A
long
long
ago,
someone
once
told
me
that
open
open
source
is
free
if
your
time
is
worthless
and
so
products
like
red
hat
enterprise,
linux,
open
shift,
red
hat,
virtualization,
they're,
all
based
on
open
source
projects,
but
red
hat
puts
a
ton
of
effort
and
development
not
only
into
the
actual
open
source
community
for
that
project,
but
also
into
the
packaging
maintenance.
Longevity
management
of
that
thing,
and
so
openshift
is
not
just
kubernetes
right.
A
B
A
Absolutely-
and
one
thing
I
do
hear
customers
say
is
like
why
I
didn't
even
open
a
support
case.
So
what
is
this
for?
And
I
would
say
that,
even
if
you're
not
opening
sport
cases,
that
tells
me
that
we're
doing
a
good
job
right,
because
that
means
that
all
of
the
engineering
work
that
we're
putting
into
the
product
all
the
qe
work
that
we're
putting
in
before
release,
like
that's
all
paying
dividends,
which
is
why
you're
not
opening
support
cases.
But
if
you
do
need
support
cases,
we
of
course
have
that
too.
C
B
A
All
right
so
now
is
the
point
of
the
show
where
we
do
sweet
sweet
internet
points,
so
ryan
and
ben
you're
you're
new,
so
you've
not
seen
this
before
and
just
to
recap.
This
is
episode.
48
we
had
brian
atkinson
and
ben
on
for
talking
about
red
hat,
on
red
hat,
right,
running
red
hat
tools
at
red
hat,
all
right,
so
sweet,
sweet
internet
points
and
I'm
sure
stephanie
our
show
producer
will
shortly
paste
this
into
the
chat.
A
So
it
looks
like
narendev
has
woken
back
up
from
his
slumber
and
is
continuing
to
accumulate
sweet,
sweet
internet
points
to
extend
his
lead
on
the
other
folks
out.
There
bacon
fork,
still
respectable
midfielder
at
2900
points
and
we'll
we'll
see
can
can
anyone
catch
narendo.
That's
that's
the
real
question
don't
forget
to
like
and
subscribe.
If
you
enjoy
the
level
up
our
programming
and
we
look
forward
to
bringing
you
more
soon.