►
From YouTube: TGI Kubernetes 142: Carvel
Description
Come hang out with Josh Rosso as he explores the Carvel toolset! In this episode we'll explore the various pieces that compose this packaging and deployment solution!
A
almost
that
150
mark
how's
it
going
everyone
if
you're
just
joining
us
feel
free
to
say,
hey
in
chat,
it's
a
bit
of
tradition
to
kind
of
say
where
you're
signing
in
from.
If
you
feel
comfortable,
we
have
a
pretty
big
audience
from
all
over
the
world,
so
we're
super
glad
to
have.
You
looks
like
so
far.
We've
got
rory
joining
from
scotland.
It's
great
to
see
you
rory
got
haim
from
israel,
rupesh,
hey
rupash,
noel
great,
to
see
you
noelle,
martin
great,
to
see
you
as
always
from
the
netherlands.
A
A
So
just
looking
at
a
white
wall
there,
hey
michael
nice,
to
see
you,
we
got
savvy
from
istanbul,
hey
savvy
rescind
from
poland
great
to
have
you
all
right.
Let's
see
great,
to
see
everyone
signing
in
here.
So,
let's
just
flip
my
screen
over
to
the
desktop
today's
episode.
We're
gonna
be
talking
a
little
bit
about
carvel,
which
is
a
really
cool
tool
set
that
I'm
excited
to
explore.
It's
something
that
I'll
be
using
for
some
projects
that
we're
working
on
right
now
at
vmware.
A
So
I'm
kind
of
excited
to
learn
a
bit
about
some
of
the
tool
set
with
y'all
and
kind
of
see
what
you
think
and
and
get
some
feedback
and
thoughts
who
else
we
got
joining
us
so
far,
so
we
saw
michael
youssef
from
morocco.
Hey
it's
nice
to
see
you
too
again,
youssef
kr
from
scotland,
orada
from
scotland
good
to
see
you
here.
A
Bee
from
london,
we've
got
keith
from
ireland
he's
signing
in
from
ireland:
hey
keith
danielle
daniel
from
san
jose
elko
from
holland,
wow
cool
we've
got
a
pretty
big,
pretty
big
audience
today,
kana
great
to
see
you
happy
to
I'm
glad
you're
here
to
learn
we're
going
to
both
learn
some
stuff
together
for
sure
khakjan
in
argentina,
juca,
helsinki
rupash
from
south
africa,
hey
how's
it
going.
We've
got
joe
hanging
out
as
well
before.
A
So
if
anybody
from
carvel
is
here
feel
free
to
say
something
in
chat
that
you're
from
the
carvel
team
and
you'll
probably
help
us
out
as
we
play
around
here
and
learn
a
bit
about
the
carvel
tool
set
all
right
so
carvel.
What
do
we
got
going
on
this
week?
And
I
guess
let
me
just
I'll
back
up
and
get
ahead
of
myself.
A
It
was
a
pretty
crazy
week.
This
week,
I'm
not
gonna
lie.
So
if
anybody
has
things
that
are
happening
in
the
kubernetes
ecosystem
that
you
want
to
add
and
have
us
talk
about
you're
welcome
to
edit
this
doc,
you
can
go
to
tgik.io
forward,
slash
notes
and
add
any
any
news
items
in,
but
I
have
a
very
short
update
this
week.
A
One
is
that
there's
been
some
new
kubernetes
releases
so
check
that
out,
if
you're
in
17,
18,
19,
20
or
21
land,
I
guess
if
you're
testing
out
21
there
are
new
releases,
so
do
check
those
out.
You
know
figure
out
what
you're
going
to
do,
update
wise
and
get
all
that
pulled
together,
and
the
only
other
thing
that
I've
got
this
week
is
manuel
from
ingress.
A
Nginx
is
stepping
down,
and
I
wanted
to
call
this
one
out
in
particular,
because
back
in
like
how
long
ago
was
it,
it
was
like
kubernetes
1-4
or
something
like
that.
We
myself
and
some
co-workers
wrote
what
eventually
became
the
alb
ingress
controller,
and
I
think
amazon
just
calls
it
or
sig
sig
aws
just
calls
it
like
the.
A
What
is
it
called
now
that
someone
probably
knows
in
chat,
it's
like
the
amazon
or
the
aws
ingress
controller,
because
it's
more
like
general
purpose
than
alb
now,
nonetheless,
what
I'm
trying
to
tell
you
is
manuel
was
extremely
helpful
not
only
in
shaping
ingress
over
time,
but
obviously
being
a
huge
proponent
to
ingress
nginx.
I
remember
when
we
were
writing
our
controller.
He
helped
do
code
reviews.
A
He
helped
us
with
some
of
like
the
core
library
stuff
for
ingress,
which
I
think
now
most
folks
are
using
like
controller
runtime,
but
back
in
the
day,
I
think
we
actually
had,
like
a
library
called
ingress
or
something
like
that.
I
can't
I
can't
really
remember.
Nonetheless,
he
was
extremely
helpful
to
us,
and
I
know
that
a
lot
of
us
have
been
impacted
by
his
work
because
who
hasn't
deployed
an
ingress
engine
x
controller
at
some
point
in
their
kubernetes
history.
Right,
we've
all
done
it.
A
You
know
whether
we're
running
nginx
today
or
not
is
another
story,
but,
like
we've
all
deployed
this
thing
and
this
human
has
had
a
big
impact.
So
thanks
so
much
for
all
your
work
and
yeah.
I
don't
I
don't
know
what
you're
doing
next,
but
best
of
wishes
to
you
all
right.
So,
let's
see
what
we
got
going
on
cool.
So
we
have
some
folks
from
the
carvel
team.
Joining
us
looks
like
we've
got
helen
aaron
thanks
so
much
for
joining
us
folks
glad
to
have
you
in
chat.
A
A
So
let's
look
a
little
bit
into
carvel.
I
guess
it's
good
that
the
newsweek
is
light.
This
week
I
have
a
bit
of
a
hard
stop
at
the
top
of
the
hour,
so
we'll
get
to
we'll
get
to
spend
as
much
time
as
possible
digging
into
to
the
carvel
toolset.
So
let's
do
some
framing
real
quick
chat.
Help
me
out
here.
A
We
have
a
lot
of
tools
to
do
a
lot
of
different
things
with
packaging,
with
deployment
with
lifecycle,
management
of
bits
and
kubernetes
right.
So
what
do
you
all
use
for
these
types
of
things?
Let
me
know
in
chat.
Some
of
you
probably
use
helm.
Maybe
some
of
you
are
using
carvel.
Maybe
some
of
you
are
using,
like
I
don't
know
like
an
argo
cd
workflow
or
something
like
that
to
kind
of
deploy.
A
Let
me
know
in
chat
what
what
what
do
you
use
at
your
org
right
now
to
to
maybe
package
apps
or,
if
not,
package,
even
deploy
them?
Just
you
know
give
me
give
me
kind
of
your
your
tool
set
your
stack
that
you're
you're
currently
using
michael
says,
helm
coke
jen,
you
said
helm
v2,
oh
you're
migrating
to
v3
at
the
moment.
Good,
I'm
glad
I'm
glad
you're
getting
on
that.
Definitely
definitely
important
to
to
knock
that
out.
A
Okay,
cool,
seeing
fully
geared
bare
argo
cd
with
json
at
workflow,
cool,
interesting
that
you
got
a
json
at
workflow
going
and
argo
cd
and
some
of
the
other
ones
are
obviously
gaining
popularity.
Flux
controller
is
one
I
think,
we've
done
with
with
steve
wade
right
back
in
the
day.
A
lot
of
these
git
ops
workflows
are
emerging
and
becoming
more
popular,
seeing
some
more
flux,
get
ops
tool,
kit,
yup,
absolutely
hey,
maddie
cap
deploy
and
cap
inspector
rock
awesome,
very
cool.
A
Are
you
using
that
today,
manny
and
yeah,
and
then
bojancha?
You
said
palumi,
helm,
spinnaker,
so
you've
got
a
pretty
diverse
stack
of
things
there
like
a
pure
code
approach.
You've
got
helm,
probably
doing
templating
and
life
cycle
management
to
some
degree,
and
then
argo
cd,
probably
facilitating
the
deployments
right
so
cool
all
right.
So
let's
talk.
Let's
talk
a
little
bit
about
the
carvel
tool
toolset
and
what
we're
going
to
focus
on
today.
So
carvel
has
a
newish
website.
A
If
you
all
have
not
checked
it
out
yet,
and
I
do
have
it
in
the
show
notes.
Although
it's
pretty
easy
to
remember,
it's
just
carvel
dot
dev
and
I
think
one
of
the
interesting
things
about
carvel
is
that,
instead
of
being
kind
of
like
a
one-size-fits-all
tool
that
does
all
the
things
end
to
end,
it
kind
of
breaks
the
different
problems
into
small
chunks
and
then
follows
you
know
the
kind
of
do
one
thing
well:
philosophy
to
what,
to
whatever
extent,
that's
possible
in
individualized
tools
right.
A
So
some
of
you
might
remember
a
tgik
that
joe
did
a
while
back
and
I
think
joe
focused
on
I
could
be
wrong,
but
I
think
it
was
ytt
and
cap
primarily.
So
when
we
kind
of
look
at
the
different
problems
that
we
need
to
solve
for
right,
one
of
the
problems
that
we're
oftentimes
solving
for
is
how
do
we
templatize
parameters?
A
You
know
et
cetera
the
the
different
the
different
manifests
and
all
the
things
that
we're
trying
to
do
right
and
then,
once
we've
got
all
those
different
bits
templatized.
We
also
need
to
figure
out.
How
are
we
going
to
actually
deploy
the
thing
right?
This
is
just
I'm
putting
I'm
making
very
broad
buckets
here,
right
and
kind
of
including
potentially
multiple
tools
in
each
of
these.
A
Of
course,
you
know
even
maybe
a
step
before
all
this
before
we
worry
about
like
templatizing
and
parameterizing,
our
manifest
that
we
eventually
get
into
cube.
We've
obviously
got
the
need
to
build
to
have
kind
of
a
build
step
in
there
to
some
degree,
so
creating
a
container
image.
You
know,
building
our
probably
within
our
container
image,
with
like
a
build
image
or
something
actually
building
the
the
binary
or
the
assets
that
are
going
to
run
inside
of
the
application
right.
A
We've
got
deploy,
templatize
and
there's
a
whole
other
kind
of
a
whole
other
kind
of
grouping
of
things
that
we
might
care
about
here
right,
we
might
care
about
things
like
well.
How
do
we
take
this
approach
like
deploy
and
how
do
we
do
it
in
a
git
ops
model
right
or
how
do
we
do
it
from
a
cli
and
so
on?
And
when
we
look
at
these
different
problem
domains,
carvel
has
tools
that,
let
us
do
all
these
different
pieces
right
or
at
least
some
of
these
different
pieces.
A
Ytt
is
a
is
a
templating
language
right.
So
that's
something
that
we
can
go
in.
We
can
templatize
or
parameterize
certain
fields
in
the
manifest
we
can
inject
values
in
all
that
good
stuff
cap,
as
we've
seen
with
joe
in
the
past,
is
something
that's
going
to
enable
us
to
actually
deploy
and
do
life
cycle
things
with
packages
that
we
deploy
into
the
cluster
as
well.
A
A
So
one
of
the
one
of
the
kind
of
interesting
things
that
we
we
think
about
when
we're
actually
going
in
and
kind
of
starting
off
our
processes
is
oftentimes
the
idea
of
building
images,
pushing
them
and
making
sure
that
they
resolve
consistently
in
our
environment
right.
So,
let's,
let's
think
about
the
space
a
little
bit
and
kind
of
what
what
this
build
box
might
might
actually
do
so.
A
What
kubernetes
is
going
to
do.
Is
it's
going
to
essentially
resolve
the
image
that
we
specify
right
now?
One
of
the
things
that
we
want
to
kind
of
look
at
in
each
of
these
different
pieces
is
how
we
can
effectively
do
each
one
of
these
steps
like
starting
off
with
creating
an
image.
So
you
know
what
how
what
ways
can
we
create
an
image
so
chat?
I'm
going
to
ask
you
again
here
when
you
build
container
images.
What
do
you
use
today?
Are
you
using
docker?
Are
you
using
just
pure
build
kit?
Are
you
using?
A
A
So
I
see
some
docker
with
build
kit
since
buildkit
is,
is
a
first
class
citizen
and
docker
now
right,
so
that
totally
makes
sense,
basil
and
docker
yep.
Absolutely
we've
got
get
lab
runner
running
docker
right
yusuf,
you've
got
jib,
which
jib
is
going
to
enable
us
to
do
java
based
builds
in
a
really
elegant
way
and
allow
us
to
kind
of
put
layers
in
place
in
that
in
that
jar
that
we
eventually
create,
so
that
we're
not
always
repackaging
a
full
jar.
A
Does
some
fancy
stuff
joe
says:
we've
got
kaneko
yep,
absolutely
so
there's
we
have
a
lot
of
ways
to
to
do.
Some
of
these
different
builds
right
and
actually
creating
the
image
so
with
a
tool
like
kbld
we're
going
to
look
at
how
we
can
generate
some
of
these
builds
through
potentially
different
technologies.
A
Different
providers,
as
it's
probably
going
to
be
referred
to
docker,
build
packs
and
otherwise,
and
then
you
know
one
of
the
big
things
that
a
lot
of
these
tool
sets
or
the
carvel
kind
of
tool
set,
I
think,
does
a
really
great
job
of
is
making
sure
that
we're
referencing,
something
that
is,
reproducible
referencing,
something
that
is
that
is
knowingly
consistent
when
we
redeploy
it
move
it
around
and
so
on.
And
you
know,
if
you
even
kind
of
think
about
this
for
just
a
moment
right.
A
We
all
know
the
old,
the
tweets
that
come
out
that
are
like
never
use
latest
it's
the
worst
thing
you
could
ever
do
in
the
entire
world
and
people
will
be
hurt.
If
you
do
it
and
it's
it's
a
good
piece
of
advice
right
because,
like
you
think
about
a
tag
like
latest
and
latest
changes
over
time,
so
like
when
an
enviro
something
happens
in
an
environment
in
one
place,
you
might
you
have
no
idea
like
what
what
what
was
latest
and
also
in
this
iteration
of
a
cluster.
A
What
does
latest
actually
represent
right
and
if
you
kind
of
think
about
that
for
a
moment
like
it's
probably
well,
it's
not
probably
it's
definitely
way
better
to
do
something
like
1.0.2
like
significantly
significantly
better
to
do
something
like
this.
But
what
is
this
right?
It's
a
tag.
So
can
I
rewrite
1.0.0.2?
A
Can
I
change
the
underlying
image
that
gets
represented
in
it
right?
Am
I
guaranteed
that
it's
going
to
be
the
same
thing
in
most
environments
now,
in
almost
all
the
cases
that
we
probably
run
into?
There's,
no
doubt
that
we
that
you
know
using
these
tags
is
consistent
and
people
have
really
elegant
pipelines
in
that
they
would
never
overwrite,
theoretically
a
tag
and
so
on
and
so
forth.
A
We
want
a
way
to
guarantee
consistency
in
our
builds
consistency.
In
this
case,
I
guess
in
our
run
time
even
right.
So
these
are
the
kinds
of
concerns
that
we're
going
to
be
looking
at
with
kbld
and
now
maybe
I'll
shut
up
and
we'll
actually
try
try
to
try
to
make
it
work.
What
do
you
say?
So?
What
do
you
think
chat?
A
Let's
see
what
we
got
going
on
here,
so
I
am
going
to
flip
over
to
my
terminal.
Okay
and
let's
see
if
we
can
get
get
this
kind
of
bootstrapped.
In
fact,
we'll
we'll
actually
go
over
one
of
the
one
of
the
guides
here
in
the
docs.
So
we'll
go
to
examples
and
all
right.
Where
were
my?
Where
are
my
docs?
I
was
looking
at
earlier
documentation
there.
A
If
you
will
into
that
digest
format
such
that
we
can
have
some
amount
of
guarantee
that
the
thing
is
going
to
that
the
thing
is
going
to.
Actually,
you
know
be
again
a
consistent
experience
across
all
the
different
places
that
we
might
be
deploying
to.
So,
let's
try
this
out
real,
quick,
resolving
image
references
to
digest.
This
should
probably
be
exactly
what
we
talked
about
so
speaking
of
ingress
engine
x.
A
A
great
and
we
will
do
the
enginex
yml
file
the
there.
We
go
all
right,
so
we've
got
the
image.
We've
got
nginx
14.2
and
we
know
that
this
will
resolve
from
docker
hub
right.
So
let's
go
to
docker
hub
real
quick
and
we
will
grab
just
take
a
quick
look
here
at
nginx,
nginx,
all
right
so
tags
and
we'll
see
if
we
can
even
find
that
tag.
Real,
quick,
so
114
to
14
2.,
all
right,
114,
two
okay,
so
here's
our
different
digest
for
our
different
architectures.
A
So
to
noelle's
point
exactly
you
you're
one
thing
that
you're
doing
with
the
specificity
here
is:
you
are
narrowing
in
on
an
instance
of
the
container
based
on
the
shot,
or
I
should
say
the
instance
of
the
image
based
on
the
sha,
but
each
one
there's
going
to
be
a
unique
one,
potentially
for
each
architecture
right
which
is
effectively
what
we
can
see
right
here,
all
right,
so
I'm
on
amd
64.
I'd
expect
it
to
probably
resolve
to
this
digest
right
here.
A
If,
if
all
goes
well,
so
let's
go
ahead
and
try
that
out
so
kbld
and
let's
see,
if
there's
a,
I
guess,
there's
no
command,
it
doesn't
say
what
command
I
should
run.
Oh
there,
it
is
okay
cool.
So
let's
go
ahead
and
do
that
so
we've
got
kbld
on
the
machine.
We'll
do
quick
version
check
cool,
then
we'll
do
kbld
and
let's
just
let's
look
at
the
help,
real
quick
that
will
probably
be
good.
A
Okay,
so
kbld
is
a
is
a
command
in
and
of
itself.
It
has
some
sub
commands
inspecting
images,
packaging
them
into
a
tarball
relocating
images
between
two
registries.
So
this
will
be
an
interesting
use
case
that
we'll
look
at
today,
including
in
the
context
of
image
pack
and
unpackaging,
the
tarball
of
course,
and
then
the
version
which
we
just
saw
so
let's
go
ahead
and
run
this
command,
which
was
kbld
for
the
file
and
we'll
do
nginx.yaml
here.
A
Okay
and
I
should
have
put
that
into
a
file
so
we'll
do
nginx
2.
oops
nginx2.yaml,
let's
roll
with
that
great
all
right.
So
what
happened
to
the
manifest
here?
We've
got
some
annotation
information
that
got
put
in
so
it
looks
like
this
is
our
way
of
saying
hey.
This
started
out
as
tag
114
2..
We
resolved
it
against
this
url
and
then
here
is
a
specific
url
that
we
grabbed
from
docker
hub
right.
A
A
A
295C,
okay,
cool
well,
nonetheless,
we've
got
a
specific.
We've
got
a
specific
hash
right
here
that
it's
referencing,
so
we
can
have
some
amount
of
guarantee
of
which
container
that
this
is
coming
from
right,
so
that
was
kind
of
like
a
conversion
piece.
We
kind
of
just
did
basically
one
piece
of
that
of
that
bigger
puzzle.
Okay,
now
what
about
actually
taking
it?
A
A
step
back
and
maybe
like
building
out,
manifests
themselves
and
actually
running
some
type
of
build
with
a
tool
set
like
this,
getting
the
digest
potentially
pushing
it
to
a
repo
and
all
that
good
stuff.
Let's,
let's
take
a
quick
look
at
that
all
right,
so
we'll
back
up
a
little
bit
and
talk
about
building
images
all
right
now.
This
isn't!
This
is
kind
of
an
interesting
one.
So,
let's,
let's
actually
take
this
this
yaml
file
and
just
take
a
look
at
some
of
the
fields
here,
we'll
take
a
closer
look
all
right,
so.
A
Do
okay,
in
fact,
I'm
going
to
do
this
in
a
go
project.
I
have
and
just
get
rid
of
some
extra
files
here
that
used
to
have
manifest
in
them:
yeah.
Okay,
so
call
this
deploy.yaml,
okay,
cool!
Let's
take
a
quick
look,
so
in
this
case
we've
got
a
deployment
manifest
right
and
you'll
notice
that
right
now
this
has
a
unresolved
image
ref
right.
A
So
what
we're
hoping
to
do
here
is
be
able
to
build
some
arbitrary
project
right
and
actually
go
in
and
potentially
push
the
image
and
then
replace
this
kind
of
placeholder
with
the
digest.
So
you
can
think
about
this
from
like
a
build
pipeline
and
how
nice
something
like
that
can
be.
We
run
the
build.
The
underlying
piece
uses,
docker
or
maybe
build
packs
pushes
to
the
repo,
and
then
it
stamps
out
this
kind
of
immutable
manifest.
If
you
will,
that
again
is
representing
the
digest
of
the
exact
thing
that
we
built.
A
So,
let's
see
if
we
can
make
this
work
now,
this
has
two
deployments
in
it
and
I'm
just
going
to
go
ahead
and
get
rid
of
one
of
them
and
we'll
take
a
quick
look
at
this
config
crd,
which
I
think
has
a
bit
of
the
magic
in
it
all
right.
So
for
the
config
crd
that
we've
got
down
here,
we've
got
obviously
the
image
name
that
we
want
to
put
in
place
and
we've
got
the
path.
A
Now,
taking
a
look
at
some
of
these
fields,
I
think
there
is
yeah
configuration
for
sources
here
all
right.
Let's
look
at
the
configuration
for
what
was
this.
Was
it
sources?
Isn't
that
what
I'm
in
right
now
sources
right,
right,
okay,
cool
so
for
sources,
we
have,
in
our
case
a
image
and
a
path
field,
so
the
image
field,
starting
with
that
I'm
guessing.
A
A
A
Specified
path
path
is
source
pool
file.
Oh
name
of
the
docker
file
is
in
file
interesting,
okay,
we'll
see
if
that
works,
okay,
pack,
config
path,
okay,
so
we'll
go
into
sources
and
into
path,
and
in
this
case
I
do
have
a
docker
file
right
here.
So
let's
just
see,
if
I
can
make
this
work
all
right.
So
in
this
case
we
have
a
docker
file
for
this
little
go
app.
This
go
app
is
something
that
I
wrote
the
other
day
just
to
demonstrate
something
about
file
streaming.
A
A
So
inside
of
the
docker
file
here,
I'm
I'm
definitely
not
doing
what
I
should
do
if
this
was
like
a
more
serious
thing
right,
I'm
using
the
golang
image,
which
has
all
the
build
tools
and
all
that
stuff.
I
should
be
eventually
copying
this
into
like
a
distro-less
image
or
maybe
a
scratch
image
and
doing
all
that,
but
just
for
the
sake
of
simplicity,
I
copy
and
pasted
this
out
of
the
out
of
the
the
go,
the
godox
for
the
dockerfile,
but
nonetheless
this
is
a
docker
file.
A
It
should
be
able
to
run
and
we'll
go
ahead
and
go
back
here
quit
out
of
here.
Real
quick,
all
right,
noelle
says
well,
formatted
code.
Yes,
thank
you.
It's
not
a
lot
of
code
though,
but
it
is,
it
is
well
formatted.
It
has.
It
has
comments,
okay,
cool
cool,
so
the
path
here
I
I
messed
around
with
this
tool
a
little
bit
today
and
I
think
path
is
referencing
the
docker
file,
but
someone
in
the
carvel
team
can
tell
me
if
I'm
wrong.
I
don't
for
some
reason.
A
I
can't
find
I
swear.
I
saw
it
in
docs
today,
but
I
can't
figure
out
what
this
field
actually
means:
executing
sources
configure
kbld
to
execute
image,
building
operations
based
on
the
path
all
right.
Well,
we'll
see
we'll
see
if
it
works,
and
then
the
image
simple
app.
So
again,
the
the
kind
of
matching
resolution
that
I'm
looking
at
here
is
that
image
here
should
ideally
match
image
here
and
I'm
thinking
again.
A
If
it
builds,
okay
sees
the
docker
file
understands
to
use
a
docker
provider,
it
should
build
it,
and
then
we
should
get
a
digest
in
here.
If
you
will
so,
let's
just
see
if
that
works,
and
we
can
figure
out
if
I
did
something
terrible
so
we'll
do
kbld
again
we'll
do
the
file
of
what
did
I
call
this
thing.
Deploy.Yaml
okay
started
build
using
docker
docker
should
be
running.
So,
let's
see
real
quick
pseudo
system,
ctl
status,
docker.
A
A
All
right
so
dimitri
says
it's
under
the
config
crd
and
aaron
says
the
configuration
dock
explains
the
config
schema
see
if
I
can
find
that,
while
it's
building
configuration
doc
explains
the
config
schema
sources.
Okay,
so
I
was
in
sources
right
sources
inside
of
config
and
then
the
definition
of
path.
Where
is
that
at.
A
Path
to
source
location,
okay,
I'm
guessing
that
this
is
what
you're
talking
about
then
so
path
to
source
location,
source
of
the
entire
project,
cool
all
right,
so
docker
is
the
default.
So
the
fact
that
I
didn't
put
docker
in
that.
We
know
why
it
detected
that
let's
do
a
quick
check
on
the
the
build
okay.
So
it
looks
like
it's
building
bringing
some
output
from
the
docker
dame
and
so
like
yeah
again,
the
the
important
thing
to
know
again
about
like
the
scope
of
a
tool
like
this.
A
Is
it's
not
like
re-implementing
another
build
system
per
se?
It's
it's
leveraging
build
systems
that
are
well
established
to
do
the
job
really
well
to
delegate
this
work
to
them,
which
is
again
kind
of
a
kind
of
a
beautiful
thing
about
some
of
these.
These
carvel
tools
is
their
their
scope.
So
all
right,
so
we
have
image.
We
have
path,
source
location.
A
A
Everyone,
because
I'm
obviously
building
locally-
and
my
guess,
is
that
the
digest
that
it
puts
in
here
is
not
going
to
be
a
real
thing
unless
somehow
my
computer
is
all
of
a
sudden
hosting
a
publicly
facing
registry
right,
so
I'm
guessing
destinations
will
be
one
of
our
next
things
and
I'll
probably
be
able
to
put
in
my
own,
like
docker,
hub
url,
at
least
that's
what
I'm
hoping
so
we'll.
Try
that
where
do
you
see
20
gigs,
oh
wow,
20
gigabytes.
A
A
There's
that
all
right
we'll
let
that
build
for
a
second
and
while
that's
building
actually
open
up
a
new
window
here
and
let's
go
ahead
and
check
out
the
file
again
here
to
make
some
changes
so
to
try
to
bring
this
full
circle
a
little
bit.
We've
got
config
we've
got
the
simple
app
bit:
let's
go
ahead
and
talk
a
bit
about
putting
a
destination
in
place
so
destinations
and
carvel
team.
If
I
do
something
really
silly
here,
just
let
me
know
because
I'm
mostly
shooting
from
the
hip
destinations
will
be.
This.
A
We've
got
the
image
right,
which
we'll
call
the
image
itself
I'm
guessing.
This
will
be
interesting.
I
wonder
what
the
image
field
means
in
this
context.
Actually
image
is
an
optional
image
matcher,
so
it
would.
My
intuition
would
be
that
this
should
also
be
simple,
app,
we'll
find
out
and
also
I
should
probably
do
this
real,
quick,
docker,
login,
okay,
great
I'm
logged
into
docker,
okay
cool,
so
we've
got
simple
app.
We've
got
the
path
set.
This
is
probably
dimitri.
A
A
A
So
we
should
be
looking
pretty
good
destinations.
All
that
good
stuff.
I
almost
wonder
if
I
should
kill.
Oh
no,
it
succeeded
great
okay,
yeah,
vim
and
capslock
is
a
bad,
a
bad
combo.
It's
amazing
how
much
you
can
destroy
when
your
capslock
is
on
right,
okay,
cool,
so
it
did
build.
You
can
actually
see
the
image
digest
as
well.
I
think
I
had
t-mux
like
scrolling
up,
so
it
wasn't
actively
showing
more
the
terminal.
Let's
take
a
quick
look
inside
so
did
it.
A
A
Oh
yeah,
it
is
my
repo
yeah
serving
large
files,
because
I
was
trying
to
explain
how
you
could
how
you
could
push
like
a
nine
gigabyte
file
with
only
using
like
a
couple
kilobytes
of
memory
through
buffering,
so
I
picked.
Maybe
I
picked
the
worst
example
humanly
possible
that
could
that
could
very
much
be
it
yeah.
So,
let's,
let's
see
something
real
quick,
actually
check
this
out.
We're
gonna
get
rid
of
these
two
files:
lots
of
data.
A
A
A
Is
it
I
don't
know
dimitri?
Is
this
saving
it
to
a
file
somewhere?
Am
I
missing
it,
or
is
it
just
output
that
I
there's
probably
a
flag
that
I
need
to
put,
but
let
me
just
copy
it
real,
quick
here:
let's
grab
all
this,
so
boop
get
all
this
okay
cool,
so
we
will
do
a
new
just
standard
out:
okay,
fair
enough
new
yaml
dot
yaml.
A
How
do
you
like
that
name?
Newyamble.Yaml,
okay,
deployment
cool.
So
what
do
we
got
this
time
in
the
metadata?
So
some
information
I
mean
again,
this
is
really
just
cool-
how
it's
got
details
about.
What's
going
on
with
the
actual
source
repository
again,
it
speaks
to
kind
of
the
chain
of
integrity.
We
now
have
in
understanding
source
to
image
and
then
even
resolving
the
image
eventually
downstream,
so
the
url
is
index,
dot,
docker
io
and
then
obviously
this
is
oh.
A
This
is
my
repo
right,
so
in
theory,
because
I
just
did
a
rebuild
let's,
let's
take
a
quick
look,
so
I
just
did
a
rebuild
on
this
deploy
right
and
I
didn't.
I
had
forgotten
that
I
had
changed
this
piece
of
it,
so
in
theory
and
docker
hub,
my
repo
probably
has
simple
app
inside
of
it.
Let's,
let's
validate
that
real
quick,
so
we
will
go
to
docker
hub,
I
will
sign
in
to
docker
hub.
A
Okay,
what
do
we
got
in
docker
hub
josh?
My
content,
I
haven't
been
in
docker
hub
in
so
long
and
it
will
show
in
a
moment
here
when
I
literally
don't
know
where
to
go.
Hey
simple,
app
check
it
out
all
right,
so
we
built
simple
app
and
we've
got
the
tags
here.
This
is
an
interesting
thing:
kbld
rand,
where
does
this
tag
come
from?
A
That's
interesting!
Is
that
just
something
that
comes
along
with
what
I
built?
Maybe
I
don't
know,
but
there's
v
1.0.0.
We
can
see
the
digest
right
there
as
well,
so
yeah
noel.
I
really
dig
the
metadata
too.
I
think
just
you
know
again
carrying
this
all
the
way
to
the
point
where
we
deploy
in
kubernetes,
in
just
being
like
wow.
I
very
very
concretely
know
the
source
right.
I
concretely
know
the
source
where
it
came
from
in
some
context
around
it
is,
is
really
neat.
I
like
that.
A
A
lot
and
john
says
images
built
and
docker
damon
are
not
assigned
digest.
That
makes
sense.
Okay,
so
you
gotta
make
up
the
tag.
I
got
it.
Okay,
yeah,
that
makes
so
much
sense,
cool
yeah.
That's
that's!
Pretty
neat
so
effectively,
we've
gone
in
and
taken
a
an
arbitrary
project
with
a
massive
build
context,
and
we've
been
able
to
set
up
a
manifest
like
this,
where
the
builds
are
actually,
you
know,
reproducible
and
we
can
pair
a
lot
of
this
stuff
up
with
again
like
the
different
tools
in
the
tool
chain.
A
So
if
you
go
back
to
a
previous
tgik,
where
joe
explored
ytt
you
can
use,
we
can
use
kbld
to
handle
some
of
this
image
resolution
stuff
for
our
various
images.
Have
it
be
consistently
built?
We
can
also
have
ytt
going
in
and
changing
some
of
the
different
attributes
out
inside
of
here
as
well,
and
then
all
inside
of
our
build
pipelines
right
or
even
in
our
local
desktops,
like
in
my
case,
we
have
a
really
easy
way
to
create
these
consistent
builds,
so
pretty
cool
yeah.
I
like
it.
What
do
you
all
think?
A
I
think
one
other
thing
we
can
look
at
before
we
leave
kbld
behind
is
there
is
the
notion
of
relocation
which
I'll
just
mention,
because
we'll
talk
a
little
bit
about
this,
I
believe
with
image
pack
when
we
get
into
that.
But
inside
of
here
there
is
the
ability
to
actually
go
in
and
bring
bring
these
different
images
between,
I
believe,
just
between
either
a
a
new
tar.
A
If
you
will
that
you
could,
you
could
bring
up
and
manually
put
somewhere
or
actually
go
between
different
different
repositories,
right,
which
is
pretty
cool,
so
we'll
we'll
explore
that
a
little
bit
with
image
pack.
But
one
of
the
commands
you
probably
should
at
least
be
cognizant
of
and
check
out
is-
is
some
of
these
bits
in
the
packaging
and
relocation
docs
as
well
all
right.
So
let's
go
ahead
and
swap
on
over
to
image
package,
all
right
cool.
A
But
what
about
the
idea
of
the
assets
that
aren't
just
container
images
right,
like
think
about,
think
about
what
kubernetes
has
sort
of
become
for
a
moment?
We
we
go
in
and
we
deploy
these
applications
like
istio
or
k,
native
or
database
operator
of
some
sort,
and
we
basically
have
like
you
know,
500
lines
of
yaml
that
describe
all
the
different
things.
Declaratively
and
it's
great.
We
just
apply
that
yaml
to
the
cluster
and
then
through
reconciliation.
A
A
bunch
of
stuff
happens
to
make
it
to
make
it
exist
right,
but
when
we
think
about
the
process
of
of
packaging
stuff
that
we
want
to
be
able
to
consistently
deliver
what.
If
we
want
to
be
able
to
provide
a
similar
guarantee
for
all
of
the
different
pieces
of
the
puzzle
here,
not
just
the
container
images,
but
the
manifests,
the
ancillary
files
and
all
that
different
kind
of
stuff,
and
taking
that
a
step
further,
we
know
that
there
has
been
kind
of
the
proliferation
of
registries
that
support
oci
compliant
bundles
in
general.
A
A
I
can't
remember,
but
one
of
the
two
were
the
first
to
kind
of,
say:
hey
we're
going
to
let
you
bring
your
helm
charts
up
into
the
repo
and
other
oci
compliant
assets
as
well,
and
this
is
something
that
harbor
does
today.
So
we've
got
these
oci
compliant
registries
and
basically,
if
we
think
about
these
as
not
just
specific
to
container
images
but
kind
of
bundles
in
general,
we
can
create
these
packages
of
all
the
contents.
A
So
that's
what
we're
going
to
be
kind
of
taking
a
look
at
with
image
pack-
and
this
is
one
that
I'm
I'm
really
particularly
excited
about
so
image
pack
we're
going
to
be
looking
at
in
the
context
of
kubernetes,
of
course,
but
it's
kind
of
like
a
very
a
very
generic
thing
like
it's
going
to.
Let
us
bring
arbitrary
files
together
package
them
up
and
and
kind
of
create
this
oci
compliant
bundle
and,
like
you
think
about
what's
a
use
case
where
this
makes
sense
so
josh
that
all
sounds
neat
but
like.
A
Why
would
I
ever
care-
and
I
think
this
middle
box
is-
is
a
great
example
one
of
many
of
why
this
is
why
this
is
nice
so
being
able
to
take
in
in
air-gapped
environments.
If
any
of
you
work
in
like
the
federal
space
or
the
financial
services
space,
you
probably
are
familiar
with
the
pain
and
agony.
That
is
the
inability
to
just
go
out
to
docker
hub
whenever
you
want
to
like
some
of
us
like
myself,
who
just
screws
around
with
random
things
all
day
right,
I
can
just
go
grab
any
old
image.
A
I
want
to
right,
but
in
a
lot
of
our
environments,
they're
super
locked
down,
and
it
requires
us
to
kind
of
bring
all
the
different
assets
into
a
location.
Be
it
an
internal
registry
or
even
just
like
I've
had
a
lot
of
times
where
I've
had
to
like
load
tars
manually
into
the
docker
daemon,
to
make
them
work
in
someone's
environment
right
not
manually
with
a
script,
but
it
might
as
well
have
been
manually.
A
So,
let's
see
if
we
can
do
a
little
bit
with
image
pack
image
package
now
so
oh
cool,
so
image
package
set
of
arbitrary
files
into
an
oci
image.
That's
what
we
have!
That's!
What
we
have
figured
out,
noelle,
you
said
true
releases-
is
a
hundreds
of
gig
tarpaul
yeah.
It
can
be
big
image.
Pack's
primary
concept
is
a
bundle.
So
that's
what
we'll
be
looking
at
today,
which
is
an
oci
image
that
holds
zero
or
more
arbitrary
files
and
then
references
the
oci
images.
A
So
again,
this
is
kind
of
where
that,
like.
I
think
this
is
where
that,
like
lock,
file
and
stuff
comes
into
play,
where
we
actually
have
the
ability
to
go
in
and
reference
other
things
consistently,
and
you
can
kind
of
see
where
the
story's
playing
out
here.
If
you
take
a
step
back,
it's
like
you
have
the
shaw
integrity
of
the
bundle,
and
then
you
have
the
references
to
the
oci
images
that
you
can
also
guarantee
on
that
level
as
well.
So
we
can
actually
again
build
this
package.
A
A
All
right
prepare
the
bundle
contents,
so
we'll
see
if
I
can
work
with
work
with
my
existing
repo
here.
If
not
we'll
go
to
this.
This
basic
example
here
has
a
configural
which
contains
very
simple
kubernetes
application.
Yep
we've
got
that
so
in
our
case,
I
guess
I
think,
what
we're
going
to
end
up
pointing
to
is
going
to
be
new
or
I
guess
what
we're
going
to
care
about
initially
is
going
to
be
new
yaml.yaml,
because
this
is
the
output
from
standard
out
that
I
did
copy.
A
I
probably
should
just
make
sure
real,
quick
cube,
cuddle,
apply,
new
yaml
just
make
sure
okay
cool.
I
have
no
idea
if
the
app
will
run
successfully
in
kubernetes,
but
at
least
I
know
that
the
man,
the
schema,
is
right
from
a
kubernetes
standpoint.
Let's
see
real
quick,
I'm
kind
of
curious,
I'm
pretty
sure
that
this
is
gonna
blow
up
for
some
arbitrary
reason,
but
we'll
see.
A
Okay,
so
we've
got
that
in
place
and
we're
going
to
add
this
image
package
directory,
okay,
which
will
have
the
optional
bundle
yaml,
which
records
informational,
metadata
and
then
the
images
yaml
which
records
the
image
references
used
by
the
configuration
okay.
So
this
will
be.
This
will
be
kind
of
interesting.
Let's
see
if
we
can
build
this
out
here
together,
so
we'll
go
in
and
go
ahead
and
make
the
image
package
directory
inside
of
here
all
right
image
package
and
then
the
bundle
yaml
and
then
the
images
yaml.
A
So
let's
check
this
out
real,
quick,
bundles,
yaml,
okay,
so
this
is
the
bundle
itself
file.
Contains
bundle
configuration
details
about
the
bundle's
authors
associated
website,
all
that
good
stuff.
So
let's
just
copy
an
example
out
of
here.
This
appears
to
be
metadata,
so
bundle
oops.
Let's
make
sure
it's
in
the
right
place,
though
right
image
package
bundle,
yaml,
okay,
cool.
Let's
do
that,
so
we've
got
the
bundle.
A
This
will
be
tgik
rocks
bundle,
full
name
will
be
josh,
okay
and
then
we'll
keep
the
rest,
as
is
okay,
so
we've
got
the
bundle
metadata
in
place
and
next
up
we
need
the
actual
images
yaml.
So
is
this:
the
lock
file
required
contains
image,
lock,
configuration
okay
image,
lock
configuration
good
good
api
images,
lock
images,
blah
blah
blah
okay,
this
seems
good.
A
So,
let's
see
if
we
can
grab
this
image
lock
file
out
of
here
and
put
it
inside
as
well
all
right,
so
we've
got
bundle
yaml,
let's
go
ahead
and
put
images.yaml
inside
of
here;
okay,
so
images
image
lock
all
right.
So
I'm
going
to
come
back
to
this
in
a
second
as
we
get
deeper
into
image
package,
but
we've
got
image
package:
we've
got
the
bundle.
We've
got.
The
images
note
that
image
package
images
contains
a
list
of
images
each
with
fully
resolved,
digest
references
and
a
little
bit
of
additional
metadata.
A
A
I
see
we
should
have
done
that
silly
us,
so
this
is
obviously
we
can
create
it
manually
and
we
probably
could
reference
the
the
image
that
we
want,
but
we're
using
kbld
to
build.
So
why
would
I
not
put
the
images
file
in
through
kbld?
Let's
see
if
we
can
do
that,
so
we'll
back
up
and
again,
this
is
kind
of
the
great
thing
about
tools
that
are
designed.
This
way
is
that
they
can
be
single
purpose.
A
They
don't
have
to
solve
the
world's
problems,
yet
they
can
pipe
together
in
in
ways
that
make
us
and
that
enable
us
to
build,
really
effective
workflows.
Right
so
john
says
you
still
can
rerun
the
lock
with
the
lock
file
flag.
That's
what
I'm
thinking
john!
So
I'm
going
to
do
exactly
that.
Did
I
call
it
config.yml
what
the
heck
did?
A
Oh,
I
called
deploy.yellow
yeah,
some
of
some
of
you
who
haven't
seen
me
on
tgik
before,
if
you
haven't,
you
should
know
that
I
am
a
master
at
naming
things
extremely
poorly,
like
like
in
the
most
confusing
way.
You
could
possibly
think
I
mean
if
you,
if
you
think
about
it
for
a
moment
like,
let's
just
just
humor
me
real,
quick,
let's
go
into
serving
large
files.
A
I
named
this
file
new
yaml.yaml,
so
if
anyone
needs
any
any
advice
on
naming
you
just
you
just,
let
me
know:
okay,
so
kbld
deploy
yaml
image
package,
lock,
output,
images.yaml!
Let's
do
it
error
checking
file,
deploy
dot,
oops
deploy.yaml,
because
I
weirdly
put
a's
in
my
yaml
files.
All
right.
Let's
do
this
again,
1.458
megabytes.
A
A
Okay,
cool
so
we'll
go
back
to
the
bundle
and
we've
got
that
output.
Here
we've
got
the
index
okay
again,
because
I'm
just
worried
about
losing
this,
I'm
just
going
to
save
it
for
later,
we'll
call
this
new
yaml,
newer,
newer,
yaml,
dot,
yaml,
newer,
yaml.yaml,
we'll
put
this
here
just
for
the
sake
of
reference
all
right,
and
then,
let's
see
if
the
file
now
exists
inside
of
the
image
pack
directory.
So
if
we
go
into
image
package,
we
go
into
the
images
yaml.
A
And
there
it
is
sweet,
so
the
image
lock
file
got
created
by
k,
build
which
is
cool
so
put
that
inside
of
there
it's
got
the
the
actual
reference.
This
is
effectively
our
lock
file
and
then
we'll
go
back
to
our
our
example.
Here
all
right,
pushing
the
bundle
to
a
registry
authenticate
with
a
registry
where
we
will
push
our
bundle.
Okay,
okay,
so
I
should
be
authenticated
because
I
did
docker
login.
That
seems
fine
push.
A
A
So
if
we
have
dimitri
kate's,
simple
app,
then
go
back
to
the
configural
yeah,
I'm
guessing
so
right
is
that
kind
of
working
like
a
selector.
It
seems
like
it,
so
it's
probably
going
to
use
the
image
lock
to
swap
that
out.
I'm
guessing,
I
guess
we'll
see
we'll
see
in
mine,
so
we've
got
this
right
here.
We'll
save
that
up.
We
will
back
up
real
quick
now.
A
So
if
I
go
into
the
deploy
yaml
file
and
the
image
pack
file-
and
I
put
this
into
manifest-
okay
great
so
manifest
inside
of
here-
deploy
yaml
image
pack
and
john
says
those
strings
will
match
and
replace
the
unresolved
reference
with
the
resolved
one
think
of
that
lock
file
as
a
mapping
from
a
string
to
a
resolved
reference.
Perfect,
that's
exactly
what
we
need,
so
we've
got
deploy.
A
A
So
there's
my
selector
simple,
app
right.
It
just
feels
weird
to
me
to
have
this
config
in
here,
but
maybe
I'm
overthinking.
It
we'll
see
so
we'll
do
we'll
do
config.yml
here
and
put
this
in
place.
Oops
yeah
that
one
all
right,
config.yml
seems
good
resolve
that
all
right
we've
got
this
manifest
directory.
Now
inside
of
my
repo
and
again,
this
has
the
dot
image
package.
It
has
the
config
it
has
the
deploy.
A
A
Where
was
I
at
before
I
started
screwing
around
with
everything
so
k
build
made
our
lock
file,
that's
fantastic!
We
authenticated
with
the
registry
already
we're
going
to
push
the
bundle
to
the
registry.
That's
where
we
were
so
b
is
the
location
of
the
bundle
for
the
oci
registry.
Okay.
So
this
is
probably
where
it's
going
to
be
in
docker
hub.
I
guess
in
my
case
in
docker
hub.
The
second
one
is
the
file,
which
is
the
actual
contents
to
include
so
remember,
backing
up
a
step.
We
are
not
sending
the
image
up
here.
A
We
are
sending
the
package
of
the
assets
that
are
the
manifest
in
our
case
right
and
then
that
will
again
have
references
to
the
images
which
can
be
a
completely
different
oci
repo
and
all
that
good
stuff,
cool
and
john
said,
because
config
is
not
a
resource.
It's
a
good
idea
to
have
them
in
separate
files
for
humans,
okay,
but
they
don't
have
to
be
in
a
separate
file,
so
maybe
just
best
practice
from
a
cleanliness
standpoint,
but
I
might
not
have
had
to
to
separate
these
per
se
all
right
sweet.
A
So,
let's
go
back
and
get
this
thing
pushed
up
all
right,
so
image,
pack
push
b,
okay,
so
mine's
gonna
be
image
package.
Here,
let's
clear
this
out
image
package
push
b
and
in
my
case
it
is
going
to
be
this.
Oh
cool,
simple,
app
bundle
so
we'll
keep
that
consistent.
So
we'll
go
back
here,
we'll
put
this
in
place.
Obviously
I
am
not
user
one
as
rad
as
that
username
is,
and
my
file,
as
you
all
know,
is
inside
of
manifest.
A
So
I
think
this
is
our
command,
pretty
sure
who
else
had
split
and
tabby
learned
something
new
and
vim:
hey,
I'm
here
to
help
noel,
if
not
in
kubernetes,
at
least
in
at
least
in
vim.
Okay
image
package
push,
let's
see
if
this
works,
dir
image
package,
image
package
bundle,
config,
deploy
deploy.yaml,
and
now
we
have
pushed
this
bundle
into
docker
hub.
So
let's
go
ahead
and
check
this
out
so
we'll
go
over
to
docker
hub,
which
is
right
here
we'll
go
back
over
to
my
repo,
maybe
repositories
and.
A
Okay,
let's
take
a
quick
look
and
I'll
I'll,
I'm
gonna
do
something
very
I
don't
know
if
you
call
it
meta
here,
I'm
probably
mostly
just
wasting
your
time
at
this
point,
but
if
we
grab
what
something
looks
like
from
kind
of
a
package
management
standpoint
for
just
a
moment,
so
I'm
going
to
go
into
attempt
directory.
I
am
going
to
see
if
I
have
anything
carvel
related
here
already.
A
This
is
how
one
could
go
in
and
install
the
carvel
tool
set
if
you're
running
this,
this
specific
distribution
and
then
you've
got
all
of
the
different
shaw
checksums,
which
are
effectively
pointers
to
the
binary
for
the
architecture
that
you're
you're
using
in
this
case
and
and
why
I
bring
this
up.
Is
it's
just
really
really
interesting?
A
But
aside
from
that,
like
random
thought
process
there
yeah
I
mean
this
is
this
is
really
cool.
We've
got
our
app
bundle
in
place.
We've
it's
in
an
oci
repository
which
is
docker
hub.
In
this
case
and
tommy
you
said
package
build,
is
similar
to
the
old
bsd
way,
exactly
right.
So,
what's
what's
old
is
new
again
from
what
was
also
old
in
the
past
as
well
right.
A
So
it's
just
it's
just
a
super
super
interesting
thing,
and
I
I
I
don't
know
like
kubernetes-
is
kind
of
becoming
boring
in
ways
but
like
this
is,
I
think
it's
an
area
of
kubernetes.
That's
like
really
interesting
and
potentially
ready
for
some
some
cool
innovation
right.
So
yeah
we've
got
simple
app
bundle.
We've
got
simple,
app
I'll
see.
If
there's
anything
else,
it
recommends
pulling
the
bundle
to
the
registry
image
package
pool
yeah.
A
Let's
I
guess,
let's
use
the
pooled,
bundled
contents,
okay
cool,
so
you
can
see
here
right.
We've
got
the
ability
once
again
to
kind
of
pipe
some
of
these
things
through
so
kbld
can
be.
We
can
take
the
assets
that
come
out
of
it.
We
can
cube
cuddle,
apply
it
of
course.
In
fact,
let's
just
let's
just
look
at
that
real
quick,
let's
see
if
I
can
do
a
quick
pool,
so
pool
is
probably
the
exact
same
thing,
and
I
just
tell
it
where
to
go
right
all
right.
Let's
try
that
real
quick.
A
A
Tgik,
okay,
so
great
all
right,
let's
pull
this
guy
in
and
then
I
wonder:
if
is
it
going
to
put
like
the
locating
lock
files,
one
or
more
images
not
found
in
bundle
repo
skipping,
lock,
file
updates?
Okay,
let's
see
if
I
can
find
this
real,
quick,
so
temp
tgik
cool.
So
there
are
our
files
effectively
and
if
we
look
at
the
deploy.yml
we
can
see
simple
app
is
inside
of
there
and
then
I'm
guessing,
let's
see
here
so
it's
put
in,
would
I
run
kbld
again
to
put
in
the
config
yeah?
A
So
let's
do
that
real,
quick,
so
kbld
yeah
cause
this
okay,
sorry,
I'm
I'm
learning
and
thinking
at
the
same
time
and
kind
of
rambling
here,
but
you
can
probably
see
what's
going
on
so
configuraml
is
inside
of
here
right.
The
image
package
is,
of
course,
inside
of
here,
because
this
is
going
to
contain
the
lock
file.
So
once
this
asset
comes
down
once
we
pool
this
bundled
hashed,
you
know
asset.
We
can
then
go
in
and
basically
do
similar
things
to
what
we
were
doing
before
now.
A
This
time
this
time
we
of
course
don't
need
to
build
the
actual
application
right.
We
just
need
to
basically
build
the
or
I
don't
even
want
to
call
it
build.
We
need
to
parse
or
render
the
the
manifest
right.
So
if
we
do
kbld
again
and
the
file
in
this
case
will
be
my
configural
and
then
I
need
to
reference-
oh
interesting,
so
I'm
surprised
it
doesn't
look
for
this
file
automatically.
But
I
guess
maybe
it's
just
not
a
convention
thing.
I
don't
know
images.
A
A
So
I
can
pipe
it
through
cube
cuddle.
What
am
I
doing
wrong
here?
Dash
f,
deploy,
oh
duh
yeah.
Thank
you.
Thanks
dimitri
as
long
as
someone's
paying
attention,
it
does
tell
me
it
succeeded
when
the
file
didn't
exist,
so
maybe
maybe
that's
something
we
should
look
into,
but
there
we
go
cool,
so
containers.
We've
got,
the
hash
seems
pretty
good
yeah.
A
Now,
I'm
not
like
figuring
out
the
14
000
different
places
with
the
relevant
tags
and
all
that
junk
of
where
to
get
the
thing
like
this
is
it.
This
is
the
immutable
unit
of
the
descriptor
that
tells
me
how
to
deploy
the
freaking
thing.
It's
not
that
complicated
and
then
the
beauty
of
it
is.
We
were
able
to
again
do
this.
A
Do
this
pull
command
here,
in
which
I
was
able
to
bring
it
down
right
and
then
once
it
got
brought
down,
I
was
able
to
come
inside
of
here
and
basically
say:
hey
go
ahead
and
do
this
deploy
file,
make
sure
you
look
at
the
image
lock
file,
and
then
that
is
the
asset.
It
is
you
know
true,
unless
unless
we
theoretically
go
in
and
do
something
like
this
image
image
package,
where
are
you?
Where
am
I
no
such
directory?
A
They
must
have
had
the
old
one
image
package
there
we
go
unless
I
go
in
and
do
something
like
this
which
why
the
heck
would
I
ever
do
it
right?
We're
good
like
this?
Is
this
is
consistent
through
and
through
right?
So
that's
the
only
way
that
I
could.
I
could
really
screw
up
this
process
from
this
perspective.
Right,
hey,
steve,
glad
to
see
you
we
are,
we
are
making
some
immutable
kubernetes
packages
and
images
right
now,
so
you're
yeah
we're
we're
making
them
immutable.
A
So
very
very
cool,
dimitri
said:
configurable
also
existed
there
just
wasn't
any
resources
that
weren't
exactly
that
makes
sense
dimitri
and
that's
what
probably,
what
john
was
saying
too
earlier,
like
from
a
human
standpoint
like
you
probably
want
these
separate,
but
in
theory,
if
I
had
done
this,
I'm
sure
kbld
is
smart
enough
to
know
that
this
is
not
the
actual
kubernetes
manifest
right.
In
fact,
we
saw
that
earlier,
but
I'll
just
tease
it
out
anyways
if
we
go
to
deploy
we'll.
Do
this
real
quick?
A
It
knows
that
it's
I
don't
know
what
would
you
call
config
like
a
descriptor
to
instruct
kbld
on
what
it
should
do,
or
something
like
that,
I
suppose
so,
all
in
all,
that's
pretty
good
all
right!
This
is
pretty
sweet,
I'm
pretty
close
to
being
out
of
time
here,
but
let's
take
a
quick
look
at
the
air
gap
stuff
and
see
if
there's
anything
that
I
should
call
out
here,
like
you
could
probably
imagine
just
based
on
what
we've
seen
so
far,
how
we
can
enable
this
air
gap
workflow.
A
But,
let's
maybe
end
end
the
day
on
this
and
take
just
a
quick
look
at
some
of
the
air
gap
capabilities.
Yeah
steve.
We
did
talk
a
little
bit
about
flux
earlier,
okay,
so
finding
bundle
in
source
registry,
okay,
so
we've
already
pushed
to
a
source
registry.
We
know
that
then
there's
two
methods
of
copying:
the
bundle
right
option,
one
from
a
common
location
connected
to
both
registries,
more
efficient,
because
the
changed
image
layers
will
be
transferred
to
different
registries
option
two
with
an
intermediate
tarball.
Maybe
we
should
do
the
intermediate
tarball.
A
So
basically,
thinking
like
in
the
scenario
that
I
had
told
you
about
which
I've
had
in
a
couple
financial
services
examples
were
like,
we
don't
have
a
registry
figure
out
how
to
get
our
images
in
here
and
it's
like
okay.
Well,
I
guess
I
will
tar
them
all
up
and
then
load
them
into
your
your
container
runtime.
Thank
you
for
making
me
hate
my
life,
so
we'll
try
that
out
from
location
to
both
registry.
So
this
is
what
I
was
kind
of
talking
about
by
the
way,
I
think
carvel
team.
A
You
can
tell
me
if
this
is
a
stupid
statement,
but
when
I
was
talking
a
bit
about
k,
build
and
like
the
what
was
it
called,
relocate
or
whatever
like
in
a
way,
this
is
kind
of
sort
of
similar.
I
think
in
the
sense
that,
like
this
is
going
to
go
from
one
repo
to
another
repo
with
the
bundle
and
then
will
this
also
yeah.
Will
this
also
move
the
container
images,
I'm
guessing
so
the
bundle
or,
let's
just
move
the
bundle?
Actually
I'm
trying
to
think
that
through.
A
Would
the
references
still
look
at
the
not
internal
repo
anyways
I'll,
we'll
check
it
out
or
someone
in
chat
will
answer?
Okay?
So,
let's
do
the
intermediate
tarball
just
to
understand
this?
Actually
the
intermediate
tarball
will
tell
us
the
answer
so
we'll
do
an
image
package
copy
of
our
bundle
and
we're
going
to
turn
it
onto
our
machine
here
so
get
the
location
of
the
source,
repo
blah
blah
blah,
okay,
cool
yeah.
I
wish
this.
I
wish
this
thing
existed
a
year
ago.
A
A
A
We
did
a
copy
and
it's
basically
being
like
hey
cool,
so
you've
got
the
bundle.
I
understand
that,
but
also
I
understand
that
in
the
bundle
you
need
the
the
image
itself
right.
So
you
can
see
right
here.
This
is
the
container
image
that
it
referenced
right.
So
we
think
about
that
relationship.
It's
like
the
lock
file
went
over
and
pointed
to
the
image
it
resolved
that
it
knew
it
needed
the
image
and
it
appears
it
brought
that
down
into
the
the
tarball
as
well.
A
A
Okay,
I
see
what
it's
doing
there
yep
pulling
the
bundle
from
the
destination
repo,
okay
cool,
so
in
short,
we
were
able
to
actually
kind
of
move
this
over
to
an
entirely
different
place
again.
The
the
beauty
here
is
kind
of
like
the
the
resolution.
It's
like,
let's,
let's
visualize,
this
real
quick,
because
it's
kind
of
it's
in
my
head,
but
I
don't
know
if
it's
clicking
with
everybody
so
like
we
think
about
the
idea
of
like
the
descriptor
right.
Actually,
you
know
what
we
should
do,
instead
of
josh
doing
terrible
diagramming.
A
Let's
do
this
real,
quick
about
image
package.
Perfect!
Let's
grab
this
okay,
we'll
we'll
we'll
riff
on
this
a
little
bit
right,
all
right,
so
this
is
actually.
This
is
a
good
overview,
too,
of
kind
of
like
what
we
talked
about
today.
So
the
images
yaml
file,
that's
the
lock
file,
it
went
out
and
it
knows
what
the
images
are,
and
it
knows
them
again
from
their
digest,
not
just
their
tag
so
in
bringing
this
bundle,
local
or
locally
kind
of
bringing
it
in
we're.
A
Actually
taking
these
different,
these
little
oci
images
and
we're
basically
copying
all
of
these
as
well.
So
basically
these
these,
I
should
put
copied
in
here
copied
right.
So
by
kind
of
understanding
that
resolution
we
were
able
to
take
this
and
bring
it
down
locally
into
this
repo,
including
the
the
the
bundle
itself.
A
So
this
gives
us
a
lot
of
ability
to
kind
of
move
things
between
repositories.
Do
air
gapped
use
cases
all
of
that
good
stuff.
So
you
know
one
thing
that
we
probably
could
do
pretty
easily.
Let's
go
back
to
this,
this
b
command
that
we
were
doing
before.
So
we'll
do
this,
and
let's
just
like-
I
don't
know,
let's,
let's:
let's
do
a
destination,
that's
slightly
different,
so
we'll
go
into
image
package
and
we'll
grab
the
air
gapped
workflow,
so
to
go
repo
to
repo.
A
Let's
see
what
this
looks
like
b
and
then
the
two
repo
flag,
okay,
cool,
so
I'm
guessing
it's
cool.
If
I
just
do
a
different,
I'm
guessing
it's
cool,
if
I
just
do
a
different
name
for
docker
hub
right,
so
instead
of
tutar
we'll
do
this
and
we'll
call
this
here.
Let
me
break
this
down,
so
it's
easier
for
y'all
to
read:
we'll
do
this
here,
simple,
app!
Bundle!
Okay,
got
that
good,
good,
simple,
app
bundle,
we'll
call
this
complicated,
app
bundle!
A
Okay,
and
let's
run
that
image
copy
does
not
accept
extra
arguments.
What
did
I
screw
up?
Oh,
I
didn't
put
the
flag
in.
Let's
do
that
real
quick.
So
this
is
the
what
was
it
two
repo
there?
It
is
all
right.
So
in
theory
here
we're
able
to
building
import
repository
repository
can
only
attain
the
runes.
A
Oh
the
ruins.
It's
always
the
ruins.
What
the
heck,
oh
duh!
That's
why
those
silly
go
runes
always
always
get
me
I'll.
Tell
you.
Does
anyone
else
hate
that
it's
called
ruins?
I
feel
like
every
time
I
read
documentation.
It
mentions
a
rune,
I'm
just
like
what
is
that
it
sounds
like
something
from
lord
of
the
rings.
A
All
right,
steve
said,
has
youtube
removed
using
at
I
don't
know
steve.
I
hope
not.
Let
me
see
if
I
can
at
you.
I
can
still
at
you
unless
it's
just
because
I
have
very
fancy
permissions.
I
don't
know
all
right.
Lord
of
the
ruins
yeah
exactly
ben,
it's
just
like
I,
I
just
it's
ruin,
ruin
always
strikes
me
so
so
weird.
I
don't
know
why.
A
A
A
Let's,
let's
take
a
step
back,
so
what
we
had
set
up
initially
when
we
were
first
building
everything
up
is
we
had
simple
app,
which
you
might
remember?
I
used
k-build
to
actually
build
the
image
and
push
it
to
docker
hub,
and
then
we
just
pushed
the
bundle
up
right
and
the
bundle
was
obviously
the
metadata
content,
the
lock
file,
all
that
good
stuff
and
you'll
notice.
The
bundle
is
like
this
tag
right.
That
has
obviously
can
be
referenced
through
digest,
but
it's
just
this
that
then
has
references
to
the
oci
image.
A
It
looks
a
little
bit
more
like
this.
Now
when
we
copied
it,
it
would
appear
that
what
it
did-
and
I
don't
know
if
there's
a
flag
to
let
you
like
separate
the
repos-
if
you
want
to
this
actually
probably
is
a
more
elegant
model,
but
it
put
it
all
inside
of
one
location
and
what
it
did
is.
It
now
has
tags
for
the
image,
which
is
what
you
can
see
as
this
300
megabyte
piece
and
then
the
actual
bundle
itself.
A
So
it's
all
self-contained
when
copied
over
here
in
this
one
location,
noelle,
you
said:
how
can
we
enforce
the
deployments
to
use
a
bundled
image,
some
hackery
with
oppa
yeah,
I
think
noel.
If
I'm
understanding
your
question
right,
that
would
be
my
intuition
too.
I
think
you'd
probably
need
to
do
something
at
the
admission
control
level
that
ensures
ensures.
A
I
guess
I
guess
I'd
be
curious,
like
what
are
you
checking
for
exactly
like,
maybe
you're,
checking
to
make
sure
that
the
deployment
manifest
specifies
a
digest
rather
than
a
tag,
if
that's
kind
of
what
you're,
what
you're
looking
for?
That
would
be
probably
something
that
you
you
could
do
but
yeah.
I
think
I
might
be
misunderstanding
your
question
a
bit
but
based
on
just
the
gist
of
it.
It
probably
needs
to
happen
at
the
admission
controller
which
could
be
oppa
or
you
know
something
you
write
as
well
so
yeah.
A
This
is
super
interesting
now
just
to
bring
the
last
piece
full
circle
here,
everyone
and
then
we're
gonna.
I
told
you,
I
was
only
gonna
stay
on
until
until
2
p.m.
Pacific
time
we're
a
little
over,
but
I
don't
want
to
waste
too
much
time.
So,
let's
go
ahead
and
I
never
I
never
stay
on
time
during
these
anyways.
So
it's
old
news
right.
Let's
go
ahead
and
just
pull
this
down
then!
Okay,
so
we've
got
all
right.
A
So
we've
got
cool
all
right
and
I'm
going
to
do
a
new
directory
here.
Just
so
we're
a
little
bit
cleaned
up
and
we're
going
to
call
this
the
complicated
directory
right
and
this
time
we're
going
to
bring
down
the
complicated,
app
bundle,
complicated,
app
bundle
right
just
so
we
can
kind
of
see
all
this
come
together.
All
right.
A
Locating
image
succeeded
good,
okay,
so
inside
of
here,
if
I
go
into
complicated
there,
we
go
all
right.
So
in
the
top
we've
got
complicated
in
the
bottom.
We've
got
simple
or
tgik,
but
these
are
these.
These
are
basically
our
two
right
and
if
we
look
inside
of
the
config
yaml
file
for
or
actually
I
should
say,
the
image
lock
file,
so
image
package
images,
yaml
right
and
then,
if
we
look
inside
of
the
image
package
for
the
image
lock
file
again
now
we
can
see
the
difference
here.
A
So
the
copied
one
knows
that
the
image
digest
comes
from
this
location.
Here
it
comes
from
the
same
bundle,
repo
thingy
in
in
in
container
registries,
whatever
the
heck,
this
part
of
the
uri
represents
right,
and
it
knows
to
reference
that
sha
a0
c7,
which
should
be
this
right
here,
a0
c7
right,
which
is
the
actual
image
itself,
but
then,
of
course,
what
we
pulled
down
as
the
bundle
was
the
7c
833,
whereas
this
one
here
simple,
app
right,
simple
app
was
built
by
us
and
it
is
in
a
completely
different
repo.
A
So
the
simple
app
bundle
we
pulled
this
bundle
down,
but
in
reality
it's
referencing,
not
the
simple
app
bundle,
repo,
but
just
the
simple
app
rebo
again,
which
is
what
the
beauty
of
these
these
lock
files
here
is.
They
can
reference
anything
arbitrarily
and,
and
that's
about
it,
so
this
is
pretty
cool,
I
guess
maybe
to
kind
of
wrap
it
up
here.
Everyone.
What
we
kind
of,
took
a
look
at
today
is
this
idea
of
being
able
to
we,
we
kind
of
okay.
A
We
started
from
like
the
ground
level
right
of
how
can
we
create
consistent,
builds
and
references
for
resolution
to
our
our
deployments
and
their
images
effectively
like?
How
can
we
make
this
immutable?
How
can
we
make
this
consistent,
ensure
integrity
and
I'm
using
the
word
integrity
kind
of
loosely
there?
A
So
don't
read
too
much
into
what
I
mean
by
integrity
as
much
as
just
making
sure
the
file
contents
are
consistent
right
and
then
we
took
that
a
step
further
and
said:
okay,
like
that's
neat,
can
we
do
something
similar
and
create
these
larger
packages?
That
kind
of
understand
all
the
kubernetes
bits?
A
They
understand
the
references
to
those
oci
images
that
we've
now
made
immutable
and
then
just
kind
of
create
this
truly
immutable
system
and
then,
as
I
kind
of
you,
know,
projected
or
postured
about
for
a
little
bit
how,
in
this
format,
we
can
enable
really
really
interesting
models
around
package
management
and
specifically
consistency
in
our
package
management.
As
we
get
super
complex
in
the
different
in
the
different
images
that
we
depend
on,
and
then
perhaps
you
know
we
don't
just
want
to
like.
A
A
We
want
to
make
sure
that
whenever
we
build
the
the
shaw
that
it
references
is
consistent
and
will
not
change
and
that's
something
that
we
can
do
with
a
tool
like
that
which
obviously
sometimes
we
vendor
everything
locally
into
the
repo
to
be
like
extra
extra
extra
sure,
but
it
does
show
how
this
model
can
again
create
consistency
across
all
of
these
packages
and
dependencies,
and
that's
all
I
got
for
today.
So
I
hope
you
all
really
enjoyed
this.
A
This
was
this
was
super
cool
and
I
think
we
should
do
one
more
where
we
try
to
bring
all
the
pieces
together.
So
as
a
reminder,
there
is
a
new
dev
site
up
for
carvel
check
it
out.
I'm
sure
I
should
know
this,
I'm
sorry,
I
don't,
but
I'm
sure,
there's
a
kubernetes
slack
channel.
Someone
in
the
carvel
team
could
probably
say
it.
A
A
But
with
that
being
said,
everyone
thanks
so
much
for
joining
today.
This
was
super
awesome.
I
hope
you
learned
something
about
k-build
and
image
package.
I
definitely
did
it
was
super
fun
and
super
interesting
to
dive
into
this.
As
a
reminder,
we
do
these
tgiks
at
friday
at
1pm,
so
we
should
be
back
very
very
soon.
Exploring
new
topics
might
be
myself,
paul,
tiffany,
joe
we'll,
let
you
know
as
soon
as
possible
on
twitter
when
the
next
episode
is,
but
until
then
everyone.