►
Description
With a growing number of developers building Cloud Native applications with Kubernetes as the preferred platform, managing workloads on Kubernetes effectively and then packaging and distributing these applications while ensuring reproducibility and security has been on the top of their minds.
This workshop starts with the fundamentals of cloud native application development with emphasis on GitOps and does a deep dive with Carvel. At the end of the workshop, the audience will learn how to manage and run their workloads on top of Kubernetes.
Carvel provides a set of reliable, single-purpose, composable tools that help you build, configure and deploy applications on Kubernetes. Carvel tools help reduce the burden of managing workloads on kubernetes, are transparent with the user and have a strong focus on simplicity to make the process of managing workloads intuitive.These tools follow the UNIX philosophy allowing users to integrate them with other tools that are already a part of their workflow conveniently.
When put together with each other, the tools allow users to declaratively set up GitOps (and other single-source-of-truth) workflows for deploying their resources on Kubernetes. Carvel's declarative APIs also allow users to package, version and distribute such workflows to consumers - with special considerations for air-gapped environments. The powerful CLI tools ensure that the workflow can be reproduced while developing the applications reliably, and become an essential part of the development process.
A
Everyone
welcome
to
today's
workshop
on
cloud
data
application
life
cycle
management.
Today
we're
going
to
discuss
some
problems,
people
face
while
managing
the
workloads
on
top
of
kubernetes
and
through
the
course
of
the
workshop.
We
hope
that
you
guys
will
pick
up
some
new
tools
that
might
help
you
in
your
workflows
and
we'll
also
be
sort
of
teaching
you
how
to
distribute
these
workflows
reliably.
A
Then
we're
gonna
explore
how
some
of
the
tools
that
are
part
of
the
kabul
tool
set
address
these
issues
and
then
we're
gonna
get
our
hands
dirty.
We're
gonna
pop
our
terminals
out
and
sort
of
get
some
hands-on
experience
using
these
tools
and
it'll
be
really
cool.
If
you
guys
can
like
sort
of
follow
along
with
us
on,
while
we're
doing
that
it'll
sort
of
help,
you
understand,
what's
going
on
better
before
we
go
any
further
like
quick
introductions,
I'm
sorry
majimdar!
A
I
work
with
the
kabul
team
at
vmware,
so
most
of
my
work
has
been
about
helping
developers,
deploy
their
resources
and
workloads
on
kubernetes
safely
and
confidently
and
sort
of
helping
them
package.
These
work,
workloads
and
version
them
and
deliver
them
to
the
users
in
a
manner
which
lets
them
configure
it
and
then
deploy
it
on
their
own
environments.
B
Thank
you
so
much
hi
everyone,
I'm
praveen,
and
I'm
also
working
at
kavel
team
at
vmware,
and
it
has
been
a
great
experience.
Working
in
the
open
source
community
like
we
directly
get
to
get
feedback
from
users
and
we
are
able
to
provide
them
with
solutions
and
fix
issues
before
work.
Before
joining
the
open
source
community,
I
used
to
develop
microservices
and
go
and
use
to
deploy
them
on
kubernetes
using
cube,
ctrl
yep.
That's
it.
A
You
guys
want
to
sort
of
drop
in
what
you'll
do
and
what
kind
of
work
you
do
in
the
chat
box.
That'll
be
super
cool.
Please
go
ahead
and
do
that,
if
you
want
to
so
now,
I'm
gonna
start
off
and
talk
about
some
of
these
problems.
We
are
talking
about
right,
but
before
we
jump
into
that,
we
would
like
to
know
how
you
all
have
used
kubernetes
so
far,
like
I
think,
garish
and
a
few
other
people
actually
shared
how
they've
been
using
communities
in
their
organizations.
A
C
I'll
I'll
share
it
so
at
cloud
we
use
basically
kubernetes
to
run
our
hands-on
lab,
so
we
provide
hands-on
lab
for
the
end
user
in
the
collaborative
space
and
that
we
run
on
top
of
kubernetes,
and
currently
our
workflow
is
pretty
straightforward.
We
just
have
github
pipelines,
which
we
have
configured
and
as
soon
as
the
we
kind
of
do,
a
code
check
in
the
pipeline
runs,
and
then
we
have
our
department
staging
and
production.
So
it's
pretty
straightforward
right
now,
not
too
many
complications
but
of
course
want
to
hear
more
international.
A
D
We
have
an
application,
which
is
a
micro
based
micro
service
based
application.
We
have
a
lot
of
components
in
that,
and
so
currently
what
we
are
doing
is
we
are
deploying
all
those
services
right.
All
those
micro
services
using
a
helmet,
so
helm
is
like
a
package
manager
right.
We
create
packages
for
all
our
docker
containers
and
packages
for
docker
containers
and
then
do
the
deployment
using
the
pipeline.
Yeah.
A
So,
since
you
all
have
some
experience
with
kubernetes
now
we
can
sort
of
move
on
and
see
some
of
the
problems
which,
I'm
pretty
sure
you
all
must
have
faced
this
one
yeah.
So
starting
off
with
the
first
issue,
we
would
like
to
address
so
since
when,
since
we
author
resources
using
yaml
on
top
of
kubernetes,
it
becomes
pretty
important
to
ensure
that
our
consumers
are
consuming
these
yaml
files
and
configurations
to
deploy
resources
authored
by
us
on
their
environments
are
able
to
sort
of
configure
their
configure.
A
A
The
second
point
is
defining
interactions
between
the
sources
declaratively.
So
basically,
the
kubernetes
appeals
to
people
a
lot,
because
there's
this
whole
idea
that
once
I've
written
my
config,
I
can
easily
deploy
it
in
any
environment.
That's
running
on
humanities,
cluster
rate,
and
it
would
be
the
best
to
get
as
much
as
I
can
done.
A
Declaratively
like
instead
of
having
maybe
some
controller,
or
maybe
some
program
that
or
a
basket
for
that
matter,
which
sort
of
programmatically
let's
say,
creates
a
resource,
then
waits
for
it
to
pop
up
and
then
creates
another
resource.
You
would
rather
just
define
interactions
and
relationships
like
these
between
the
resources
declaratively
in
your
manifests
when
you're
authoring
them,
so
that
it's
good
to
go
for
the
consumer
once
they're
deploying
it
in
their
environments.
A
So
yeah,
that's
where
the
second
point
comes
in
the
third
one
is
replicating
workflows
used
by
developing
applications
reliably.
So
so
we
are
templating
our
manifest
and
we're
defining
relations
among
them.
Then
we're
deploying
it
to
our
cluster
so
we'll
be
using
a
bunch
of
tools
right,
like
kirish
mentioned
that
he's
using
and
some
people
might
be
using
customize,
and
so
you,
you
template
your
yaml
files
using
one
or
multiple
tools.
You
deployed
you
using
a
certain
tool.
A
A
So
now
you
have
a
workflow
setup.
Let's
set
so
get
top
slope
flow
and
you
have
shifted
to
your
consumer
now
they
would
maybe
they
have
some
feedback
for
you
and
you're,
making
some
changes
to
it.
What
you
want
to
do
is
you
want
to
have
some
means
of
creating
different
versions
of
such
workflows
and
then
shipping
it
to
your
users.
So
the
user
should
be
the
user
shouldn't
be
forced
to
move
a
version.
The
user
should
be
able
to
pick
a
certain
version
of
your
workflow
and
then
consume
it.
A
That
brings
us
to
our
last
point
ensuring
immutability
and
consistency.
So
you
have
your
manifests.
You
have
your
manifest
that
are
returned.
Referring
to
some
images,
it's
pretty
important
to
make
sure
that
when
you're
packaging
applications
and
when
the
users
are
consuming
your
applications,
the
manifests
and
images
that
are
consumed
are
exactly
the
same
as
the
time
when
you
are
packaging
it
just
to
ensure
consistency
in
the
development
workflow
in
the
production
workflow
and
even
between
different
users
who
are
consuming
the
same
version
of
your
package
right.
A
So
kavel
provides
a
set
of
tools
that
are
really
each
of
the
individual
tools
are
really
good
at
doing.
One
thing
like
they
do
one
thing
really
well,
but
when
these
tools
are
put
together
to
create
a
development
workflow,
what
we
see
is
that
it's
an
ideal
tool
set
for
managing
your
workloads
on
top
of
kubernetes
and
the
cool
part
is,
if
you
use
the
kabul
tools
to
sort
of
build
your
development
workflows.
A
A
So
and
another
cool
thing
about
travel
is
that
it's
based
on
the
unix
philosophy,
where,
as
I
said,
each
tool
is
really
good
at
something,
and
these
tools
are
composable
like
so
you
can
choose
to
use
one
of
our
tools
ytt
with
one
of
our
other
tools
cap,
but
you
could
also
choose
to
use
ytt
and
maybe
cube
cutter
or,
let's
say
even
helm
and
cap,
like
these
tools,
are
pretty
that's
what
we
mean
by
composable.
They
can
fit
into
your
existing
workflows
pretty
easily
and
you
can
also
pair
them
with
other
tools
pretty
easily.
A
So
what
I'm
gonna
describe
over
here
is
exactly
what
we'll
be
doing
when
we
get
to
the
hands-on
part
of
the
workshop
so
yeah,
so
things
might
get
much
more
clearer
when
we
actually
start
doing
these
things
right.
So
the
first
part
we
discussed
was
authoring
a
parameterized
and
configurable
package
of
manifest
right
so
and
the
second
point
being
define
interactions
between
resources
declaratively.
So
these
two
are
addressed
together
by
cap
and
ytt.
A
The
idea
is
that
cap
surfaces,
this
api,
which
lets
you
define
a
certain
ordering
amongst
the
resources
and
even
dependencies
in
that
manner.
Like
let's
say
you
have
a
deployment
which
is
consuming
a
secret
which
has
some
sensitive
credentials
rate
and
every
time
you
update
your
secret,
you
have
to
restart
your
deployment.
You
can
define
such
relationships
declaratively
in
your
conflict
and
that's
it
once
you
deploy
resources.
Your
deployment
is
restarted.
Every
time
you
update
your
secret,
you
don't
have
to
keep
in
mind
that
you
have
to
do
that.
You
can
declare
relationships
like
that.
A
You
can
use
ytt
to
allow
the
user
to
supply
certain
values
which
can
be
used
to
template
your
manifest
and
what's
unique
about
ytt
and
which
sort
of
makes
ytd
different
from
other
templating
tools.
Is
that
templating
tools
generally
look
at
yaml
as
of
their
text
like
it'll,
be
more
like
okay,
so
at
this
line
I
want
to
add
this
value
that
the
user
has
provided.
A
A
A
So
so
you
will
be
doing
certain
steps
using
these
tools
when
you're
deploying
your
applications
using
your
host
rate.
So
what
cap
control
lets
you
do?
Is
it
lets?
You
create
resources
which
sort
of
create
a
workflow
template?
You
tell
cap
controller
that
to
deploy
this
application.
What
you
have
to
do
is
fetch
the
manifest
from
this
location,
templated,
using
these
tools
and
then
deploy
it
using
cap
and
cap
controller
takes
care
of
it,
so
it
allows
people
consuming
your
concept
to
easily
deploy
it
into
that
environment.
A
The
third
one
is
packaging
and
distributing
different
versions
of
switch
workflow
and
the
last
point
being
ensuring
immutability,
so
image
package
and
cable
sort
of
work,
hand
in
hand
with
tap
control
over
here.
What
cable,
basically
does
is
so
when
we
are
referring
to
images
right
when
we
are
referencing
images
and
manifests
what
we
generally
do
is
we
use
tags
to
decide
which
version
of
the
image
to
use
and
tags,
however,
are
not
immutable,
we'll
be
getting
more
into
that
later
on,
so,
basically,
cable
converts
these
references
into
immutable
references.
A
That
means
that
referencing
point
to
only
one
image
and
what
image
package
does
is
image
package.
So
we
have
two
components
here.
There
are
your
images
and
you
have
your
config,
that's
written
in
yaml
right,
so
we
use
cable
to
ensure
that
our
images
are
immutable
because
the
references
are
immutable.
A
So
how
do
we
ensure
that
the
yaml
config
that
we've
written
is
immutable
as
well?
So
what
image
package
does?
Is
it
sort
of
creates
an
oci
image
with
your
yaml
files,
it
bundles
your
ml
files
into
an
oci
image
that
can
be
pushed
onto
any
image
registry
like
docker
hub-
or
maybe
you
all
have
hardware
running
internally
so
now
that
we
have
an
image
with
all
of
our
files
in
it.
A
It
can
also
be
made
immutable
by
cable
right
so
yeah,
that's
how
so
that's
how
all
the
tools
fit
in-
and
this
is
going
to
be.
This
workflow
is
going
to
be
way
easier
to
visualize.
Once
we
actually
get
some
hands-on,
then
we
get
to
the
hands-on
part
of
the
workshop
right.
So
I'm
just
going
to
go
over
the
agenda
of
the
workshop
itself,
so
we're
going
to
start
off
by
authoring
a
config
and
then
parameterizing
using
ytt.
A
Your
applications
using
these
tools,
allows
your
consumers
to
get
up
and
running
with
these
applications
quickly
and
configure
them
according
to
their
needs
right.
So
before
we
jump
into
the
hands-on
part.
So
does
anyone
have
any
questions
or
thoughts?
So
far,
does
anyone
want
to
share
anything
regarding
the
previous
slide
or
this
one.
A
A
B
F
Yeah
yeah
hi
yeah,
I
mean
hi
strong,
so
yeah
so
just
to
be
like
I
just
want
to
understand
so.
Kpac
basically,
is
part
of
this
kubernetes
container
build
service
tool,
so
what
it
does
basically
is
creates
a
complete
oca
compliant
image
from
source
right.
So,
as
I
understand
kpac
from
the
buildback
ecosystem,
it's
run.
It
runs
a
complete
life
cycle
execution
phase
in
creating
that
image.
F
A
E
A
Before
we
jump
into
the
hands-on
part
of
it,
I'm
just
going
to
share
across
the
repository
right
now
and
that
repository
basically
sort
of
it's.
It's
like
an
overview
of
everything
that
we'll
be
going
through
in
the
workshop
and
it'll
really
help
you
guys
sort
of
follow
along
with
us
before.
So
I'm
going
to
share
this
link
in
the
chat
right.
A
So
if
you're
able
to
see
your
api
resources
listed
there,
that
means
that
we're
good
to
go.
So
in
this
repo
we
have
most
of
the
commands
that
we'll
be
executing,
so
you
can
easily
copy
them
and
paste
them
in
your
terminal
so
that
you
can
keep
up
with
us
and
if
we
do
execute
something
that
is
maybe
not
listed
over
here,
we'll
make
it
a
point
to
sort
of
put
down
the
chat
box
right.
A
So
to
start
off
with,
let's
install
the
tools,
we
were
just
talking
about
right
so
for
people
who
are
following
along
just
you
can
either
use
the
installation
strip
that
we
have
on
the
site
to
install
all
the
tools
by
running
this
command
or
if
you
prefer
brew,
you
can
go
ahead
and
run
these
set
of
commands
and
tap
into
our
home
view.
Repo
and
just
grab
the
cli.
A
A
A
A
A
A
B
All
right
so
we'll
get
started
with
chapter
one,
and
we
are
going
to
take
a
look
at
a
very
simple
app.
It's
it's
written
and
go
it.
What
it
does
is
it
just
starts
a
server
on
port,
8081
and
prints.
The
message,
hello,
username
and
username
is
something
that
we
can
provide
by
provide
by
using
an
environment.
Variable,
that's
user
underscore
name,
and
what
we
have
done
is
we
have
already
dockerized
it
and
pushed
the
image
to
docker
hub,
and
you
can
see
that
image
over
here.
B
B
Okay,
so
now,
once
we
have
our
application
ready,
what
we
would
want
to
do
is
would
want
to
like
deploy
it
to
our
cluster
and
like
to
deploy
a
service.
We
generally
use
deployments
and
we
will
be
using
a
service
to
communicate
with
the
deployment,
and
we
will
be
using
a
config
map
to
sort
of
provide
the
environment
variables
that
we
would
want
to
use
in
our
application.
G
B
G
B
Okay,
so,
as
you
all
can
see
over
here,
what
tap
does
is
it
provides
a
basic
summary
of
what
are
the
changes
it's
going
to
make
on
the
cluster.
So
it's
going
to
create
a
config
map
and
it's
going
to
wait
for
it
to
reconcile
successfully.
Then
it's
going
to
create
deployment
and
a
service
and
again
wait
for
reconciliation.
B
So,
for
example,
it
tries
to
deploy
the
crds
before
cos
and
names
pisses
before
namespace
resources
and
resources,
like
config
maps
and
secrets,
which
are
mostly
used
in
deployments
and
services,
so
it
creates
the
config
map,
first
waits
for
it
to
reconcile
and
then
goes
on,
to
deploy
the
service
and
the
deployment,
and
then
it
waits
for
all
the
parts
to
show
up.
So
if
we
do
cube
cdl
get
purge
would
be.
We
should
be
seeing
three
three
parts
which
are
up
and
running
for
the
simple
server
app.
B
Does
anyone
have
questions
so
far?
So
if
there
are
some
changes
on
the
cluster
after
deployment
will
lead
to
the
reconciliation
depends
on
what
kind
of
changes
we
are
looking
at.
Like
let's
say
there
is
some
mutating
web
book
which
is
going
to
make
some
changes
afterwards,
then
probably
not,
but,
for
example
over
here.
If
the
deployment
is
going
to
create
a
replica
set
and
three
other
parts,
then
yes
I'll
wait
for
the
or
wait
for
all
the
child
resources
to
be
up
and
running.
B
B
So,
okay,
actually,
we
can
also
use
a
flag
called
high
frequency
to
which
cap
to
show
so
show
the
diff
between
the
current
changes
in
the
cluster
and
the
and
the
one
that
we
are
trying
to
like
make
to
it
have
made
to
the
manifest
right
now.
So,
as
you
can
notice,
we
made
the
change
over
here
in
the
configmap.
We
updated
our
username
environment
variable
and
now
now
we
would
go
back
to
like.
Why
did
we
use
an
annotation
called
version?
B
B
Now
what
this
does
is
it
versions
this
resource,
and
now,
whenever
we
are
trying
to
use
this
config
map
in
a
deployment
it
sort
of
like
updates
the
deployment
as
well,
because
the
version
has
been
updated
for
it.
So
if
we
take
a
look
at
the
stiff,
it
shows
a
simple
app
config
version
2
instead
of
version
1,
because
we
have
updated
a
value
in
the
config
map.
B
B
B
B
B
B
B
B
B
B
B
B
Let's
move
on
to
our
next
section,
then.
So,
while
taking
a
look
at
the
our
deployment
conflict,
we
could
see
that
there
are
like
bunch
of
duplications
present
over
here,
and
there
are
also
some
configurations
configure
configurable
values
that
we
would
want
to
like.
Maybe
make
them
maybe
like
supply
them
in
a
more
configurable
way.
Let's
say
so.
B
B
B
So,
instead
of
like
up
providing
these
labels
at
every
place,
we
could
define
a
function,
which
is,
let's
say,
define
labels
simple
app,
and
then
we
could
just
call
this
function
wherever
we
want
to
provide
those
values.
So
we
do
match
labels,
labels
and
labels,
labels,
which
this
would
basically
provide
all
these
all
the
labels
that
are
in
this
function
to
wherever
we
have
used
this,
where
very,
have
called
this
labels
function.
B
B
B
So
we
could
also
like
type
by
td
output
through
cap
and
do
make
the
deployment
using
that
also
the
day.
The
schema
that
we
have
provided
is
kind
of
the
default
values
that
we
would
want
to
have.
If
we
want
to
overwrite
the
default
values,
we
can
have
data
values
and
we
could
provide
those
values
over
here.
So
if
we
would
create
a
values.ml
with
this,
then
it
would
replace
the
username
that
zombic.
C
B
G
B
B
About
cap,
I
would
say,
like
I
guess
I
have
already
mentioned
a
few
advantages,
which
is
you
get
to
see?
What
are
the
changes
that
you
are
making
like?
There
is
a
transparency
which,
like
increases
the
confidence,
and
then
there
are
things
like
ordering
custom,
ordering
weight,
rules
and
versioning
of
resources
that
would
allow
us
to
like
or
deploy
resources.
B
B
B
E
B
B
Setting
a
root
cancellation
loop
in
case
objects
bring
different
resources
to
the
desired
state
and
dcd
great
cool.
We
I've
got
some
great
answers
over
here.
So,
as
you
all
have
like
mentioned,
controller
is
basically,
it
sets
a
control
loop
in
cage
where
and
it's
basically
like
a
thermostat.
So
if,
like
we
said
a
temperature,
it
tries
to
like
have
that
temperature
maintained
so
as
soon
as
like
it
notices
a
difference
in
the
temperature
that
has
been
provided
and
is
there
in
the
group.
B
B
So
we
have
a
tap
controller,
which
does
something
similar
for
app
crs
and
appcrs
is
something
that
tap
controller
provides.
So
in
one
of
the
steps
that
sumik
had
provided.
Initially,
you
would
have
installed
cap
controller
using
cap.
Now
we're
going
to
take
a
look
at
what
an
app
crs
like
it's.
Basically,
it
defined
three
stages:
where
can
it
fetch
the
required
resources
from
how
it
should
template
it
and
how
it
should
deploy
it?
B
So
we
have
like
created
an
appcr
for
our
purpose
over
here,
which
is
named
as
hello
app,
and
then
it
uses
a
service
account
which
is
default
nssa.
It
would
create
this
create
that
default,
create
that
service
account
as
well,
and
then
we
have
the
first
stage,
which
is
where
it
should
fetch
the
configuration
from
we
are
going
to
use
the
configuration
that
we
had
just
provided.
B
So
it's
it's
going
to
be
the
same
repo
that
we
are
in
right
now
and
it's
going
to
fetch
it
from
the
main
branch
and
then
it's
going
to
use
templating
and
using
vitate,
and
we
would
want
to-
and
this
is
like
the
path
where
the
configuration
would
be
located.
So
that's
chapter,
one
slash
config,
and
then
we
are
going
to
use
cap
to
basically
deploy
our
application.
B
B
B
B
Okay,
now
we
can
also
talk
about.
There
was
one
question
like
what,
if
there
are
some
changes-
and
we
would
want
to
like
get
those
deployed
as
soon
as
like
the
changes
are
made,
so
that's
where,
like
tap
controller,
comes
into
picture,
so
I
have
like
appear
ready,
which
would
basically
change
the
value
schema
and
make
the
default
value
to
be
kcd,
and
we
are
going
to
merge
this
pr
to
the
main
branch.
B
E
B
So
cap
controller
has
like
a
default
sync
period,
which
I
think
is
10
seconds
and
what
it
would
do
is
it
would
fetch
the
resources
again
and
then
do
the
templating
and
do
the
deployment
if
there
are
like
any
changes,
detected,
not
sure
if
it
has
already
done
that.
But
we
can
take
a
look
at
okay.
It
hasn't
done
it
yet.
E
B
B
B
Any
questions
so
far,
I
am
pasting
the
link
for
the
custom
app
over
here
and
which
is
basically
fetching
the
app
from
the
same
repository
and
chapter
one
config.
You
can
take
a
look
at
the
apps
here,
the
different
three,
the
different
stages
of
the
app
cr2
like
see
how
it
does
the
fetch
flick
from
where
it
fetches
and
what's
the
path
for
templating.
A
E
A
Now,
what
we'll
be
doing
is
we'll
be
sort
of
moving
towards
the
packaging
part
of
things
now
quick
question
for
people
here:
what
do
you?
What
comes
to
your
mind
when
we
say
packaging
like
in
a
general
sense?
It
doesn't
have
to
be
specific
to
kubernetes
or
anything
like
that
when
you're
packaging
and
versioning
an
application.
E
A
A
So
when
we
talk
about
applications
that
we're
deploying
on
top
of
humanities,
there
are
two
parts
to
it
right
one.
We
have
the
images
that
are
being
referred
to
by
the
config,
and
then
we
have
the
config
itself
so
for
chapter
three.
What
we'll
do
is
we'll
sort
of
first
make
sure
that
our
images
themselves
are
immutable,
then
go
ahead
and
see
how
we
can
make
our
config
immutable
as
well
to
start
off
with.
So
we
generally
reference
images
using
their
tags
right.
A
So
what
we
do
is
we
ensure
that
each
image
that's
being
referenced
by
our
configuration
is
in
its
digest
form.
So
what
the
digest?
Basically,
is
it's
a
sha-256
hash
of
the
image
itself
so
to
put
into
context
we
always
hash
passwords
before
storing
them,
because
for
a
particular
password
there
can
only
be
one
hash
and
similarly
for
a
particular
image,
there
can
be
only
one
hash
that
can
refer
to
it.
A
A
It
has
a
configuration
that
we
templated
using
ytt
and
added
some
rules
to
using
tap.
So
what
I'm
going
to
do
is
I'm
quickly
going
to
template
it
again
and
we
should
be
able
to
see
the
output
and
std
out.
So
that's
the
templated
image
we,
the
templated
configuration
we
deployed
last
time
so
now
what
we
would
want
to
do
is
we
would
like
to
ensure
that
all
of
the
images
that
are
being
used
or
are
being
referenced
to
using
digest.
A
A
So,
as
you
can
see
what
cable
did
over
here
is
it
sort
of
replaced
all
of
the
images
that
were
being
referenced
to
its
digest
form
so
now,
let's
say
we're
packaging.
This
application
right
now
right.
So
now
we're
sure
that
if
we
give
this
package
to
someone,
the
image
that
is
going
to
be
used
is
going
to
be
the
exact
image
which
we're
using
while
we're
packaging
it,
and
so
now
that
our
images
are
in
place.
A
Now
that
we
are
sure
that
our
images
are
immutable,
the
next
part
would
be
to
sort
of
make
our
manifest
the
configuration
that
we've
written
immutable
as
well,
so
to
do
that.
We're
going
to
use
the
tool
image
package
so
also,
if
you
all,
are
following
along-
and
you
want
to
push
your
own
image
package
bundles
to
your
own
repositories,
make
sure
that
you're
logged
into
your
docker
account
like
you've,
run
docker
login
once
because
image
package
is
going
to
pick
up
that
configuration
right
so
go
ahead
with
the
actual
bundling
of
things.
A
So
the
desired
state
here
would
be
to
bundle
all
of
the
files
that
we
have
in
our
config
directory
into
one
image
that
can
be
pushed
to
a
registry
before
we
do
that.
We
want
to
let
image
package
know
about
the
references
that
we
want
our
yaml
to
use
right
the
image
references
that
we
just
made
immutable.
A
A
A
A
A
A
A
A
A
A
A
Why
create
an
image
for
the
config?
How
do
we
change
the
config
per
environment
right
so
when
we
get
to
the
packaging
part
of
it
right,
I'm
going
to
go
over
how
users
can
configure
the
packaged
yamls
as
well.
So
if
you
noted,
I
did
point
out
that
we're
storing
the
templated
manifest
rate
in
the
bundle
itself,
so
when
the
user
installs
the
package
there's
a
way
in
which
the
user
can
apply
their
own
data
values
to
the
package
while
installing
it.
A
A
And
it's
worth
noting
that
so
when
we
bundle
that
image
right,
it
had
a
certain
structure,
the
structure
looked
something
like
there's:
an
image
package
directory
with
all
the
with
the
reference,
the
digested
references
for
the
images,
and
then
we
had
all
our
config
right.
This
config
file
can
have
multiple
yaml
files
as
well.
A
E
E
A
So
a
package,
the
first
thing
about
a
package
is
that
you
might
have
multiple
versions
of
a
package
and,
however,
the
different
versions
of
the
package
will
be
associated
with
the
same
metadata.
Right
like
you
might
wanna
with
you
might
wanna
include
information
such
as
what
the
application
does
a
list
of
maintainers
you
might
wanna
mention
how
the
users
can
find
help.
So
the
first
thing
we
do
is
we
sort
of
define
a
metadata
config,
which
sort
of
tells
the
users
what
the
package
does.
A
A
The
next
thing
we
like
to
do
is
template
the
config
template
the
configuration
that
we
have.
So
we
tell
the
package
that
once
you've
fetched
the
resources
needed
you're
going
to
go
ahead
and
template
it
with
ytt,
and
if
you
remember
correctly,
all
of
our
resources
are
in
the
conflict
directory
right
and
we
tell
that
after
the
resources
have
been
templated
using
ytt.
A
A
So
if
there
are
no
questions,
we
are
gonna
go
ahead
and
address
garish's
questions
right,
like
how
do
our
users,
while
consuming
these
packages,
sort
of
configure
the
application?
So
while
a
user
is
installing
an
application,
they
can
actually
supply
an
open
api
schema
of
sorts
which
defines
the
values
that
the
user
can
configure.
A
So
if
we
go
back
to
the
value
schema
which
we
made
in
chapter
one,
we
have
two
values
that
can
be
configured
svc.
Port
has
a
description,
it's
a
number.
Username
is
a
string
and
it
has
a
description
as
well.
So
we
put
in
the
same
information
into
our
package
right
and
yeah,
so
we
basically
say
that
these
are
the
properties
that
the
user
can
provide.
We
specify
the
type
for
each
of
those
properties.
A
A
A
So,
let's
take
an
example
of
rpm
or
debris
if
you're
using
dev,
you
would
probably
add
something
like
epl,
which
is
a
repository
of
all
the
common
packages
that
are
used
right
and
yeah.
So
if,
if,
if
you're,
using
npm
the
go
to
packages,
the
npm
modules
repository
that's
there
and
it
has
all
sorts
of
packages
that
you
can
use.
So
when
your
user
is
consuming
your
packages,
you
sort
of
want
to
surface
a
certain
repository
which
lets
the
user
grab
all
of
the
all
of
your
packages
at
one
state.
A
So
for
creating
a
repository,
we
don't
have
to
write
any
yaml,
particularly
so,
if
you,
if
we
go
back
to
our
previous
chapter,
we
would
recall
that
we
use
the
certain
format
for
defining
our
package
contents.
Repository
like
this
is
the
like.
We
sort
of
had
a
format
where
we
had
an
image
package
folder
with
our
image
log
file,
and
then
we
had
a
file
with
all
of
our
configuration.
A
So
the
image
package
log
file
will
have
the
image
log
file,
which
sort
of
maps
every
image
that's
consumed
by
the
packages
in
the
repository
to
its
digest
form
and
the
packages
directory
will
have
a
folder
dedicated
to
each
one
of
your
packages.
Since
we
only
have
one
package,
our
our
directory
is
going
to
look
something
like
this.
A
E
E
A
So
this
is
a
log
file
which
we
can
generate
by
using
the
cable
right.
So
if
we
were
to
do
this
again,
we
would
do
something
like
cable
dash,
f,
and
here
we
want
to
hash
all
of
the
images
that
are
being
used
in
your
repository,
like
we
use
by
all
of
the
packages
in
your
repository.
So
we
do.
We
mentioned
that
this
is
the
folder,
where
you
can
find
all
the
image
references
and
then
we
go
ahead
and
put
the
image
package
lock.
Output
file.
A
A
What
and
if
we
so
we
have
our
image
package
log
file,
which
defines
all
of
the
images
the
relation
between
the
tag
and
digest
for
an
image.
And
if
you
look
at
our
packages,
it
has
a
hello
package
and
that
itself
will
contain
the
package
file
that
we
have
written
and
the
metadata
file.
So
if
we
look
take
a
look
at
it
over
here,.
E
A
A
A
But
the
answer
to
your
question
is:
definitely:
yes,
you
don't
have
to
bundle
it
as
an
image
package
bundle.
It
can
definitely
be
directly
consumed
as
a
yaml
file
like
if
we,
if
you
recall
previously,
I
tried
to
deploy
my
packages
using
cap
instead
of
bundling
them
into
a
repository.
That's
that's
a
definite
possibility.
A
Does
that
answer
your
question?
Yeah,
okay,
cool
right!
So
if
there
aren't
any
more
questions,
I
think
we're
going
to
go
ahead
and
see
how
our
users
consume
the
packages
right
so
you've
put
in
the
work.
You've
created
a
package
out
of
your
application.
You've
created
a
repository
and
you've
now
you're
ready
to
ship
it
to
a
user.
So
let's
see
how
a
user
would
go
around
about
like
consuming
a
package
repo
so
as
to
say.
A
So
for
consuming
a
package
repo
we'll
be
using
the
kc
trl
cll,
which
sort
of
makes
it
easier
for
users
to
get
up
and
running
with
packages
super
fast
rate.
So
from
our
previous
commands,
we
have.
We
have
a
link
to
the
image
package
image
package
bundle
which
has
which
con,
which
has
all
the
information
required
for
us
to
create
a
repository
so
to
get
up
and
running
with
the
repository.
The
user
would
do
something
like
we're
going
to
call
this
repo,
hello,
reaper
and
we'll
supply
this
url
to
the
user
right.
A
A
A
And
list
the
packages
that
are
available
on
the
cluster,
so
this
is
the
package
that
we
created
previously,
and
so
what
the
repository
allowed
the
user
to
do
is
execute
one
straightforward,
simple,
command
and
add
all
of
the
packages
that
can
be
bundled
as
a
part
of
that
resource.
Oh
that
can,
oh,
I
think,
there's
a
question.
A
E
A
So
here
we
can
so
what
happens
here
is
this
information
is
actually
fetched
on
the
metadata
right
and
we
are
also
listing
all
of
the
versions
that
are
available
on
the
cluster,
and
so
let's
say
once
the
user
has
used
this
information.
They
want
to
go
ahead
and
install
version
one
onto
their
clusters.
A
E
A
So
when
a
package
is
installed,
what
it
basically
does
is
it
replicates
the
workflow
that
we
had
defined
while
creating
it
how
it
should
template
the
application?
Where
should
it
get
the
image
references
from
and
how
it
should
deploy
it
right?
So
if
we
were
to
run
a
cap
list
right
now,
we
can
see
that
there's
an
app
called
hello,
app
ctll,
that's
created
right.
A
So,
as
you
can
see
the
resources
that
are
created
by
this
package
once
it's
installed
and
the
same
as
the
one
that
was
once
that
were
created
when
we
deployed
our
resources
initially
and
to
verify-
let's
just
port
forward
at
once.
So
we're
gonna
port
forward
and
just
open
up
our
browsers
to
see
if
it's
up
and
running.
E
A
Stranger,
so
now
that
we
have
a
package
up
and
running,
we,
we
see
how
the
user
can
install
the
package.
What
one
of
the
most
important
parts
is,
how
the
user
configures
the
packages
right.
So,
let's
get
to
that.
So,
if
you
recall
correctly,
we
also
defined
a
schema
for
the
values
which
can
be
supplied
by
the
user
to
we
can
actually
view
the
values
that
can
be
configured
by
doing
something
like.
A
So
over
here
we
can
see
that
these
are
the
two
configurable
values
that
we
have.
We
can
see
the
types
and
we
can
see
the
effect
they
have
on
the
package
itself
right
when
it's
being
installed.
So
what
I'm
going
to
do
is
I'm
going
to
try
to
sort
of
change
the
username
that's
being
consumed?
Maybe
so,
since
this
package
is
already
installed,
I'm
going
to
update
the
existing
installation
with
a
new
username,
I'm
quickly
going
to
whip
up
file
which
supplies
these
values
to
the
package.
A
A
We
wrapped
it
in
the
package
and
then
we
created
a
package
repository
which
supplies
that
package,
and
then
we
sort
of
took
the
role
of
a
consumer
and
went
through
how
a
consumer
would
consume
such
a
package.
Right
so
is.
Are
there
any
questions
regarding
how
the
whole
package
creation
and
consumption
process
went
through?
A
E
A
So
you
can
join
our
kavel's
travel
slack
channel,
which
is
on
the
cube
in
the
kubernetes
workspace,
and
you
can
also
find
us
on
github
if
you
have
any
issues
regarding
how
you're
using
the
kavel
tools
or
if
you
have
any
suggestions
that
might
help
us
improve
on
the
karma
tools,
you
could
definitely
raise
an
issue
on
a
github,
github
deposit.
Please,
you
can
find
the
links
to
the
same
in
the
dock
itself,
like
in
the
github
itself.