►
Description
In this briefing, Red Hat’s Mark LaMourine outlines the characteristics that define a “container host”, an OS tuned to run software in containers. Explore the benefits and peculiarities of a stripped down, light weight minimal OS image and the implications for CM and update strategies.
lnstall and setup your own Project Atomic environment and follow along as he demonstrates how a container host differs in operation from a conventional package based host.You will learn how to boot and integrate container hosts into your existing infrastructure. He will demonstrate how to install and use traditional host tools from containers and how to manage, update and customize container hosts.
Finally he will look at how a sysadmin’s day to day tasks and operations will differ when running infrastructure services and providing application runtime environments for developers and users on container hosts. We will establish base network services (DNS, NTP, Authentication) on container hosts as well as installing and demonstrating utility containers to provide standard admin tools that are stripped from light-weight hosts.
This briefing is aimed at Sysadmins and service designers interested in learning to use container hosts to reduce host management. Attendees will understand the goals and basic design requirements for container hosts. They will get an overview of the design of both CoreOS and Atomic host, highlighting the differences in architecture and how these inform the choice of container host for an installation.
A
A
Well,
hello,
everybody
and
welcome
again
to
another
OpenShift
Commons,
this
time,
we're
going
to
talk
about
one
of
the
building
blocks
of
containers
and
all
this
wonderful
cloud
native
stuff
on
my
guest
today
is
mark
la
marine,
a
good
friend
of
mine
and
a
longtime
red
Hatter,
and
he's
going
to
really
go
through
the
underpinnings
of
everything
and
give
us
an
inter
introduction
to
container
hosts
the
mark.
Take
it
away.
B
This
is
actually
a
condensed
version
of
a
presentation
I
gave
at
Lisa
conference
about
a
week
ago,
and
that
was
a
three
hour
tutorial,
so
I
think
for
half
an
hour.
We
can
just
cover
the
pieces,
but
this
talk
contains
references
to
the
original
material
I
had
for
that
for
that
tutorial
as
well,
and
if
people
have
questions
or
if
people
want
to
follow
up,
there
are
links
and
references
here
to
the
to
that
material.
B
B
I
want
to
go
back
to
kind
of
the
beginning
again.
I'm
talking
about
container
hosts
and
I'll
need
to
talk
about
what
a
container
host
is,
but
first
I
want
to
kind
of
revisit
what
our
our
conventional
view
of
the
Linux
hoster
of
a
server
is,
and
the
fact
that
it
it
is
the
way
it
is
because
of
history.
It
was
built
up
over
time
to
serve
our
needs
and,
if
you're
old,
like
me,
you
remember
things
like
recompiling,
your
your
kernel,
so
that
you
could
add
a
tape
drive.
B
You
can
remember
going
and
getting
your
compiler
on
on
tape
and
building
it
three
times
to
produce
with
itself
to
verify
that
it
still
works.
When
we
first
started
with
these,
we
didn't
have
packages
we
didn't
have.
We
were
still
learning,
we
were.
We
were
learning
from
the
very
beginning
and
we
were
doing
things
like
putting
our
software
and
user
local
because
we
didn't
have
any
way
to
keep
it
separate.
B
We
had
kind
of
standard
ways
of
building
software,
we'd
grab
a
tarball
from
somewhere
and
there
would
be
a
file
or
a
script
in
there
called
configure
it
with
one
configure
make
make
install
I
remember
a
time
when
I
thought
shared
libraries
were
evil
because
I
was
used
to
old
systems.
Windows
95
and
98
that
had
Windows
dll's
and
the
biggest
complaint
Microsoft
had
for
service
was
people
who
were
editing
the
configuration
files
and
messing
with
the
DLL,
and
they
literally
created
the
registry
to
counter
that
so
I'm
coming
from
the
the
old
days.
B
B
B
Now
these
layers
impose
a
Serie
of
dependencies.
Each
layer
depends
on
the
layer
beneath
it
to
do
its
job,
and
each
layer
from
the
bottom
up
provides
an
interface
that
has
to
be
stable
so
that
the
next
layer
up
can
trust
it.
If
we
start
at
the
bottom,
the
operating
system
is
managed
by
an
ops
team.
They
install
the
kernel,
they
install
the
operating
environment,
it's
generally
managed
by
package
management,
or
most
of
us
are
going
to
be
familiar
with
you
more
apt,
and
these
are
the
layers
that
are
fairly
static.
B
B
At
the
top
layer
we
have
our
applications
developers.
These
are
people
who
they're
moving
fairly
quickly
relatively
quickly.
They
want
to
do
things
with.
They
want
to
use
the
most
up-to-date
software.
They
want
to
use
the
most
up-to-date
libraries
they're,
constantly
changing
the
their
business
logic
and
their
business
data
to
meet
new
demands,
and
they
have
a
very
dynamic
update
schedule.
These
people
are
really
moving
quickly
and
they
they
appreciates
the
stability
from
below,
but
there
are
times
when
there
are
issues
now
in
the
middle
layer.
This
is
where
things
get
kind
of
interesting.
B
In
the
ideal
situation,
this
is
controlled
by
the
ops
team
and
they
they
maintain
it
in
the
same
way
that
they
maintain
their
other
layers,
because
these
are
the
pieces
that
the
apps
people
use
there.
If
they
are
moved
too
quickly,
the
apps,
the
apps
layers
can
break
and
the
apps
people
will
be
upset
and
on
the
other
hand,
if
they,
if
they
contain
security,
flaws
or
something
like
that,
then
the
operating
system
people
will
get
blamed
for
it,
and
so
they
want
to
do
the
updates
in
lockstep,
with
with
security
updates.
B
But
these
two
things
caused
some
conflict.
This
is
more
the
reality
of
what
you
see
in
that
middle
layer.
You
see
the
ops
people
who
control
some
app
libraries
and
then
you're
gonna
find
the
the
apps
people
say:
I
can't
wait
for
whatever
it
is.
I
need
the
next
version
of
my
Ruby
library,
and
so
they
start
taking
responsibility
for
those
things,
but
they
also
and
they
take
control
and
you
get
kind
of
a
mixed
bag
in
this
layer
of
pieces
that
are
run
in
system
space
and
pieces
that
are
maintained
in
user
space.
B
It
means
that
you've
got
new
software
management
systems
because
the
apps
people
at
the
top
are
maintaining
their
code.
The
operating
system,
people
at
the
bottom,
are
maintaining
their
code
a
different
way
and
then
there's
a
conflict
in
the
middle
over
who
owns
those
middle
pieces
and
who's
responsible
for
keeping
them
up
to
date
and
keeping
them
secure
and
stable.
B
So
to
come
back
the
things
that
characterize
our
traditional
hosts
are
a
fairly
tight
coupling
between
the
OS
and
the
app.
You
know,
and
you
ask
some
questions.
You
know
the
ops
team
owns
the
binaries
and
libraries,
but
why
does
the
ops
team
care
which
version
of
Apache
or
which
version
of
Ruby
the
developers
are
using?
B
which
can
be
in
conflict
with
the
system
once
and
then,
when
something
goes
wrong,
it
becomes
difficult
to
say
you
know
who's
responsible
for
that
for
the
layer
that
you're
working
with
one
of
the
things
about
scripting
libraries
in
userspace
is
that
it
actually
kind
of
discourages
interface
stability.
The
users
are
able
to
make
updates
whenever
they
want,
and
then
the
developers
of
those
libraries
also
seem
to
be
less
concerned
about
interface
stability.
They
just
keep
adding
new
features
because
they're
using
the
same
mindset.
B
There's
software
collections,
which
are
something
that
are
provided
as
packages
which
allow
you
to
run
different
environments
of,
say,
Ruby
or
rails,
or
various
other
tools
where
the
ops
people
can
install
a
set
of
packages
for
a
specific
version,
and
then
the
users
can
can
enter
an
environment
for
the
appropriate
version.
But
this
is
really
just
putting
off
the
problem.
It's
it's
actually
doing
kind
of
a
combinatorial
explosion.
B
In
the
case
of
the
where
you
just
install
everything,
one
of
the
things
about
about
current
hose
is
that
we
just
generally
install
everything
in
system
space,
because
some
user
is
going
to
need
it.
If
you
look
at
the
system,
libraries
for
something
like
Python
or
Perl
or
Ruby
you're,
going
to
find
that
there
are
lots
and
lots
of
libraries
there
that
that
the
two
or
three
applications
running
on
a
typical
host,
probably
never
use,
and
so
they
never
need
to
be
there.
B
Only
a
small
piece
of
the
ops
team
will
roll
forward
their
operating
system,
and
then,
why
tweak
to
see
if
they're,
if
their
services
break
and
then,
when
the
worst
Attis
fine
with
that
for
a
week
or
so
we'll
roll
it
forward
to
a
slightly
larger
dev
space,
where
those
people
can
do
their
work.
And
then
the
final
thing
we'll
do
is
roll
it
all
out
to
to
our
production
environments.
B
So
one
potential
solution
for
this
is
something
that
we're
calling
container
hosts
and
I'm
using
this
as
a
broad
term
I'm
going
to
cover
two
of
the
varieties
of
container
house
right
now,
which
are
both
popular
and
well-maintained
and
I'm.
Familiar
with
them,
there
are
others
that
I'm
less
familiar
with
and
I
can't
speak
to
them.
B
Just
for
background,
the
there's,
a
history
of
trying
to
create
some
hosts
that
have
different
characteristics
from
the
container
from
the
traditional
hosts.
The
earliest
ones,
were
embedded
systems,
pea,
sauce,
Wind
River,
and
there
was
a
third
one
whose
name
I
can't
remember.
The
idea
of
these
was
that
you
would
have
a
very
small
operating
system
that
would
run
in
some
kind
of
very
limited
hardware
and
you'd,
build
your
application
tightly
bound
to
that
environment
and
then
any
on
to
us,
and
it
would
run
or
even.
B
A
generic
one
is
busybox,
which
is
it's
kind
of
a
solo
binary
that
has
everything
built
in
Android
by
Google
is
specifically
designed
for
phone
operating
systems,
so
it's
not
quite
as
reliable
as
aircraft,
but
it
is
a
tightly
controlled
environment
because
they
have
security
concerns
and
to
some
degree,
stability
is
concerned.
Chrome
OS
is
a
third
one.
It's
designed
specifically
to
run
Linux
for
running
a
browser
very
lightweight
hardware.
B
Those
are
the
precursors
to
what
I'm
calling
a
container
host.
None
of
those
are
fairly
difficult
to
program,
for
they
require
rebuilds
to
add
applications.
They
tend
to
be
completely
read-only
with
very
small
limitations.
The
first.
What
I'm
calling
a
container
host
is,
is
content,
container,
Linux
or
core
OS
is
only
about
three
years
old
or
four
years
old.
It
was
introduced
in
October,
2013
project
atomic
came
along
about
six
months
later.
The
project
atomic
is
a
an
additional.
B
It's
a
different
way
of
approaching
this
problem.
Rancher
OS
was
also
in
2014.
I
can't
speak
much.
Tarantulas
I
haven't
used
it
much,
but
it's
from
what
I
understand.
In
the
same
kind
of
class
of
things,
the
character
is
container.
How
must
have
some
specific
characteristics
and
I'm
looking
at
bullets
here,
so
I'm
just
going
to
run
down
them,
but
the
important
things
are
that
it's
minimal.
You
can
do
atomic
for
roll
forward
and
reliable
roll
back.
They
do
have
writable
space,
but
it's
not
the
slash
user
space.
B
That's
actually
read-only
on
most
container
hosts
they're
meant
to
have
come
in
Amol
configuration
because
they're
not
actually
designed
to
have
users
login.
Unlike
previous
services,
you
do
have
a
login,
but
it's
not
meant
to
have
particular
users
that
the
users
should
access
it
through
other
means,
they're
just
logging
on
and
getting
a
shell
they're
designed
to
be
clustered
whether
this
means
an
integrated
class
string
mechanism
or
some
there's
some
built-in
way
of
forming
clusters
and
sharing
resources.
B
They
have
an
integrated
software-defined
network
so
that
those
resources
can
communicate
with
each
other
within
the
cluster
without
exposing
their
traffic
to
the
outside,
and
one
of
the
key
features
is
that
they
actually
have
an
integrated
container,
runtime
and
they're
intended
to
run
containers
at
scale.
Now
the
individual
hosts
are
still
individual
hosts,
but
using
the
clustering
and
networking
you
can
build
applications
out
of
individual
containers,
we'll
talk
about
what
the
what
it
means,
what
a
container
runtime
means
in
a
minute.
B
The
two
I'm
talking
about
have
very
different
architectures,
even
though
they
have
similar
similar
goals.
Container
Linux
core
OS
is
based
on
Chrome
OS.
It's
designed
to
be
embedded
or
frozen
in
the
system.
It
builds
from
source
every
time,
so
you
get
a
clean
build,
but
it
means
you
have
to
build
from
source
every
time.
I'll
show
how
this
works
in
a
minute,
but
it
does
the
updates
by
having
a
read-only
user
partition
and
then
overwriting
the
the
new
version
and
swapping
to
it.
B
B
And
what
that
means
is
that
you,
it
does
require
a
reboot
to
update,
so
you've
got
to
have
applications
that
can
tolerate
that,
hopefully,
that
are
spread
out
over
many
systems
so
that
you
can
reboot
a
single
instance,
but
it
also
means
that
you
can
reboot
directly
back
to
the
previous
working
version.
If
there's
a
problem,
the
tools
that
Korres
uses
or
something
called
update,
engine
and
locksmith
thee,
what
update
engine
does
is
it
checks
for
updates,
pulls
them
down
and
initiates
a
reboot,
and
what
locksmith
D
does?
Is
it?
B
It
forms
a
cluster
and
it
locks.
It
grabs
a
mute
mutual
exclusion
lock
when
it
goes
to
do
an
update
so
that
you
don't
get
a
a
wave
or
you
don't
get
a
lot
of
simultaneous
reboots
you
get
in
the
role
system
fail
in
anyway,
after
the
reboot
it's
fairly
trivial
to
boot,
back
to
the
old
version.
The
atomic
host
is
the
second
one
and
the
one
I
know
most
about,
and
it
turns
out
the
one
that
has
the
most
tools
in
the
area
I'm
talking
about
for
participants
to
manage
them.
B
The
atomic
host
is
based
on
rpms
it.
It
uses
a
thing
called
rpm
OS
tree,
which
is
it's
a
more
complex
management
system
than
then
core
OS,
swapping
images,
but
it
provides
some
some
very
valuable
controls
that
a
simpler
mechanism
doesn't
that
was
tree
is
integrated
right
at
the
bootloader.
So
when
you,
the
grub
to
bootloader,
can
recognize
that
it's
booting
an
OS
tree
and
and
manages
that
properly,
that
the
code
is
up
streamed
and
maintained.
B
So
this
isn't
something
you
have
to
worry
about
a
custom
grub
to,
instead
of
merely
mounting
slash
user
back
and
forth.
Is
this
a
more
complex
set
of
layerings?
It
uses
LVM
you
dev
and
mapper,
to
provide
all
the
maps
effectively
hiding
the
complexity
from
the
from
the
users
and
the
operators.
The
swapping
patterns
are
well
known,
though,
so
that,
while
those
things
are
hidden,
they're
not
really
magic,
they're,
they're,
very
well
known
techniques
that
are
used
in
other
places
as
well.
B
B
If
you
look
at
the
the
bin
bash
from
both
sides,
you'll
see
that
they
link
to
the
same
hashed
object,
and
so,
when
those
two
versions
use
the
same
object,
they
actually
use
the
same
object
and
there's
only
one
copy
there
and
again
for
the
directory.
If
you
look
at
the
hash
to
the
third
element,
as
long
as
both
are
using
the
same
thing,
there's
only
one
actual
copy
of
the
target.
B
In
the
case,
if
you
look
at
the
second
line
at
both
the
user,
0
and
user
1,
you
can
see
that
the
hashes
are
different.
In
that
case,
each
one
uses
its
own
version
of
VI,
and
so
there
are
two
copies
of
it
and
each
one
is
linked
correctly
to
it.
And
if
you
look
at
the
last
line,
what
you
see
is
that
when
you
do
an
update
and
a
specific
hash
is
no
longer
referenced.
Neither
version
of
the
neither
bootable
version
references
that
file.
B
B
B
It's
also.
Currently,
the
clustering
used
by
OpenShift
and
by
various
other
container
clustering
systems
is
called
Etsy
D.
It's
it's
a
key
value,
store
kind
of
like
LDAP
and
kind
of
like
something
like
a
sleepy
cat
bsd,
but
it's
networked
and
it's
clustered
and
it
doesn't
use.
Unlike
other
databases,
it
has
a
fairly
high
latency
see
you
can't
easily
use
it
in
the
same
way
that
you
would
for
for
messaging,
although
some
of
that
is
done,
but
the
goal
really
is
fast
reads
and
and
good
consistency.
B
The
sed
itself
is
just
a
database,
it's
just
a
cluster
database
and
it's
actually
the
thing
that
forms
the
clusters
in
any
of
these.
When
you
see
an
open
shift
cluster
or
if
you
see
a
kubernetes
cluster,
there
really
isn't
a
kubernetes
cluster,
there's
really
an
EDD
cluster
that
kubernetes
or
open
shift
are
using
for
their
database
and
that's
what
forms
their
actual
cluster.
The
second
piece
is
the
software-defined
network.
B
There's
a
couple
of
those
I
detailed
flannel,
which
is
an
older,
simpler
flat
networking
system
that
core
OS
is
created
when
they
were
just
getting
started
more
recently,
people
have
switched
to
to
using
calico
or
one
of
the
other
slightly
more
modern
software-defined
networks,
containerized
software-defined
networks,
the
big
benefit
for
something
like
calico
is,
is
isolation.
You
can
build
dynamically
isolated
networks
where
flannel
is
a
big
flat
network
space.
I
walk
down
some
of
this
for
ED
CD,
so
I
won't
go
into
too
much
detail
here.
It's
a
key
value
store.
B
B
One
of
the
interesting
things
about
EDD
is
that
well
it
has
a
put
get
mechanism
that
any
kind
of
key
value
store
is
going
to
have.
It
also
has
a
watch
mechanism.
The
watch
mechanism
is
is
kind
of
special,
because
you
can.
You
can
tell
a
client
to
watch
a
particular
key
and
that
watch
will
block
until
the
key
changes
and
then
it
will.
The
watch
will
hand
you
back
the
the
new
value.
So
you
can
use
this
for
things
like
polling.
B
Flannels,
specifically,
it's
a
software-defined
network.
It
was
created
by
core
OS,
it's
still
supported,
although
it's
less
and
less
the
recommended
Sdn,
you
can
run
it
on
a
public
or
private
network
and
flannel
encapsulates
the
traffic
so
that,
if
you're
running
with
only
a
single
interface,
the
traffic
running
between
the
container
hosts
on
behalf
of
the
containers
is
not
directly
exposed
to
the
the
carrier.
B
B
Campus
as
well
soon
I
do
want
to
cover
something.
It's
gonna
be
a
little
bit
of
a
of
a
sidestep,
because
one
of
the
things
I
found
is
that
people
have
a
series
of
misconceptions
about
what
containers
are
that
sometimes
incorrectly
inform
how
they
use
them.
Just
so
people
are
know
the
the
key
word
in
the
first
four
lines
here
is
the
word.
Just
a
lot
of
people
will
say:
containers
are
just
two
Rooter
jails,
they're,
not
just
that
there's
significantly
more
to
them
and
they
shouldn't
be
dismissed.
They're,
not
just
solaris
containers.
B
Yes,
there's
a
history
there,
but
there
are
significant
differences.
It's
not
just
Alexei
Alexei
is
a
precursor
to
to
docker
and
to
other
container
systems
that
essentially
was
kind
of
like
an
erector
set
for
containers.
You
could
build
containers,
but
you
had
to
be
really
dedicated.
You
had
to
really
know
how
you
were
doing
it.
One
of
the
probably
the
biggest
advantage
docker
brought
when
it
came
was
that
it
removed
this
kind
of
erector
set
mentality.
It
made
it
possible
for
people
to
worry
more
about
the
software
inside
than
the
construction
I've
heard.
B
B
One
really
important
thing
is
it's
not
it's.
The
containers
are
not
going
to
replace
VMs.
There
are
software
that
are
well
suited
to
containerization
and
then
there's
some,
that's
really
not,
and
VMs
will
continue
to
have
a
place
another.
The
flip
side
of
that
is,
it's
really
important
over
time,
not
to
just
try
to
stuff
the
contents
of
a
VM
into
a
container.
B
But
there
have
been
several
several
follow-ons
rocket
is
one
that
I'm,
particularly
intrigued
by,
but
rocket
has
also
been
taken
over
or
excuse
me.
A
of
people
have
gotten
together
to
form
the
the
open
container
initiative,
which
is
seeking
to
define
standards
for
containers
both
for
the
the
runtime
and
the
images
that
make
it
possible
for
other
container
runtimes
to
use
those
images
and
to
provide
different
sets
of
characteristics.
B
So
if
those
are
the
things
that
containers
not
you
know
what
is
a
container
and
I
think
people
confuse
three
things
about
containers.
They
can
they
confuse
the
container
instance,
which
is
execution
the
container,
the
image
which
is
a
software
package
plus
some
stuff
and
the
container
runtime,
which
is
software
management
they
may?
They
may
also
can
confuse
the
container
image
repository,
although
that's
less
less
common,
just
to
run
down
what
a
container
is
is
is
not
a
virtual
machine.
It's
not
even
containers,
really
not
a
great
term.
B
What
it
is
is
a
process
with
blinders
on
a
fairly
new
set
of
techniques
called
kernel
namespaces
and
by
new
I
mean
with
the
last
four
or
five
years
kernel
namespaces.
Allow
a
process
to
see
the
host
system
differently
from
other
hosts
and
what
a
namespace
does
is.
It
provides
this
new
view
containers
run
in
a
set
of
kernel
namespaces
so
that
when
they
make
queries
of
the
operating
system,
they
see
a
different
view
from
what
the
system
sees
the
limitations.
B
The
processes
can
be
limited
by
kernel
capabilities,
which
are
also
a
relatively
new
addition
to
the
to
the
Linux
kernel
again
in
the
last
four
or
five
years
in
internet
times.
It's
not
all
that
long
or
it's
a
long
time,
depending
on
your
view,
capabilities,
allow
very
fine-grain
control
of
what
a
process
is
allowed
to
you
when
it
accesses
the
kernel,
NSE
Linux,
which
allows
labeling
and
control
of
access
of
file,
resources
and
process
resources.
B
B
It
also
contains
a
security
hash
or
can
contain
a
security
hash
so
that
you
can
be
sure
that
the
contents
are
unmodified
in
a
signature
so
that
you
know
that
it
came
from
the
source
that
claims
to
have
created
it,
and
the
link
at
the
bottom
is
the
the
link
to
the
OCI
image
specification
and
that
was
version.
1
was
released,
I
think
in
October,
maybe
late
September
early
October.
B
So
the
container
runtime
is
the
environment
in
which
something
works.
So
it's
it's
more.
What
it
does
than
what
it
is.
The
container
runtime
is
the
piece
on
the
operating
system
that
takes
an
image
and
it
takes
some
other
information
and
it
initializes
the
environment
in
which
that
container
will
run
in
which
the
the
runtime
will
happen.
B
It
creates
the
namespaces
so
that
it
creates
the
views.
The
process
will
see
it
unpacks
the
image
layers
into
a
space
into
a
file
space
and
makes
that
available
as
a
unit.
It
can
remount
mount
remote
file
services
file
systems
on
behalf
of
the
container
when
it's
going
to
run
and
there's
a
gap
that
the
container
runtime
fills
between
the
parts
that
the
container
image
Creator
finishes
and
the
consumer
wants
to
use.
It
fills
that
gap
and
establishes
that
space
file
systems
and
other
environments
it
sets
or
removes
kernel
capabilities.
B
B
In
addition,
the
container
runtime
provides
some
some
access
stuff
and
here
I
used
the
the
docker
examples.
But
there
are
examples
in
pretty
much
any
runtime
where
you
can
run
a
command
which
will
execute
an
additional
process
within
that
set
of
namespaces
so
that
you
can
do
debugging,
and
you
can
take
a
look
at
the
running
container
so
that
you
can
find
out
what
IP
addresses
it
has.
What
resources
it's
using,
how
it's
connected
to
others
and
again
the
the
link
at
the
bottom
is
the
link
to
the
the
runtime
specification
from
the
OCI.
B
Went
the
wrong
way
that
time
so
now,
we've
gone
through
what
the
containers
are
and
covered
some
background
and
now
I'm
actually
getting
to
the
piece
that
matters,
and
maybe
it's
been
a
long
time
coming.
We've
got
the
container
host,
we've
got
the
container
runtime
and
we've
got
system
administrators
who
have
to
make
this
stuff
work.
B
So
the
container
house
comes
with
minimal
tools.
All
it's
meant
to
do
is
boot
and
attach
to
a
network,
and
so
when
it
boots,
it
needs
to
know
who
it
is.
It
needs
to
know
how
to
reach
other
systems
with
an
IP
address
and
and
some
routing
information
it
needs
to
have
time.
Sync,
it's
really
really
critical
that
these
have
time.
Sync,
because
many
of
the
operations
they
do
use
are
time
critical
and
they
need
to
have
some
kind
of
authentication
mechanism
to
allow
somebody
in
from
the
outside.
B
So
if
you've
got
these
machines
and
the
process
is
the
software,
you
want
isn't
there,
what
do
you
do?
Well,
you
install
your
software
as
containers
now
they're
going
to
be
special
containers,
because
if
you
know,
as
it
says,
you
know
you
would
run
a
container,
they
have
blinders
on.
You
can't
see
the
system
well,
it
turns
out
the
containers
because
their
processes
and
namespaces
all
processes
on
a
container
hose
and
actually
all
processes
on
a
conventional
host.
Now
that
has
the
capability
of
running
namespaces.
Those
are
running
in
the
system.
Namespace.
B
If
you
log
on
to
your
ordinary,
a
Linux
box.
Now
your
process
is
running
in
the
system.
Namespace
by
default
containers
are
running
in
their
own
namespaces.
You
can
run
containers
in
the
system.
Namespace
and
it's
important
to
remember.
People
think
you're,
letting
the
container
out
you're
not
really
you're
letting
the
system
into
the
container
there
are.
There
are
some
cases
where
you
can
install
additional
stuff
that
I
will
go
into
in
a
minute.
B
There
are
several
kinds
of
special
containers
for
doing
this.
The
first
kind
is,
what's
called
a
super
privileged
container,
and
if
you
look
at
the
the
docker
run
back
here,
it
spends
a
lot
of
time
punching
holes.
If
you
see
the
minus
e
host
equals
slash
host
and
the
IP
C
equals
host
net
equals,
host
and
PID
equals
host,
and
it's
running
privileged.
What
those
three
things
do
is
it
says
the
inter-process
communications.
B
B
That
has
you
know,
traceroute
and
various
other
network
tools,
IP
pieces
that
you
need
to
do
system
administration
now
you're
installing
this
as
a
container,
but
it's
really
meant
for
only
running
individual
commands.
You
log
in
you
get
a
shell.
You
run
your
commands,
you
exit
and
the
container
processes
have
gone
away.
B
The
image
is
still
there,
you
can
reuse
it
or
you
can
delete
it,
but
what
that
the
super
privileged
containers
allow
you
to
do
is
run
individual
commands
as
a
system
administrator
to
examine
the
system,
examine
the
the
state
of
the
system
and
the
process
is
running
using
tools
that
aren't
normally
embedded
there's
a
second
special
container,
which
it's
they're
just
getting
started.
I
think,
in
my
opinion,
they're
still
working
their
way
up.
This
is
called
a
system
container.
B
What
a
system
container
does
that
a
super
privileged
container
dozen
is
a
system
container,
can
run
system
services
on
the
host
in
a
way
as
if
you
had
installed
the
container
instead
of
running
for
that,
this
is
really
common
for
for
network
services.
If
you
wanted
to
run
a
DNS
name
server,
you
probably
don't
want
to
run
that
in
a
container
by
yourself.
You
want
to
run
it
using
the
system.
You
want
people
to
query
the
whole
system,
so
you
can
run
your
your
name
services.
You
can
run
an
LDAP
authentication
service.
B
You
can
run
in
TP
so
that
it's
available
to
other
things,
but
to
run
it
as
a
system
service.
You
want
it
to
start
when
the
system
starts,
you
want
it
to
boot
up
as
part
of
the
system
boot
up,
and
so
these
containers
have
some
special
metadata,
that's
outlined
in
the
in
the
links
there
I'm
not
going
to
go
into
a
lot
of
detail,
but
they're
they're,
specifically
designed
to
run
as
system
services.
You
note
the
first
bullet
says
it's
not
dependent
on
Docherty.
B
These
are
startup
these
startup
using
run
C
or
system
D
so
that
they
can
run
before
the
Docherty
is
started
because
the
doctor
D
depends
on
some
local
networking
that
may
not
be
established.
Yet
there
are
some
special
commands
that
it
can
be
used
to
install
these
there.
They
can
be
done
with
ordinary
docker
commands
or
with
ordinary
container
commands.
But
there
is
there's
a
pattern.
That's
emerged,
so
the
atomic
CLI
was
created
to
manage
those
as
an
example
of
one
of
these
there's
a
system
container
called
cockpit
and
cockpit.
B
Is
it's
a
very
neat
web-based
it's
a
monitoring
tool?
It
runs
as
a
process
on
the
Box,
it's
very
small,
but
it
offers
a
web
interface
and
an
API
interface
for
interacting
with
with
the
system
it
uses
the
system
authentication
to
grant
control.
I
only
have
it
here
just
to
go.
Take
a
look
at
it.
It's
an
example
of
something
that
you
could
run
in
every
container
house.
To
give
you
some
some
visibility
to
the
system
that
wouldn't
otherwise
have
Dan
is.
Are
there
any
questions,
yet
no
I'm
going
very
fast.
B
A
B
There
are
already
several
applications.
I
know:
Maureen
Duffy
uses
English
scape
as
a
flat
pack,
which
is
a
graphical
containerized
version
of
Inkscape
that
has
no
dependencies
on
the
underlying
operating
system.
So
you
don't
get
any
kind
of
conflicts
if
it
needs
a
shared
library
or
something
that
that
hasn't
been
installed
by
the
ops
team.
B
All
of
that
self-contained
and
you
can
update
completely
independently
of
the
operating
system
underneath
there
are
a
set
of
modules,
I
provided
the
links
for
the
modularity
project
and
Voltron
and
for
the
set
of
modularity
containers
that
have
been
treated
so
far.
The
goal
of
modularity
is
is
very
ambitious.
B
B
If
you
make
a
change
to
the
underlying
operating
system,
you
grab
that
change
and
you
use
it,
and
you
are
confident
that
it
will
not
have
detrimental
effects
on
the
applications
you
already
have
and
are
running,
and
the
same
goes
for
your
applications
when
you
need
to
upgrade
one,
you
just
update
it
and
all
of
your
applications
are
no
longer
coupled
to
each
other.
You
no
longer
get
conflicting
shared
libraries
or
situations
like
that
that
make
it
difficult
to
maintain
the
applications
you
want.
This
is
very
young.
B
It's
very
experimental
there
really
I'm,
not
even
sure
if
they
would
call
themselves
beta
yet
and
it's
not
something
that
I've
had
the
time
to
try,
but
I
definitely
want
to
try
it
out
and
see
and
regardless
I
think
of
whether
modularity
and
Voltron
become
widely
adopted.
I
think
they're,
gonna
start
they're
gonna
start
establishing
patterns
that
others
are
going
to
adopt.
So
I
suspect
this
is
going
to
be
influential,
whether
it
whether
it
takes
off
or
not,
we
got
to
the
CLI
tolls.
B
I
talked
about
the
different
containers,
but
I
haven't
actually
talked
about
the
tools
themselves
on
container
Linux.
There
really
is
only
one
tool:
it's
called
tool
box
and
what
tool
box
does?
Is
it
actually
downloads
a
copy
of
Fedora
latest?
And
you
can
install
packages
inside
it
because
it
looks
like
an
operating
system,
then
you
can
can
delete
them
when
you're
done,
but
that's
about
as
far
as
core
OS
goes
in
assisting
the
administrator
in
managing
the
hosts.
They
really
are
concentrating
on
both
ends
and
their
model
really
is
build.
B
B
They
notice
those
patterns
where
you
would
say,
I
want
to
start
a
container
with
traceroute
in
it,
but
I
want
to
use
all
of
these
system
namespaces,
and
so
they
created
the
atomic
command
originally
just
as
a
just
as
a
shortcut
for
some
of
those
long
container
invitations,
because
they
noticed
that
there
was
constant
pattern
over
time.
They
realized
that
there
were
a
whole
lot
of
kind
of
logical
operations
that
they
wanted
to
be
able
to
do
that
were
related
to
how
container
hosts
work
and
they've
gradually
incorporated
a
bunch
of
them
in
now.
B
B
In
any
case,
the
atomic
host
commands
are
our
system
maintenance.
Rather
than
creating
individual
individual
processes.
The
atomic
host
commands
the
upgrade
and
rollback
and
status
of
the
of
the
running
system.
Then
again
it's
kind
of
a
wrapper
for
our
pmos
tree.
Most
of
those
commands
can
be
done
directly
as
our
pmos
tree
commands,
but
they
found
over
time
that
there
was
a
pattern
to
how
they
were
doing
it
and
that
the
pattern
could
be
encapsulated.
B
Again,
I
think
this
part
is
probably
obvious
to
people.
One
thing
to
be
aware
of:
is
you?
Can
you
can
deploy
these
pretty
much
anywhere?
You
would
deploy
an
ordinary
host.
You
can
pixie
boot
them.
You
can
boot
them
in
cloud
providers.
You
can
configure
with
cloud
in
it.
There
are
images
for
core
OS
in
all
of
the
major
commercial
cloud
providers.
I
haven't
yet
seen
atomic
host,
whether
Fedora
core
OS
or
rel,
offered
as
standard
containers
from
the
vendor
in
in
those
areas.
B
But
it's
simple
enough
to
upload
a
single
image,
butyou're
machines
from
it
and
then
roll
it
forward
from
your
cloud.
You
can
also
load
them
in
a
personal
VM
through
vagrant
and
I've
got
the
links.
I
have
provide
a
couple
of
different
examples,
one
for
core
OS
and
one
for
atomic
customizing.
You
can
customize
container
Linux
again
because
it's
based
on
chromium
and
Chrome
OS.
You
can
download
the
tools
and
rebuild
it
when
you
do
that,
there's
a
couple
of
different.
B
You
can
build
the
image
and
then
there's
a
couple
of
different
ways
to
turn
them
into
development
or
production
images
which
have
slightly
different
characteristics.
The
production
images
will
have
a
signature
that
the
development
once
won't
currently
building
requires
a
manual
patch
and
I've
listed
the
the
pull
request
to
do
that.
It's
fairly
straightforward
to
apply
that,
but
it
hasn't
been
applied
upstream.
B
If
you're
updating
atomic
we've
already
already
looked
at
this
briefly
you're
going
to
do
a
atomic
host
upgrade
and
it
will
tell
you
what
rpms
it's
updating,
what
differences
there
are
between
your
current
version
in
your
new
one,
you
reboot
to
go
to
the
new
one.
Once
you've
done
the
upgrade.
If
you're
unhappy
you
do
an
atomic
host
rollback
and
then
reboot
and
each
of
those
operations,
it
will
tell
you
which
packages
are
changing.
B
B
B
So
your
your
long-term
network
traffic
is
going
to
be
much
much
smaller
with
the
atomic
than
it
would
be,
with
core
OS
they're,
not
so
great
for
complex
and
monolithic
apps,
and
that's
that's
true
of
containers.
In
general,
you
really
want
to
decompose
the
your
applications
so
that
they
fit
into
containers.
It
doesn't
mean
that
system
bins
need
to
adapt
and
developers
need
to
adapt.
B
People
need
to
start
building
system
containers,
and
then
you
need
to
plan
how
you're
going
to
do
updates
and
then
automate
and
then
let
the
automation
do
its
job.
So
that's
what
I've
got
for
today
thanks
everybody
thanks
Diane,
for
the
opportunity
to
talk.
That
was
a
bit
of
a
whirlwind,
but
I
hope
there
was
something
there
for
everybody.
Well,.
A
There
definitely
was
Marc
I
think
that
the
interesting
thing
was
it
gave
us
AI,
really
good
for
the
first
time.
For
me,
it
really
clarified
the
difference
between
core
OS
and
atomic
and
a
real
succinct
way.
So
thank
you
very
much
for
that,
plus
all
the
talk
about
the
tools
and
in
it
you
are
opinionated
and
I
love
that
about
you.
A
Also
really
good,
because
most
of
the
time
when
we,
when,
when
I
interact
with
folks
I'm
interacting
with
developers
who
want
just
the
most
simplest
tools
and
so
to
get
the
sort
of
assisted,
Minh
point
of
view
on
their
house
is
really
very
helpful
to
understand.
You
know
once
you
know
once
it's
day
two
as
we
were
talking
about
before,
and
you
really
have
to
start
maintaining
and
using
all
of
this,
this
is
kind
of
it
was
real.
It
was
really
good.
I
mean.
B
A
A
A
A
A
It's
all
good,
so
thank
you
very
much
for
doing
this.
I
think
we're
gonna
end
up
having
some
follow-ons
on
this
topic,
but
I
wanted
to
get
it
out
there,
and
so
thank
you
very
much
for
taking
the
time
today
and
those
of
you
who
listened
in.
Thank
you
for
your
your
patience
and
your
questions,
which
I
think
you
answered
all
of
them
in
the
talk
as
soon
as
you
started
going
so
we'll
do
this
again
very
soon.
So
thanks
again
mark
thanks.