►
From YouTube: Webinar: Getting Helm to be Enterprise-ready
Description
Package managers are hard. Helm learned a lot of lessons from others’ mistakes, but also repeated some. For example, having a single index file per repository is not scalable. It’s the same mistake that NPM made and it causes slower CI, high memory consumption, slower searches, and more. Another example is not having private enterprise repositories in mind, leaving out authorization and authentication features. In this webinar, we’ll explore several solutions to those problems, their strengths, and their weaknesses.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
A
B
B
B
A
A
B
B
B
B
B
A
Okay,
tell
you
what
let's
go
ahead
and
get
started?
The
number
looks
to
have
normalize.
Is
there
a
little
bit
welcome
to
today
CN
CF
webinar
getting
home
to
be
enterprise
ready?
My
name
is
Ariel
chatib
I'm,
a
founder
at
a
company
called
stack
point
cloud
where
we
make
it
really
easy
for
you
to
deploy
and
manage
native
tooling,
and
a
variety
of
leading
cloud
providers
I'm.
Also
a
ciencia
ambassador,
much
like
our
presenter
today,
Dorsky
Gorski
I
think
I
got
it
there.
A
Thank
you
all
for
making
time
today
to
join
us.
Baruch
comes
to
us
from
J
Prague
and
he's
going
to
be
sharing
with
some
of
their
expertise
on
helm
with
you
today,
a
little
bit
of
housekeeping
during
the
webinar.
If
you're
not
able,
you're,
not
gonna,
be
able
to
speak
as
an
attendee
there's
the
chat
window
feel
free
to
add
your
question
there
and
then
we'll
go
ahead
and
pass
those
on
to
Brooke.
A
Once
we
have
natural
kind
of
break-in
in
it,
there's
also
a
Q&A
function
down
there
so
feel
free
to
also
submit
your
questions
there.
Let
me
tell
you
a
little
bit
of
Berkeley's
our
presenter
today.
He's
developer
advocate
at
gate
frog
again,
a
fellow
CM
TF
ambassador.
His
passion
is
speaking
about
technology
speaking
in
general,
but
doing
it
about
technology.
A
He
peels
makes
them
look
a
little
bit
smart
and
with
17
years
of
high
tech
experience,
it
sure
helps
so
when
he's
not
on
stage
or
in
Sunnyvale,
he's
usually
on
a
plane
on
a
way
to
a
stage
someplace
else.
So
we're
very
excited
to
have
him
here
and
without
any
further
ado,
I'll
throw
it
over
to
him
to
lead
us
into
the
topic.
C
C
They
are
not
oh
here
you
go
and
that
perfectly
describes
me
and
at
Jabar
on
twitter,
as
you
can
see
right
in
second
slide,
very
entertaining
guy
definitely
worth
following,
and
in
case
you
forget,
I
have
the
Twitter
handle
on
every
slide,
so
you
can
keep
up
and
and
and
yeah.
That's
actually
fresh
screen
screenshot
from
today
and
I've
been
added
to
their
this
great
bunch
of
people
who
are
a
CNN,
safe
ambassadors
and
and
I'm
I'm
really
proud
to
be
there.
C
So
thank
you,
CN
CF
for
honoring
me
being
your
ambassador,
I
hope,
I,
won't!
Let
you
down
I
want
to
start
with
with
a
poll
to
kind
of
calibrate
in
the
level
of
discussion
first,
so
my
question
to
you
will
be
and
what
is
your
knowledge
of
of
helm?
I,
don't
see
the
poll,
but
it
doesn't
mean
that
you
don't
do
to
the
poll
yeah.
C
C
Okay,
well,
that's
that's
very,
very
nice
distribution.
It's
like
a
perfect
bell
curve.
Most
of
the
people
played
with
with
helm
a
little
bit
and
that
means
kind
of
a
mid
level
of
discussion.
That's
that's!
That's
a
great
one
of
the
helm!
Authoress
creators
are
here
with
us
which
are
great
news
because
then
I
it
will
be
less
chance
of
embarrassing
myself
and
for
the
couple
folks
that
never
heard
about
it
or
don't
have
enough
knowledge
about
it.
C
C
It
is
a
dependency
manager
for
kubernetes
and
it
solves
the
problem
that
is
described
here
so
before
helm
or
in
in-plane
kubernetes.
What
do
we
do?
How
do
we
deploy
anything
to
kubernetes?
We
find
the
young
for
EML
files
and
documentation,
but
usually
just
googling
it
and
stumble
upon,
and
then
we
copy
them,
but
we
paste
them
and
then
we
fix
intense
and
and
and
then
we
repeat
so-
that's
kind
of
our
life,
a
deploying
stuff
into
kubernetes,
and
that's
of
course,
a
very
annoying.
C
The
other
problem
is
I.
Have
this
is
like
a
normal
kubernetes
resource.
I
I
bet,
most
of
you
at
least
seen
it
at
least
once,
and
this
is
how
it
looks
like
and
note
how
you
have
the
version
here,
embedded
in
there
spec
of
our
kind.
That's
our
daughter,
a
doctor
tag,
that's
our
version
of
our
application.
C
So
now
we
decide
to
build
a
new
one,
so
we
do
docker
build
and
we
target
with
the
version
1.1,
and
the
last
thing
that
we
need
to
do
is
to
update
the
version
inside
our
kubernetes
deployment
Yunel
file.
There
are
a
couple
of
ways
to
do
it.
One
of
them
is
running
the
set
command
and
well
that's
you
know:
we've
seen
better
commands
in
our
life,
the
other
where
the
other
option
is
would
be
just
use
latest,
and
you
know
that's
that's
a
great
idea.
C
C
Sorry,
how
the
hell
do
ab
need
my
descriptors
once
and
have
a
new
version,
and
it
does
it
by
a
encapsulate
packages
of
pro
Nettie's
deployments,
and
I
have
here
an
example
of
one
of
our
products.
Jeffro
x-ray-
and
you
know
bunch
of
micro
services
and
stuff
like
service
for
for
analysis
and
event,
ingress
a
indexer
and
storage
server,
persistence
layer,
all
this
stuff
each
and
every
one
of
them
is
a
kubernetes
deployment.
It's
a
it's
a
bunch
of
a
bunch
of
containers,
wrapped
up
in
kubernetes
deployment
so
and
before.
He'll
me.
C
If
I
wanted
to
a
deploy,
X
ray
on
one
of
my
machines,
I
had
to
deploy
all
those
and
actually
know
which
versions
will
work
with
with
which
additional
versions,
etc,
etc.
But
once
I
have
a
help
chart
I
can
encapsulate
all
those
deployments
into
one
chart.
I
just
say:
X
ray
and
surely
knows
which
deployments
it
consists
of
and
that's
a
big
deal.
Another
very
important
benefit
off
of
helm
is
a
templating
engine
for
descriptor
files.
So
remember
in
how
we
are
hard-coded
the
version
and
then
didn't
find
a
good
way
to
update
it.
C
All
this
is
gone
whose
helm
we
can
use
a
templates
and
then
provide
values
into
it,
and
we
can
provide
values
from
multiple
sources
and
they
take
precedence
one
over
another.
So
we
can
have
a
values
file
that
will
have
kind
of
defaults
and
staff
that
we
don't
want
to
update
in
the
runtime
or
we
can
have
dynamic
versions
that
will
come
from
our
common
line
or
from
M
variables,
and
they
will
override
the
default
versions
that
we
provide
so.
C
We
spoke
about
in
in
the
helm
registry
and
we
see
that
it's
actually
just
an
archive
and
in
which
we
have
predefined
directories
like
the
templates
and
which
have
bunch
of
templates
like
the
deployment
one,
the
one
that
I
showed
you
earlier
in
and
then
metadata
like
the
charity
arm,
the
readme
file
and
Jenkins
filing
in
is,
if
needed
and
and
then
and
then
values-
and
this
is
pretty
much
it-
it's
very,
very
simple.
So
it
provides
us
with
with
a
very
simple
way
to
get
started,
because
how
simple
it
is!
C
C
C
It
sounds
like
a
very
writing
good
idea,
but
then
it
actually
requires
you
to
provide
a
version
of
the
application
each
time
you
want
to
to
deploy
something
using
chart,
because
if
you
want
just
to
deploy
something
like
we
did
in
the
X,
for
example,
and
you
what
you
want
to
install
x-ray
and
you
do
he'll
install
x-ray
and
don't
provide
a
version,
the
version
will
be
taken
from
the
values
descriptor
and
the
values.
Descriptor
and,
as
you
remember,
is
a
part
of
the
chart
itself.
C
So,
although
we
can
use
our
template
to
have
a
one
chart
version
to
serve
multiple
image
versions
in
our
deployment,
it's
actually
not
very
uncommon
to
have
a
relationship
of
one
to
one.
When
you
have
one
chart
that
has
a
one
container
with
the
tag,
one
image
with
the
tag-
and
you
still
use
templates.
But
then
the
value
is
hard-coded
in
the
value
document
which
descriptor,
which
is
a
part
of
the
same
hem.
C
So
this
is
on
the
descriptor
and
the
chart
as
a
package
level
talking
a
little
bit
about
the
architecture
of
helm
itself.
Helm.
Not
only
is
a
package
manager
that
can
download
resolve
our
search
and
packages
for
you.
It
also
takes
care
of
a
deployment
of
those
helm
charts
into
your
kubernetes
cluster.
C
It's
like
the
steering
part
of
the
boat,
so
I
guess
our
word
of
analogies
with
boats
continued
here.
We
have
a
tiller
that
will
make
the
install
of
the
of
the
helm
chart
inside
your
kubernetes
cluster
if
the
tiller
will
communicate
with
your
cube
control
command
and
will
make
sure
that
all
the
deployments
that
are
part
of
this
helm
chart
are
actually
installed
into
a
your
kubernetes
cluster
right.
So
two
parts,
the
client,
local
child
development.
C
C
Comparing
to
what
is
found
in
the
repository
by
using
their
index
that
was
downloaded
previously
and
a
helm.
Repo
actually
provides
you
a
command
for
working
with
repositories
specifying
which
repository
a
chute,
helm,
client
interact
with
when
it
searches,
downloads,
etc,
etcetera
and
and
speaking
about
repositories.
C
Yeah.
The
reason
official
repository,
cube,
ops,
comm,
you
go
there
and
you
can
see
in
the
the
charts
that
are
that
are
available.
There
are
here
in
the
official
one,
that's
pretty
old,
I
think
screenshot.
A
couple
of
weeks
ago,
a
160,
charts
and
artifactory
is
right
here
on
the
first
line,
so
I
didn't
have
to
scroll
down
to
take
a
screenshot,
it's
so
good
and
there
are
also
a
yeast
on
the
Cooper
net
helm,
a
github
repo
as
well.
C
So
that's
a
visual
repository,
but
as
normally
with
the
repositories
and
registers,
you
really
want
to
have
the
local
one.
Both
in
terms
of
you
know,
we
never
can
trust
the
internet,
so
you
want
to
local
cache
and
also
you
want
to
write
your
own
help,
charts
which
are
not
public
and
you
are
not
going
to
deploy
them
to
do
repository.
So
you
should.
You
should
use
the
local
repository
for
them
as
well
and
extremely
simple.
C
Artifacts
repositories
like
Jeff,
regatta,
factory
or
others.
Those
guys
pay
me
money.
So
this
is
why
they're
called
by
name
and
and
artifactory,
for
example,
is
a
kubernetes
registry
which
supports
both
helm,
contain
and
everything
inside
of
containers
as
well.
There
are
others
which
provide
an
out-of-the-box
helm
repository
as
well,
so
these
parts
kind
of
covers
the
introduction
to
helm
and
again
I
hope,
people
who
never
heard
about
it
got
their
idea
what
it
is,
and
people
who
are
pros
and
power
users
didn't
get
too
bored
anyway.
C
Sorry,
they
even
go
a
dependency
managers.
I
think
he
worked
on
on
go
get
if
I
remember
correctly
before
he
started.
He
wrote
sorry
about
it.
This
hilarious
blog
post
on
medium
and
which
is
called
so
you
want
to
write
a
package
manager
should
go
ahead
and
Google
that
and
and
write
it.
Basically,
you
walk
out
this
more
this
morning,
roll
out
of
bed
and
felt
you
know
what
I
don't
have
enough
misery
and
suffering
in
my
life.
C
I
know
what
to
do
a
right
language
package
manager
he's
talking
about
language,
it's
it's
absolutely
the
same
for
for
any
package
manager
at
all.
A
package
management
is
awful.
You
should
quit
right
now.
Peggy
demands
that
is
nasty
domain,
really
nasty
on
a
surface.
It
seems
like
a
purely
technical
problem,
a
but
people
approach,
but
but
but
there
are
people
that
that
actually
make
it
and
make
it
worse.
Software
is
terrible.
People
are
terrible.
There
are
too
many
different
scenarios.
Nothing
will
really
work
for
sure.
C
It's
provable
that
nothing
will
really
work
for
sure
and
allies
are
meaningless,
perturbations
of
treatment,
workers
of
house
and
entropy,
and-
and
you
get
into
this
realization
once
you
work
on
package
manager
and
that's
actually
the
case
with
with
any
of
them.
The
reason
why
I'm
talking
about
it
is
that
I,
we
are
dealing
Jeff
rock
with
specs
managers
for
the
last
decade,
and
we
saw
them
all.
C
We
know
how
horrible
any
package
manager
in
the
world
is,
and
they
kind
of
fall
into
one
of
the
seventh
at
least
one
or
more
usually
more
of
the
seven
suddenly
seeing
the
scenes
of
package
managers.
The
one
is
over
architecture.
There
are
very,
very
sophisticated
and
very
complicated
package
managers
that
fall
on
short
on
doing
the
simplest
things
or
they're
just
too
complicated
to
work
with
another
kind
of
disadvantage
of
some
package
managers
are,
they
are
not
thinking
when
they
are
created
of
enterprise
scenarios
and
we
end
up
with
pretty
basic
stuff
missing
completely.
C
For
example,
there
are
package
managers
that
just
don't
have
any
way
to
have
a
private
repository,
because
everything
should
be
open
source.
Everything
should
be
on
github,
and
if
it's
not,
we
don't
care
about
it
and
that's
a
horrible
approach
and
another
Racine
is
having
downloadable
index.
We're
going
to
talk
about
why
downloadables
index
have
more
downsides
than
actually
pros
and
cross-site
dependency
resolution.
C
Loopholes
is
the
way
that,
when
you
as
an
enterprise,
try
to
a
control
where
the
dependencies
come
from,
actually
every
developer
can
override
it
and
bring
whatever
dependencies
they
like
from
whatever
place
in
the
world.
They
have
in
our
authentication.
Don'trun
done
wrong
when
you
have
a
central
repository
full
of
packages,
that
you
have
no
idea
who
actually
wrote
them
and
that's
of
course,
can
be
very,
very
dangerous
version
management
or
more
precisely,
the
lack
of
their
off
their
our
package.
C
So
and
every
package
mentioned
the
world
suffer
from
some
combination
of
those
sins
and
the
ones
that
will
like
the
most
like
helm.
We
are
actually
trying
to
help
and
cure
them
from
those
from
those
diseases
and
with
helm
and
one
of
the
examples
of
our
contribution
during
the
helm
summit
and
couple
of
months
ago
by
now
yeah
February,
and
we
have
our
own
Ankush
our
solution
architect,
giving
some
ideas
of
how
to
fight
some
of
those
problems.
C
It
was
very
well
accepted.
There
are
results
that
I'm
going
to
share
with
you
now
and
by
the
way,
if
you
want
to
work
on
stuff
like
helping
help,
get
better
or
whatever
it
is
we're
hiring
like
crazy.
So
you
worth
taking
a
look
for,
and-
and
this
is
a
lot
of
things
helm
did
right
so,
as
you
can
see,
five
of
the
seven
deadly
sins
do
not
present
in
in
helm.
For
example,
the
central
registry
is
in
in
buckets
on
Google
cloud
platform.
That's
the
right
way
to
place
it.
C
You
can
configure
which
repositories
you
want
to
use
and
proxy
helm
packages.
This
is
also
very
good
and
helm
requires
versions
on
the
dependencies.
So
this
is
fine.
I'll
sent
ocation
is
done
by
public
profile,
usually
github,
also
very
good,
a
good
choice.
You
cannot
provide
a
link
to
any
dependency
inside
your
helm
tops.
Instead,
you
provide
names
which
guarantee
is
that
they
will
come
from
a
trusted
source
and,
as
I
mentioned
over
architecture
is
definitely
not
one
of
a
helm.
C
Since
it's
a
it's
simple
and
that's
a
good
thing,
there
are
two
aspects
that
can
be
improved.
One
is
Enterprise
scenarios
we're
going
to
talk
about
that
and
the
other
is
having
a
downloadable
index
and
which
were
are
going
to
talk
as
well
so
Enterprise
scenarios.
What
we
had
in
mind
is
what
what
do
you
need?
Having
an
in-house
registry
check?
We
spoke
about
that
using
the
authentication
and
authorization.
That's
because
enterprises
in
actually
want
to
have
control
of
who
can
download
what
or
who
can
deploy.
C
C
Cn
CF
ambassador
I'm,
not
sure
people
are
celebrating
all
day
long
right,
M
segmentation
per
object
per
sorry
per
organization
per
project
per
team
with
central
man
and
join
so
we'll
probably
have
some
administers
administrators
of
our
a
organization
wide
or
company-wide
helm
repository,
and
then
we
need
to
segment
it
per
different
levels.
This
is
something
very
important
as
well
and
promotion
pipelines.
So
today
we
are
not
going
to
talk
about
the
later
to
because
there
are
just
features
of
the
repository
itself.
The
factory
supports
both
not
the
topic
of
today's
discussion.
C
Instead
we're
going
to
talk
about
the
second
topic,
which
is
authentication
and
authorization.
Well,
it's
it's
a
very
simple
story
with
it
a
helm
didn't
have
it
and
now
it
has
it,
and
we
submitted
a
pull
request
to
support
authentication,
a
both
base
and
SSL,
and
it
was
accepted
two
weeks
ago
exactly
two
weeks
ago,
14
days
ago,
and
next
version
of
helm
will
include
the
support
for
authentication
which
and
any
register
repository
can
benefit,
not
only
a
artifactory
of
course.
C
So
that's
one
thing
and
this
kind
of
covers
the
topics
of
having
helm,
Enterprise
ready.
The
other
one
is
scale
now
when
we
have
it
Enterprise
ready
and
we
deploy
it
on
the
enterprise.
Usually
the
load
increases
specially
in
in
our
biggest
customers.
And
now,
let's
talk
about
that,
the
topic
of
the
discussion
is
downloadable
index
good
orbit.
So
there
are
some
obvious
good
things
about
a
downloadable
index
stuff.
C
Like
simple
server
spoke
about
it,
you
calculate
the
index
on
the
client,
and
then
you
have
a
file
that
you
need
to
make
available
of
your
HTTP
server
and
you're
done.
Simple
server
is
a
very
advantage
and
actually
a
very
good
way
to
start
another.
Bad
fate
is
offline
search
which
I'm
not
quite
sure.
Why?
C
How
useful
it
is
because,
okay,
now
you
downloaded
your
your
index,
let's
pretend
it's
up
to
date.
Again,
we're
talking
about
Hell
being
crazy
popular
there
are
tons
of
new
packages
and
tons
of
new
charts
being
deployed.
Every
day
index
will
become
obsolete
very
very
fast.
If
you
are
flying,
but
let's
say
you
just
downloaded
the
index,
you
cut
your
connection
and
then
you
can
search
fine.
C
The
search
load
of
the
server
to
spare
computer
power
because
the
searches
are
then
performed
locally
on
the
client
machines
and
I
guess
that
was
the
reason
why
the
whole
idea
of
downloadable
index
was
invented
in
the
60s
and
the
70s
or
whenever
the
first
package
manager'
felt
of
this
great
idea,
but
well
I,
don't
know
it
holds
today.
The
server
will
be
powerful
enough
to
perform
searches
for
everybody,
and
if
we
don't
know
how
to
do
it,
we
can
ask
Google
they
are
they
manage.
This
problem
will
really
well
so
I.
C
Don't
think
that
offloading
the
search
should
be
a
big,
a
big
advantage.
On
the
disadvantages
front.
We
have
a
of
course
obsolete.
A
index
and
stuff
is
getting
deployed
to
the
server
all
the
time
and
my
search
becomes
obsolete
very
fast
and
then,
more
importantly,
is
that
index
becomes
a
bottleneck
specially
if
we
designed
not
in
a
scalable
way
and
and
the
problem
with
helm,
is
that
index
is
a
bottleneck.
C
So
we
have
here
some
benchmarking
that
we
did
and
that's
a
correlation
between
number
of
charts
that
exist
in
there
in
the
search
in
the
Indy
index
on
the
server
and
the
memory
consumption.
So
you
can
see
here
that
and
when
we
deploy
a
reasonable,
reasonably
big
amount
of
of
charts,
what
it
is
that
120,000
charts
we
actually
go
through
the
roof
in
our
in
our
memory.
Consumption
and
here's,
where
you
ask,
are
you:
are
you
nuts
and
insane?
How
will
we
get
to
a
hundred
twenty
thousand
of
charms
of
charts?
C
If
we
want
a
seamless
helm,
install
command,
we
will
have
to
hard
code
the
version
of
everything
inside
our
chart
into
the
virgin's
channel,
which
is
a
part
of
the
chart,
and
that
means
that
every
change
in
any
beat
inside
one
of
the
packages
that
go
inside
one
any
of
our
containers
that
are
part
of
our
helm
chart
generates
a
new
version
of
chart.
So,
yes,
we
will
have
a
lot
of
charts
through
the
roof
and
especially
if
we
are
considering
now
its
central
repository
and
not
an
in-house
repository.
C
This
is
going
to
be
out
of
hand
very
very
quickly
and,
of
course,
you
can
consider
use
cases
such
as
interim
registry
and
maven
central.
The
number
of
packages
in
those
popular
central
repositories
are
huge
and
we
of
course
predict
a
Hjelm
repository
to
be
one
of
the
big
ones.
So
yeah,
it's
not
gonna
scale.
Now
the
question
is:
how
can
we
fix
it?
There
are
two
kinds
of
Fix.
There
is
very
quick
one
and
it
kind
of
helps
and
that's
we
can
compress
the
index
in
transit.
C
Frankly,
this
is
so
easy
to
deploy
I'm
a
little
bit
surprised.
It's
not
done
yet
and
it
will
fix
some
of
the
issues,
namely,
of
course,
the
bandwidth
and
the
latency
of
downloading
darling
the
central
index,
but
it
won't
solve
the
problem
of
managing
those
huge
index
files
both
on
the
server
and
on
the
cloud.
So
the
most
scalable
solution
will
be
distributing
the
index.
Now,
let's
take
a
look
at
the
index
and
try
to
figure
out
how
we
what
we
can
do
in
order
to
build
it
better.
C
So
that's
a
snippet
from
from
actual
hell
rip
or
index,
and
you
can
see
here
that
what
we
have
are
three
different
parts
in
one
index.
So
we
have
an
entry
per
application
in
the
in
this
example
artifactory,
and
then
we
have
a
lot
of
metadata,
which
actually
relates
to
a
certain
version
of
this
help
chart.
In
our
case,
there
will
be
a
version.
C
Six
point,
two
point:
five
of
the
artifact
helm
chat,
which
relates
to
an
application
version
or
factor
version
5.83
and
those
are
getting
repeated
for
each
and
every
different
version
of
our
helm.
Chart
so
below
we'll
have
a
lot
of
entries
refer
to
artifactory
as
well,
and
some
of
the
information
will
repeat
itself
in
two
inch
and
every
one
so,
for
example,
staff
like
description,
so
you
can
see
here,
description,
Universal
repository
manager
and
then
again,
Universal
requester
manager.
Why?
Because
the
description
won't
change
over
versions.
C
C
There
is
an
information,
actually
metadata,
not
an
index
pair,
an
application
stuff
that
you
were
not
know
about
artifact
or
help
chart
and
the
description,
the
home,
the
home
URL,
the
sources
URL,
the
maintenance,
except
the
icon-
probably
not
going
to
change
this
kind
of
stuff,
and
there
is
another
set
of
metadata,
also
not
an
index
and
metadata
about
the
particular
version
and
this
stuff
like
digest,
obviously,
and
the
URLs,
where
it
can
be
downloaded.
This
change
by
the
version
right.
C
C
What
is
the
digest
and
where
should
we
download
it
from
in
this
way
we
have
a
distributed
index
so
for
the
search
all
you
need
to
download
is
this
main
end
index,
which
will
be
a
fraction
of
what
it
is
today.
It
will
only
list
the
entries
for
the
apps
and
if
you
have
want
to
get
info
about
them
up,
you
will
run
a
command
like
helm
info
artifactory.
You
will
actually
download
the
second
part,
which
is
the
information
about
the
app
and
the
available
versions
of
it.
C
And
then,
if
you
want
to
install
a
particular
app,
you
will
actually
fetch
the
descript
or
for
the
particular
app
which
will
have
staff
like
ok.
Where
do
I
download
the
binary
of
this
app
from
and
and
that
that
solves
the
the
problem
that
that
we
spoke
about
now?
It
introduces
a
new
requirement
and
this
new
requirement
now
is
a
layout
inside
the
repository,
because
now,
when
we
have
three
different
types
of
index
and
metadata
files,
we
need
to
know
where
to
find
them.
C
So
this
very
nice
and
simple
layout,
we
have
a
root
directory
and
just
bunch
of
these
pouches
add
files
and
one
index
won't
hold
anymore.
So
that
means
that
we
will
need
a
layout
like
repo
in
which
will
have
the
top-level
index
and
then
a
directory
for
our
app.
It
will
be
called
artifactory
in
our
case,
and
then
we
will
have
our
application
descriptor
and
then
directories
where
each
and
every
version
in
which
we
will
have
the
version
descriptor
and
the
binary
itself.
That
is
our
helm
chart
for
this
particular
particular
versions.
C
The
downside
of
having
a
more
complicated
or
more
evolved,
structured
repository
or
layouts
is,
of
course,
that
it
complicates
the
push
command,
because
at
the
moment
there
are
no
push.
If
you
remember,
I
showed
you
the
list
of
a
helm
commands
there
is,
there
is
no
pushing
it
because
you
don't
need
to
you.
Just
do
a
curl
upload
or
with
with
this
post
HTTP
command,
and
you
upload
the
route
you
you
are
will
be
or
your
helm
to
the
root
of
the
repository
in
your
done.
C
But
when
you
have,
when
you
have
a
layout,
it
complicates
a
push,
because
you
need
to
know
the
internals,
the
implementation
details
of
this
layout
to
order
to
in
order
to
push
files
and
one
of
the
bail
examples
in
this
report.
Its
Debian
packages,
which
actually
do
have
a
structured
layout
repository
and
more
than
one
but
don't
have
any
push
built
into
the
into
the
client
into
an
object.
C
So
you
actually
need
to
figure
out
what
is
the
structure
of
the
layout,
which
is
the
correct
one
for
your
particular
use
case
and
then
do
the
curl
command
by
constructing
this
particular
layout.
We
don't
want
that.
We
want
to
encapsulate
the
details
of
the
layout
and
provide
a
push
command
to
our
a
to
our
users,
and
that
requires
adding
helm,
push
to
helm,
a
he'll
push
command
to
helm
and,
and
today,
as
of
today,
there
are
discussions
on
how
to
do
it
and
you
can
see
or
obviously
the
rationale
behind
it.
C
Several
urges
tremendous
support
to
helm
chart,
including
Jeff,
Roberts,
Factory
and
others
and
and
the
registries
are
asking
and
could
benefit
from
a
capacity
to
push
packages
from
the
helm,
client
and
that's
the
main
dropping
force
is
that
if
we're
going
to
do
something
with
the
layout,
we
need
the
ability
to
hide
the
complications
of
the
layout
into
this
command.
So
this
is
actually
it
what's
going
on
now,
that's
proposal.
It's
on
Helen's
github.
If
you
want
to
participate,
you
can
go
ahead
and
participate
in
discussion.
C
We
are
going
to
get
into
implementation
details
later
later,
but
there
is
the
implementation
is,
is
pretty
straightforward.
We
will
have
a
default
HTTP
push
that
will
respect
the
layout
and
we'll
be
able
to
change
the
layout
once
we
progress
with
the
index
there
centralization
that
that
we
propose
another
very
good.
Exactly
another,
very
good
reason
to
absolutely
push
is
the
ability
to
transit
from
a
central
index
to
distributed
index
without
disturbing
the
users.
C
We
can
encapsulate
the
knowledge
that
the
layout
shifted
and
support
the
old
layout
for
a
while
all
because
we
will
have
our
push
encapsulated
into
the
helm
command
so-
and
this
is
all
those
are,
the
three
topics
that
we
enjoy
frog
and
hopefully
help
helm
community
to
improve
and
actually
get
rid
of
all
the
deadly
sins
and
of
package
managers.
I
really
hope
that
one
day
he'll
will
be
the
example
that
I
will
give.
C
When
I
speak
about
how
horrible
package
managers
are
and
I
will
give
a
contour
example
that
we
do
have
a
good
package
manager
which
is
called
helm,
the
gaps
are
not
so
big,
and
hopefully
that
will
happen
before
we
are
getting.
We
will
get
to
your
to
answer
your
some
of
your
questions
and
just
a
shameless
plug
of
our
user
conference
that
comes
opponents
in
a
less
than
two
months
in
the
middle
of
May
and
napa
valley
people.
I
don't
know
if
I
need
to
add
anything
else.
C
Conference
was
out,
stay
in
a
resort,
a
lot
of
wine,
and
I
don't
know
if
any
of
the
content
even
matters
after
what
I
just
said.
But
if
it
does,
there
is
tons
of
CN
CF,
related
content
swamp
up
and
we're
going
to
talk
about
a
gazillion
flavors
of
kubernetes,
on
openshift
on
Azure
and
on
AWS.
We're
going
to
talk
about
interesting
integrations
with
rancher
with
other
platforms.
C
Of
course,
a
lot
of
helm,
building
pipeline,
throughs
Helms,
the
ICD
and
working
with
Usher,
and
and
actually
our
very
own,
lessons
learned
from
working
with
kubernetes
in
helm,
because
we
have
pretty
interesting
use
cases
to
share
with
you
as
well,
so
with
that
shameless
plug.
Thank
you
very
much
and
a
real
back
to
you
it's
time
to
take
some
questions
again.
C
A
C
Of
course,
that's
that's
a
great
question
and,
and
that's
actually
kind
of
related
but
unrelated
they're
related,
because
they
are
both
dependency
managers
for
eventually
container
of
technologies,
kubernetes,
and
all
that
the
difference.
Docker
registry
is
a
registry
for
docker
package
management.
It
holds
a
daughter,
couldn't
docker
images
that
we
instantiate
containers
for
either
for
kubernetes
or
for
any
other
reason,
although
by
today
there
are
not
much
other
reasons,
but
but
it
only
deals
with
docker
images.
Now
helm
repository
on
the
other
side
is
the
same
idea.
C
It's
a
repository
for
a
package
manager
and
the
package
manager
in
our
example
is
helm.
So
there
are
different
structure.
There
are
different
index.
There
is
a
different
artifact
type
dock.
Your
image
vs.
helm
chart.
Now,
of
course,
it
would
be
beneficial
to
have
both
of
them
in
the
same
repository,
because
then,
for
example,
you
can
set
up
metadata
and
generally
you
don't
want
to
manage
multiple
repositories
and
that's
exactly
where
Jeff
for
craft
Factory
and
alike
can
help
I
hope
that
clarifies
okay.
A
C
Yes,
yes,
yes,
so
let's
that
I
try
to
explain
it,
but
probably
didn't
do
a
very
good
job.
Since
there
are
questions-
and
so
you
remember
this-
this
is
a
kubernetes
resource
which
actually
hard
codes,
the
version
of
our
image
and
that
basically
means
that
every
time
I
have
a
new
version
of
my
docker
app
I
need
to
have
a
new
version
of
my
kubernetes
resource
and
that's
a
bad
thing
because
well
it's
not
a
bad
thing.
C
It
is
what
it
is,
but
it
kind
of
limits
me
to
one
to
one
relationship
between
docker
image
and
coburn
ancestors.
Now
we
step
into
helm-
and
we
say-
hey
but
he'll-
actually
help
us
with
that,
because
it
has
all
those
wonderful
templating
right.
So
what
it
looks
like
is
that
I
can
use
this
template
for
serving
multiple,
a
multiple
kubernetes
resources,
which
essentially
means
multiple
docker,
doggett
images
right
so
far,
so
good,
that's
exactly
what
it
means
to
solve.
C
So,
for
example,
if
I
have
here
my
daughter,
app
version,
one
I
can
use
the
same
dock
at
the
same
helm
chart
to
serve
my
daugher
app
version
1.1.
But
if
I
want
to
keep
this
a
template
here,
I
need
to
provide
value
in
some
point
of
time.
I
can
do
it.
When
I
do
my
my
chart
my
chart,
my
Hellmann's
document
when
I
install
my
my
my
charts,
but
then
I
need
to
specify
version.
I
will
run
the
same.
C
The
same
kubernetes,
the
same
helm
chart
one
time
with
docker
with
version
1.0
and
the
other,
with
version
1.1
and
I
actually
reuse.
My
daugher
chart
for
two
different
versions
of
docker
image.
The
problem
comes
is
when
I
don't
want
to
force
my
users
to
specify
a
version
every
time
they
run
a
Hellmann's
document.
That
means
that
the
version
should
come
from
somewhere
and
it
comes
from
this
values
descriptor
that
I
have
in
values.
Descriptor
I
will
refer
to
this
dr.
C
The
thing
is
that
the
values
document
is
a
part
of
the
chart
of
the
chart
and
it's
packed
with
the
chart
and
has
a
version
of
its
own,
which
practically
means
that
every
time
I
want
to
change
my
daugher
image
version
and
I
want
to
change
my
kubernetes
descriptor
version.
I
have
repack
it
because
I
changed
the
value
file
and
I
will
have
a
new
version
of
helm
chart.
So
what
we
end
up
with
is
practically
if
we
don't
want
to
specify
a
version.
C
A
Leave
so
I'll
wait
for
follow.
Ups,
we're
running
a
little
short
on
times.
You
know
we
might
run
over
a
little
bit.
People
want
to
hang
around
I
do
want
to
ask
the
question
of
a
desmond
before
digging
a
little
bit
deeper
into
the
topic.
I
want
to
shift
a
little
bit
desmond
asked.
What
do
you
recommend
for
companies
that
need
to
install
helm
customer
sites
right
and
there
and
when
there
is
limited
internet
access
on
that
site,
yeah
she's,
a
company?
A
C
C
So
so
there
are
a
couple
of
aspects
in
managing
values:
file
the
first
owner.
On
the
first
level,
the
management
of
llamó
files
of
value
files
is
having
them
inside
the
charts
right.
So
it's
managed.
As
we
mentioned,
we
don't
manage
them
separately.
They
are
part
of
our
a
of
our
chart
and
their
version
with
the
chart
itself
and
the
values
that
are
provided
there
will
be.
The
default
will
be
kind
of
a
production
value.
What
we
actually
want.
We
can
have
different
sets
of
these
value
files
based
on
our
environments.
C
For
example,
we
want
different
set
of
values
for
our
staging
different
set
of
values,
for
our
testing,
etc,
etc,
and
those
can
be
used
when
the
when
the
helm,
charts
are
deployed
to
those
different
environments
in
the
easiest
way
to
do.
It
is
just
having
them
in
different
repositories
in
your
repository
manager.
So
again,
if
you
using
something
like
a
factory,
you
will
have
different
repositories
for
a
different
stages.
C
Yes,
so
that
the
applet
of
the
image
version
is
very,
very
simple:
you
basically
change
the
value
in
the
values
you
know,
and
then
you
pack,
a
new
version
of
chart
with
this
new
values
file
and
then
you
deploy
to
your
registry
and
you
you've
got
yourself
a
new
version
of
the
help
chart
which
will
eventually
deploy
and
you
a
write
version.
New
version
of
your
of
your
doctor
container
image
should
I
say
it's
basically
changing
the
value
in
the
repacking.
It
yep
yeah.
A
That
brings
us
to
the
end
of
today's
webinar.
Thank
you
all
who
attended
check
your
email,
we're
gonna,
be
sending
you
a
link
to
the
video.
This
was
recorded
along
with
link
to
Luke's
deck,
so
thank
you
all
very
much
for
attending
Beru.
Thank
you
for
presenting
and
thanks
to
the
CNCs
and
Katelyn
in
the
background
for
helping
facilitate
all
this
I
hope
to
see
you
again
in
our
next
one
and
thanks
again
thank.