►
From YouTube: Keynote: Best Practices In Implementing Container Image Promotion Pipelines - Baruch Sadogursky
Description
Keynote Session Sponsored by JFrog - Best Practices In Implementing Container Image Promotion Pipelines - Baruch Sadogursky, JFrog
Surprisingly, implementing a secure, robust and fast promotion pipelines for container images is not as easy as it might sound. Automating dependency resolution (base images), implementing multiple registries for different maturity stages and making sure that we actually run in production containers from the images we intended can be tricky. In this talk, we will compare different approaches, compile a wish-list of features and create a pipeline that checks all the boxes using free and open-source tools.
A
B
B
The
primary
concern
with
docker
is
that
you
have
this
uneasy
feeling
that
you
are
not
100
sure
that
what
you
have
in
your
docker
images
or
containers
in
production
is
what
you
intended
to
put
there
we're
going
to
tell
to
to
speak
about.
Why
and
what
you
can
do
about
it.
My
name
is
barak
sadogurski,
I'm
the
chief
sticker
officer
of
jfrog
if
it
was
an
in-person
event,
as
I
definitely
hope
the
next
one
will
be.
I
would
be
with
you
spreading
stickers
all
around
for
now.
B
I
am
going
to
use
my
head
of
devops
advocacy
hat,
to
explain
to
you
a
little
bit
about
docker.
The
most
important
part
of
this
slide
is
my
twitter
handle
no
I'm
just
kidding.
Let
me
tell
you
one
phrase
about
jeffrey
jeffrog
is
a
company
behind
jeffrey
container
registry,
jeffrey
platform,
jeffrey
artifactory,
that
you
might
heard
about,
and
we
help
companies
bringing
software
faster
to
production
so
fast.
B
It
looks
like
a
flow
of
liquid,
and
this
is
why
we
call
it
the
liquid
software
visit
our
booth
to
see
demo
of
our
products,
and,
let's
talk
about,
show
notes.
This
is
the
most
important
slide
of
this
talk.
If
you
go
to
jeffer.com's,
show
notes,
you
will
find
there
the
slides
already
there,
the
video
already
there
all
the
links
that
I'm
mentioning
and
a
place
to
comment
and
rate,
and
the
small
raffle
for
coming
to
my
talk
today.
So
don't
forget,
jeff
homsey
show
notes.
B
If
you
look
at
the
bottom
of
every
slide,
you
will
find
this
link
and
my
twitter
handle
as
the
hashtag
of
the
conference.
But
let's
talk
about
promotions,
promotion
pipelines
are
a
pattern,
and
when
we
need
to
deal
with
a
pattern
we
should
ask:
do
we
have
an
existing
one
and
should
we
adopt
it
or
maybe
adopt
it?
And
here
is
a
pipeline
that
we
do
for
years?
Promotion
pipelines-
and
this
is
something
that
shouldn't
be
new
to
any
of
you.
B
We
have
this
promotion
pyramid
that
we
have
in
the
beginning,
a
lot
of
builds
with
very
rapid
tests
and
the
less
builds
survive
the
more
evolved.
The
tests
are
all
the
way
to
production,
and
if
we
look
at
the
same
pyramid
and
the
same
promotion
from
a
different
angle,
you
can
see
here
how
you
take
the
sources
you
convert
them
to
binaries
with
your
ci
server,
and
this
is
where
the
promotion
actually
begins
and
the
promotion
is
about
taking
artifacts,
deploying
them
to
the
runtime
environments
and
then
test
them
on
those
environments.
B
If
the
tests
succeed
and
if
the
quality
requirements
are
hit,
and
that
will
be
your
tests,
your
security
checks,
your
license,
compliance
check
your
performance,
everything,
then
those
artifacts
are
promoted
through
quality
gates,
those
locks
through
quality
gates
to
the
next
environment,
and
we
do
the
same
again.
We
deploy
them
to
the
runtime.
We
test
the
hell
out
of
them.
We
promote
them
further
through
quality
gates,
all
the
way
to
production.
B
Now,
the
problem
with
docker
is
that
it
makes
it
very
easy
to
do
the
right
thing
and
it
makes
it
very
hard
to
sorry
very
easy
to
do
the
wrong
thing
and
very
hard
to
do
the
right
thing.
Let's
start
with
the
easy
and
the
wrong
way
and
the
easy
and
the
wrong
way
is
actually
just
rebuilding
the
image.
All
the
time.
Rebuilding
the
image.
All
the
time
has
two
benefits.
B
B
Why
you
ask
so
that's
why
I
wanted
to
create
the
most
unstable
docker
image
just
for
the
demonstration
purposes,
but
then
I
just
went
online
and
I
saw
tons
of
images
which
are
ridiculously
fragile
just
over
there
that
people
go
ahead
and
use.
This
is
a
real
world
example.
You
can,
you
can
go
to
jfrog.com,
show,
notes
and
see
the
link
to
github
of
this
docker
image.
B
B
Is
it
better
well
to
an
extent
it
is
1904,
but
you
need
to
remember
the
docker
images
are
mutable,
and
that
means
that
canonical
the
maintainer
of
ubuntu
can
and
will
push
changes
like
security
fixes
into
the
same
tag.
So
you
build
ubuntu
1904
from
ubuntu
1904
twice,
you
can
get
different
results
and
what
about
all
the
all
the
rest,
oh
yeah,
and
we
can
do
something
else
we
can
nail
down
with
a
checksum.
Well,
this
is
completely
repeatable,
but
not
very
useful.
B
What
version
do
I
refer
to?
Is
it
even
a
valid
shot
too?
Maybe
my
cat
went
over
my
keyboard
and
this
is
what
we
ended
up
with
and
what
about
the
rest
of
them?
Well,
the
question
is:
do
you
can
you
lock
the
version
and
all
the
transitive
dependency
tree
when
you
do
upgrade?
Maybe
you
can?
Maybe
you
can't
how
about
other
dependency
tools?
Maybe,
for
example,
can
you
nail
the
dependency
tree
of
maven
to
be
completely
immutable?
Well,
if
you
don't
know
maven,
you
will
say
I
don't
know.
B
If
you
do
know,
maybe
you
can
say
well.
I
can,
if
you
do
know
me
even
very
well,
you
will
say
well,
I
don't
know
in
any
way
how
about
this
we
can
just
get
files
from
all
over
without
any
control.
So
what
I
mean
by
that
is
that's
why
you
have
this
feeling.
This
is
why
every
time
you
rebuild,
you
know
that
the
docker
image
that
you
get
might
be
slightly
different
and
then
you
are
not
sure
if
what
you
have
in
production
is
exactly
what
you
tested
during
your
pipeline.
B
What's
the
solution,
building
a
pipeline
with
promotion
of
immutable
binaries
great
great?
What
we
want
to
do
is
this:
we
build
it
only
once
and
then
we
promote
the
right
artifact
through
those
quality
gates
all
the
way
to
production,
and
I
keep
speaking
about
those
quality
gates.
Why
are
they
important?
They
are
super
important,
because
those
quality
gates
are
the
guarantee
that
you
won't
end
up
in
your
production
with
untested
binaries.
This
is
how
you
know
that
what
the
production
has
has
been
through
the
entire
pipeline,
as
it
should
be.
B
B
Labels
are
key
value,
parts,
just
strings
that
you
can
attach
to
everything
in
docker,
including
images,
and
then
you
could
do
something
like
maturity,
testing
maturity,
staging
maturity,
prod.
This
is
nice,
but
those
are
just
free
form
strings.
You
need
to
make
sure
that
you
put
them
and
you
need
to
make
sure
that
the
receiving
part
their
runtime
actually
checks
for
them
in
exactly
the
same
way.
You
intended
it's
not
strong
enough.
The
other
option
is
docker
repositories.
Docker
repository
sounds
like
a
great
idea.
B
They
have
full
rbc
control,
and
that
means
that
you
can
control
who
sees
which
environment
sees,
which
repository
great.
Well.
Almost
the
concept
of
docker
repositories
comes
from
us
from
github
from
github
repositories
and,
as
you
know,
there
is
no
maturity.
Separation
in
github
repositories.
You
don't
have
a
separate
given
hub
repository
for
development,
staging
and
production.
B
The
repositories
are
for
different
projects
and
it's
exactly
the
same
with
docker.
The
repositories
are
for
different
projects,
so,
let's
keep
looking.
What
you
really
want
to
do
is
having
separate
registries
per
environment.
If
you
have
separate
registries,
those
quality
gates
are
ideal
because
then
the
environments,
the
runtime
environments,
know
nothing
about
any
other
registry
except
of
the
registry
they
need
to
consume.
B
The
problem
is
it's
not
so
easy
to
do
with
docker,
and
this
is
because
docker
has
some
strange
limitations
that
was
imposed
from
the
beginning
and
now
are
in
our
way,
for
example,
or
not.
For
example,
what
I
mean
is
the
docker
tag
syntax
when
we
tug
or
pull
or
push
the
image
we
don't
specify,
which
registry
it
should
be
pushed
or
pulled
from,
but
only
on
which
host
and
the
question
is
now.
I
want
multiple
registers
per
host
right.
I
have
a
server
with
all
those
environments.
B
B
We
can
abuse
the
username
token
in
the
url
to
use
it
as
to
use
it
as
a
as
a
maturity
qualifier
to
say
to
which
repository
we
actually
want
to
go,
and
then,
when
we
have
that
and
we
have
multiple
registries
per
host,
the
next
question
is:
how
do
we
promote
our
images
from
one
registry
to
another
when
we
had
the
registries
in
different
hosts?
The
answer
was
well
through
network.
You
pull
you
re-tag
and
you
push
that's
fine.
B
Your
registries
are
on
different
hosts
anyway,
so
you
will
pay
the
network
price
either
way.
But
now,
when
you
have
multiple
registries
per
host,
downloading
retargeting
and
uploading
is
just
insane.
So
instead
you
need
to
look
for
a
tool
that
knows
how
to
have
multiple
registries
per
host
and
know
how
to
promote-
and
it's
obviously
achievable
with
jfrog
artifactory,
jeffrey
container
registry
and
the
j4
platform,
but
that
there
are
other
tools
as
well.
What
you
need
to
look
for
are
number
of
things.
First
of
all,
here
is
our
promotion
pipeline.
B
You
can
see
here
how
we
have
local
registries
for
dev
testing
staging
and
prod,
and
they
are
sitting
on
the
same
storage
and
it
means
the
promotion
moving
from
one
registry
to
another
is
done
by
api
by
different
tools
by
jfrog
common
line
interface
or
your
favorite
ci,
and
it
is
immediate
and
free
because
no
files
are
actually
moving.
You
just
change
the
visibility
of
this
docker
image
from
one
registry
to
another.
There
are
other
important
features,
for
example,
proxing
remote
registries
like
docker
hub,
and
you
know
docker
hub
now-
will
throttle
you.
B
Now
you
are
protected
from
a
requesting
too
many
times
and
you
have
a
cache
of
what
might
be
otherwise
deleted,
and
the
virtual
registry
is
also
very
useful
because
it
allows
you
to
group
any
type
of
visibility
from
any
type
of
other
registries
together
and
present
it
as
a
registry
of
its
own-
and
this
is
our
resolution
in
in
action-
you
can
see
how
each
and
every
cluster
can
only
see
the
registry
that
it
has
to
see
and
won't
see
others,
and
this
is
extremely
important.
Those
are
the
quality
gates.
B
So
we
have
win-win-win
situation
in
which
you
have
a
single
point
of
access
to
multiple
registries.
When
you
need
it,
that's
the
virtual
registry,
you
have
completely
other
related
environments
and
those
are
the
quality
gates
and
you
have
immediate
and
free
promotions
between
all
those
registers
because
of
the
unified
checksum-based
that
duplicated
storage
for
all
of
them,
so
just
to
conclude,
build
only
once
separate
environment,
promote
what
you'll
build
and
own
your
dependencies
in
your
system,
and
then
you
will
have
a
very
strong
promotion
pipelines
with
that.
Thank
you
very
much.
B
I'm
edgy
baruch
on
twitter.
This
is
cdcon
use.
This
hashtag
and
jeffersonville
show
notes
the
slides,
the
video
all
the
links,
comments
rating
and
don't
forget
the
raffle
for
being
here.
Thank
you
very
much.
Bye-Bye.