►
From YouTube: The Operating System for Enterprise Edge Ben Breard (Red Hat) OpenShift Commons Gathering KubeCon NA
Description
The Operating System for Enterprise Edge
Ben Breard (Red Hat)
OpenShift Commons Gathering KubeCon NA
November 17, 2020
Red Hat Enterprise Linux 8.3 brings a number of exciting improvements and key among them is a new deployment option targeted at edge. In this session we'll take closer look at how RHEL is using Image Builder and rpm-ostree to help to simplify challenges with running remote systems.
466757 The Operating System
A
My
name
is
ben
brierd
on
the
product
management
team
here
at
red
hat,
I've
basically
spent
the
past
five
years.
Kind
of
operating
in
between
rel
and
openshift
kind
of
covering
all
of
our
immutable
operating
systems,
container,
run
times,
image
offerings
and
things
in
that
kind
of
that
world,
and
now
I'm
really
focused
on
on
edge
and
what
it
takes
to
be
successful
there
yeah,
so
I
just
hit
10
years
at
red
hat.
So
it's
it's
awesome.
I
have
the
greatest
job
in
the
world.
A
A
Okay,
so
what
is
edge
well
for
everyone's
education?
Oh
that's!
Terrible!
It's
yeah!
Anyway!
We'll
keep
we'll
keep
moving
here.
Basically,
we
now
have
the
situation
where
we
have
sources
of
data
all
over
the
place
and
there's
all
kinds
of
use
cases
to
capitalize
on
this
data
quicker,
faster,
more
efficiently
and
in
some
cases
we've
reached
the
limits
of
where
we
can
actually
ship
data
to
a
cloud
or
data
center
environment
to
process
this
and
so
putting
compute
closer
to
these
sources
of
data.
Sometimes
those
sources
could
be
humans.
A
Sometimes
it's
sensors.
It
can
be
all
types
of
use
cases,
but
that's
typically
the
combination
of
what
we're
talking
with
edge,
and
so
of
course,
you
guys
can
probably
imagine
all
of
the
things
that
we
take
for
granted
inside
of
the
data
center
or
cloud
environment
are
now
luxuries
from
an
infrastructure
side
that
may
or
may
not
exist
at
the
edge.
So
that's
that's
kind
of
a
key
thing
and,
and
one
another
point
I
would
make,
is
depending
on
what
industry
you're
in
edge
is
going
to
look
completely
different.
A
A
A
I
think
I
think
of
right
now
we're
kind
of
seeing
the
west
is
kind
of,
though
excuse
me,
the
edge
is
kind
of
like
the
wild
west.
In
a
lot
of
ways,
in
terms
of
just
what
hardware
is
available,
what
accelerators
are
being
used
if
any
oftentimes
there's
kind
of
a
existing
legacy
footprint
and
how
newer
systems
are
interacting
with
that
or
maybe
they're
interacting
with,
like,
like
hardware
systems
talking
to
plcs
on
a
manufacturing
line,
that
they
can't
stop
for
safety
protocols?
And
there's
it's
just
a
it's.
A
It's
a
lot
of
moving
pieces.
It's
going
to
continue
evolving
and
adapting
a
lot
over
the
next
few
years,
but
how
these
protocols
work
at
a
very
low
level,
sticking
with
the
manufacturing
cases,
there's
not
a
lot
of
commonality
between
the
vendors
and
types
of
communication
that
we
see
at
a
very
low
level.
So
it's
a
there's
a
it's!
It's
a
complicated
matrix
of
layers
of
technology
that
that
intersect
here
and,
of
course,
from
a
consistency
perspective.
A
You
know
basically
keeping
things
updated.
We
oftentimes
talk
about
the
convergence
of
operational
technology
with
it
networks
and
systems,
and
that
right
there
creates
sometimes
organizational
tension,
but
also
creates
huge
opportunity
for
us
to
solve
problems
and
really
work
with
customers
to
get
make
sure
that
you
know
we
can
meet.
Basically,
requirements
and
and
and
have
these
systems
kind
of
converge
over
time
all
right,
and
we
look
at
kind
of
an
application
lens
here.
A
A
You
know
close
to
sensors,
for
example,
or
you
know
doing
inferencing
on
say,
like
a
webcam
or
these
types
of
things,
you
know
we
basically
see
that
os
is
being
or
rel
specifically
being
a
great
fit
for
a
lot
of
these
use
cases
all
right.
So
I'm
going
to
put
this
in
context
and
we've
got
a
lot
of
cool
deployments
for
openshift
in
an
edge
context.
A
We
can
now
do
smaller
three
note
clusters.
The
remote
workers
landed
in
in
four
six
or
much
much
more
progress
has
been
made
there
and
then
the
single
node
work
is
is
coming
is
on
the
way,
but
today,
just
to
put
this
in
context
we're
talking
about
just
like
what
can
I
do
with
linux,
and
so
you
could
think
of
this.
I've
had
two
people
come
up
with
this
term.
We
know
we
have
k-8s
and
there's
kind
of
k3,
which
is
like
the
slim
down
kubernetes.
A
Type
of
initiative
could
be.
You
know
the
itot
convergence
is
another
huge,
huge
things
going
on,
or
really
people
just
trying
to
make
better
use
of
analytics
on
top
of
data
to
either
make
them
smarter
from
a
competitive
standpoint,
improve
customer
experience
or
really
just
increase
like
operational
efficiency.
All
of
these
are
kind
of
tend
to
be
the
bigger
trends
that
people
are
going
after.
I
talked
a
little
bit
about
the
verticals
already,
so
I'm
not
going
to
rehash
that.
But
what
can
you
do
with
kind
of
a
standalone
os
at
this
point?
A
That's
a
that's
a
really
really
common
use
case
here
that
we
can
solve
really
well,
particularly
on
smaller
footprint
devices.
These
are
just
edge
servers
or
a
gateway
to
where
we're
really
just
passing
packets.
Back
and
forth.
I've
talked
a
little
bit
about
computer
vision
a
second
ago
where
we're
doing
inferencing
on
like
a
feed
of
what's
coming
into
the
system
and
trying
to
identify,
what's
happening
on
it
and
make
decisions
from
that.
You
know
kiosks
are
still
a
huge
thing,
particularly
for
like
a
like
in
the
in
the
transportation
space.
A
That's
that's
still.
We
see
huge
investment
happening
there
and
then,
of
course,
we
see
the
classic
kind
of
iot
use
case
rolling
up
under
under
edge
as
well
all
right
so
with
rel
in
the
next
update,
which
will
be
8.3.
We
are
on
the
time
based
model
now,
so
the
november
release
we
kind
of
have
these
four
things
landing,
which
represents.
A
You
know
our
first
step
in
the
journey
of
kind
of
adapting
rel
for
edge.
We're
not
finished
with
this
release.
This
again.
This
represents
kind
of
that
first
step
for
us
and
effectively.
What
we
have
is
this,
this
tool
called
image
builder
and
we'll
we'll
go
over
this
in
more
detail.
But
basically
we
can
generate
these
pretty
pretty
small
footprint
operating
system
images.
A
I
mentioned
earlier
that
there's
pretty
sizable
legacy
footprint
in
a
lot
of
these
edge
use
cases,
and
I
wanna
you
know
basically
there's
no
technical
reason
why
we
can't
just
drop
in
containers
next
to
traditional
damage
running
on
a
linux
system.
It
works
great
now,
depending
if
you
need
to
orchestrate
and
do
fancy
things
with
those
containers.
A
You
know
you
will
probably
hit
the
limits
of
that
pretty
quick
and
that's
obviously
where
kubernetes
adds
a
massive
amount
of
value,
but
if
this
is
more
of
a
static
workload
type
case,
this
is
pretty
simple
to
do
and
works
really
really
well
again.
One
of
the
things
I
do
want
to
point
out
is
that
in
rel
eight
we
make
it
easy
for
just
regular
daemons
running
on
the
system
to
really
present
the
same
kernel
primitives
that
give
you
container
isolation
to
services
installed
on
your
system.
A
Okay,
so
we
are
from
a
container
runtime
perspective.
We
are
talking
more
about
the
podman
side
of
the
house
right
now.
Hopefully,
everybody
here
is
kind
of
familiar
with
the
differences
of
cryo,
which
is
meant
to
talk
to
the
kubernetes,
cri
and
podman,
which
uses
basically
all
the
same
same
underlying
components,
but
it's
kind
of
standalone
in
terms
of
it
has
a
cli.
A
A
A
Basically,
we
can
have
timers
on
these
nodes
and
now
check
that
tag
at
whatever
interval
is
appropriate
and
just
kind
of
auto
pull
that
image
and
update
as
new
ones
are
made
available
on
the
registry.
So
again,
little
features
like
that
make
life
super
simple
and
again
easy
to
scale,
because
these
are
all
client
initiated
actions.
A
A
This
is
made
available
via
the
cockpit
ui,
there's
also
a
cli
and
an
api
for
this,
but
really
log
in
and
you
know,
approximately
four
clicks:
you're
gonna
get
the
default
image.
If
you
need
to
customize
it
with
rpm
content,
you
can
here
I'm
going
to
include
c
run,
as
I
really
enjoy
see
run
because
I
like
using
secrets,
v2
super
fast,
instantiate
containers
as
well,
but
here's
we'll
just
we'll
go
ahead
and
we'll
commit
this
to
the
blueprint
again.
You
don't
have
to
do
this
by
default.
A
But
you
see
I
just
select
the
image
content
rel
for
edge
commit,
and
this
is
going
to
generate
an
rpm
os3
commit
that
we
can
then
serve
out
from
the
central
place
and
just
again
this
is
going
to
give
us
that
remote
update
capability
and
that's
it
it's
going
to
kick
off
the
build
right
here.
We
can
see
this
going.
A
It
happens
pretty
quick
on
my
junky
laptop.
This
will
complete
in
I
don't
know.
Seven
eight
minutes
if
you're
running
on
good
hardware
expect
faster
results
all
right.
So
let's
talk
about
the
mirroring
and
providing
these
updates.
So
again
we
create
the
initial
image.
The
way
you
saw
we
are
going
to
create
updates
for
these
images
using
that
same
process.
A
A
Node
0
is
finished
here
and
this
compose
image
is
really
just
going
to
download
it
and
give
me
an
artifact
that
I
can
work
with
here,
and
this
happens
super
fast
since
it's
local,
but
I
now
have
this
tar
file
with
that
commit
of
the
rpmos
tree
locally,
and
now
I'm
going
to
build
a
web-based
server
to
host
my
commit
so
I'll
spit
out
the
file.
Here
you
can
see
it's
super
simple
I'll.
Just
give
me
apache
extract
this
tarball
that
I
made
an
image
builder
and
then
go
ahead
and
serve
that.
A
A
But
this
is
a
good
proof.
Point
that
you
can.
You
can
host
these
any
number
of
ways
you
want
and
then
once
that's
going,
I'm
just
going
to
I'm
just
going
to
curl
the
latest
ref
of
the
commit,
if
you
guys
have
used
rpms3
or
looked
at
it,
you'll
know
that
it
it's
kind
of
modeled
after
git,
so
a
lot
of
those
same
same
ideas
and
concepts
that
you
probably
are
familiar
with
from
git
rpmo
street,
basically
leverages
those
all
right.
A
So
once
you
have
made
an
image
from
image
builder,
that
is
a
good
way.
You
can
easily
serve
that
up
and
let's
talk
about
the
updates
themselves
so
day,
one
is
pretty
simple
updates,
though
a
lot
of
edge
environments,
some
of
them
have
like
amazing
data
center
style
networks,
which
is
super
fast,
and
you
know,
efficiency
at
this
tier
is
not.
A
You
know
it's
a
nice
to
have,
but
it's
maybe
not
a
requirement,
but
in
some
environments
we
have
just
horrible
connectivity
like
like
microwave
links,
that
make
make
modems
look
really
or
old,
dial-up.
Modems
look
really
fast.
You
know,
retail,
we
still
see
like
fractional
t-ones
and
these
types
of
things,
and
so
what's
cool
is
even
if
you
have
constrained
networking.
A
But
even
if
you
have
really
really
great
connectivity
and
bandwidth
isn't
like
near
a
scarce
resource,
you
still
probably
want
to
be
using
that
for
your
applications
of
workloads,
not
you
know
os
updates
and
these
types
of
things
so
having
that
efficiency
really
helps
regardless
of
what
type
of
infrastructure
you
have
and
again.
This
is
just
a
great
side
effect
of
of
using
rpmos
tree
natively
for
all
this
stuff
now
provisioning.
Here,
if
you're
familiar
with
our
cost,
you
may
be
wondering
why
is
this
not
ignition?
A
A
If
you
point
it
to
your
production
mirror
once
you
deploy
the
system,
it's
going
to
know
where
to
look
for
updates
automatically.
So
that's
probably
a
good
thing
to
do.
If
you
can
and
that's
all
you
need
to
do,
you
can
do
any
customization
stuff
and
percent
post
if
needed.
Pre
is
still
there,
but
kind
of
a
good
rule
is
to
keep
these
as
simple
as
possible.
A
Okay,
and
so
that's
how
we
can
easily
just
get
the
commit
on
to
your
devices
and
now
a
little
bit
about
rpm
h3.
It's
just
really
gives
us
this
great
kind
of
a
the
kind
of
the
best
of
both
worlds.
If
you
think
of
a
traditional
like,
like
embedded
type
firmware,
you
know
like
your
your
router
that
may
have
a
an
amb
partition
on
it,
so
we
kind
of
blend
that
av
update
model
with
like
the
benefits
of
a
package-based
distribution.
A
A
So
again
we
get
the
benefits
of
this
av
model
where
we
can
fail
back,
if
necessary,
as
well
as
kind
of
that
flexibility
with
the
packages,
which
is
great
so
really
everything
of
the
operating
system
that
lands
under
slash
user
gets
swapped
out
with
the
or
at
least
at
least
in
each
commit
there's
a
the
full
os
in
there
right
and
then,
once
you
pull
that
into
your
repo
and
clone
it
locally
again.
We're
only
going
to
send
the
delta,
but
you
get.
A
A
So
you,
the
whole
operating
system,
is
not
technically
immutable
like
from
the
strictest
definition
possible
and
that's
not
a
bad
thing,
because
true
immutability
often
requires
a
significant
amount
of
infrastructure
to
be
available,
and
that's
not
something
that
we
we
can
count
on
in
these
environments.
So
again
maintaining
your
configs
and
container
images,
and
these
types
of
things
is
generally
a
really
healthy
and
convenient
thing
to
do
so.
That's
it
and
we
always
get
this
known
state
that
we're
operating
in
on
the
system,
which
is
powerful.
A
So
I
mentioned
earlier
that
we
can
automatically
stage
these
updates
in
the
background,
and
so
that's
that's
a
great
way
to
approach
it.
That's
probably
what
I
would
do,
but
it
depends
on
your
environment
on
what
you
should
do
and
then,
whenever
an
update
is
staged,
typically,
you
may
want
to
align
to
a
maintenance
window
again.
A
lot
of
these
systems
are
responsible
for
like
critical
infrastructure.
A
You
can't
just
can't
just
accept
reboots,
you
know
like
free
form
like
we
would
expect
in
a
cloud
environment,
and
so
it's
pretty
easy
to
schedule.
Reboots
with
a
timer
or
there's
a
number
of
ways.
You
can
use
any
type
of
a
management
system,
but
once
you
have
a
scheduled
reboot
when
they
come
back
up,
they'll
be
at
the
next
update
automatically.
A
A
This
is
a
really
good
model.
Okay,
so
the
last
little
screenshot,
just
to
kind
of
give
you
guys
a
look
if
you
haven't
played
with
rpms3
on
a
system
before
I'm
going
to
ssh
into
this
is
a
bare
metal
system,
I'm
running
and
again,
I'm
using
the
web
console
terminal
to
do
this.
I'm
running
a
container.
That's
just
sucking
the
four
cores
of
this
little
box
dry
and
I
check
the
status
I'm
running
a
single
commit.
So
this
box
has
just
been
provisioned
from
from
image
builder.
A
It's
still
going
now,
I'm
forcing
a
reboot
just
to
just
to
move
into
this
really
quickly.
You
can
see
how
I
got
impatient
and
tried
to
ssh
before
the
system
came
back
and
I
checked
the
container
runtime
and,
of
course
my
application
is
running
as
expected,
because
it
is
being
managed
by
systemd,
and
we
can
see
here.
The
asterisk
has
moved
up
and
I'm
in
my
new
update
now
again
this
this.
This
model
is
familiar.
A
A
A
I
can
basically
write
scripts
and
green
boot
gives
us
this
framework
to
run
those
scripts
that
integrates
with
the
boot
process
of
the
system
and
if
they
fail
using
a
counter
system.
So
it's
not
strictly
like
well,
it's
it's
as
flexible
as
you
need
it
to
be.
If,
if
an
update
causes,
you
know
one
of
the
critical
roles
of
that
node
to
fail,
we
can
revert
the
state
of
the
system
and
go
back
to
where
it
was
working
right.
A
So
super
super
powerful
here
and
yeah.
We're
basically
really
excited
to
have
that.
Have
that
linkage
again
between
the
workloads
and
and
the
operating
system
update
level
one
of
the
customers
we
worked
on
on
this
capability
really
closely
with
you
know.
Their
feedback
to
us
is
basically
the
combination
of
rpmos
stream.
Green
boot
is
going
to
save
us
millions
of
dollars
with
our
deployments
once
these
systems
get
provisioned
at
the
edge.
A
The
goal
is
to
not
go
back
and
revisit
them
physically,
and
so
you
can
imagine
how
having
having
this
type
of
safety
mechanism
in
place
is
a
big
deal
for
a
lot
of
people
and
moving
into
this
space,
all
right.
So
with
that,
basically,
you
know
again.
I
mentioned
8-3
as
kind
of
the
first
step
in
our
journey
of
kind
of
meeting
the
challenges
of
the
space.
A
We
do
see
the
security
story
of
rel
being
a
huge
value
to
edge
deployments,
in
fact
that
challenges
we
talked
about
earlier.
In
this
talk,
I
would
say
all
of
those
challenges,
kind
of
kind
of
live
on
top
of
the
security
concern
right
because
again
in
the
data
center,
things
tend
to
be
physically
protected.
A
A
This
is
a
super
simple
way
to
just
to
just
go
meet
that
need
and
be
successful,
and
then,
of
course,
why
not
do
that
by
leveraging
kind
of
the
existing
investments
and
people,
skills
and
technologies
right
that
people
know
and
love
from
red
hat?
So
that's
a
that's
a
key
value
prop
in
everything
here,
and
so
at
this
point
I
guess
everybody's
probably
going
crazy
thinking.
Oh
my
gosh.
A
I've
got
to
get
my
hands
on
this
and
try
it
to
go:
go
conquer
conquer
edge
in
my
my
environment,
and
so
one
you've
come
to
the
right
conclusion
and
two:
it's
super
easy
to
go.
Do
this
and
get
your
hands
on
it.
If
you
go
to
the
os
build
github
repo,
we
really
have
kind
of
this
whole
thing
documented
out
here
and
you
can
walk
through
it.
It's
super
simple!
You
can
just
do
it
in
a
couple
of
vms,
if
you
like.