►
Description
Need to move your containers from your desktop to production Kubernetes? No sweat! Podman's generate-kube functionality can help. In this episode, we'll look at deploying a multi-tier containerized application from Podman container, pod, or volume to OpenShift. We'll first walkthrough generating a Kubernetes YAML file using Podman and then cover the steps needed to use that YAML to move the environment from local development into OpenShift production. So join us to learn more about using Podman generate-kube to help move from local development into OpenShift production.
Learn more: https://developers.redhat.com/blog/2019/01/29/podman-kubernetes-yaml
Want to try OpenShift?
https://www.redhat.com/en/technologies/cloud-computing/openshift/try-it
Follow us:
Scott McBrien https://twitter.com/stabby_mc
Randy Russell https://www.linkedin.com/in/randy-russell-0312243
Jaafar Chraibi https://twitter.com/ChraibiJc
What is the Level Up Hour?
Every other 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 #RHEL #tluh
A
A
A
Well,
there's
functionality
and
tooling.
That
actually
will
help
with
that
and
jafar
is
going
to
walk
through
a
bunch
of
the
steps
involved
with
this
some
of
the
tooling
some
of
the
kinds
of
things
that
you
need
to
know
we'll
even
take
maybe
a
brief
demo
and
of
course,
your
questions
in
the
chat
are
always
welcome.
So
jafar
welcome.
B
A
B
A
B
Yeah
sure,
so
that's
that's.
I
think
a
very
good
start
starting
point,
because
so
I've
been
working
with
customers
when
I
was
doing
openshift
consulting
for
about
five
years
so
and
during
those
five
years
I've
I've
met
probably
hundreds
of
customers
who
were
all
using
different
types
of
technologies
and
are
and
started
getting
into
the
container
journey,
and
so
for
us
from
an
openshift
perspective.
B
A
B
I
went
to
developer
to
to
meet
our
customers
and
our
developers.
I
was
actually
surprised
to
see
that
those
topics
were
very,
very
new
to
them.
Actually
so
and
even
years
after
we
we
had
embraced
that
there
were
still
some
developers
who
were
still
using
like
the
traditional
way
of
doing
things,
kicking
off
application
servers
on
their
laptop
doing,
building
their
code
locally,
deploying
it
locally
etc.
B
B
So
so
I'd
say
that
docker
had
made
in
the
early
days
a
great
job
in
making
things
easier
and
the
the
the
some
things
happened
along
the
way
they
they
started
to
to
have
some
difficulties
in
in
providing
a
reliable
life
cycle
for
their
container
engine
and
stuff.
Like
that,
and
some
some
things
emerge
in
the
open
source
community
as
a
as
an
alternative
to
docker.
So
we
we
can
think
about
things
like
cryo,
which
is
like
the
now
has
become
the
default
runtime
for
kubernetes.
B
B
B
B
You
have
several
options,
which
is
the
first
one
is
to
make
everything
run
within
the
same
pod.
You
have
maybe
three
containers
that
are
going
to
run
in
the
same
pod.
It's
probably
going
to
be
easier
to
deploy,
but
it's
not
necessarily
a
good
practice
if
your
individual
components
need
to
be
able
to
scale
up
and
down
individually,
so
there
you
have
the
other
option,
which
is
packaging,
your
application
into
separate
containers
and
into
and
deploying
them
into
separate
pods.
B
B
A
B
But
if
you
wanted
to
be
able
to
scale
your
components
individually
and
still
have
this
notion
of
a
shared
state
between
all
of
those
instances,
because
now
you
are
going
to
run
tens
10
instances
of
your
containers
for
the
same
thing,
which
is
probably
maybe
your
front
end
or
something
like
that.
You
don't
want
the
user
to
to
switch
from
one
container
to
the
other
and
then
suddenly
lose
state.
B
So
now
you
have
to
to
start
thinking
about
things
like
distributed,
cache
or
replication,
and
and
such
things
when
you
are
moving
your
applications
into
containers.
So
so
yes,
there
are
several
things
you
need
to
take
into
consideration
and
that's
probably
why
developers
needed
some
time
before
really
starting
to
use
containers
as
such
as
a
native
way
of
doing
their
local
development,
so
yeah.
B
So
something
else,
but
that's
going
to
be
a
different
story
when
you
are
when,
when
you
are
doing
so,
for
example,
web
development
or
javascript
or
such
things,
and
and
you
want
to
iterate
very
quickly
on
your
local
ide,
you
have
things
like
hot
reload
or
or
what
we
call
live
reload,
which
is
basically
as
soon
as
you
hit
the
changes
and
save
them
in
your
local
files.
They
are
immediately
reflected
into
your
local
application
that
runs
on
your
laptop.
B
B
And
then
this
is
going
to
generate
a
new
container
image,
and
then
you
have
to
re-deploy
a
new
pod
from
that
new
image
which
takes
time
because
now,
in
addition
to
the
build
time
required
for
your
application
package,
you
are
adding
that
build
time
for
the
image
which
can
be
30
seconds
to
maybe
a
minute
and
then
redeploying.
The
application
etc.
B
You
run
running
in
a
container,
but
maybe
mounting
your
local
volumes
where
your
code
is
so
you
can
have
that
sort
of
live,
reload
experience
that
you
would
have
with
with
a
traditional
environment
so
yeah.
There
are
many
things
to
to
take
into
consideration
and
we
we
actually,
as
red
hat,
have
provided
different
ways
to
address
that.
But
maybe
that
can
be,
I
would
say,
the
content
for
another
episode.
A
B
A
B
B
A
B
You
go
in
there
all
right,
cool,
so
yeah,
so,
as
you
can
see,
we
are
going
to
run
three
podman
commands,
so
the
first
one
is
going
to
create
the
the
demo
database
based
on
mysql,
and
it's
going
to
use
a
container
image
that
we
have
on
clay.
The
second
one
is
going
to
generate
a
in
a
python
application
that
injects
data
points
in
in
the
the
database
and
the
third
one
is
going
to
be
a
web
front
application.
That's
going
to
show
basically
some
live
graphs.
B
B
So
we
see
that
we
have
a
volume
that
has
been
created
to
store
the
data
for
the
database.
So
that's
a
first
check
then
now,
as
I
would
say,
a
developer,
I'm
gonna
try
to
list
my
containers
to
check
the
logs
for
for
those
components.
So
what
I
want
to
see
here
is
if
the
the
demo
web
component
is
started
or
not
yet.
So,
if
you
know
a
bit
about
so
yeah,
it
seems
like
it
has
already
started.
So
I
have
the
the
the
application
up
and
running
in
here.
B
B
B
B
As
you
can
see
here,
there's
I
would
say
an
a
container
that
we
call
the
intracontainer
and
there's
the
container.
That
has
your
application
layer
on
top
of
it,
and
if
you
want
to
be
able
to
to
see
all
your
containers,
then
you
have
to
add
those
extra
commands
that
say
container
ids
that
basically
display
all
the
containers
that
run
within
the
same
pod
right
and
how
do
I
under
know
which
spot
is
my
application
layer?
B
So
basically,
you
see
here
the
id
of
the
infra
container,
and
that's
the
same
that
you
see
here,
so
you
can
guess
that
the
other
one
is
the
actual
container
that
you
want
to
look
at
if
you
want
to
troubleshoot
your
application
and
understand,
basically,
what's
what's
what's
happening
in
there,
okay,
so
the
goal
here
is
also
to
show
you
the
experience
when
you
are
using
podman
and
how
to
to
do
some
usual
things
before
going
into
openshift.
Okay.
B
So
now
that
we
have
that
application
up
and
running,
let's
switch
to
openshift
and
try
to
replicate
the
demo
on
on
the
openshift
server.
So
here
on
my
openshift
cluster,
I'm
already
logged
in-
and
I
can
see
that
I
have
nothing
running
yet
in
the
palman
environment.
It
looks
like
a
whole
lot
of
nothing.
B
Yes,
so
if
you
remember
correctly,
we
had
a
volume
when
we
were
using
podman
locally.
We
had
a
volume
that
was
created
to
store
the
data
for
the
mysql
database
right.
So
we
want
to
replicate
the
same
thing
on
openshift
and
the
mechanism
that
we
are
going
to
use
is
by
creating
what
we
call
persistent
volume
claims,
and
this
is
going
to
trigger
the
creation
of
a
persistent
volume
on
openshift.
A
B
B
How
about
now
you're,
not
bad
okay?
So
what
what
I
have
here?
You
can
see
that
there
are
some
some
comments
here
that
say
this
kubernetes
resource
has
been
generated
by
podman
and
so
we're
first
gonna
run
it
on
openshift
and
then
I'll
show
you
how
to
actually
generate
those
assets
from
from
openshift.
So
first
thing
we're
going
to
create
the
the
pvc
okay.
A
B
Yeah,
so,
okay,
let's,
let's,
let's
see
what
has
been
generated
for
us.
So
first
thing
is
the
persistent
volume
claim?
Okay,
so
all
everything
has
been
created
now
it
seems.
Okay,
I
have
my
persistent
volume
here
and
if
I
look
at
the
pods
I
already
have
also
the
pods
that
are
running
in
in
in
openshift.
B
Okay,
so
how?
How
did
we
create
those?
So,
basically,
if
you
look
at
the
different
components
that
we
have,
the
first
one
is
the
the
demo
database
and
podman
has
generated
a
pulled
resource
for
us.
That
has
all
the
arguments
that
we
we
need,
like
the
container
image,
the
capabilities,
the
mount
point,
etc.
So,
basically,
all
the
resources.
I
need
to
deploy
the
the
container
image.
So
this
is
a
pawn.
B
I
have
the
other
component,
which
is
the
generator
and
again
it
references
the
image
it
tells
bootcamp
which
capabilities
I
need
and
the
third
one
is
the
the
web
environment.
So
there's
something
that
is
specific
to
this
container
image.
So
I
picked,
I
would
say,
a
random
image
from
from
the
internet
that
we
use
as
an
example
when
you
are
using
pubmen
and
this
image
happens
to
run
with
a
root
user,
which
is
not
something
that
you
usually
want
to
do
when
you
are
using
openshift.
B
B
A
B
Sure
so
now
I
have
all
the
three
components
running
and
the
error
that
you
sow
is
actually
an
important
one
and
I'll
be
just
discussing
it
when
we
are
done
with
the
with
the
department
generate
stuff.
So
as
you
see
here,
we
are
using
pods
in
here,
but
I
don't
have
yet
any
service
that
allows
me
to
access
my
containers
and
to
answer
the
firewall
question
that
we
had.
B
And
I'm
going
to
specify
the
port
that
I
want
to
expose,
which
is
80
50..
So
now,
if
we
go
back
to
openshift,
I
have
a
service
that
allows
me
to
access
my
container,
but
I
still
don't
have
the
route
to
do
that
and
we
do
provide
a
convenient
way
to
create
a
route
from
an
existing
service
with
openshift,
which
is
the
oc
exposed
svc
for
service
demo
web
and
now
it
tells
us
that
it
has
created
a
route
within
openshift
right.
So,
okay,
everything
everything,
looks
fine.
A
B
A
B
B
So
that's
the.
I
would
say
the
the
principle
that
we
follow
within
openshift.
You
have
your
dev
name
space,
your
q,
a
namespace,
your
pro
namespace.
You
built
your
image
once
and
for
all
within
the
openshift
environment,
and
then
you
promote
that
application
from
dev
to
qa,
meaning
that
you
don't
rebuild
the
application.
You
just
use
the
image
that
has
been
already
built
and
deploy
it
to
the
other
environment.
B
Yeah,
okay,
so
that's
I
would
say
getting
back
to
our
to
to
to
the
main
topic
of
today.
So
as
we
see
here
locally,
we
have
three
pods
that
have
been
generated.
Okay
and
now
we
want
to
generate
the
the
yaml
assets
for
that.
So
what
we're
going
to
do
is
actually
spot
man
generate,
and
if
we
look
at
it,
we
have
two
targets
that
we
can
use.
B
We
can
generate
system
d
containers
or
we
can
use
cube
assets
and
that's
the
latter
one
that
we
are
going
to
use
okay.
So
what
are
the
options?
It
says
you
can
generate
so
basically
palm
and
generate
cube
and
give
it
a
container
id
a
pod
id
a
volume
name,
for
instance,
or
a
service
if
you
wanted
to
expose
or
to
generate
the
service
for
your
asset.
B
So
let's
go
ahead
and
generate
the
cube
resources
for
demo
web
demo
web
and
we
are
going
to
generate
demo
web.jmo,
for
instance,
and
now,
if
we
look
at
it,
we
can
see
that
it
has
sorry
it
has.
You
know
the
timestamp
timestamp
shown
that
it
has
just
been
created
and
it's
a
kind.
It's
a
resource
of
type
of
port
type,
so
it
has
reference
the
image
that
we
used
to
deploy
the
container,
and
it
has
also
referenced
the
containers
that
we
need
to
expose.
B
B
It
references
the
mydb,
persistent
volume
claim
that
should
be
mounted
as
the
volume
that
is
used
by
the
container
image.
So
the
mighty
my
db
volume
should
be
mounted
at
var
leave
my
sequel,
okay.
But
in
this
definition
here
we
don't
have
the
yaml
resource
to
create
the
pvc,
because
if
you
look
at
what
we
have
generated
so
far,
we
have
the
front
end.
We
have
the
generator
and
we
have
the
database.
B
B
Okay,
so
is
a
red
hat
recommending
pubmen
over
docker,
I
would
say
yeah.
Definitely
we
have
made
the
shift
out
from
docker
as
they
run
time
a
long
time
ago,
and
the
community
in
kubernetes
is
also
using
cryo
as
the
default
runtime
for
kubernetes,
and
this
is
what
we
implement
in
openshift,
so
yeah.
I
think
that's,
basically
the
way
things
have
evolved.
I
would
say
upstream.
B
A
B
Yeah
and
there
are
actually
a
lot
of
advantages
of
using
podman,
which
is
basically
also
so,
for
example,
rootless,
builds
and,
and
such
concerns
were
huge
concerns
if
you
were
using
docker.
So,
for
instance,
you
want
to
build
your
applications
within
a
pipeline.
You
needed
to
expose
the
docker
socket
to
be
able
to
do
such
things,
and
that's
basically,
one
of
the
use
cases
for
which
we
built
pubman
and
builder,
and
those
those
very
special,
specific
or
use
case
focused
container
tools
so
yeah.
A
A
B
B
B
B
B
B
A
Week
so
to
make
to
clear
the
air
time
for
the
what's
new.
What's
next
podcast,
that
immediately
follows,
but
we
actually
have
a
question
in
the
chat
from
ravi
sharma
who's
saying:
would
it
be
possible
to
show
how
to
extract
the
whole
dev
environment,
yaml
files?
Would
this
include
svc
and
routes
as
well?
I
think
yeah.
B
What's
your
attention
we
are,
we
are
going
to
be
able
to
do
that,
but
just
before
that,
I'm
going
to
show
you
something
oc
new
app,
which
is
basically
the
openshift
command
line,
is
going
to
generate
all
the
resources
that
we
need
and
it's
going
to
actually
use
deployments
instead
of
pods.
So
basically,
this
will
give
us
the
behavior
that
we
were
looking
for.
B
B
Oh
okay,
I'll
see
get
parts;
okay,
let's
oc,
get
bot
demo
web,
all
jason
or
yaml.
Sorry,
because
that's
what
you
wanted
so
basically
I
have
the
running
assets
which
are
in
the
namespace
and
basically
I
can
just
do
that.
Like
oc,
get
the
the
resource
dash,
oh
yaml,
and
then
I
have
the
ammo
files
that
I
can
store
somewhere,
and
that
also
includes
like
the
routes.
B
B
A
Fantastic
all
right.
Well,
that
was
you
know
we
had
been
thinking.
This
might
actually
be
a
short
show,
but
in
fact
we're
sort
of
down
to
the
wire
here
with
with
all
this
information,
I
hope
everybody
found
it
useful
and
thank
you
for
your
your
questions
again.
I
would
encourage
everybody
to
like
subscribe
and
share
I'd,
also
mention.
A
So
do
take
a
look
at
that
link,
see
if
you
can
maybe
learn
a
bit
more
about
some
of
these
interesting
topics,
and
you
know
thank
you
jafar
for
a
very
a
very
interesting
discussion
and
demo
is
there?
Is
there
anything
else
you
wanted
us
to
kind
of
leave
people
with
before
we
got
the
heck
out
of
here
to
make
room
for
the
next.
The
next
live
stream.
B
B
Openshift
is
another
step,
and
the
more
I
would
say,
advanced
step
is
also
using
like
things
like
containerized
environments,
which
fully
run
remotely
like
code,
radio
workspaces
that
we
provide
with
openshift.
So
you
don't
have
to
to
to
care
at
all
about
having
things
running
on
your
laptop
anymore,.