►
From YouTube: Getting Started with Helm
Description
Fern with the Technical Marketing team presents on getting started with Helm.
Key Topics:
* What is Helm
* Helm2 vs. Helm3
* Helm Architecture
* Helm via CLI
* Helm in GitLab CI
* Build, Publish, and Share Helm Charts using GitLab
* Useful Resources
A
B
So
I'll
go
over
a
little
bit
about
that,
but
just
to
kind
of
tell
you
a
little
bit
about
myself.
If
you
haven't
seen
me
or
met
me
before
I
work
for
the
marketing
department
and
I'm
specifically
in
technical
marketing,
so
I'll
provide
demos,
presentations,
knowledge
sharing
and
all
kinds
of
solutions.
You
know
to
help
us
better
use
our
product,
so
just
just
to
give
a
quick
introduction
so
just
to
get
a
raise
of
hands.
B
B
Okay,
perfect,
so
y'all
can
see
this
yep,
okay
cool
all
right,
so
just
to
start
off.
This
is
a
picture
of
me
actually
sailing.
So
I
am
right
here
in
the
middle
of
the
boat,
and
this
was
the
frost
fight
regatta
here
that
we
have
here
in
austin,
so
we
placed
second
out
of
five
boats,
so
I
do
like
sailboat
racing
back
when
you
know
when
that
was
a
more
active
community
about
two
years
ago.
B
So
what
are
we
going
to
go
over?
So
what
is
helm
helm2
versus
helm3?
So
there's
been
some
changes,
mainly
on
the
server
side,
with
the
different
versions
of
helm,
I'm
going
to
go
over
a
little
bit
about
the
architecture
of
home
3
and
I'm
going
to
kind
of
showcase
how
helm
is
used
and
how
you
can
benefit
from
it.
B
So
what's
a
helm,
so
it's
a
tiller
or
a
wheel
and
any
associated
equipment
for
actually
steering
the
boat
or
the
ship.
So
that
is
the
literal
sense.
So
this
is
kind
of
a
stock
photo
that
I
got
of
of
the
helm
where
you
can
actually
steer
that
it'll
move
the
rudder
and
you
can
move
the
ship.
So
I'm
not
exactly
sure
why
that
was
chosen
for
a
package
manager
for
kubernetes
where
that
name
was
chosen
but
interesting
name.
B
Maybe
it
steers
you
into
deploying
things
onto
kubernetes,
so
so
what
it
is,
is
it'll
manage
all
your
packages
in
the
sense
where
right
now,
kubernetes
is
very
the
way
that
you
deploy.
Things
can
be
very,
you
know,
tedious,
because
you
have
to
define
so
many
different
things
to
deploy
an
application.
For
example,
you
can
deploy
the
actual
deployment
that
deploys
the
pods.
B
You
can
define
the
service
to
expose
it
in
the
internal
network.
You
can
define
the
ingress
to
expose
it
to
the
external
network
and
you
may
need
to
change
all
these
values
per
environment.
So
what
ends
up
happening
with
helm
is
that
it
makes
it
easy.
You
just
have
a
values.yaml
file
that
you
can
kind
of
edit
per
environment,
and
then
you
run
the
helm,
commands
and
it'll
install
all
these
different
kubernetes
manifests
required.
B
So
so,
just
to
continue
with
the
bullet
points,
it
allows
you
to
use
commands
to
install
and
update
kubernetes
yaml.
So
instead
of
having
like
20
ammos,
you
have
one
helm
chart
that
has
those
yamls
and
then
you
can
just
update
one
file
and
by
updating
that
one
file
it
makes
it
easier
to
manage
your
your
deployments,
and
this
is
this
is
mainly
done
for
large
deployments
and
making
them
done
in
an
organized
manner.
So
you
can
have
multiple
helm,
charts
that
you're
using
on
your
cluster,
for
example,
nginx.
B
B
So
2
versus
home
3,
so
there
are
migration
guides
with
helm,
2
and
home
3..
I
would
say
that
helm.
3
is
a
lot
better
and
more
secure
because
it
removes
tiller
and
what
tiller
was
was
pretty
much
the
server
that
would
interact
with
the
helm
client.
So
it
would
need
to
be
an
additional
item
that
was
installed
within
your
kubernetes
cluster
and
that
server
would
then
perform
the
functions
of
actually
deploying
the
application.
B
So
it
would
be
a
client
server
model
where
the
client
would
ask
the
tiller
server
to
see
if
it's
okay
to
deploy
these
things
and
then
taylor
would
go
ahead
and
deploy
them
and
you
had
to
work
with
permissions
and
making
sure
you
set
everything
up
securely
and
a
lot
of
people.
Weren't
setting
up
those
permissions
securely
and
tiller
also
had
access
to
a
lot
of
the
cube
api.
So
it
caused
some
security
issues
there.
B
So
film
three,
it
was
decided
to
actually
remove
tiller
and
you
know
and
then
some
other
differences
that
are
smart,
like
just
there's
different,
some
different
commands
and
some
different
ways
of
packaging
the
charts.
So
I
would
just
recommend,
use
home
three
and
and
then
find
documentation
on
migrating
from
home
to
the
home
three.
If
you
have
applications
running
on
the
older
home
and
a
lot
of
the
new
gitlab
charts
which
I'll
get
into
are
actually
using
home
three
or
provide
helm3
as
part
of
the
actual
container
image.
B
B
You
can
create
your
own
home
charge
to
put
application
and
change
values
and
all
that
as
I've
said,
so,
let's
kind
of
just
just
actually.
Let
me
just
show
you
the
next
slide
before
I
get
into
that
so
and
then
the
way
that
you
would
use
helm
in
the
gitlab
ci
is
you
would
use
a
container
image
that
already
has
helm
installed.
B
For
example,
I'm
using
this
image,
that's
provided
within
the
cluster
integration
for
gitlab
and
it
already
has
helm3
installed
and
then,
when
I'm
running
the
script,
what
I'm
actually
going
to
do
is
I'm
just
going
to
run
helm
upgrade
and
I'm
going
to
use
the
values.yaml
file
and
I'm
going
to
set
the
image
to
what
I
have
defined
here.
So
you
can
actually
change
different
values
within
within
the
actual
command
line
and
I'm
gonna
install
it.
C
B
B
B
And
when
I
look
at
this
home
directory,
you
can
see
these
are
the
values
that
I
have
so
support.
Target
port
host,
which
are
which
can
be
overwritten
or
new
ones,
can
be
added,
but
essentially
what
that
does
is.
If
you
look
at
this
nodes.yaml,
you
can
see
that
I'm
grabbing
the
values.image,
I'm
grabbing
the
values.targetport
from
either
the
command
line
or
the
values.yaml
file,
and
then
I'm
applying
it
to
this
actual
deployment.
That's
what
I'm
saying
like
this
would
be.
B
Let's
say
for
a
staging
environment,
but
depending
on
what
values.yaml
you
have,
I
can
have
different
gitlab.
I
can
have
different
jobs
that
changes
the
values.yaml,
so
I
can
have
multiple
different
values.yaml
files
here,
so
I
can
have
one
for
staging
for
production
for
dev
environments
and
having
all
those
there.
I
can
easily
just
apply,
which
one
I
want
to
whichever
environment
I
want,
via
the
gitlab
ci
ammo,
so
pretty
much.
B
What
what
helm
does
is.
It'll
just
go
ahead
and
install
whatever's
in
this
templates
directory,
so
install
all
these
different
deployments
that
I
have
and
then
it'll
overwrite
things
that
I
need
override
so
see.
This
has
nothing
to
overwrite
from
values.yaml,
so
install
it
as
is,
but
you
can
see
that
this
one
does
actually
override
things
from
values.yaml.
B
B
B
Okay,
so
yeah,
because
it
was
only
looking
at
the
default
namespace.
So
if
you
can
see
here,
you
can
see
that
I
can
see
and
manage
my
deployments
within
all
my
name
spaces.
So
you
can
see
that
this
is
what
was
deployed.
It's
been
deployed
15
times,
so
it
keeps
getting
revised
every
time
that
the
job
is
run
and
the
chart
is
called
notes
one,
and
we
can
continuously
update
the
version
and
different
things
by
changing
also
what's
in
chart.yaml,
so
I
can
update
the
version,
the
app
version
and
different
information
about
it.
B
B
B
You
send
a
request
to
the
gitlab
api
with
your
project
id
and
what
you
do
is
you
use
your
username
and
personal
access
token,
and
what
it'll
do
is
it'll
upload
that
file
and
then
what
you
can
do
now
is.
If
you
perform
helm,
repo
ls
you'll
actually
have
that
repo
available,
and
you
can
actually
just
do
a
home,
install
and
call
that
repo
without
you
won't
have
to
like
actually
get
clone
the
project,
or
do
any
of
that.
B
You
can
just
manually,
deploy
it
into
your
cluster
or
use
automation
to
deploy
it
into
your
cluster
by
just
calling
the
home
repo
command.
So
what
that
looks
like
is,
I
can
do
home
repo
ls,
and
you
can
see
that
I
have
the
gitlab
from
when
I
actually
installed
gitlab
onto
a
also
kubernetes
cluster,
but
you
also
see
that
I
have
the
simply
simple
notes
on
repo
that
I
can
download
from
that
url
so
repo.
B
B
And
then
you
would
do
like
a
home,
install
home
re
and
and
install
the
file
from
the
actual
home
repo.
So
I
provided
kind
of
documentation
how
to
do
these
things.
So
there
there's
a
usage,
video
there's
the
helm,
repository
documentation
that
you
can
go
to
here.
To
actually
add
your
token
and
publish
it
and
so
see
when
you
do
the
helm.
Repo
ad
you'll
add
that
repository.
B
But
then
you
can
install
the
item
using
home
install
once
it's
been
added
to
the
repository
so
saying
that
that's
my
quick
introduction
to
how
how
it
works
and
how
it
can
be
used
and
leverage
and
the
new
feature
within
gitlab
14.1
I'd
like
to
kind
of
turn
it
over
to
some
to
just
a
question
and
answer
session
and
kind
of
go
over
any
thoughts
and
any
questions
y'all
might
have
on
using
health.
So
let
me
stop
sharing
and
let's
make
this
more
of
a
dialogue.
So.
C
Hey
fern,
this
is
samir
great
presentation.
Thank
you
for
putting
this
together.
A
quick
question
that
I
have
is
what
you
were
displaying
there
with
regards
to
the
app
that
you
created.
You
have
a
helm
folder
with
some
chart
and
values
and
things
could
you
in
the
context
of
the
new
helm,
repository
functionality?
B
Yes,
so
I
can,
I
can
explain
how
the
process
would
work.
So
let
me
let
me
go
back
into
sharing,
so
in
this
case,
the
way,
the
way
that
it
can
be
done
would
be,
and
within
this
helm
folder
I
would
have
a
job
that
would
every
time
that
there's
an
update,
I
will
have
a
job
that
builds
a
tar
file
from
this
helm
file,
so
kind
of
to
show
you
kind
of
to
show
you
how
it
would
work.
B
B
So
what
what
I
can
do
is,
in
my
actual,
my
actual
project,
where
I
perform
the
get
lab
command
for
helm.
Instead
of
actually
using
that
directory,
I
can,
I
can
directly
just
call
helm
and
install
it
via
the
package
that
exists
here
in
this
package
registry.
So
what
I
can
have
done
is
I
can
have
a
separate
job
that
always
does
the
helm
package
and
it'll
keep
packaging
the
different
items,
and
now
anyone
with
access
to
this
repository
can
easily
just
like
link
the
repository
and
add
it.
B
So
what
this
is
good
for
is
kind
of
making
guides
and
having
official
versions
so
that
someone
doesn't
need
to
actually
clone
the
project
and
work
through
that
to
be
able
to
actually
install
it
on
their
system.
So
like
the
way
that
nginx
and
these
other,
like
bigger
tools
that
everyone's
using
work,
is
that
instead
of
actually
cloning,
nginx
and
then
deploying
it,
what
people
will
do
is
they'll.
B
Do
a
helm,
repo
ad
they'll,
add
the
nginx
home
repository
that
contains
all
the
helm,
charts
and
then
they'll
run
helm,
install
nginx
from
that
helm
chart.
So
they
don't
need
to
clone
and
constantly
update
stuff
and
update
values
directly.
They
just
kind
of
do
it
all
through
one
interface,
and
then
they
can
have
that
in
their
csc,
the
jobs
and
they're
constantly
getting
the
newest
updates.
So
that's
the
main
reasoning
behind
this
is
to
have
it
easy
for
our
users
to
get
updates
to
not
having
to
work
with
the
actual
code
itself.
D
A
fern
as
a
follow-up
to
that
you,
so
what
so?
From
a
business
value
standpoint
or
or
a
dead
set?
You
know
devops
standpoint,
it's
it's
it's
a
single
source
of
truth
and
it
and
it's
maintained
by
one
it's
maintained
centrally-
is
that
the
idea
right,
you're
not
making
clones
of
this
you're
going
to
one
central
helm
package,
repo
to
get
that
that
central
copy
right.
B
For
example,
I'm
a
company
bestbuy.com,
for
example,
and
I
have
like
a
container
that
checks
for
all
the
newest
video
cards
that
are
coming
out
right
and
it
installs
in
the
kubernetes
cluster.
So
now
I
know
that
I
can
update
that
software
and
do
everything
through
helm
and
install
it,
and
I
know
that
I'm
getting
it
from
the
official
source.
I
don't
have
to
constantly
be
looking
at
best
buy's
code
base
to
you
know
to
get
the
updates.
D
Yeah,
that's
going
to
make
sense.
Are
we
as
get
lab
using
this?
I
I
mean,
I'm
pretty
sure,
we've
got
helm,
charts
galore
right
for
a
lot
of
what
we
do.
Are
we
starting
to
also
get
into
the
package
registry
to
provide
it?
That
way,
as
opposed
to
go
to
this
repo,
get
the
helm
charts
and
do
your
thing.
B
So
good
question
so
as
part
of
the
release
notes,
so
the
team
that
did
produce
this
is
actually
going
to
start
dog
fooding.
This
feature
yeah
there
you
go,
you
know
so
it'll
probably
take
a
few
releases
to
it,
for
it
to
be
kind
of
really
active
and
really
being
used,
but
I
think
moving
forward.
That's
that's
exactly!
What's
going
to
happen,
nice.
D
And,
and
is
it
similar
to
other
package
registries
that
in
your
pipeline
you
can
say
I
want
anything,
you
know
2.x,
you
know,
I
don't
want
three
yet,
and
I
don't
want
one
point
x,
because
it's
too
old
and
3.x
is
too
too
blazing
is:
is
that
kind
of
functionality
in
there
like
we
do
with
like
maven,
repos
and
stuff
that
you
can
kind
of
you
know
wild
card
your
way
into
a
a
a
certain
range?
Is
that
sort
of
thing
also
is?
It
is
part
of
the
the
same
concept.
B
D
D
I
was
just
thinking,
that's
kind
of
how
package
registries
I've
seen
in
the
past
are
used
right.
You
give
it
a
range
and
say
hey
anything
in
this
range
is
valid.
I
don't
need
to
know
that
it's
2.6
it
could
be
2.7.
I
don't
care
as
long
as
it's
two
dots,
something
it's
compatible
with
what
I
need.
So
I
could
see
that
being
advantageous.
B
B
Where
you
can
specify
greater
than
three
but
less
than
four,
exactly
where
the
newest
thing
is
so
that
that's
what
you're
saying
like?
Can
you
do
that
yeah,
there's,
probably
a
thing
on
on
the
helm
command
that
lets
you
do
that,
so
I
I
haven't
done
that.
But
if
I
do
home
upgrade-
and
let's
say
I
just
do-
help
right-
there
should
be
a
way
of
actually
setting
what
values
that
that
you
want
to
pick
up
between
what
and
what
see
so
version
specify
the
exact
version
to
use.
B
D
B
C
B
D
B
Yeah
there's
a
lot
of
people
that
can
do
it.
I
mean
yeah,
it's
pretty
easy
thing
to
set
up
like
I.
I
can
set
it
up
in
my
house
and
then
I
can
sell
this
service
to
y'all.
If
you
want
vern
you're
such
a
hustler,
but
yeah
look,
so
you
can
see
here-
and
let
me
just
put
this-
this
is
helm's
information
as
to
who.
B
B
B
That's
a
good
idea,
yeah,
honestly,
that's
a
good
idea
now
that
not
it's
something
new
that
we've
offered
now
so
honestly,
it's
something
that
that
we
can
actually,
you
know,
be
part
of
now.
So
I
think
it's
a
good
point,
put
put
it
in
the
know,
whoever's
typing
on
the
notes.
Put
it
in
the
notes,
see
if
we
can
get
it
kind
of
there.
B
E
B
E
E
B
It's
they're
used
for
different
reasons,
so
docker
hub,
and
that
is
a
container
repulsor,
so
that
stores
the
container
images
this
stores
our
helm
chart.
So
it
stores
like
the
metadata.
I
guess
you
can
think
of
that's
used
to
actually
deploy
everything
right,
so
you
would
still
you
would
need
them
both
together
right
because,
like
let's
say
you
have
your
application
application
image
in
the
container
registry.
But
then
you
have
your
charts
on
how
you
deploy
that
application
in
the
helm
register
in.
B
D
Which
is
why
it's
super
awesome
that
for
us
to
have
one
built
in
because
a
you
don't
have
to
go,
find
one
somewhere
else,
and
you
can
now
be
more
single
app
right.
You
can,
you
know
simple
application
for
the
whole
process,
because
now
you
don't
have
to
go
out
to
doctor
and
then
go
out
to
somebody
else's
registry
to
get
to
get
that
piece
and
some
you
know
be
pulling
from
all
over
the
place.
Now
you
got
it
one
spot,
which
is
nice.
B
Yeah,
I
would
say,
makes
it
easier
to
maintain,
makes
it
makes
it
faster
makes
it
it's
it's
all
in
one
place,
so
it
adds
a
lot
of
benefit
in
that,
so
it
makes
it
just
makes
it
easier
for
the
developer
in
general.
If
you
want
to
make
something
official
like
let's
say,
nginx
was
using
gitlab
and
they
had
everything
on
gitlab.
They
can
easily
just
put
the
charts
all
there
and
then
everyone
can
just
just
add
it
easily
and
be
able
to
to
deploy
it
into
their
application.
That's
just
an
easy
example:.
D
And
I
think
it
we
can
use
all
of
our
roles
and
permissions
and
all
that
good
stuff,
so
that
we
can
have
you
know
an
owner
of
that
registry
that
has
a
permissions
to
you
know,
make
changes
updated
versus
users
that
can
pull
from
it,
but
can't
contribute
to
it.
Just
like
all
our
other
registry
type
stuff.
B
Yeah,
I'm
sure
this
is
something
new,
so
I
don't
know
what's
what's
exactly
been
implemented
and
I
haven't
had
a
chance
to
play
right
now.
I
know
that
you
need
a
personal
access
token,
with
a
certain
scope
to
be
able
to
access
it
and
since
personal
access
tokens
are,
you
can
also
make
a
ci
cd
token
and
all
of
that
and
I
think,
you're
able
to
actually
specify
a
role
within
that
token,
so
you
can
have
it
limited
to
doing
certain
things
and
not
doing
certain
things.
So
that's.