►
From YouTube: Cloud Native Live: Automating Kubernetes Deployments
Description
Don't miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from 18 - 21 April, 2023. 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
Where
we
dive
into
the
code
behind
Cloud
native
I'm,
Annie,
talbasto
and
I
am
a
cncf,
Ambassador
and
I
will
be
your
host
tonight.
So
every
week
we
bring
a
new
set
of
presenters
to
Showcase
how
to
work
with
Cloud
native
Technologies,
and
as
always,
they
will
build
things.
They
will
break
things
and
they
will
answer
all
of
your
questions.
A
So
Joe
can
you
can
join
us
every
Wednesday
to
watch
live
so
this
week
we
have
amazing
session
on
automating
kubernetes
deployment
coming
right
up
and
as
always,
this
is
an
official
live
stream
of
the
CNC
app
and
as
such,
it
is
subject
to
the
cncf
code
of
conduct.
So
please
do
not
add
anything
to
the
chat
or
the
questions
that
would
be
in
violation
of
that
code
of
conduct.
C
And
you
was
as
giggles
I'm
a
DX
developer
experience
engineer
at
weworks.
B
Welcome
everyone,
and
thanks
for
joining
us,
I'm,
just
going
to
share
my
screen
real,
quick,
hopefully
this
works.
Can
everyone
see
my
slides
yeah?
They.
B
Okay,
so
we're
not
going
to
do
slides
for
very
long
I
know
this
is
not
a
slide's
venue,
but
we
did
want
to
set
some
slides
to
sort
of
introduce
some
Concepts
before
we
Dive
Right
In.
B
So
this
is
the
automating
kubernetes
deployments,
presentation
and
hello,
and
thanks
for
joining
us
today
and
the
main
idea
that
I
think
we
want
to
get
across
is
that
there
is
really
not
just
one
set
of
best
practices.
So
there
are
different
ideas
in
different
contexts
and
we're
going
to
show
how
we're
we're
going
to
introduce
a
concept
of
templates
and
we're
going
to
show
how
you
can
use
templates
to
automate
kubernetes
so
that
you
can
show
your
team
a
different
way.
B
Now
that
is
a
great
question.
I
actually
mean
both
of
those
people
and
sorry.
I
have
to
I
want
to
see,
see
you
while
you're
talking
to
me
so
I'm
just
going
to
move
you
down
here,
so
I
can
see
what
I'm
doing
a
little
bit
better
sorry
about
this,
yes,
I
mean
both
of
those
people.
B
If
you're
a
platform
engineer,
you
need
to
be
able
to
provide
examples
to
your
team
and
if
you
are
an
app
developer,
you
want
to
be
able
to
consume
those
examples
without
having
to
think
too
hard
about
them.
Those
are
the
main
personas
so
yeah.
So
this
is
about
providing
examples
to
customers
as
a
word
I'm
going
to
use.
B
But
let's
be
clear,
we
are
talking
about
humans,
so
it's
all
about
reducing
cognitive
load
and
making
sure
that
you
can
access
the
essential
complexity
in
your
examples,
whatever
they
are
in
your
templates
well
being
able
to
gloss
over
the
incidental
complexity.
That's
that's
what
we
want.
Our
aim
is
to
help
people
with
a
template.
B
So
we'll
be
we'll
be
showing
these
three
separate
examples
and
keeping
with
the
topic
and
the
description
that
I've
given
so
far,
it's
sort
of
an
evolutionary
model.
C
As
a
app
developer,
I
don't
want
to
learn
a
lot
about
kubernetes.
So
how
do
I
start
with
the
most
simple
example?
Yeah.
B
So
the
most
simple
example
is
a
Dev
Branch
we're
going
to
have
a
Dev
branch
and
we're
going
to
automate
that
branch
and
just
to
back
up
before
we
talk
about
any
individual
example.
What
does
it
mean
that
we're
automating
a
branch?
Well,
this
is
git
Ops,
so
we
have
kubernetes
over
there
and
we
have
git
over
here.
B
We're
going
to
show
a
promotion
so
in
a
promotion
model
we
will
have
more
than
one
environment
and
we
will
need
a
mechanism
for
moving
the
change
from
one
environment
to
the
next.
B
So
I've
used
the
word
pipeline
here
and
to
explain
a
little
bit
what
I
mean
by
pipeline.
It's
not
a
physical
thing.
It's
an
abstraction!
The
pipeline
helps
us
to
test
our
changes
before
they
go
to
production.
That's
really
what
it's
for!
So,
there's
a
little
bit
of
friction
that
we're
adding
here
to
avoid
problem
in
production
down
the
line.
So
we
can
do
our
testing
in
an
environment,
that's
as
similar
as
possible
to
production
and
then
promote
the
change
and.
C
B
Yeah,
exactly
and
and
then
when
we
so
so,
what
we're
doing
in
this
case
we're
talking
about
release
versioning
release.
Versioning
is
an
important
thing
to
use
in
your
release
pipeline,
but
it's
also
an
extra
bit
of
friction
that
we
might
like
to
avoid.
B
So
there
are
all
these
different
models
and
this
one
we're
also
going
to
start
to
talk
about
oci
at
that
point,
we'll
gloss
over
it
a
little
bit
and
we'll
see.
The
examples
do
include
oci
up
to
this
point,
but
we
won't
really
talk
about
oci
until
we
get
to
the
third
example
and
we're
going
to
talk
about
Helm.
Also,
so
we
haven't
talked
about
Helm
yet,
but
Helm
is
the
templating
tool
that
we're
going
to
be
using
today.
C
B
Yeah
not
only
simple
but
also
extremely
popular
vendors
have
all
basically
sort
of
settled
on
Helm
as
the
tool
if
you're
a
kubernetes
vendor,
so
we'll
we'll
show
some
Advanced
Talent
features,
including
oci
Helm
charts.
Hopefully
we
get
that
far
and
let's,
let's
keep
things
moving
here,
so
the
short
version
is
there
are
the
three
examples
that
we're
going
to
show,
and
here
is
the
small
version.
If
you
got
it
all
lost
in
that,
if
you
want
to
take
a
screenshot
of
this,
so
you
can
refer
back
to
it.
C
Okay
so
I
guess,
let's
get
started.
I'm
a
developer
and
I
want
to
working
on
my
local
system
to
start
using
flux
and
to
start
using
get
like
process
as
part
of
my
development
workflow
that
later
I
hope
to
promote
to
whole
team
and
to
Enterprise
environment.
B
B
C
B
B
B
This
is
where
we
keep
our
manifests
and
there's
a
deployment.yaml
if
you're
unfamiliar
with
kubernetes,
don't
worry
if
you
are
familiar.
This
should
be
relatively
familiar
already,
of
course,
because
this
is
one
of
the
fundamental
units
in
kubernetes
a
deployment,
and
what
we're
going
to
see
about
this
is
that
this
is
a
deployment
that
creates
a
pod
with
two
containers.
B
They
both
the
purpose
of
this
structure,
is
we
wanted
to
use
the
existing
nginx
image
because
we're
serving
a
website.
That's
all
we're
doing
it's
not
a
program
that
runs
it's
just
a
website
and
we
do
need
to
retrieve
that
content
from
somewhere.
So
we
could
build
it
into
the
image.
But
if
you
are
really
spend
a
lot
of
time
with
Docker
build,
you
probably
find
that
there
are
a
lot
of
more
efficient
ways.
You
can
build
things
than
by
doing
it
in
a
Docker
image.
B
B
And,
like
I
said,
we
have
a
Dev
Branch,
that's
what
my
can
everyone
see
this
I
probably
need
to
increase
the
font
size.
A
It
looks
better
but
I
think
in
this
case
the
the
bigger
the
font
size
usually
is
the
better
but
I
think
we're
getting
there
and
if
the
audience
you
feel
like
you
need
a
bit
more
zooming
in
just.
Let
us
know.
B
Okay,
all
right,
so
here
we
have
our
Dev
branch
on
our
example:
Cube
config
repo
and
we're
gonna
make
a
change.
C
B
Okay,
so
we're
just
going
to
change
some
content
in
here.
I
think
we
have
hello,
get
Ops
we're
going
to
change
this
to
hello,
cncf.
B
B
B
So
this
git
repository
reference
points
at
our
Dev
branch
and
it
has
a
secret
ref.
This
secret
is
able
to
write
commits
to
the
dev
branch
we
can
see.
Our
build
is
finished
and
let's
see
if
we
can
catch
the
change
here,
so
it
says
hello,
get
Ops
in
the
previous
deployment,
we're
going
to
look
at
the
image,
update,
automation
and
we're
going
to
see
the
deployment
go.
B
B
B
A
A
Audience,
member
checking
in
as
well
would
it
be
possible
to
get
the
GitHub
link
repo
link
as
well
to
the
attendees
or,
if
it's
not,
obviously,
we
understand
yes,.
B
Absolutely
all
this
stuff
is
public,
so
this
this
is
the
repo
I'm,
not
sure
where
I
can
paste
it,
because
I
don't
have
access
to
the
chat
from
here.
But
if
I'll
paste
it
right
now,
okay,
yeah.
A
And
I
can
highlight
it
then
afterwards,
if
we
get
it
to
the
comments
or
the
private
chat,
great.
B
Thank
you,
okay,
so
this
is
the
commit
that
was
just
made.
We
can
see
what's
happened
here.
We've
got
this
comment
that
tells
flux's
image
update
automation
where
to
look
for
the
image
ref.
So
this
is
a
tag
ref,
that's
what
this
tag
means
and
that's
to
distinguish
it
from
a
fully
qualified
ref.
If
we
left
this
colon
tag
off
the
end,
then
we
would
get
the
name
of
this
image
in
full,
including
the
repository
where
it
comes
from,
but
we're
we
actually.
We
only
just
need
this
string
to
change.
B
We
don't
even
care
about
what
content.
It
is
right
now
because
of
the
way
this
example
is
built
and-
and
we
can
see
that
it's
deployed
here-
we
could
do
that
again.
I
think
we
have
enough
time
to
still
do
that
again.
Yeah.
A
And
I
think
you
can
see
the
GitHub
a
link
right
now
highlighted
in
the
Stream
as
well
as
well
as
in
the
comments.
B
Okay-
and
we
looked
at
one
part
of
the
automation,
so
this
is
the
commit
that
actually
changes
our
manifest,
and
here
is
the
rest,
so
that
image
automation
is
the
business
end.
Then
there
are
other
parts
that
are
important
for
this
process,
there's
the
image
policy
and
the
image
Repository.
B
So
this
is
the
actual
repository
that
our
Dev
branch
is
pushing
to,
and
you
note
that
it's
a
separate
repository
from
the
main
there
is
no.
There
is
no
prod
environment
here.
This
is
a
Dev
only
example,
so
you
could
imagine
that
we
would
push
another
image
here
for
the
production
environment,
but
we're
pushing
to
the
dev
Branch
here.
C
B
Okay
outstanding,
so
what
we
want
to
do,
let's
recap
what
we
did
here.
We
use
the
docker
file,
we
haven't
looked
at
the
docker
file,
but
the
docker
file
Builds
an
image
and
we
push
an
image
and
those
examples
by
the
way.
Those
are
all
GitHub
actions,
so
you
can
follow
them
here
and
we're
going
to
switch
to
our
next
example.
B
Where
we
will
change
a
few
things,
so
first
we're
going
to
change
what
type
of
app
we're
deploying.
So
it's
no
longer
a
simple
website.
It's
now
an
app
that
runs
and
we've
also
added
a
Helm
chart
which
has
some
interesting
properties.
We're
going
to
look
at
and
git
repository
is
connected
to
a
Helm
release.
B
So
let's
look
at
that
all
right.
So
here's
our
app.
This
is
a
CLI,
it's
written
in
Ruby
and
there
are
a
couple
of
other
components.
This
is
a
good
example
of
fibers.
Well,
good
example
may
be
a
stretch
I'm.
My
Ruby
is
a
bit
Rusty
these
days,
but
okay,
here
this
is
the
app
that
runs
there's
a
web
server,
and
this
is
actually
you
can
see-
we've
put
in
a
print
statement
here,
so
that
we
can
see,
because
this
is
not
serving
any
content.
B
The
app
is
doing
something
else
in
the
background
there's
a
job
that
we
want
to
run.
But
for
for
our
purposes
that's
not
super
important.
So,
let's
go
to.
B
B
So
one
of
the
things
I
want
to
point
out
here
is
that
we're
creating
a
pull
request.
We're
doing
this
because
we
have
things
pointed
at
the
main
branch.
We
have
flux
syncing
from
this
main
branch.
This
is
a
little
bit
aggressively.
Large
I
have
to
tone
it
down.
Sorry
I
hope
we
can
still
read
so
so
there
are
two
directories
to
look
at
here
now.
One
is
the
helm
chart
itself
and
there
is
where
flux
deploys
from
since
home.
Charts
are
not
deployed
directly
by
flux,
they're
deployed
through
another
set
of
automation.
B
That's
part
of
the
git
Ops
model
customization.
So
here's
our
Helm
chart
and
I'd
like
to
highlight
that
the
template
is
very
lightweight.
There's
actually
very
little
in
here.
If
you've
ever
written,
a
Helm
chart
you're,
probably
going
to
wonder
how
I
did
this,
because
this
is
probably
the
worst
part
of
writing.
Helm
charts
is
building
out
all
the
templates
and
filling
out
all
the
boilerplate.
Wouldn't
it
be
great
if
we
could
just
skip
all
that
stuff?
Well,
yes,
you
can
so
here's
our
chart
definition
chart.yaml.
B
And
how
do
we
skip
all
that
stuff?
We're
going
to
use
a
library
chart
so
I
had
never
heard
of
this
company
until
I
heard
of
the
helmet
company
info.
This
kind
of
sounds
like
a
made-up
company
I'm,
not
sure
how
much
I
trust
them,
but
Helm
releases
are
versioned.
So
we
know
that
this
isn't
going
to
change
out
from
under
us.
It's
immutable,
hopefully,
and
let's
do
see
how
that
build,
went
if
it's
still
going.
B
A
A
An
audience
question
so
gaurav
is
asking
we
need
to
make
a
commit
in
the
git
repo
for
previous
running
code.
Slash
image
and
flux
will
do
the
deployment
again.
B
Yeah
and
so
there's
something
we're
building
up
to
that,
we'll
see
in
the
next
example
and
I
kind
of
don't
want
to
go
over
that
point
yet
but
I.
So
the
question
that
you're
asking
I
think
is:
will
there
be
a
commit
that
we
can
roll
back
and,
and
the
answer
is
yes,
there
is
a
commit
that
you
can
roll
back,
but
the
first
example
that
we
looked
at
we
saw
automation
is
pushing
commits
to
our
working
branch
and
that
causes
extra
friction.
B
So
we
actually
want
to
avoid
that
we
we
want
to
migrate
from
the
latest
commit
determines
what's
deployed.
We
would
like
to
migrate
from
that
to
the
latest.
Released
version
determines
what's
deployed
and
we're
on
a
road
to
get
there
at
this
point
because
we're
creating
a
Helm
chart,
and
that
gives
us
something
versioned
that
we
can
publish
and
we're
not
publishing
it
yet
so
we're
actually
deploying
this
home
chart
from
the
master
Branch
here.
So
this
branch,
we'll
we'll,
show
the
other
directory
here.
B
This
is
our
deploy
basis,
and
this
is
very
similar
to
the
last
one
except
there's.
No
automation,
Primitives,
there's
no
flux,
automation,
resources
required,
and
this
is
to
help
understand
something
else
that
flux
will
do.
That
will
make
our
lives
easier.
So
we
have
a
Helm
release
and
it's
a
source,
ref
git
repository
type.
This
is
a
special
thing
that
you
can
do
in
flux
that,
depending
on
this
particular
setting,
what's
going
to
happen,
is
yes,
this
new
link
here,
let's
post
this
as
well.
B
So,
what's
going
to
happen,
is
we're
going
to
check
under
the
git
repository
for
a
directory
named
charts,
slash
mark
here
and
so
I'm
going
to
pronounce
that?
And
it's
got
to
be
in
the
main
branch
which
we've
defined
in
that
git
repository
as
as
actually
being
named
Master
here
and.
B
Sure
a
little
bit
further
yeah,
so
there's
not
much
to
see
in
here
it.
The
only
thing
that
I
would
highlight
is
there's
a
version.
That's
implicit
here.
Since
we
haven't
mentioned
a
version,
it's
just
going
to
deploy
the
latest
version,
whatever
metric
it
has
for
determining
what
the
latest
version
is
so
because
we're
using
a
git
repository,
that's
whatever's
in
the
latest
Branch.
If
you
want.
B
B
We'll
see
the
chart
kick
off
and
start
updating
itself
to
the
newest
version
and
what
has
changed
in
the
chart?
Actually,
nothing
there's.
This
is
another
thing
we
ought
to
look
at,
because
this
is
another
thing
we're
going
to
improve
in
the
next
example.
B
So
how
does
helmet
know
if
there
is
no
template?
What
to
deploy?
Well
all
of
the
important
details
go
into
this
values
file.
So
here
you
can
see,
we've
pointed
out
an
image
called
Canary,
and
that
is
the
image
that
we
build
on
any
branch
and
there
are
some
other
details
in
here.
How
is
the
port
exposed?
These
are
details
that
are
important
if
you're
serving
up
a
web
page,
for
example.
A
Good,
so
the
question
is
in
case:
there
is
a
requirement
to
do
a
backup
of
newly
deployed
codes,
last
images
and
as
flux
automatically
do
it
by
observing
the
new
deployment
status
or
new.
Commit
is
required.
C
So
Flex
will
apply
the
latest
manifest
in
the
repository
and
the
latest
images.
Using
whatever
is
specified
policy
you
have,
so
it
will
not
roll
anything
back
unless
that's
what
git
is
the
final
source
of
trip,
but
you
can
set
up
things
like
Flagger,
whatever
system
that
will
do
the
rollback
using
git
Ops
for.
B
You
yeah
and
there's
actually
like
about
three
large
exceptions
to
what
you
just
said
that
are
important
to
understand
here.
So
one
of
the
things
to
note
is
you
can
do
testing
in
the
helm
chart
you
can
do
testing
in
a
pod
with
a
health
check
and
those
tests
will
help
determine
whether
the
release
is
going
successfully
or
not
so
I
haven't
created
any
health
checks
for
this.
B
So
when
this
pod
rolls
out
as
long
as
it
runs,
then
the
release
is
okay
as
far
as
kubernetes
is
concerned,
so
so
we
have
to
kind
of
Leverage
these
tools
in
order.
We
want
to
use
the
health
checks
first,
because
that
will
help
kubernetes
know
whether
this
pod
is
healthy
or
not,
and
that's
the
only
signal
that
Helm
can
use
to
tell
us
if
the
release
is
okay,
then
down
the
line.
B
Flux
can
look
at
that
signal
from
Helm
and
say
this
release
is
a
success
or
not,
and
you
can
configure
remediation
strategies
in
flux
to
say
what
should
we
do
when
a
release
has
failed?
If
you
want
it
to
be
rolled
back
immediately,
then
you
can
configure
that
remediation
strategy.
So
that
it's
rolled
back
immediately.
B
B
Configuring
failure
remediation,
so
this
is
here's
that
version
line
that
I
mentioned
that
we
aren't
using.
Yet
we're
going
to
see
it
in
the
next
example.
B
But
here
the
here
are
the
parameters
for
remediation,
and
you
can
see
that
there's
a
different
thing
that
you'd
like
to
do
on
install
and
upgrade
because
actually,
if
it's
a
failed
install,
we
can't
there's
nothing
to
roll
back
to
so
we'd
like
to
retry
and
if
the
upgrade
fails.
Actually
this
example
says
no,
don't
retry
just
let
it
fail,
don't
remediate
the
failure.
B
So
this
upgrade
that
failed,
doesn't
represent
an
incident
in
production
or
maybe
it
represents
an
incident.
But
it's
a
different
class
of
incident.
We're
not
serving
up
a
dead
release
to
end
users
right,
it's
just
there
in
production.
It
needs
to
be
remediated
by
someone,
but
we
we
can
configure
that
to
happen
automatically.
If
you
want
here
and
then
there
is
no
commit
that
represents
that
remediation
so
that,
hopefully
that's
a
good
answer
for
your
question.
A
B
B
Well,
yeah:
let's
see
what
was
the
other
question.
A
B
Good
question:
okay!
So
what
we're
showing
we
actually
want
to
get
away
from
the
idea
of
using
separate
branches
in
this
progression
in
this
Evolution,
so
we're
starting
with
a
Dev
Branch,
because
that's
the
easiest
thing
to
conceptualize
and
because
we
can
configure
automation
to
push
to
a
Dev
Branch
without
breaking
everybody's
workflow
right.
If
you're,
not
on
that,
Dev
Branch,
you
won't.
You
won't
even
notice
that
those
commits
are
in
the
way
because
you're
on
a
different
branch.
B
So
that's
why
we
start
with
the
dev
branch,
but
in
in
most
of
the
flux
docs,
you
will
find
that
they
do
not
advise
you
to
use
separate
branches,
and
that's
because
inside
of
the
branch
is
a
ref
that
points
to
the
branch.
And
what
do
you
do
when
you
merge
if
you've
got
a
git
Repository
here
that
points
to
a
branch
that
we're
deploying
from
and
now
we
want
to
merge,
but
this
ref
is
still
going
to
be
pointed
at
that
Old
Branch.
B
So
so
this
is
the
main
reason
why
we
want
to
get
away
from
using
branches
as
a
instrument
of
deployment
right.
We
want
to
use
the
branch
as
a
place
to
review,
to
run
CI
and
then
once
it
merges,
then
it
gets
deployed.
That's
the
idea.
B
So
we're
trying
to
move
away
from
simple
trunk-based
workflows
that
don't
version
and
we're
trying
to
move
towards
versioning.
So
one
thing
we
didn't
see:
let's
look
at
that
deployment
or
that
pod.
B
We
didn't
see
what
Helm
is
doing
with
that
that
version.
B
So
we
had
this,
we
saw
this
version
in
the
chart.yaml
really
briefly,
this
one
came
from
flux
when
flux
found
that
there
was
a
new
commit
and
we
had
that
revision
strategy
set
Flex
said
well,
Helm
charts
are
immutable,
so
I
need
a
new
version
if
I'm
going
to
have
a
new
chart,
and
so
it
reconciled
a
new
version
and
then
our
deployment
went
out-
and
here
is
the
other
thing
I
want
to
notice
in
here
is
I
think
we
already
saw
this
we're
just
using
colon
Canary.
So
this
is
again.
B
This
is
not
an
ideal
deployment
strategy,
because
this
is
like
latest
this
image.
Doesn't
this
tag
you
know
should
change
over
time,
but
we're
we're
going
to
show
in
the
next
example
how
we
can
do
that
as
part
of
the
release
workflow,
because
we've
already
seen
how
we
can
use
automation
to
change
that
tag
so
and
we've
seen
how
we
can
run
a
file
of
that
and
it
can
be
kind
of
irritating,
depending
on
the
context.
So
we've
got
these
two
examples
in
opposition
and
now
we're
going
to
switch
I.
Think
to
the
next
example.
B
B
B
If
you
have
a
Helm
chart
and
you're
wondering
how
can
I
release
it
as
oci
well,
this
is
what
I
would
suggest.
First,
it's
actually
really
easy
to
build
the
oci
release
workflow
into
your
release,
workflow,
but
we
wanted
to
have
an
action
I
think
most
people
want
to
have
an
action
that
they
can
point
at
that'll
handle
the
hard
Parts
when
we
get
to
it.
So
so
this
is
an
action.
That's
it's
not
published
by
Helm
official
and
I'm,
going
to
show
the
helm
official
action
for
a
moment
to
explain
why.
B
Start
release
or
action
okay,
so
this
is
an
open
feature
request.
We
would
like
to
add
support
for
pushing
charts
to
oci.
We
mentioned
that
this
is
a
new
feature
in
flux.
It's
oci,
Helm
charts,
it's
a
new
feature
in
Helm
as
well,
so
there
are
places
where
the
support
is
lacking.
I
think
this
is
the
most
popular
chart.
Releaser,
probably
a
lot
of
people
are
using
this
to
push
their
charts
to
GitHub
pages
and-
and
this
probably
will
work
for
almost
everyone
for
a
long
time.
B
So
why
doesn't
it
work
very
well
because
of
the
structure
of
a
Helm
repository,
the
Legacy
kind?
There's
this
index.yaml
file,
where
all
of
the
metadata
for
all
of
the
releases
for
all
of
the
different
applications
that
are
on
this
repository
is
collected
in
Aggregate
and
every
time
a
new
release
comes
out.
Whoever
consumes
the
helm
repository
has
to
download
that
entire
index.yaml
again,
even
if
only
a
small
part,
has
changed.
B
B
B
I
think
it's
called
Bart
yeah.
Here
we
go
anyone
familiar
with
fermion
in
the
audience.
This
is
the
Bartholomew
who
hasn't
blog,
nothing
to
see
here.
It's
pretty
cool
I
like
it
I'm
going
to
build
a
website
on
it
and,
as
you
can
see,
I've
already
started
okay.
So
if
we
go
to
slash
blog,
we
can
see
the
title
of
the
page
here.
It
says
hello
get
Ops,
let's
make
something
a
little
more
visible,
since
that's
kind
of
thank
you
small.
B
By
the
way,
if
you're
not
familiar
with
this
GH
tool
that
I'm
using
to
watch
the
workflow
runs,
it's
really
very
similar
to
what
you
see
on
the
GitHub
actions
view.
But
maybe
this
is
a
little
bit
easier
to
follow.
If
we
go
see,
here's
our
new
action
that
we're
running
and
we've
got
a
couple
of
things
that
run
in
parallel.
We
can
see
that
that's
happening
over
here
too,
but.
C
Running
there's
a
question:
how
would
you
handle
different
environment
settings
using
githubs.
B
So
we
have
two
environments
that
we'll
deploy
this
to.
One
is
called
test
and
the
other
is
called
stage.
Let's
look
at
those
environments.
Where
are
those
defined?
Here's
one
more
repo?
This
is
where
all
of
these
examples
are
collected
and
deployed
from
Kingdom
CI,
slash,
Fleet
infra.
So
this
is
our
cluster
Repository.
A
There
was
also
a
question
from
the
audience
on
the
recording
of
this
meeting
or
this
event
and
no
worries.
This
is
going
to
be
available
essentially
immediately
after
this,
in
the
cncf
YouTube
channel,
under
the
lives
or
in
the
playlist
for
cloud
native
live,
so
you
can
find
it
there
immediately.
So
you
can
always
check
back
on
the
recording,
no
worries.
B
So
what
we
want
to
see
in
our
test
and
Stage
environments
is
what's
different
between
these
environments
and
what's
what's
promoted,
exactly,
let's
see
if
we're
deploying
things
before
we
get
any
further.
B
Okay,
so
we're
pushed
into
a
branch,
so
nothing
should
be
deployed,
and
in
this
Helm
release
we
have
a
version
pin
here
and
ideally,
in
my
perspective,
this
is
how
we
handle
a
difference
between
environments
is
by
creating
a
parallel
structure
in
both
environments.
So
we
know
that
this
test
environment
here
is
called
bart.howard
here
and
if
we
go
to
look
at
the
other
environment,
we
can
see
that
it
has
a
different
DNS
name
here.
B
So
this
is
using
Helm
repository
source
and
that's
where
we
publish
our
release
artifacts
too.
So
what
we?
What
we
want
to
see
is
the
test
environment
deploys
as
soon
as
we've
merged
our
change
to
main
see
it's
a
git
repository
source
and
then
the
production
environment
or
the
staging
environment
is
going
to
deploy
as
soon
as
we've
published
our
release
to
the
helm
repository,
and
these
should
behave
the
same
except
they
have
values
that
are
not
the
same.
B
So
this
one
says
they're
both
in
this
public
Ingress
class
they're,
both
using
TLs,
but
they
have
a
different
host
name
and
you
can
configure
them
differently
if
you
need
to,
but
does.
C
A
Ahead
yeah,
there
was
a
question
in
the
audience
as
well.
Do
you
think
flux
is
better
than
Argo
CD.
B
B
They
are
separate
projects
for
different
use
cases,
Stacy
you're,
exactly
right
about
that.
Thank
you.
So
flux
from
my
perspective
is
better
for
infrastructure.
Builders,
it's
better
for
platform
teams.
It
gives
you
a
little
bit
more
control,
whereas
Argo
maybe
gives
you
a
bit
more
flexibility
in
a
couple
of
ways:
I'm
not
going
to
go
into
detail
about
that
because
we're
almost
finished
here
we
can.
We
can
talk
more
about
that
at
the
end,
but
I'd
like
to
see
this
full
release
happen.
B
So,
okay,
so
what
we've
got
is
we've
got
to
merge
this
pull
request.
Where
did
we
create
a
pull
request
yet.
A
B
And
because
this
is
going
to
be
a
new
release,
there's
a
few
extra
things
we
have
to
do.
I
said:
there's
some
friction
that
we're
going
to
add
we're
going
to
solve
the
friction
with
automation
too.
So
so
we've
got
this
make
file
it's
a
little
bit
complicated,
but
the
main
thing
to
look
at
is
here
at
the
top.
We
have
these
two
versions
that
we
can
use.
Tag,
that's
the
app
version
and
sound
vert
here
is
supposed
to
be
the
chart
version
and
we've
got
these
workflows.
B
B
B
I
am
still
committing
it
to
this
Branch.
We
could
commit
it
to
either
Branch
this
part.
Actually
it
could
be
done
before
or
after
the
merge.
That's
a
good
question
and
we
also
have
to
update
the
chart
version.
B
B
B
B
We
had
some
issues
with
GitHub
this
morning.
I
don't
know
if
anyone
was
watching
the
status
dashboard,
but
I
really
was
nervous
about
this.
Everything
went
green
about
five
minutes
before
we're
supposed
to
go
live,
and
this
is
the
part
where
we
really
need
all
those
things
to
be
working
so
make
release
app
first
here,
I
want
to
push
this
and
merge
that
change
and
then
we'll
do
make
release
app.
This
is
going
to
get
tag
and
push
the
tag.
B
So
this
is
you
could
do
this
manually
or
you
could
build
this
into
your
release
workflow,
but
this
is
how
we
push
an
image.
B
B
C
B
B
B
My
goal
is
to
help
you
understand
how
you
can
adopt
Helm,
but
also
to
help
you
understand
how
this
is
not
the
tool
for
every
job.
There
are
different
tools
for
different
jobs,
just
like
we've
seen
with
Argo
influx.
There
are
different
tools
and
Hell
may
not
be
the
template
tool
to
solve
every
problem,
but
we've
used
it
to
solve
this
problem.
B
B
Okay,
so
well,
we
still
have
a
couple
of
minutes.
We
have
time
for
more
questions.
Adiosis,
do
you
have
any
questions
at.
B
Me
too,
maybe
we
want
to
look
at
some
of
this
example
in
a
little
bit
more
depth
to
see
what
what
we've
deployed
exactly.
A
Yeah
I
think
that
sounds
good
and,
while
that's
happening
audience
feel
free
to
write
your
comments
and
questions
in
so
that
we
have
the
time
to
go
through
them.
B
Yeah,
so
this
is
a
good
question.
We
had
only
one
branch,
that's
configured
for
deployment
and
we
pushed
to
multiple
environments.
Yes,
that's
correct.
Let's
look
at
the
two
environments.
Now
the
environments
are
designed
here
in
this
separate
repository
and
this.
This
is
something
that's
Up,
For
Debate.
Do
you
take
the
environment
definitions
from
the
app
itself
or
do
you
keep
them
in
a
place?
That's
more
closely
tied
to
the
cluster.
Those
are
options.
So
here
we
have
Helm
Repository.
B
B
So
if
we
look
at
the
other
environment,
we'll
see
the
same
thing
there,
except
we're
not
using
the
git
repository
for
anything.
But
yes,
it's
deploying
from
Branch
Maine,
and
this
can
cause
problems
as
well.
So
the
really
nice
thing
about
our
oci
repository
example
is
yes,
it
depends
on
the
release
cycle.
B
If
we,
if
we
want
to
deploy
things
from
versioned
releases,
only
oci
is
great
if
we
want
to
change
our
version
strategy
so
that
we
version
a
different
way
like
so
that
developers
don't
actually
have
to
create
semantic
version
numbers
for
every
single
release,
then
you
can
do
the
same
thing:
the
the
differences,
okay.
So
there's
one
thing
I
wanted
to
show
here.
Let's
see,
where
is
this.
C
Maybe
related
to
this:
did
we
look
at
specifying
versions
in
version
constraints
in
in
Helm.
B
B
So
this
is
going
to
scan
our
Helm
repository
for
versions
that
match
that
constraint
and
it's
going
to
deploy
anything
it
finds,
because
this
is
also
this
Helm
repository
of
type
oti
is
also
an
image
repository
structurally
oci
and
Docker
they're.
The
same
standard
under
the
hood
or
oci
is
a
superset,
I
guess
of
the
standard.
B
Also
use
image
update
Automation
in
this
place,
so
if
you
have
a
requirement
that
actually
I
heard
someone
ask
earlier,
is
there
a
commit
that
I
can
roll
back?
This
is
the
place
where
you
can
insert
that.
So
we
saw
in
the
very
first
example
how
you
can
monitor
an
image
repository
for
changes
and
then
deploy
those
changes
by
updating
a
yaml
with
the
new
tag.
Well,
that's
what
we
would
do
here
if
we
really
wanted
to
to
have
a
commit
that
we
can
roll
back.
B
That
represents
the
rollout,
but
in
this
environment,
in
this
particular
environment
we
haven't
got
thousands
of
releases
yet
and
that's
unnecessary.
Friction
we
don't
want
to
add.
We
don't
want
to
have
to
have
create
those
extra
image,
update,
automation,
resources,
we'd
like
to
just
be
able
to
say
source,
applier
and
pair
them
together
and
and
let
those
do
their
job.
So
where
this
says
version
there
is
another
trick
that
we
can
use
if
we
are
using
a
git
repository
or
a
Helm
repository
I.
B
Think
actually
sorry,
not
only
git
repository
and
oci
repository
Source
we'll
do
this.
Where
is
it
Helm?
Repo?
Okay?
Let's
make
a
change
here
to
this.
B
So
what
I
can
do
here?
Oh
this
is
where
vs
code
is
going
to
help
actually
I'm
going
to
pull
up
this
example
in
vs
code,
because
vs
code
has
a
little
bit
of
awareness
of
the
yaml
because
it's
connected
to
our
cluster
and
it
knows
about
these
yaml
types.
So
if
we
go
into
this
environment-
and
we
open
this
up
all
right,
so
what
we
want
to
do,
we'd
like
to
use
the
git
repository
again
for
some
reason,
maybe
we've
decided
that
oci
is
too
fresh
and
we're
not
ready
to
adopt
it.
Yet.
B
Same
thing,
we
said
in
the
other
guy
all
right,
so
we're
going
to
put
that
there
and
then
in
our
Helm
release
we're
going
to
change
this
to
use
the
git
Repository,
and
this
no
longer
matters
this
one
I
think
we
can
leave
as
chart
version
because
we
are
actually
tagging
and
releasing
versions.
We
are
actually
changing,
chart.yaml,
where
the
version
number
is,
but
you
could
change
it
to
revision
here.
If
you
weren't
doing
that.
B
C
B
But
what
I'm
trying
to
show
here
is
that
oci
doesn't
drastically
change
things
in
a
way.
That's
unreversible,
if
you,
if
you
haven't
yet
adopted
oci
most
of
the
same
options
are
still
available
to
you
for
the
git
repository.
So
you
can
do
this
with
an
oci
repository
or
you
can
do
this
with
a
Helm
release.
The
version
spec
goes
in
one
of
those
three
places
in
the
git
Repository
in
the
oci
repository,
which
has
the
same
structures,
git
repository
or
in
the
helm,
release.
B
And
how
will
we
know
that
it's
switched.
B
B
B
I
think
I'm
looking
for
this
FAQ,
or
maybe
it's
here-
this
one
refer
to
values
and
config
Maps
generated
with
customize
all
right.
Maybe
this
is
the
page
we
were
on
already,
so
there
are
three
or
four
good
examples
over
here
that
are
in
succeeding
order
of
difficulty.
The
very
first
one
is
about
generating
a
config
map,
I
think
here,
and
you
can
use
this
to
refer
to
values
from
a
config
map.
Okay,
so,
but
you
said
with
Sops,
that
is
the
hardest
example.
B
We
don't
have
time
to
cover
all
three
of
these
today,
but
we
do
have
this
documented.
How
do
you
use
Sops
with
a
Helm
release
and
a
secret
generator
and
spoiler?
This
solves
one
of
the
problems
that
we
saw
in
the
very
beginning
is
how
do
we
get
our
deployment
to
reload
when,
when
things
are
upgraded,
we
actually
need
a
secret
to
be
changed,
the
content
of
the
secret
changes
and
that
needs
to
filter
down
to
the
helm,
release
which
should
also
change.
B
So
what
we
see
here,
values
pod
info
values,
is
a
name
of
a
config
map
or
a
secret,
rather
that
we've
encoded
in
encrypted
in
yaml,
and
then
we're
decrypting
here
and
we're
using
customize
config
to
locate
this
reference
here.
Spec
values
from
name,
here's
spec
values
from
name
and
it's
going
to
take
and
dynamically
update
this
reference,
so
that
every
time
you
have
a
new
version
of
this
Secret,
the
helm
release
will
get
a
new
version
as
well.
So
that
upgrades
proceed
immediately.
A
Yeah
and
then
there
was
the
final
question:
I
think
we
have,
the
import
is
oci
repository
question
mark.
Is
it
a
version
controller
like
git
question
mark
or
an
image
repo
like
docker.
B
Yeah
it's
a
little
bit
of
both,
so
the
oci
repository
in
flux,
that's
been
added.
The
best
documentation
right
now
is
probably
under
the
resources,
but
then
there's
also
this
more
expansive
cheat
sheet
version.
That
shows
how
we
expect
oci
to
work
their
their
short
answer.
Is
it's
supposed
to
be
an
extension
of
your
git
repository.
It
doesn't
replace
the
git
repository.
It
has
traceability
back
to
the
git
Repository,
so
here's
an
oci
repository
definition.
B
And
here's
a
customization-
that's
pointed
at
that-
and
here's
some
more
examples,
foreign-
and
this
is
the
workflow
that
we
expect
people
to
use.
So
the
user
pushes
to
the
git
repository
which
triggers
a
CI
job.
Then
you
build
an
image
for
container
registry
and
the
only
thing
that
changes
at
this
point
is
we're
not
only
building
a
runtime
app
image,
we're
also
building
something
like
a
chart.
It's
an
oci
repository
artifact.
B
It's
not
a
template
in
the
sense
that
a
Helm
chart
is
a
template
with
holes,
punched
out
that
the
user
is
meant
to
fill
in,
but
it
is
in
that
in
that
same
spot
in
the
workflow.
So
what
this
really
enables
us
to
do
is
it
enables
us
to
avoid
creating
a
right
credential
for
that
first
example.
We
want
the
first
example
to
be
able
to
write
back
to
a
git
repository.
We
expect
that
this
is
the
first
thing
that
your
security
team
will
block
at
say.
B
A
A
It
was
great
to
have
a
session
about
automating
communities
deployments
here
today,
and
we
also
really
love
the
introduction,
interaction
and
the
questions
from
the
audience
always
great
to
see
those,
and
we
always
bring
you
the
latest
Cloud
native
code,
every
Wednesday,
so
in
the
coming
weeks,
there's
going
to
be
more
great
sessions
coming
up
so
tune
in
then.
Thank
you
for
joining
us
today
and
see
you
all
next
week.