►
From YouTube: OpenShift Commons Briefing #102: Introducing Buildah with Nalin Dahyabhai and Dan Walsh
Description
Buildah facilitates building OCI container images and is able to create and run containers without the Docker daemon even being installed. Buildah also allows you to easily create smaller, stronger, purpose-built containers that precisely fit your needs. A common problem people have with building container images with tools like Dockerfile and the run-time-based docker build command is the size of the image, as well as the number of build tools that end up inside of it. Another concern about these unnecessary tools is they can weaken your container by opening potential venues for hackers to take advantage. A really nice feature about Buildah is you can strengthen your container making it “stronger and more fit”. By finely tuning the creation of the container, and then adding or removing pieces as you desire, you can control the size of your container and lessen its vulnerabilities. It’s all under your control. In this briefing, Nalin and Dan will give us an overview of Buildah and a demo how to use it.
A
C
So
today,
we're
here
to
talk
about
build-out,
which
grew
a
bit
out
of
the
cryo
project,
so
in
terms
of
background,
cryo
exists
primarily
to
be
a
run
time
for
the
container
run
time
interface
that
kubernetes
and
open
ship
used,
and
at
least
as
far
as
kubernetes
is
concerned.
Building
and
image
is
not
part
of
that.
So
it's
out
of
scope
for
cryo,
so
a
while
ago,
I
guess
it's
getting
on
to
several
ones.
C
At
this
point,
Dan
have
been
telling
me
about
how
we
really
can't
really
needed
something
in
the
space
to
be
able
to
handle
this
problem
and
because
it
wasn't
filling
me
part
of
cryo
is
gonna,
have
to
probably
be
something
else,
and
so
we
knocked
something
together
and
result
is
build
up.
But
let's
back
up
a
second
and
see
what
the
problem
that
we're
trying
to
solve
is
essentially
an
image
cuz,
that's
what
we're
trying
to
produce
is
just
described
by
the
manifest
it's
got
it.
C
So
the
first
item,
in
the
manifest
that
we
care
about,
is
a
configuration
plot.
It's
really
just
a
JSON
document,
another
one
yeah,
which
contains
some
encoded
settings
and
defaults
for
how
to
run
the
container.
You
know
which
command
you're
going
to
run
what
environment
variables
you
set
for
it
what's
going
to
run
it
has.
The
key
thing
here
is
to
know
that
it
is
not
exactly
the
same
as
it
configuration
that
you
would
pass
to
a
tool
like
run
C.
C
It
actually
contains
a
much
smaller
set
of
information
than
you
can
pass
to
run
C.
It
doesn't
even
include
fields
for
things
like
process
limits
or
C
group
configuration,
so
you
can't
just
well
the
upshot,
is
you
can't
just
take
it
and
pass
it
to
run
C
and
have
it
go
because
you
have
to
use
the
mineral
processing
to
make
that
go.
The
other
type
of
thing
that
you're
going
to
keep
it
in
an
image
is
file
system
layers
notionally.
B
C
They're
still
sharing
the
same
underlying
layers
for
the
Fedora
image
in
the
incremental
space
used
by
the
additional
image
by
the
new
images
is
really
just
the
set
of
changes
you've
made
in
them,
so
it
really
does
cut
down
space,
though,
if
you're
talking
about
building
an
image,
you
can
start
with.
Well,
let
me
back
up
a
second
so
when
you're
actually
going
to
run
the
container,
this
is
a
little
bit
redundant.
You're
just
going
to
build
up
the
root
filesystem.
C
Do
some
processing
using
your
configuration
up
to
build
a
configuration
here
at
one
time
and
kick
it
off.
This
is
actually
the
simplest
part
of
cryo
and
the
cryo
actually
does
quite
a
bit
more
than
this.
In
order
to
do
the
things
that
brandies
and
OpenShift
expects
it
to
be
able
to
do
so,
the
hard
part
of
building
an
image
from
a
container
is,
you
know,
you've
got
the
set
of
layers
that
you
started
with
when
you
created
the
image
and
you've
made
some
changes
to
do
a
file
system.
C
So
how
do
you
do
this?
Well,
if
you're,
using
a
UNAM
file
system,
something
that
lets
you
efficiently,
compute
the
differences
between
layers
or
actually
has
layering
built
into
it?
You
can
do
something
clever.
You
can
extract
just
the
changes
for
that
layer.
In
fact,
originally,
and
this
carries
over
into
the
layer
format.
Well,
the
format
of
white
out
closely
matches
the
format
used
by
a
ufs,
which
is
an
implementation
detail
which
okay.
B
C
If
you're,
not
using
some
union
file
system,
where
you
say
you're
using
block
devices
or
you're
not
doing
any
copy-on-write
logic,
you
basically
want
the
files
of
nutri
and
do
the
equivalent
of
a
recursive
dip.
This
can
be
very
time
consuming.
In
fact,
a
lot
of
time
and
work
has
been
put
into
trying
to
make
this
faster,
so
once
you've
done
that
the
rest
of
it
is
fairly
simple.
You
create
a
new
layer
for
your
changes.
You
update
the
manifest
to
include
the
new
layer.
C
You
generate
a
new
configuration
blob
which
may
include
information
from
the
previous
configuration
blob.
If
you
started
with
another
image
and
the
net
result
is
a
brand
new
dimension,
so
he
produced
a
tool
called
Builder
that
actually
just
automates.
All
of
this,
for
you
build
it
from
is
the
command
line
the
holes
done
an
image
and
erase
the
puppet.
The
file
system
creates
a
new
writable
layer.
If
you're
using
copy-on-write
file
systems,
you
can
mount
that
image
for
sorry.
You
can
mount
that
container
for
direct
manipulation.
C
You
can
have
it
run,
commands
in
it
using
run,
see,
and
then
you
can
make
your
changes
producing
a
new
image.
Other
things
it
does
is
well.
One
of
the
other
primary
drivers
of
this
goal
is
that
we
would
be
able
to
reuse
a
lot
of
the
libraries
that
we're
using
in
cryo.
So
when
you
pull
that
an
image
with
bilder
cryo
sees
that
image,
if
cryo
has
already
pulled
the
image
down,
it'll
is
able
to
use
it
without
a
mid
download
a
new
copy.
As
soon
as
you
commit
a
new
image
would
build
up.
C
Ryo
sees
it
because
they're
using
the
same
storage
space
and
yes,
it
can
also
push
to
a
registry,
because
that's,
I
think
people
expect
to
be
able
to
do
with
a
build
tool.
Now
the
build
a
command
line
is
closely
modeled
after
docker
file
instructions.
But
in
addition
to
being
able
to
do
things
on
the
command
line,
you
can
eat
a
docker
file.
It
actually
uses
the
open
ship
and
we
build
our
library
to
drive
this.
The
behavior
is
a
little
bit
different.
You
don't
get
multiple
layers,
you
don't
get
layer.
Caching.
C
D
You
know
we
have
so
steam
age
I
know.
Binda
objective
is
to
really
build
some
real
the
image
or
modify
an
image
without
having
a
big
docker
environment
or
openshift
and
maíam
environment
instead
of
having
one
more
extra
to.
Is
it
possible
to
make
it
a
subsystem
of
so
stream
age?
That
way,
there's
one
more
less
thing:
people
have
to
remember
and
update
or
whatever
so.
C
If
you're
building
in
an
environment
where
you're
using
the
command-line
tools,
then
build
is
perfectly
usable
thing
but
longer
term,
we
want
to
just
have
it
built
into
the
the
building
facility
that
we
have
an
open
chef.
So
you
don't
actually
have
to
know
that
you're
using
builder
to
do
the
many
buildings.
B
That
yeah,
so
this
is
one
of
the
one
of
the
things
we've
done
is
most
the
functionality
can
be
put
into
a
library.
So
if
OpenShift
wants
to
call
in
to
the
library
directly,
then
it
could
do
that
or
or
I
could
exact
the
command.
So
right
now,
we're
in
my
main
goal
with
builder,
is
potentially
give
us
a
more
secure
way
of
building
sauced
images
from
a
from
a
goal.
C
C
Daemon
billa
is
not
a
client-server
application,
so
it's
actually
doing
everything
in
process
and
that's
a
trade-off
and
the
thing
that
we
have
to
work
on
in
order
to
be
better
integrating
with
open
and
in
order
to
better
integrate
with
openshift
is
to
try
to
get
the
set
of
privileges
that
it
needs
in
order
to
do
what,
but
it
does
down
to
a
much
smaller,
manageable
level.
Now,
right
now,
you
can't
run
the
whole
thing
inside
of
a
container.
B
You
can
use
so
building
can
be
used
as
just
a
tool
that
replaces
docker
build.
One
of
the
things
I
think
he's
gonna
show
on
his
demos.
Is
there
actually
is
alternative
ways
to
building
without
using
docker
file,
but
bottom
line
yeah
you
can
use
build
to
build
any
image
using
a
similar
workflow
that
you've
done
with
darker
build
in
the
past.
Also,
since
cryo
and
bilder
can
share
the
same
that
she
had
the
same
storage,
you
could
actually
build
a
container
into
your
local
storage
and
then
instantaneously.
Allow
you
to
run
kubernetes
container.
B
You
know,
have
kubernetes
instantly
launch
that
container
in
your
environment
so
build
there.
Also
some
really
cool
features
in
that
it
can
store
and
different
types
of
you
can.
Actually,
when
you
commit
and
push
you
can
actually
push
directly
into
container
registries
like
docker
I/o,
but
you
can
also
push
directly
into
you
know
right
into
the
darker
diamond.
You
can
push
in
to
sort
of
extract
a
tower
into
table
walls.
You
can
do
everything
you
can
do
with
tools
like
scope,
yo.
C
C
C
So
here
we're
creators,
cache
container
and
we're
gonna
use
that
to
install
most
of
the
user
space.
Well,
we're
gonna
mount
it
first,
because
otherwise
we
wouldn't
have
access
to
it.
That
tells
us
where
it's
mounted
you
said
the
environment,
rail,
because
that's
a
lot
a
lot
of
things
to
remember,
then
we're
executing
TNF
on
the
host
actually
installed
the
entirety
of
well
Fedora
26
is
users
base
into
that
previously
empty
container
file
system
does
is
gonna
run
for
bit,
we'll
grab
the
source
path
for
no,
that's
not
what
it's
called.
No,
that
was
down.
C
Unfortunately,
the
package
server
was
down
at
the
time,
so
I
had
to
download
the
source
rpm
from
somewhere
else.
So
in
this
case
we
are
having
built
well,
having
downloaded
a
source
package
and
copied
into
the
file
system
were
able
to
just
run
RPM
build
or
young
build
up
to
install
the
build
dependencies
for
it
inside
of
it.
At
that
point,
we
were
actually
well
having
installed
the
entire
build
environment
that
can
fit
into
that
container.
We're
able
to
rebuild
the
source
package
there,
or
rather
do
built
an
image
with
just
the
build
dependencies.
C
C
This
is
not
entirely
dissimilar
from
the
mock
tool
that
people
who
build
packages
per
door
are
probably
already
familiar
with,
and
this
one
we
copy
the
binary
packages
out
of
the
container,
remove
it
create
a
brand
new
one
which
only
contains
runtime
dependencies
all
the
packages
for
this.
This
is
a
much
smaller
set
of
packages
than
we
installed
in
the
first
image,
because
it
doesn't
contain
any
build
tools.
We
installed
the
buyer
here
p.m.
and
then
we
run
it.
C
B
Let's
talk,
let's
hold
off
from
this
demo
for
a
second,
please
deposit
yeah.
So
one
of
the
things
I
wanted
to
point
out
in
the
previous
demo,
we
were
using
all
standard
tools
that
are
provided
from
Linux.
So
if
you
were
familiar
with
darker,
you
have
to
do
a
darker
copy
to
get
content
and
they're
not
of
container
images
in
the
demo.
You
just
saw
he's
using
this
standard
copy
command
to
copy
stuff.
In
and
out
of
images,
the
image
is
mounted
on
disks,
so
you're
able
to
redirect
DNF
to
install
on
it.
B
So,
for
instance,
you,
if
you
just
use
any
container
you
it
requires
DNF
to
be
inside
the
container
or
requires
apt-get
to
be
inside
of
the
container,
but
really,
if
you're
running
at
a
container,
that's
just
gonna,
be
running,
say
a
web
interface.
You
know
you
really
don't
want
all
these
tools,
and
so
similarly
geela
seed,
libraries
other
things
like
secrets,
always
been
a
problem
with
doing
darker
builds
because
you
end
up
with
that
say,
say
you
need
secret
information,
say
Kerberos
keys
or
something
like
that
to
get
access
to
content.
B
B
C
And
those
of
you
who,
from
sources
probably
notice
the
first
thing
it
does,
is
it
builds
a
build
environment,
container
images
just
so
you
can
build
the
entirety
of
docker
in
a
container.
So
as
a
test
case,
we
actually
use
builder
to
build
this
one
and
that's
what
we're
watching
here,
we're
just
stepping
through
the
top-level
docker
file
that
you
find
in
the
normal
docker
source
tree.
C
One
thing
I
want
to
touch
on
that
Dan
was
mentioning
earlier,
is
that
we
do
have
a
bill
to
run
command
and
that
does
run
use
run,
so
you
to
run
a
command
using
the
file
system
that
you're
creating
what
I
found
is
that
people
tend
to
try
to
use
it
as
a
shortcut
for
docker
1.
It
is
really
not
comparable.
It's
much
more
comparable
to
well
the
docker
file
run
instruction
and
how
that's
handled.
C
C
B
A
couple
of
other
interesting
things,
depending
on
your
use
case,
builders,
either
faster
or
slower
than
docker,
build
darker
builder
for
the
general
developer.
Use
case
at
this
point
is
a
little
bit
slower
because
we're
not
caching,
so
if
you're
continuously
say
modifying
your
docker
file
and
then
rebuilding
builder
will
start
from
scratch
on
each
one
of
them.
So
you
know
if
so,
if
you're
running
a
DNF
command
inside
of
a
docker
file,
it
will
go
back
and
rerun.
B
The
dock
of
the
DNF,
where
is
currently
darker,
build
knows
that
that
command
already
succeeded,
and
you
haven't
changed
anything
up
to
that
point.
So
it
continues
later.
So.
Therefore,
in
those
cases
you
know
for
developers,
sometimes
it
could
be
a
little
bit
slower,
but
in
the
case
where
you're
starting
you're
just
doing
a
docker
file
directly,
that's
already
been
compiled.
So
it's
sort
of
like
a
build
system.
Environment
builder
is
actually
a
lot
quicker
because
it
doesn't
cache
the
each
step.
B
B
You
know
to
allow
you
to
optionally
specify
caching,
but
at
this
point
it's
it's
basically
we're
doing
one
commits
per
docker
file,
but
that
also
gives
you
that
give
you
ability
to
do
stuff
in
this
inside
of
the
dark
file
and
then
remove
it
and
not
have
to
worry
about
it
actually
accidentally
getting
cashed
in
the
being
shipped
out
of
you
product.
So
this
is
costing
benefits
of
these
methods,
but
sit.
A
B
So
right
now
are
the
current
plans
with
open
shift
is
as
far
as
cryo
is
concerned.
They'll
be
shipped
online,
is
moving
towards
using
cryo
as
a
replacement
for
docker
for
running
standardized
containers,
but
we're
going
to
be
still
using.
Docker
builds
for
sourced
image,
so
just
that
the
operations
teams
didn't
want
to
take
on
both
just
switching
over
both
ends
of
OpenShift,
online
and
openshift
to
it.
B
One
of
the
one
of
the
other
issues
you
know
not
only
mentioned
that
in
the
beginning
was
around
docker
is
a
client-server
operation.
So
if
you're
running
containers
say
you're
running
a
kubernetes
environment
and
you
want
to
leak
the
docker
socket
into
the
container,
then
you're
really
you're,
not
building
the
continue.
The
container
process
is
not
controlling
the
actual
building
of
the
of
the
image.
It's
it's
really
just
connecting
the
client
to
the
darker,
so
the
darker
server.
B
If
that's
doing
the
image
build
once
open
ship
moves
to
using
builder,
then
the
process
is
actually
building.
The
container
is
all
inside
your
sauce,
the
image
so
that
we
can
better
associate
the
C
group
constraints
on
users
using
build
of
type
method
than
then
you
can.
You
know
doing
it
through
darker.
B
A
And
the
road
ahead
too,
though
it's
you
know
I
this
earlier-
that
this
is
something
that
you
can
use
just
with
straight
up,
kubernetes
and
I'm.
Right
here
is
doing
right.
Now,
it's
in
their
github
under
project
atomic.
Is
there
any
plans
or
thoughts
about
maybe
moving
this
to
be
an
incubated
kubernetes
project,
yeah.
B
A
So
if
people
want
to
contribute
to
builder,
they
just
go
to
the
github
repo
and
they
can
connect
with
everybody
there
or
reach
out
to
newland
or
dan
via
either
I
or
C,
or,
if
you're,
a
tweeter
through
Twitter.
So
there's
there's
lots
of
good
ways
to
connect
with
everybody
this.
This
has
been
the
perfect
length
of
a
briefing
I've
been
trying
really
hard
to
get
everybody
to
do
it
within
a
half
and
you've
done
it.
A
Yeah
you
have
the
nail
on
the
head
here
in
terms
of
30
minutes.
In
so
perfect
timing,
we
look
for
two
more
tops.
I
know
we
have
a
talk
coming
up
sometime
soon
on
something
called
kapok,
so
as
a
teaser
and
hopefully
we'll
get
that
in
in
the
next
couple
of
weeks
as
well,
don't
bring
in
the
trap.
Oh
just
a
nice
job,
jin-seok
thanks
again
guys
and
we'll
talk
to
you
all
soon,
yeah.