►
From YouTube: Webinar: Making the Most of Helm 3
Description
Building upon the success of Helm 2, Helm 3 has recently been released and the server-side component, Tiller, is finally gone (yay)! Writing Kubernetes files from the ground-up is an intense process, but not to worry — Helm has you covered. In this webinar, you will learn about what Helm is, the changes from Helm 2 to Helm 3, and how you can use it for easy deployments of your Kubernetes applications.
Presenters:
Dan Garfield, Full-Stack Engineer @Codefresh
Anna Baker, Software Engineer/Technical Writer and DevOps Evangelist @Codefresh
A
A
A
B
A
Few
housekeeping
items
before
we
get
started
during
the
webinar
you're
not
able
to
talk
as
an
attendee.
There
isn't
Q&A
box
at
the
bottom
of
your
screen.
Please
feel
free
to
drop
your
questions
in
there
and
we'll
get
to
as
many
as
we
can
at
the
end
of
the
webinar.
This
is
an
official
CN,
CF
webinar
and,
as
such,
it's
subject
to
the
CN
CF
code
of
conduct.
A
B
So
we
are
gonna
talk
about
making
the
most
of
home
3
and
we're
gonna
go
through
a
number
of
things.
Just
an
introduce
myself.
My
name
is
Dan
Garfield
I
am
on
Twitter
at
today
was
awesome.
You
can
follow
me
for
four
fantastic
tweets
of
all
kinds
and
I'm.
The
chief
technology
evangelist
for
code,
fresh
Anna,
hi.
C
B
Anna
joined
us
from
Red
Hat's,
pretty
badass
engineer,
that's
been
on
our
team
for
a
few
months
now
so
excited
to
be
presenting
with
her
for
the
first
time
just
to
kind
of
set
the
stage
for
why
were
doing
this,
we're
from
code
fresh,
which
is
a
CI
CD
solution.
That's
focused
basically
the
default
CI
CD
for
people
using
kubernetes,
and
we
have
had
for
a
long
time
people
on
staff
who
were
home
contributors.
B
We've
done
a
lot
of
work
to
contribute
to
helm
as
a
company
and
a
ton
of
our
users
use
helm
every
day.
So
it's
really
critical
for
us
to
get
the
support
right
and
have
great
integrations
for
it.
So
this
is
kind
of
the
reason
why
we're
so
invested
in
home
and
why
we're
so
engaged
with
them
and
with
that
we'll
get
right
into
the
agenda.
B
We're
gonna
go
through
just
an
overview
of
helm
for
those
that
that
might
not
be
super
familiar
with
it
and
then
we'll
go
into
migration.
What's
new
and
getting
some
demos
and
first
off.
This
is
actually
perfect
timing
because
helm
just
graduated
from
the
CNS
yep.
It's
now
a
graduated
project
as
of
last
week,
so
notice
that
there
was
an
intense
amount
of
interest
in
this
webinar
today,
just
because
this
is
now
an
officially
graduated
project
from
the
CNC
F.
B
For
those
of
you
that
don't
know
the
criteria,
one
of
the
really
critical
things
I
think
the
one
that
people
are
most
interested
in
is
that
that
means
that
helm
has
passed
an
independent
third-party
security
on
it.
So
it
is
considered
a
secure
production,
ready
solution,
and
it
also
requires
most
of
the
technical,
Oversight
Committee
to
a
super
majority,
not
just
a
majority.
B
The
technical
oversight
committee
of
the
CNC
at
all
has
to
vote
and
agree,
and
basically
the
idea
behind
graduated
is
that
everything's
been
done
to
make
this
project
ready
for
the
majority
of
people
to
use
it.
So
if
you're
not
familiar
with
crossing
the
chasm.
Basically,
the
idea
is
that
there's
this
ramp
up
in
a
product-
and
you
have
this
early
adopters
group
and
then
you
get
the
early
majority
of
people
and
then
graduated
is
meant
to
symbolize.
Hey,
it's
now
ready
for
everybody
to
use.
B
So
that's
that's
wonderful,
and
that
means
I
expect
we're
gonna
see
a
lot
more
adoption.
I've
noticed
that
you
know.
Helm
too,
which
has
been
out
previously,
has
had
a
pretty
diverse
group
set
of
adoption.
There
were
a
lot
of
people
opposed
to
adopting
helm
too
because
of
tiller,
which
we'll
get
into
and
now
with
helm.
Three
the
brakes
are
off
everybody's
welcome
to
jump
into
it.
B
B
So
you
can
do
things
like
helm,
install
and
then
whatever
packages,
and
there
are
an
enormous
number
of
packages
out
there.
Hundreds
of
thousands
of
packages
that
you
can
use
and
they're
they're
very,
very
use
is
very
useful
in
this
way,
because
you
can
actually
use
packages
as
dependencies.
You
can
say:
I've
got
my
helm
tart
and
it
relies
on
this
public
health
chart
and
it
will.
It
will
pull
it
in
for
you
and
it's
all
those
dependencies
on
the
cluster
and
you
can
configure
values
and
reasonable
modifications
to
that.
B
So
the
the
reasons
why
people
use
helm
there
there
are
really
a
couple
of
number
one.
You
have
the
ability
to
actually
keep
track
of
all
of
the
revisions
of
what's
been
deployed
to
your
cluster
and
you
can
do
roll
backs.
So
that's
really
useful.
I
know
a
lot
of
people
are
living
in
the
get-ups
world
and
I.
Think
that
that's
the
correct
choice,
people
should
be
doing
get
ops.
However,
sometimes
you
end
up
in
situations
where
your
your
kit
might
not
be
in
a
state
where
it's
easy
to
roll
back.
B
You
might
have
problems
with
trying
to
merge
everything
and
get
it
all
figured
out
and
if
you're
looking
at
stuff
on
fire
and
you're,
having
downtime
having
the
ability
to
just
run
a
home
rollback
and
get
back
to
the
revision
that
you
were
previously
on,
while
you
work
out
the
gate
situation
incredibly
useful
also
integrates
really
well
with
the
ICD,
because
you
can
template
I
as
your
crew
manifests
and
just
add
in
inject
values
as
needed,
which
is
really
nice
one
other
thing
a
few
other
things
to
mention.
Obviously
installation
is
very
simple.
B
Upgrades
are
very
simple
and,
and
of
course,
dynamic
values
is
really
valuable,
especially
with
CI
CD,
where
you
might
be
building
an
image,
and
you
don't
know
what
the
tag
on
that
image
is
gonna,
be
before
you
before
you
start
it,
and
so,
instead
of
having
like
a
separate
pipeline,
you
can
actually
dynamically
create
an
image
and
inject
its
value
into
your
home.
Chart
that
you
deploy
for
something
that
is
repeatable
and
reliable.
B
Just
the
structure
of
a
helmet
art.
You
essentially
have
kubernetes
manifests
that
are
templatized
and
you
can
have
values
in
there
and
then
we
have
a
values
yamo
that
will
set
default
values
and
oftentimes.
I
so
what
I
do
personally
with
if
I'm
consuming
charts
from
from
the
stable
repositories
out
there,
all
lots
of
times
just
create
a
values
file
and
that's
it.
B
That's
the
only
code
that
I
maintain
and
then
I
can
just
consume
the
chart
that
exists
out
there
and
that's
very
convenient,
and
then
every
time
you
actually
install
a
chart,
it
actually
creates
a
release
on
the
cluster
that
keeps
your
record
of
everything
that
was
deployed
there.
So
using
these
is
pretty
easy.
You
can
install
a
helmet
art
from
a
repository
like
I
just
mentioned
in
the
example
a
second
ago
you
can
install
one
from
a
local
archive,
so
you
can
actually
package
the
whole
home
chart.
Put
it
onto
like
a
thumb.
B
B
Charts
and
helm
really
has
two
main
verbs
that
I
mentioned
rollback
earlier,
but
you
have
push
which
will
push
a
chart
to
a
home
chart
repository
so
that
you
can
reference
it
from
other
locations
or
you
can
just
install
that
chart
and
create
a
release
or
update
a
release.
So
new
and
helm
3,
the
biggest
piece
of
news
is
tiller,
is
gone
and
for
those
that
are
unfamiliar
with
tiller,
tiller
and
we'll
we'll
look
at
a
diagram
here
in
a
second
to
explain.
B
This
tiller
is
basically
this
component,
that
sort
of
had
superuser
privileges,
usually
on
your
cluster
and
could
actually
run
in
installations.
You
can
kind
of
think
of
it
like
a
prototype
for
operators.
So
if
you've
ever
used,
an
operator
tiller
was
sort
of
like
the
proto
operator
and
it
existed
before.
There
were
things
like
CR,
DS
or
operators
in
kubernetes,
and
so
because
of
that
it
had
some
architectural
limitations,
and
it
is
the
number
one
reason
that
people
did
not
adopt.
B
How
to
anybody
that
chose
not
to
adopt
home
to
their
chief
complaint
was
almost
always
tiller.
Now
there
were
ways
to
make
tiller
secure,
but
it
was
fairly
difficult,
so
tiller
being
gone,
means
there's
no
server-side
superuser
component
to
helm
anymore,
and
that
means
that
all
those
security
concerns
are
essentially
gone,
and
there
are
few
other
things
that
we'll
talk
about
to
resolve
that
another
one
is
in
helm
3.
B
We
also
have
3-way
merges
so
the
way
that
this
works
is
in
helm,
2
if
let's
say
that
I
had
installed
a
chart
and
then
I
had
made
a
modification
to
it.
So
I
I've
installed
a
chart.
That's
a
release
and
then
I
just
go
in
using.
Could
you
know
coop
control
and
I
changed
the
number
of
replicas
and
I
up
that?
B
Well,
if
in-home,
if
I
did
a
rollback
to
that
version,
it
would
see
that
there
was
no
difference
in
the
number
of
replicas
between
my
new
version
and
my
old
version,
and
it
wouldn't
update
it,
even
though
it
had
changed
in
live
State.
So
now
with
home
3,
it
actually
looks
at
the
live
State.
It
says.
Oh
actually,
this
thing
has
been
changed.
There's
been
drift
essentially,
since
the
configuration
has
been
applied,
so
we're
gonna
actually
change
those
things
back
previously
and
home.
B
You
had
to
use
a
force
command
to
essentially
treat
everything
as
letter,
recreate,
which
is
a
little
bit
messy
less-desirable.
So
that's
that's
another
great
news
for
home
3.
A
lot
of
people
were
interested
in
how
helm
3
was
going
to
use
Lua.
Now
that
is
still
planned,
but
it
has
not
happened.
There
is
no
Lua
in
helm
3.
Today
there
is
a
plan
eventually
to
have
some
programmatic
elements
in
helm,
3,
but
it's
probably
far
out
I.
Think
Anna.
You
were
guessing
that
it
would
probably
be
like
helm
for
before
we
saw.
B
I,
wouldn't
I
would
look
for
that
I
I'm
kind
of
bummed
about
it,
because
there
was
some
plugins
I
was
working.
Some
tooling
I
was
working
on
for
canary
releases
and
I
was
thinking.
Oh,
you
know
what
I'm
not
gonna
upgrade
this,
because
once
we
get
Lua
I'm
gonna
do
this
in
a
totally
different
way,
and
that
was
two
years
ago.
So
so
don't
do
what
I
did
just
that
just
get
to
work
and
work
with
what
you
got
let's
see,
and
then
there
are
also
some
changes
in
namespaces.
B
B
Using
secrets
for
storage
now,
instead
of
config
Maps,
so
if
you
think
about
the
architecture
of
home,
2
versus
home,
3
and
home
two
most
often
you
had
tiller
installed
in
specific
name
space,
usually
the
coop
system
namespace,
and
that
tiller
instance
usually
had
super
user
privileges.
Now
you
didn't
have
to
you
could
work
around
it.
B
You
could
do
a
tiller
per
namespace
that
it
was
a
lot
of
work
and
it
was
hard
to
maintain,
and
that
meant
you
had
to
if
you
had
like
10
namespaces,
that
you
wouldn't
think
you
had
10
tillers
and
you
had
to
upgrade
all
of
those
tillers
every
time
there
was
a
new
version
and
you
had
to
maintain
all
the
permissions
and
privileges
and
it
was
fairly
difficult
to
work
with.
So
that
was
a
bummer
and
then
you
had
your
applications
that
were
running
in
their
own
namespaces,
usually
or
you
know,
even
the
default
namespace.
B
But
all
the
information
that
tiller
consumed
was
stored
inside
of
config
maps.
Now
config
Maps
were
used
kind
of
because
of
the
limitations
of
kubernetes
at
the
time,
but
config
Maps
actually
aren't
a
great
place
to
store,
manifests
for
one
thing:
you
don't
have
encrypted
variables
in
there.
So
that
means
that
if
your
helm
chart
had
secrets
in
it,
it's
now
just
sitting
in
plain
text
in
a
config
map
in
cou
system.
So
that's
a
bummer
and
the
other
issue
is
that
config
maps
have
a
limitation
in
size
that
could
actually
cause
problems.
B
We
actually
developed
this
whole
caching
system
for
the
config
maps
so
that
we
could
handle
those
things,
so
that
was
that
was
a
bit
messy
so
in
home
3,
it's
much
simpler
because
we
have
CR
DS
what
we
do,
what
home
3
does.
Is
it
actually
stores
the
release
information
in
secrets
in
a
in
a
custom
secret,
a
CR
D?
B
So
if
you
look
at,
if
you
didn't
like
a
coupe,
sitio
get
secrets
and
you
put
a
field
separator
field,
selector
type
equals
how
about
sh
release
you
can
actually
see
this
is
this
is
for
my
personal
cluster,
so
you
can
see
what
kind
of
home
shirts
I've
been
consuming
lately,
but
you
can
actually
see
those
secrets
and
each
time
you
release
a
new
version.
It
creates
a
new
secret
and
then
helm
actually
does
some
work
to
by
default.
B
That
will
actually
trim
how
many
it
keeps
so
that
you
don't
get
overwhelmed
on
your
cluster
and
these
these
secrets,
this
this
CR
D
element,
actually
lives
inside
the
same
namespace
of
wherever
the
application
is,
which
means
it's
subject
to
just
the
same
permissions
that
you
use
to
create
that
application.
So
the
permissions
management
element
of
this
is
much
much
simpler.
The
security
element
of
it
is
much
much
simpler.
You
have
to
worry
about
tiller.
B
You
don't
have
to
do
all
that
and
I
noticed
somebody
just
asked:
what's
the
CID,
it's
a
custom
resource
definition,
so
it's
actually
the
main
way
that
kubernetes
in
kubernetes
that
you
create
extensible
objects.
So
the
release
object
for
helm.
3
is
essentially
a
custom
resource
definition
within
kubernetes,
and
so
that
resource
is
essentially
a
secret
with
a
few
different
components
on.
So
you
can
see
that
the
type
on
the
output
here
is
actually
a
helm
type
home
release
type.
B
Chart
and
they'll
have
a
a
minecraft
server
installed
on
their
cluster
same
thing,
for
my
sequel,
same
thing
for
these
other
elements
right
so
that
that
ability
to
distribute
your
software
as
a
package
for
others
to
consume
is
really
useful.
Now
a
lot
of
people
internally
don't
actually
distribute
the
packages
to
other
people
within
their
group.
Hey
I
made
I
made
a
home
truck
for
my
application.
I
don't
distribute
that
application.
I
just
deployed
maintain
it,
so
they
don't
necessarily
worry
about
the
distribution
aspects
of
helm.
Instead,
they're
really
focused
on
the
values
aspect.
B
C
C
C
C
B
B
Worth
mentioning
I
think
I
think
you
might
set
it
Anna,
but
having
that
having
help
and
three
as
the
command
is
something
that
I
see
a
lot
of
people
do
if
you're,
just
installing
the
helm,
command
line,
it'll
just
install
the
latest
version
which
will
be
held
3
and
it
was
helm,
so
Anna's
actually
created
an
alias
here
for
that
specific
binary.
Just
so
that
you
can
see
the
helm
to
client
and
the
helm,
3
client
on
the
same
machine.
So
no
that's
not
going
to
be
the
default
setup.
If
you're
still
in
install,
though.
C
C
C
C
C
C
C
C
B
C
B
Free
command
line
and
I
actually
haven't
seen
really
any
issues
I've
been
using
home
3
now
for
a
few
months
and
I
haven't
run
into
any
weird
situations
where,
like
something
didn't
work
like
everything,
has
been
working,
the
way
that
I
have
expected
it
to
and
I
actually
in
some
situations,
didn't
even
bother
to
think
I
could
get
rid
of
the
config
Maps
or
anything
on
hell,
3
for
home
2.
So
this
this
plugin
is
handy
and
there
is
a
link
to
it
in
the
webinar
slides.
B
So
so,
when
you
get
those
you'll
have
a
copy
of
it,
let's
see
and
then
we're
gonna
go
into
the
CI.
Cd
workflow
just
want
to
check
lots
of
good
questions
in
here,
so
we're
definitely
going
to
get
to
these,
but
from
a
from
a
CI
any
workflow
perspective.
What
we
most
commonly
see
is
people
will
have
their
git
repo,
where
they
make
a
change
that
goes
to
CI
CD,
which
builds
their
application.
B
That
builds
the
the
docker
image
it
pushes
that
docker
image
up
into
a
repository
and
then
we
packet,
we
create
a
help,
a
Koosh,
and
we
can
either
push
that
to
a
repo
and
deploy
that
or
we
can
deploy
that
helm
chart
directly
to
the
career
news
cluster.
Now,
why
would
you
do
one
versus
the
other?
Well,
if
you
push
it
to
a
repository,
then
that
means
it's
an
object
that
you
can
reference
from
anywhere.
B
You
can
just
say:
hey,
go
install
this
home
turn
done
right
and
it
also
allows
other
people
to
consume
that
helm,
chart
as
a
dependency
for
their
software
or
to
install
themselves
right
in
their
own
clusters.
Now,
if
you
don't
need
other
people
to
use
it,
and
you
don't
care
about
having
a
you
know
a
single
distribution
point
for
that,
then
you
don't
need
to
push
it
to
a
auditory.
It's.
B
I
built
my
docker
image,
I
I
deployed
the
helmet
chart
that
I
rendered
and
employed
the
help
target
in
a
single
step,
and
even
if
you
do
like
a
get
revision,
you
know
if
you,
if
you
robot,
get
to
a
specific
revision,
everything
should
just
work,
you
know,
so
you
can
still
drive,
you
can
still
be
totally
get
ups
oriented
with
helm
and
everything
is
just
going
to
be
derived
from
the
you
know
the
specific
get
revision.
So
that's
a
pretty
common
flow
and
I
think
Anna.
You've
got
a
demo
on
that
as
well.
C
While
it's
running
we'll
take
a
look
at
one,
that's
already
panned
run,
but
the
pipelines
and
code
fresh
run
from
left
to
right.
Each
step
is
composed
of
a
docker
image.
We
have
four
steps
here,
one
that
clones
the
main
repository,
one
that
builds
the
docker
image,
one
that
stores
the
chart
in
a
repository,
the
built-in
repository
that
comes
with
code
fresh
and
one
that
deploys
the
the
chart
to
kubernetes.
C
You
can
see
here,
I
mentioned
already.
We
have
a
clone
step,
a
build
step,
a
store
step,
but
the
cool
thing
here
is
I'm
using
two
steps
that
implement
the
helm
step
from
our
step
marketplace.
So
we
have
this
cool
marketplace
here
with
all
kinds
of
steps
available
with
different
integrations,
but
we'll
be
taking
a
look
at
the
home
step
and
if
you
look
at
the
source
code
for
this
for
any
of
our
steps,
they
are
all
just
docker
images.
So
you
can
easily
build
upon
these
or
create
your
own.
C
But
anyway,
the
let's
see
for
this
pipeline
I'll
be
using
the
push
action.
You
just
define
a
an
action,
push
install
or
off
for
auth.
You
can
run
your
own
custom
home
commands
and
then
installing
actually
deploys
it
to
kubernetes,
and
so
one
thing
two
things
to
note.
The
only
difference
here
to
make
this
two
to
three
ready.
Is
you
just
need
to
change
the
version
number
you
want
to
use
for
home
version
and
for
coupe
contexts.
C
C
Yeah,
but
that
was
using
code
fresh
to
deploy
it's
pretty
simple,
yeah
and.
C
B
So
with
that
old,
let's
say
you
can
take
the
screen
back
over
yep,
alright,
so
related
resources,
obviously
home
documentation
code
fresh,
has
a
lot
of
documentation
around
helm,
specifically
within
the
use
of
the
CI
CV
pipelines.
There's
actually
oh
I
should
have
put
the
link
in
here.
Put
it
in
the
turn
will
put
it
in
the
chat.
There's
a
ebook
on
helm,
best
practices
with
CI
CD.
That
I
think
is
really
valuable
and
with
that
I
think
we'll
move
into
questions.
You're
welcome,
of
course,
to
go.
Try
any
of
this
out
of
code.
B
First
audio,
it's
a
free
account,
you're,
gonna,
helm,
dashboard
in
the
release,
history
and
all
that
stuff.
So
you
can
try
helm
two
and
three
and
there's
also
a
view
of
all
your
helm
releases
that
works
for
both
helm,
two
and
three,
so
you
can
actually
see
what's
moved
into
helm
and
what's
moved
into
hell,
3
there's
just
a
little
switch
there.
You
can
use
so
with
that
I
think
Archie,
you're,
gonna
come
be
our
moderator
and
and
tell
us
which
questions
we
should
answer
awesome.
A
Thanks
dananana
for
great
presentation,
I
hope
it
was
really
interesting
for
everybody.
We
don't
have
some
time
for
questions.
If
you
have
a
question
that
you
would
like
to
ask,
please
drop
it
in
the
Q&A
tab
at
the
bottom
of
your
screen
and
we
try
to
get
get
back
to
you
as
soon
as
possible.
So
I
have
a
few
questions
already
dropped
here
to.
C
B
B
Most
of
that
stuff
still
applies.
I
mean
the
templating
still
works
in
the
same
way.
Really
the
the
way
that
you
actually
just
install
and
upgrade
charts
from
from
a
command
line
perspective
is
basically
the
same.
So
I
wouldn't
worry
too
much
that
you're
like
you're
learning
too
much
about
home
too.
If
you're
spending
a
bunch
of
time
on
figuring
out
how
to
secure
killer,
then
you
know
that
you
went
round
on
the
wrong
path.
You
don't
have
to
care
about
tiller
anymore,
but
other
than
that
you
know.
Stuff
is
mostly
yeah.
A
I
just
want
to
add
them
that
you
know
this
there's
a
lot
of
materials
everywhere.
How
to
you
know,
use
home,
but
if
you
want
to
do
their
own
health
charts,
you
can
probably
also
friend
start
with
the
how
create
command
this
will
create.
Like
a
boilerplate
for
you.
So
from
there
you
can,
you
know,
customize
to
create
your
own
chart
and
then
obviously
there
is
a
kubernetes
like
channel
where
people
will
be
happy
to
help
you
out
as
well.
Yeah
Michelle
was
asking
about
like
config
Maps
I
see.
Are
these
plain
text
to
know.
B
So
if
you
actually
look
in
those
secrets,
they
will
actually
do
some
work
to
obfuscate
and
hide
sensitive
items
in
there,
so
I,
but
you
know
by
default
I'm
trying
to
think
here
by
default.
There
is
some
work,
that's
done
in
there
to
help
hides
hide
values.
However,
there
there's
potentially
additional
work
that
you
might
want
to
do
for
super
sensitive
stuff,
because
I
remember
looking
around
the
secret
seen
a
bunch
of
encrypted
values,
I,
don't
know
Anna.
You
have
more
on
that.
B
B
Usually,
and
some
people
go
hog-wild
with
operators.
I
know
a
company
that
has,
over
frankly
over
a
thousand
customers
resource
definitions
each
with
their
own
operator
associated
with
it,
which
is
crazy,
I,
don't
know
if
I
would
recommend
doing
that,
but
helm
is
really
about
packaging
and
templating
an
application.
So
it's
really
about
the
definition
of
that
application,
less
so
about
the
lifecycle
of
that
application.
Now
you
new
install
help,
charts
and
you
can
do
roll
backs
and
you
can
just
create
temp.
B
You
can
just
output
the
manifests,
but
operators
are
really
designed
around
the
managing
complex
life
cycles
of
applications,
rather
than
just
creating
packages
for
them.
So
you
can
actually
use
operators
with
helm,
charts.
For
example,
you
can
have
an
operator
that
consumes
a
help,
chart
and
installs
your
application.
That
way
so
they're
not
really
competitive,
they're,
more
potentially
complementary
technologies.
B
B
An
operator
for
everything-
and
you
can
even
see
some
people-
have
thought
well,
we'll
actually
distribute
our
software
through
an
operator
installer
operate
in
order
to
consume
our
software,
and
there
are
some
reasons
for
that.
But
it's
it's
not
a
replacement
for
a
package
manager.
It's
not
meant
to
be
yeah.
A
Totally
I
see
a
lot
of
people
using
primitives
operator
and
deploying
it
as
a
home
chart
as
you
synaptic,
and
combine
those
things,
because
you
know
how
I
miss
packaging
the
application
and
then
operator
is
really
focusing
on
the
life
cycle
of
the
application.
All
right
going
to
the
next
question
from
Thiago,
Carvalho
and
he's
asking
about.
Is
there
a
way
to
rollback
database
schema
changes,
I?
Suppose?
If
it's
a
you
know,
you're
deploying
sequel,
and
then
you
have
some
changes
in
the
scheme
and
you
want
to
rollback
yeah.
B
This
is
actually
where
an
operator
does
become
valuable
because
helm
helm
is
about
applying
kubernetes
manifests
if
you
think
about
what
helm
actually
does.
If
you
run
the
command,
helm,
template
and
you're
charting
your
values,
it
will
just
spit
out,
kubernetes
manifests,
all
home
is
really
doing,
is
templating
and
then
applying
those
manifests.
So
it's
actually
not.
It's
not
necessarily
doing
a
lot
of
work
to
manage
the
life
cycle
of
something
like
a
database
schema
change.
B
That's
where
an
operator
could
be
more
useful
or
in
this
you
know
what
I
see
a
lot
of
people
do.
Is
it's
it's
less
about
rolling
back
a
database
schema
change
and
it's
more
about
doing
backups
and
having
like
custom
kind
of
scripting
around
changing
stateful
applications.
I
I
think
that
stateful
applications
and
kubernetes
are
still
somewhat
immature.
I
think
Kelsey
Hightower
has
a
lot
of
opinions
about
the
state
of
state
and
kubernetes,
but
basically
means
you're.
Gonna
probably
have
to
do
more
manual.
A
B
Actually,
one
more
thing
on
that,
because,
because
I
think
that
maybe
our
CI
CD
diagram
from
earlier
might
be
a
little
bit
misleading
on
this
is
why
there's
some
confusion?
A
helm
package
is
just
manifests.
It's
just
manifests
with
variables.
Essentially
so
ahem
package
doesn't
include
the
actual
bytes
of
a
docker
image
it
will.
It
will
include
a
reference
to
where
that
docker
image
can
be
found
in
a
helm
repository
in
a
docker
registry.
B
There's
another
standard
for
this
called
sea
now,
which
is
cloud
native
application,
bundles,
which
is
concerned
with
the
idea
of
creating
like
an
offline
package,
potentially
that
you
could
just
it
includes
the
docker
image
and
a
helmet
chart
and
everything.
So
that's
what
you
would
need
that,
for
so
the
helm
chart
is
really
just
about
manifest.
The
docker
image
is
about
the
docker
image.
All.
A
B
B
And
I've
heard
somebody
say
that
maybe
they
had
an
issue
one
time
but
I
just
haven't
seen
anything
like
that.
So
I
mean
when
in
doubt
you
know,
use
a
use.
A
staging
cluster
use
the
dry
run
command
to
actually
see.
What's
going
to
be
rendered
and
and
I
mean,
like
90
99
percent
of
the
time,
I
think
you're
in
fine
and
if
it
works
in
staging
you
know,
you
think
you
can
be
pretty
sure
that
it's
gonna
work
when
you
completed
a
production,
so
I
would
I'm
not
too
terribly
worried
about
it.
Thanks.
A
Dad
Danielle's
uberman
is
asking
about
I.
Think
we
partially
answer.
This
question
is
what,
if
you
don't
have
a
helmet
art
yet,
but
would
like
to
define
one
is
any
develops
tool
to
help
to
that
task.
So
I
mentioned
that
you
can
do
how
create
and
it's
gonna
build.
You
like
a
boilerplate
chart
that
you
can
start
to
work
with,
and
you
know
start
learning
the
gold
templating,
maybe
then
or
Anna,
have
something
as
well
to
recommend.
Isn't.
B
B
Manifests
and
helm,
charts,
I
believe
yeah
yeah,
so
you
can
actually
use
draft
to
do
this.
It's
draft
SH
is
the
website.
It's
a
pretty
cool
project,
I
think
it's
backed
by
Microsoft
and
you
can
basically
just
do
like
draft
up
and
it
will
build
it.
It
will
build
a
docker
file
and
try
to
figure
out
how
to
do
it,
but
also
just
browsing
other
people's
home
charts
they're
fairly
easy
to
read.
You
know,
usually
people
organize
it
with
like.
Oh,
this
is
a
deployment
yeah
mo.
This
is
the
service
Yambol
they'll.
A
I
would
that
just
probably
recommend
before
going
to
create
your
own
chart,
you
can
go
to
the
home
hub
and
you
know,
search
there's.
This
chart
is
already
available
by
somebody
you
know,
and
if
you
want
to
use
that
one
or
and
contribute
to
it
or
you
can
potentially
you
know
for
kit
them.
You
know
create
your
own
chart
from
that
as
well.
B
A
A
B
A
I
think
I
can
answer
partially
this.
You
know
you
don't
need
to
learn
gold
because
it's
a
go
templating,
it's
not
exactly
the
go
language
that
you
need
to
learn
it's
a
little
bit
of
you
know
kind
of
part
of
the
goal
that
you
just
need
to
understand
how
it
works.
So
you
don't
need
to
you
know,
learn
all
the
go
language
to
use
and
to
build
how
charts
so
just
kind
of
look
into
the
documentation,
and
you
understand
the
patterns
and
you're
gonna
become
pretty
familiar
quite
soon
with
that
yeah.
B
You
know
the
the
whole
point
of
of
helm
is
that
you
don't
have
to
get
into
that
kind
of
stuff.
It's
really
just
the
templating
and
it
does
use,
go
templating,
you're
right,
but
it
like
the
only
time
I've
had
to
really
know
any
Co
syntax
was
when
I
was
creating
scalable
home
charts.
That
could
create
multiple
deployments
with
different
options,
and
in
that
case
it's
just
it's
just
a
finding
it
an
array,
and
if,
if
you
want
an
example
of
that,
I
have
a
repo
github.com.
B
Slash
today
was
awesome,
slash
color,
coded
I'll
put
in
the
chat,
and
you
can
actually
see
under
I'll
throw
a
link
in
here.
You
can
actually
see
a
chart
that
takes
values
and
creates
multiple
deployments
based
on
the
values
that
are
defined,
and
you
can
see
exactly
how
that
works
in
house.
That's
context
and
stuff,
so
I'll
throw
that
in
here
great.
A
Man,
Thanks
have
I,
see
another
great
question
coming
from
Kenneth
Riddler,
so
he's
actually
asking
question
that
I
was
hoping
to
ask
as
well,
but
I
wasn't
sure
if
I
can.
So
how
do
you
describe
the
applicability
of
relationship
between
hound
and
customized
included
in
coop
Carol?
How,
if
at
all,
would
they
be
used
harmoniously.
A
A
A
B
I'm
not
I'm
not
familiar
with
any
conflicts
between
customizing,
helm,
3,
but
I
also
don't
have
very
much
very,
very
little
experience
with
customized,
so
I
wouldn't
consider
myself
the
expert
on
that
by
any
means
I'm
not
aware
of
any
conflicts.
That
would
happen
and
can't
imagine
why
there
would
be
a
conflict
between
those
two.
My
my
understanding
of
customize
is
it's
really
about
templating,
not
so
much
about
packaging
yeah,
but
I
could
have
that
wrong
again.
I
don't
know
customized.
That
was.
A
Right
I
think
you're
right
and
in
terms
of
like
how
to
use
harmoniously,
I
would
I
would
also
actually
I
thought
a
lot
about
this
thing
and
I
think
one
of
the
ways
you
can
still
use
hound
chart,
but
you
can
apply
your
customization
on
top
of
hound
charts.
Sometimes
this
is,
you
know,
requirement,
so
you
applying
customization
on
top
of
customization
that
could
be
potentially
different,
a
CD
situation
and
whatnot,
so
it
is
possible
to
use
them
together
or
one
of
another,
but
they,
you
know
the
nice
thing
about.
A
How
is
that
its
packaging,
the
application-
and
you
know
you
can
distribute
it
to
everywhere,
whereas
with
the
customized?
It's
it's
really
focusing
on
the
solving
the
problem
of
you
know
different
environments,
customizing
them
both
are
great
tools
and
I
highly
recommend
to
use
them
together,
even
Silva
Kumar.
My
applications
consist
of
many
services
and
deployed
for
free
environment.
In
some
environments,
I
don't
have
to
have
all
the
services
sort
of.
B
My
application
consists
of
many
services
and
deployed
a
few
environments
and
some
environments,
I,
don't
have
all
the
services
sort
of.
Like
addition,
any
suggestion
structuring
the
home
chart
this
blank
chart.
Ok,
so
yeah
you
can
actually
do
a
chart
of
charts
so
so,
for
example,
in
code
fresh,
there's,
a
cool
webinar
on
this
about
how
we
do
guys
to
be
for
code
fresh,
because
we
actually
have
this
conflict
complex
stack
of
micro
services
and
you
can
create
a
chart
of
charts.
B
That
is
a
single
chart
that
references
several
chart
dependencies
and
it
will
go
and
make
sure
those
are
installed.
There
are
some
challenges
with
that.
So,
for
example,
if
you
have
deployed
a
dependency
to
a
karate
stir
that
wasn't
deployed
using
how
your
application
would
work
but
helm
wouldn't
be
aware
that
it
was
there,
so
it
would
try
to
install
the
additional
dependency
and
that
could
potentially
overwrite
what
you
have
already
there
or
it
could
conflict
with
it
in
some
way.
So.
B
Yeah,
it's
a
chart
of
charts
is
definitely
an
option.
There
are
some
some
limitations
and
how
that
will
work,
because
just
the
nature
of
managing
that
many
charts
with
a
single
installation-
and
you
want
to
be
able
to
usually
people
want
to
be
able
to
deploy
a
sub
service,
a
sub
dependency
of
a
chart
without
having
to
upgrade
the
rest
of
the
chart,
because
you
have
different
people
managing
them
and
maybe
different
people
have
different
access
control.
B
A
Right,
yeah
I,
just
you
know,
recommend
as
well
people
to
look
into
the
helm
file
project
that
you
can
basically
specify
many
different
charts
in
the
one
large
helm
file,
which
is
you
know,
highly
customizable,
and
you
know
it's
quite
vibrant
community
as
well.
If
you
go
into
the
github
bound
file,
you
can
find
out
about
this
project
all
right
miguel
asking
any
plan
to
include
equivalent
command
to
help
status
of
need
to
to
show
the
status
of
all
deployed
elements.
What
is
changed
on
v3
for
that.
C
B
Doesn't
show
yet
to
your
point
homeless
doesn't
show
that
it
is
running
properly
yeah.
That's
a
good
point
and
I
haven't
seen
any
discussion
about
making
helm
status
work
for
all
releases,
rather
than
a
specifically
named
release
in
code
fresh,
there's,
a
sweet
dashboard
that
will
show
the
status
of
all
releases.
That's.
A
B
Yeah
well
actually,
this
is
this
seems
like
it's
more
of
a
a
workflow
question
so
like
if
you're
gonna
change
a
helmet
art,
you
should
do
it
in
a
new
branch
and
then
your
CI
CD
should
actually
trigger
a
build
off
that
branch
that
actually
tries
to
render
that
chart
tests.
It
tries
to
deploy
it
and
then
once
that's
happened,
then
it's
it's
accepted
and
you
can
go
ahead
and
merge
it
into
your
master
branch
for
your
production
branch
that
would
be
basically
treat
your
home
tarts.
C
B
Yeah
home
lint
is
another
option
here
that
will
help
you
see
issues.
There
is
some
work
being
done
around
helm
test
where
you
can
set
up
some
tests
for
a
chart,
but
it's
fairly
limited
in
my
experience
and
I
find
that
I
usually
just
end
up
relying
on
my
CCD
to
do
this
work
rather
than
trying
to
build
it
into
just
the
help
command.
Yeah.
A
B
There's
so
many
great
ones,
there
was
a
question
somebody
asked
about
scaling
deployments
and
they
were
saying
hey
if
I
had,
if
I
have
a
hump
chart
and
I
want
to
deploy
it
in
a
hundred
different
places.
Is
there
a
great
way
to
do
that
with
see
ICD,
and
for
that
one
I
typed,
an
answer
which
everybody
should
be
able
to
see?
We
did
a
webinar
about
how
to
do
CIC
for
micro
services
and
basically
the
crux
of
it
was
around
using
a
single
pipeline
with
lots
of
different
variables.
B
A
B
You
do
have
more
questions
on
helm.
Three
code
fresh
is
doing.
We
do
these
hangouts
every
week.
So
if
you,
if
you
want
to
check
it
out
at
code,
fresh,
do
slash
events
we're
doing
a
it's
like
a
coffee.
It's
code,
fresh
coffee,
hangout
and
I-
know
that
this
week,
I
think
it's
Thursday
we'll
have
a
few
people
that
are
definitely
super
helm
experts
and
use
it
even
more
than
I
do
so.