►
Description
What happens when you have to upgrade container images in production? If you're new to container management, maintaining container image lifecycles may seem complex or intimidating, so let's dive into possible benefits and pitfalls you may come across when managing container images. We'll explore the Red Hat Ecosystem Catalog and Container Catalog and discuss how often to upgrade, automating upgrades, Certified Container Images, the Container Health Index and more.
Want to learn more?
https://www.redhat.com/en/blog/red-hat-ecosystem-microservice-and-container-development?sc_cid=7013a000002qG1GAAU
Try Red Hat OpenShift: https://red.ht/3uYcuhU
Follow us:
Randy Russell https://red.ht/rrr-linkedin
Scott McBrien https://twitter.com/stabby_mc
Jaafar Chraibi https://twitter.com/ChraibiJc
OpenShift https://twitter.com/openshift
Subscribe to Red Hat's YouTube channel: https://www.youtube.com/redhat/?sub_confirmation=1
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
Level Up Hour on GitHub 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.
OpenShift on redhat.com https://red.ht/3uXIbaQ
OpenShift on github https://github.com/openshift/
#RedHat #OpenShift #RHEL #tluh
A
C
Missed
you
guys
I've
not
been
able
to
participate
for
a
little
bit
here,
but
I'm
back
now-
and
I
am
very
excited
about
our
show
today
because
we
are
covering
you
know
that
reality
of
life
is
that
we
don't
do
things
once
we
don't
get
to
just
deploy
and
forget.
No,
no,
no!
No,
we
have
to
upgrade
container
images.
We
have
to
do
it
in
production,
and
so
you
know
if
you're
new
to
container
management,
maintaining
container
image
life
cycles
might
seem
a
little
bit
complicated.
C
C
Not
not
for
our
audience,
their
their
brave
souls
each
and
everyone,
but
we're
going
to
talk
today
a
little
bit
about
how
you,
man,
maintain
container
images
over
time,
we're
going
to
look
at
the
red
hat,
ecosystem,
catalog
and
container
catalog
and
just
talk
about
you,
know.
Upgrading
and
automating
upgrades
certified
container
images
and
something
called
the
container
health
index,
which
you
know.
C
You
know
the
past
two
years.
Anything
that
has
health
index
in
the
in
the
phrase
makes
me
very,
very
nervous,
but
I'm
sure
it
is
I'm
sure
it's
entirely
benign.
So
anyway,
audience
if
you
will,
if
you
have
any
questions
as
we're
going
along,
please
do
post
your
questions
in
chat
and
also
please
do
remember
to
like
subscribe
and
share
so
that
everybody
knows
we're
here
every
other
week
with
level
up
power.
So,
let's
get
to
it
scott,
where
first
thing
we
even
even
begin.
A
I
think
the
first
place
where
we
begin
is
like:
where
do
you
get
your
containers
right?
So
you
could
choose
to
build
them
yourself
and
that's
perfectly
viable,
and
then
you
have
your
own
ownership
of
prod
production,
product,
wow,
anymore,
coffee,
your
own
ownership
of
production
of
those
images,
and
you
can
set
pretty
much
whatever
you
want
for
your
maintenance,
cadence
and
processes
and
procedures.
A
A
A
A
So
we
can
actually
like
look
at
older
images
that
are
in
the
catalog,
not
just
the
most
current,
and
then
you
can
click
the
pull
button
or
use
the
url
and
pull
it
with
a
docker
url
all
right,
but
it
turns
out-
and
we
can
toggle
this
back
off
again.
So
it
turns
out
that
docker
hub
is
our
secondary
location.
A
A
A
We
have
been
working
with
microsoft
to
determine
what
it
would
take
to
get
into
wsl,
but
right
now
we're
in
very
early
stages
of
just
like
talking
about
it,
trying
to
figure
out
like
what
that
looks
like
for
us
and
how
we
support
it,
and
a
variety
of
other
topics
that
go
around
managing
base.
Containers.
A
So
if
you
are
accessing
the
universal
base,
image
or
ubi,
those
are
free
to
access
free
to
redistribute.
So
that's
why
we
have
them
over
on
docker,
hub
and
they're
free
to
access
free
to
redistribute
there
on
docker
hub
ubi
and
ubi
derivative
images
in
the
red
hat
container.
Catalog
are
free
to
access
free
to
redistribute.
A
However,
today
not
all
the
software
that
comes
with
rel
is
available
for
ubi.
So
today,
ubi
is
a
subset
of
rails
software
and
it
includes
a
lot
of
stuff
so,
for
example,
language
runtimes
like
node.js
or
openjdk,
but
it
does
not
include
other
things
like
postgres
for
that
you'd
have
to
package
and
install
your
own
postgres
in
it.
If
you
want
to
retain
that
that
redistributed,
but
redistributability.
A
Now
there
are
some
images
that
are
subscription
only
and
those
would
be
the
ones
that
fall
into
the
rel
catalog
of
images,
so
ubi
free
all
good,
do
what
you
want
rel
that
provides
all
the
package
set
for
rel
and
you
would
need
a
real
subscription
to
access
those
and
that's
actually
on
their
red
hat
catalog
page
too.
So
it's
very
clear
whether
you
need
one
or
you
don't
need
one.
When
you
try
to
we
try
to
access
it.
A
Yeah,
so
the
api
on
the
red
hat
catalog
is
supports
most,
if
not
all,
of
the
same
calls
as
the
docker
api.
So
you
could
literally
take
your
docker
hub
thing
that
you're
making
calls
to
docker
hub
with
and
just
swing
the
url
to
the
red
hat
catalog
and
generally
it
should
work
yeah.
I
used
a
lot
of
weasel
words
there,
but
there's
more
metadata
and
other
things
in
the
red
hat
catalog
of
how
we
track
images
and
image
health
and
some
other
stuff
that
would
not
be
included
in
docker
hub
metadata.
A
So
so
that's
something
that
may
be
differential
between
the
two
all
right,
all
right.
So
now
that
we
talked
about
where
to
go.
Maybe
we
like
just
delve
in
and
find
one
in
the
red
hat
container
registry,
and
we
talked
some
about
how
we
manage
those
all
right.
So
I'm
just
going
to
go
ahead
and
pull
up
ubi
based
images.
A
A
All
right
so
recall
when
we
looked
at
the
docker
catalog,
the
big
metric
that
was
shown
on
the
page
was
and
generally
when
somebody
is
looking
for
quality
of
image
in
docker
hub.
I
think
they
generally
look
at
pools,
so
the
more
pools
it
has,
the
more
popular
it
is,
the
more
popular
it
is
clearly
the
better
it
is
and
that
we
have
other
mechanics
embedded
in
the
red
hat
catalog
for
providing
more
depth
of
quality
there.
A
So
number
one
is.
We
also
include
when
the
container
image
was
generated.
We
also
have
the
health
index
and
I'll
come
back
to
this
in
a
second
as
well
as
size.
The
other
information
that
we
get
is
stuff
like
security,
so
this
goes
in
a
little
bit
more
detail
about
the
health
index
I'll
come
back
to
it,
a
little
bit
of
metadata
about
the
content.
A
We
also
provide
you
a
docker
file
so
like.
If
you
want
to
build
your
own
here's,
the
docker
file
you
can
download
and
it
will
using
a
build
from
docker
file
option.
Perhaps
it
will
make
the
satan
thing
and
then
under
get
this
image.
This
is
how
you
can
pull
it,
and
you
can
see
that
there's
instructions
for
using
oc
which
which
jafar
is
going
to
get
to
a
little
bit
later
in
the
episode
and
podman,
depending
on
whether
you're
doing
openshift,
stuff
or
rel
container
host
stuff.
A
And
then
you
can
also
use
docker
if
you're,
using
something
like
docker
desktop
or
the
docker
tools
on
your
system,
all
right
and
then
the
last
thing
we
provide
source
containers.
We
had
an
episode
where
we
talked
about
this
as
well.
So
we
tell
you
where
to
get
the
source
code
for
the
packages
that
we
shipped
with,
that.
C
Yeah,
that's
what
I
was
kind
of
getting
at
is
that
is
that
this
is
really
the
the
wonderful
thing
in
the
world
of
open
source.
As
you,
you
know,
as
you
were,
going
through
all
the
various
pieces
of
information
and
how
much
insight
there
is
into
what
you're
getting
that
is
about
transparency
there,
there
shouldn't
be
any
mysteries
in
there
right.
A
So,
in
a
previous
episode
episode
57,
we
talked
about
choosing
the
right
image
right,
so
there's
four
ubi
images,
minimal
micro,
which
is
even
smaller,
regular
and
init
or
multi-service
image,
and
we
talked
about
why
you
would
choose
one
over
the
other
in
that
episode.
So,
if
you're
interested
in
like
more
information
on
the
four
flavors
of
ubi
and
why
you
might
choose
one
over
another,
I
would
recommend
that
you
go
and
take
a
look
at
that
episode.
A
There's
also
other
images
that
we
have
here
in
the
catalog
that
include
the
language,
runtimes
and
I'll.
Show
you
one
of
those
in
just
a
second
but
those
others
that
include
language
runtimes
are
based
on
ubi,
so
I
promised
that
we'd
come
back
to
the
health
index,
so
I
know
I
know
the
health
index
is
basically
how
we
gauge
the
quality
of
this
image,
and
you
can
see
that
for
this
image
we
have
a
red
hat
bug
advisory
outstanding
for
this
image,
and
it
is
a
severity,
important
security,
vulnerability
based
on
this
advisory.
A
So
we
could
go
ahead
and
like
look
at
what
it
is
and
determine
what
we
want
to
do
about
it.
So
because
of
that
outstanding
cve,
this
container
has
a
health
index
of
b,
meaning
it's
not
the
best
right.
The
best
would
be
a
some
other
things
that
we
use
for
gauging
the
health
index
would
be
the
length
of,
or
I
should
say
that
the
differential
between
builds
and
uploads
so
the
longer
the
container
image
sits
in
the
catalog,
the
worse,
its
health
index
will
get
over
time.
A
So
I
expect
this
one
to
be
rebuilt
once
we
have
a
remediation
for
this
cbe
for
openssl
libs
and
then
we'll
upload
it
and
then
we'll
push
it
to
dockerhub.
So
we
rebuild
in
the
red
hat
catalog
first
and
then
pretty
much
every
day
or
actually
multiple
times
a
day.
We
push
updated
images
over
to
docker
hub.
A
All
right
and
to
give
you
an
example
of
what
a
really
ugly
one
looks
like.
Let's
look
at
like
this
super
old
one
from
eight
months
ago
right
and
so
this
one
has
a
one
important
and
two
moderate
cves
outstanding
for
it
because
of
its
age,
and
we
can
see
that
it's
a
health
index
of
c
right,
I
say
just
generally,
I
would
choose
a
container
image.
A
C
A
Absolutely
and
the
reason
that
they're
still
there
is
sometimes
people
will
build
their
life
cycle
stuff
to
pull
a
specific
tag
of
image
right.
So
if
they
used
this
tag,
which
is
the
version
information
when
they
did
a
pool
to
then
build
their
stuff
into
the
container
and
move
onward
away
with
this
tag
in
this
image
that
would
break
their
build
process
right
right,
it
would
be.
C
A
You'll
start
with
one
of
those
fresh
images
and
and
build
it
out
latest
and
greatest
yeah
and
then
plus
as
an
added
bonus.
You
know,
containers
are
a
very
persistent
entity
all
right,
so
just
because
you
pull
down
the
latest
and
you
build
your
stuff
into
it,
you
deploy
and
it
doesn't
work.
Well,
you
still
have
your
older
one
in
your
local
library
or
your
local
repositories.
A
A
To
account
for
when
you're
building
rebuild
processes
like
how
long
do
you
keep
an
image?
You
know
my
recommendation
would
not
be
to
just
like.
Oh
there's
the
latest,
pull
it
down,
rebuild
it,
throw
away
the
old
image
and
deploy
the
new
one
right.
You
want
to
have
that
kind
of
backup
ability
to
roll
back
right.
A
A
So
at
this
point
I
would
mention
that
we
also
did
a
level
up
our
episode
episode,
55
on
configuring,
auto
updates
of
containers
for
red
hat
enterprise
linux.
So
in
that
episode
we
talked
about
setting
up
some
systemd
configuration
so
that
periodically
your
machine
would
check
with
the
red
hat
container
registry
or
your
own
local
registry.
If
that's
how
you
configured
it
to
see
if
there's
a
newer
image
available
and
if
so,
it
would
pull
down
and
redeploy
your
container
images
based
off
of
that
change
in
state
and
jafar.
B
B
B
B
B
So
that
says
that
this
image
is
based
off
an
image
stream
tag,
so
a
tag
is
basically
an
image
stream
tag
is
basically
a
dynamic
tag
that
points
to
a
specific
image,
and
this
one
points
to
the
open
shift
image
that
is
nodejs14ubi8.
So
that's
what
scott
has
explained.
We
have
different
flavors
and
this
one
is
using
the
ubi8
version
and
node.js
runtime
14..
B
So
I
see
that
there's
a
tag
here
called
ubi8
that
points
basically
to
to
a
version
of
the
image
that
has
been
a
little
bit
outdated.
So
let's
have
a
look
at
the
image.
So
currently
it's
pointing
to
this
tag,
which
is
163-
and
I
see
here
on
the
catalog
that
there's
an
updated
image
and
then
they
they
recommend
to
move
to
that
to
that
container
to
that
image
tag
instead.
B
So
what
I
want
to
do
now
is
I'm
going
to
update
the
image
that
I
have
that
is
being
used
by
by
this
application,
and
I
want
to
see
what
happens
in
openshift.
I
do
that.
So
how
do
we
sync
our
openshift
images
with
the
ones
that
come
from
the
catalog?
It's
it's
very
simple.
What
I'm
going
to
do
is
I'm
going
to
actually
tag
the
current
image
stream,
that
is
in
the
openshift
namespace
and
point
it
to
the
layers,
tag
that
we
have
just
seen
here.
B
Okay,
so
basically
there's
the
open
shift
tag
command.
I
want
to
add
this
new
tag
to
my
openshift
image
and
that's
the
node.js
14
ubi
image
stream
that
is
used
by
my
application.
Okay,
so
I'm
updating
it
here
and
as
I
do
that
you
can
see
that
openshift
has
automatically
detected,
that
the
image
that
the
application
has
been
based
upon
has
been
updated,
and
now
it's
running
a
new
build
of
my
application
as
soon
sorry,
it's
yeah
our
I'm
looking
at
the
bin.
B
Now
it's
rebuilding
the
image
based
on
the
application
image
based
on
that
base
image
and
as
soon
as
it's
finished,
it's
going
to
redeploy
that
application
on
my
namespace.
So
the
reason
why
we've
been
able
to
do
that
is
the
build.
Config
has
been
configured
to
be
retriggered
if
there's
an
image
change.
So
basically,
we've
detected
that
we
updated
the
image
stream
that
this
application
was
based
on
and
because
we
allowed
that
behavior,
which
is
allow
to
the
build
to
be
triggered
on
an
image
change.
B
B
B
So
yeah.
Basically,
that's
what
I
wanted
to
show
you
and
those
are
the
main
concepts
that
we
wanted
to
cover.
If
I
wanted
to
frequently
update
those
images
that
are
in
openshift
from
the
catalog
there's,
a
dash
dash
scheduled
parameter
that
we
can
add
when
we
type
the
image
and
when
you
do
that,
so,
for
instance,
if
I
do
instead
of
just
oc
tag,
I
do
scheduled
it's
going
to
frequently
update
the
image
and
by
default
it's
a
15
minutes
time
frame
where
we
are
going
to
pull
those
remote
images
and
check.
A
B
B
So
it's
a
good
practice
to
update
those
images
to
the
latest
ones,
but
what
we
do
provide
with
the
image
stream
tags
is
that
you
don't
have
to
call
your
image
stream
latest
for
it
to
point
to
the
latest
image.
So
in
your
application
life
cycle,
a
good
practice
is
to
never
use
latest,
because
you
then
don't
actually
know
what's
in
your
application
anymore,
because
anyone
can
update
the
tag
latest
and
you
don't
have
any
more
a
versioning
of
your
application.
B
B
For
instance-
and
you
can
then
add
a
an
application
version
tag
that
says
version
101
or
something
like
that,
and
those
are
the
tags
that
are
going
to
be
used
by
your
ci
cd
process
to
basically
update
the
deployments
of
your
images,
because
that
way
you
have
more
control
over
the
history
of
your
deployments
and
you
can
trace
back
things
to
both
image
changes
and
to
code
changes.
If
you
go
back
to
commit
ids
and
such
things.
C
C
B
C
So
it's
kind
of
interesting
to
consider.
You
know
we
had
scott's
presentation
about
a
you
know,
a
very
non-open
shift,
non-kubernetes
approach
to
you
know
this
whole
topic
of
updating
and
everything,
and
then
we
added
the
open
shift
piece
and
there's
actually
an
area
of
intersection.
First
of
all,
that
I'd
say
is
that
you
know
if
you
have
a
particular
image,
that
image
is
tagged
and
has
a
lot
of
the
characteristics
as
viewed
through
openshift,
that
you
would,
if
you
were
doing
it
through
through
one
of
the
registries.
So
that's
that's
a
common
area.
C
It
seems
to
me-
and
I
want
you
to
correct
me
if
I'm
wrong
here
in
jafar,
it
seems
to
me
that
really
what
you
get
on
the
openshift
side
is
you
start
to
have
a
little
bit
more
of
that
life
cycle
capability
when
it
comes
to
ci
cd
and
how
you
are
actually
managing
this?
Not
nearly
from
just
the
the
perspective
of
okay.
C
Well,
here's
my
container
and
I'm
updating
it,
but
rather
through
the
whole
exercise
of
saying
okay,
I'm
I'm
going
to
do
that
and
I'm
going
to
rebuild
in
dev
and
I'm
going
to
rebuild
and
test
and
then
I'm
going
to
rebuild
in
stage
and
I'm
going
to
put
it
in
prod.
Would
that
be
a
fair
characterization
that
that's
really
the
piece
that
openshift
gives
you
incrementally
when
you
take
that
approach.
B
And
so,
for
example,
you
know
that
we
provide
the
red
hat
way
registry,
which
is,
I
would
say,
a
more
production
grade
and
high
availability
geo-replicated
registry
that
you
can
use
for
your
deployments,
but
as
a
as
an
upgrade
to
the
internal
registry
that
we
provide.
It
does
allow
you
to
have
integrated
security
scans
and
such
things,
and
you
can
configure
openshift
to
automatically
push
and
pull
data
from
a
remote
query
registry,
so
that
will
enhance
the
capabilities
with
the
even
better
security
scans
results
within
your
your
registry.
B
But
if
you
are
using
the
combined
value
of
openshift
with
the
quay
acs
and
the
cicd
pipelines,
you
can
have
a
more,
I
would
say
robust
and
devsecops
approach
where
things
are
automated,
where
you
have
gay
gates
to
prevent
security
issues
from
being
propagated
to
to
the
other
environment,
and
you
know
yeah.
So
that's
I
would
say
the
overall
value
that
you
can
get
from
that
right.
C
A
C
A
B
I
hadn't
run
that
demo
for
years
and
decided
to
come
back
and
pull
it
off.
And
while
I
tried
to
rebuild
the
application
that
was
pointing
to
latest,
it
tried
to
pull
like
the
version
six
of
dot
net
core,
which
is
not
called
net
core
anymore,
because
that's
what
the
latest
tag
in
openshift
was
updated
to
and,
of
course
it
broke
everything.
The
application
was
not
running
or
building
anymore,
because
there
was
such
a
huge
change
between
dotner
core
two
or
three,
which
I
was
using
and
the
sixth
version.
B
B
Right
well,
gentlemen.
Yes,
this
is
just
another
comment,
speaking
about
managing
the
images
life
cycle,
so
something
that
we
haven't
spoken
about
is
the
the
quay
integration
that
we
have
with
openshift,
and
so,
as
mentioned,
there's
a
bi-directional
configure
integration
where
openshift
quake
can
become
the
default
registry
for
for
openshift,
but
we
also
have
a
mirroring
capability
in
quay
that
allows
you
to
use
it,
for
example,
to
mirror
those
red
hat,
catalog
images.
C
B
It's
it's
not
a
static
reference
to
a
docker
or
a
container
image
for,
for
instance,
it's
a
dynamic
reference
that
you
can
use
and
the
image
stream
is
basically
just
a
collection
of
image
stream
tags
so
basically
say
for,
for
instance,
that
you
have
an
application
that
uses
three
components.
You
have
a
front
end
front
end
a
middleware
and
a
back
end.