►
From YouTube: Simplify Your Cloud Native Application Packaging and Deployments - Chris Crone, Docker
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Simplify Your Cloud Native Application Packaging and Deployments - Chris Crone, Docker
With so many tools for declaring and deploying applications, developing cloud native apps can get complicated quickly. Single container images can be built and shared with a registry, but what about multi container or other more complex applications? Using the CNAB (Cloud Native Application Bundle) specification, open source projects like Docker App or Porter allow you to package apps that would normally require multiple tools like Terraform, Helm, and shell to deploy - into a single tooling agnostic packaging format. These packages can then be shared using existing container registries and used with other CNAB compliant tools. In this talk, Chris Crone, co-executive director of the CNAB project, will share how to simplify cloud native development workflows using your favorite tools like Terraform, Helm and others, without requiring every developer to learn them.
https://sched.co/Zet9
A
Let's
take
a
look
at
the
agenda
for
today's
talk,
we'll
start
with
what
a
cloud
native
application
is
we'll
take
a
look
at
some
of
the
packaging
and
deployment
challenges
for
them,
I'll,
introduce
you
to
cloud
native
application,
bundles
or
cnab
I'll.
Do
a
quick
demo
I'll
then
talk
about
how
cnab
solves
some
of
the
application,
packaging
and
deployment
problems
I'll
show
you
where
to
learn
more
about
cnab
and
finally
I'll
take
questions
from
the
audience.
A
So,
let's
start
with
this,
what
is
a
cloud
native
application?
The
first
place
I
looked
was
in
the
oed,
where
they
define
an
application
as
a
program
or
piece
of
software
designed
to
fulfill
a
particular
purpose.
That's
a
pretty
broad
definition,
but
it
gives
us
a
good
starting
point
to
discuss
cloud-native
applications
in
general.
An
application
is
trying
to
solve
a
problem
either
that
the
user
has,
or
your
company
has
or
something
back
office
that
you
need
to
that
you
some
problem,
you
have
the
first
aspect
of
any
application
is
the
compute.
A
A
There's
also
things
like
virtual
machines
or
even
bare
metal,
where
you
can
run
your
application.
The
next
aspect
to
any
application
is
storage.
Every
application
will
probably
have
some
some
form
of
state
that
it
needs
to
store,
or
it
may
have
assets
that
it
needs
to
serve
to
to
people
so
that
could
be
stored
in
databases.
A
It
could
be
stored
in
average,
object,
storage
like
s3
or
in
posix
volumes,
so
things
like
efs.
Finally,
because
we're
talking
about
the
cloud
there's
definitely
networking
involved.
We
need
to
connect
all
these
components
up
and
we
need
to
have
a
way
of
exposing
our
application
to
the
end
user.
That
brings
us
to
this
landscape.
A
A
A
So
let's
talk
a
little
bit
about
deployment
tooling
of
these
applications.
Well,
the
first
challenge
is
that
often
you
don't
need
just
one
tool
to
deploy
an
application.
You
need
multiple,
there's,
always
the
challenge,
then,
of
keeping
the
readme
up
to
date
to
make
sure
that
you
have
exactly
what's
required
to
deploy
and
manage
the
application
written
down
somewhere
and
that's
a
manual
process.
A
So
what
would
ideal
development
tooling
look
like?
Well,
I
think
it
would
be
defined
as
code,
so
the
tools,
versions
and
options
should
all
be
written
in
a
file
somewhere
and
they
should
be
used
as
part
of
the
deployment
process.
This
is
where
we
can
learn
from
the
infrastructure
as
code
movement,
which
has
made
infrastructure
much
more
reproducible
and
much
better
to
use.
A
The
other
thing
that
I'd
like
to
see
is
the
same
deployment
environment
everywhere.
I
don't
want
to
have
to
think
about.
If
this
is
on
windows,
mac
or
linux,
and
what
the
person
has
installed,
I
just
want
the
same.
The
same
thing
same
commands
to
work
everywhere:
let's
take
a
look
at
packaging
now,
so
the
first
thing
that
I've
noticed
when
I've
looked
at
cloud
native
applications
is
that
often
you'll
be
storing
different
parts
of
the
application
in
different
places.
A
So,
let's
start
with
the
application
manifest
or
the
part,
the
thing
that
defines
how
the
components
fit
together.
In
this
case,
I'm
going
to
use
composers,
the
example,
but
it
could
be
kubernetes
ammo
or
something
else.
Often,
this
is
stored
in
a
git
repo,
because
it's
just
a
text
file.
So
in
this
case
I
put
github
and
you
can
see-
I
have
two
services
inside
there
a
front
and
a
back
that
reference.
Two
images.
A
The
next
piece
is
the
deployment
tooling.
Well,
that's
a
challenge
because,
as
I
showed
before,
it
depends
on
which
computer
it's
running
on
so
there's
some
development
shooting
on
my
machine
which
hopefully
matches
that
on
the
ci
and
which
hopefully
then
matches
what
users,
if
you
have
any
end,
users
need
to
run
and
then
there's
application
dependencies.
So,
in
the
case
of
my
application
here,
it's
container
based,
and
so
the
container
images
would
go
to
something
like
the
docker
hub,
you'll
notice.
A
Here
that
I
have
at
least
three
different
places
where
I'm
storing
pieces
of
my
application-
and
this
is
a
problem
because,
for
example,
if
that
image
gets
deleted,
the
userfront
1.19
image
gets
deleted.
My
application
won't
deploy
anymore,
but
there's
no
way
that
somebody
who's
using
the
manifest
from
github
will
know
that.
A
A
A
A
A
A
Let's
take
a
look
at
the
bundle
structure,
so
how
the
applications
are
packaged.
We
call
this
the
bundle
definition,
which
is
usually
a
bundle.json
file.
The
first
part
of
this
is
the
invocation
image.
This
is
an
often
a
container
image
because
that's
what
we're
most
comfortable
with,
but
it
doesn't
have
to
be.
The
invocation
image
contains
both
the
application
definition
so
in
in
the
example
I
gave
before
the
compose.yaml,
as
well
as
the
deployment
tooling.
A
A
We
have
a
list
of
credentials
required
to
deploy
the
application,
so
this
is
a
way
that
the
bundle
can
communicate
what
permissions
and
things
like
that
it
needs
for
the
deployment
and
management
of
the
application
we
have
parameters.
So
these
are
minor
changes.
A
user
may
wish
to
make
to
the
application
at
runtime,
so
it
could
be
changing
which
port
the
application
is
serving
on,
or
things
like
that,
and
then
we
have
a
reference
to
the
components
that
the
application
depends
on.
A
A
You
can
also
have
custom
actions,
though,
for
your
application,
so
these
could
be
things
that
are
well
known,
like
status
or
logs,
and
they
can
be
stateless
or
stateful.
So,
for
example,
fetching
the
status
of
the
logs
from
an
application
would
be
stateless,
you're,
not
changing
the
state
of
the
application,
but
you
could
have
state
full
actions
where
you
change
the
state
of
the
application.
A
The
application
life
cycle
is
tracked
by
claims,
so
basically,
this
keeps
track
of
which
operations
have
been
run
in
your
application
installation
and
when
they
were
done,
if
they
were
successful,
not
and
so
so
forth,
it
keeps
a
record
of
which
parameters
and
outputs
were
generated
and
used
for
the
for
each
step
or
for
each
time.
You've
made
a
change
to
the
application,
but
we
only
define
the
data
structure
for
this.
We
don't
define
how
you
do
this
exactly.
A
Okay,
now
that
I've
introduced
cnab
as
a
specification,
let's
take
a
look
at
a
tool
that
actually
implements
the
specification
that
you
can
use.
So
the
tool
that
I'll
be
presenting
today
is
called
porter
and
was
developed
by
microsoft.
If
you'd
like
to
get
it,
you
can
go
to
porta.sh,
so
you
can
see
I'm
running
the
latest
version.
A
The
way
that
you
define
your
bundle
with
porter
is
using
a
porter.yaml
file,
so
you'll
see
over
here.
I've
created
one.
There
are
loads
of
comments
here,
because
I've
put
all
my
demo
material
on
github
and
I'll.
Give
you
the
link
at
the
end
of
this
talk,
so
that
you
can
run
the
demos
yourself
as
well.
A
A
A
A
A
A
We
now
get
to
the
actions,
so
we
have
the
install
action
first,
as
you'd
expect.
We
have
two
steps.
We
have
a
terraform
and
we
have
a
helm
step.
The
first
step
is
where
we're
going
to
be
creating
our
namespace,
so
I'm
passing
the
kubernetes
context
we
want
to
use
and
the
namespace
that
we
want
to
create,
and
then
over
here
you'll
see
I
have
an
output
of
the
namespace.
That's
going
to
write
the
namespace
we
create
as
an
output,
so
we
can
use
it
in
future
steps.
A
The
second
step
is
the
helm
chart
install.
So
it's
just
a
simple
helm
section
with
the
chart
that
we
want
to
install
and
that
namespace
that
we
specified
earlier
upgrading.
This
would
be
a
lot
simpler.
We
don't
need
to
do
any
namespace
app
changes,
so
I've
just
got
a
helm
step
here
and
that's
just
going
to
take
the
same,
stable,
wordpress
chart
and
do
the
update
using
that.
A
Finally,
we
have
an
install
action
here.
We
have
two
steps
with
the
first
step
being
helm,
so
the
inverse
of
what
we
had
in
the
install
that
will
remove
the
the
helm
chart
and
then
we
have
terraform,
which
will
then
delete
that
namespace
that
it
was
responsible
for
speaking
of
terraform.
Let's
just
take
a
quick
look
at
what
I
have
inside
this
terraform
folder.
So
I
have
a
main.tf,
which
is
where
the
logic
is.
A
We
only
have
one
resource
being
managed
by
terraform,
which
is
my
kubernetes
namespace,
and
that
is
set
with
a
variable
namespace
as
we're
using
kubernetes.
We
need
the
kubernetes
provider,
and
here
I'm
also
using
a
variable
to
set
which
context
will
be
we'll
be
using
great
we're
now
ready
to
go
so,
let's
open
up
a
terminal
and
see
what
the
current
state
of
my
machine
is.
So
even
though
I'm
using
terraform
and
helm,
I
actually
don't
have
either
of
these
tools
installed.
A
On
my
computer,
if
I
check
which
terraform
get
nothing
and
if
I
do
a
witch
helm,
we'll
see
that
I
also
don't
have
anything,
I
do
have
docker
desktop
running
on
my
computer
and
that
has
its
own
kubernetes
cluster
activated.
So
I
have
a
kubernetes
cluster
running,
so
we
do
a
cube,
catal
get
namespaces.
A
We
can
see
that
we
have
just
the
default
namespaces
up
and
running
all
right.
I
mentioned
earlier
that
we
we
need
some
way
of
passing
credentials
into
porter.
Porter
doesn't
store
the
credentials
itself,
but
it
needs
to
have
a
reference
so
that
it
knows
what
what
will
be
used.
So
I
have
this.
I've
already
set
up
my
kubernetes
config
inside
portal
credentials.
A
So
with
that,
we
have
everything
we
need.
We've
got
docker
desktop
running
the
kubernetes
cluster.
I've
got
portrait
installed
and
I've
linked
porter
to
my
kubernetes
config.
So
now
I
can
run
the
portrait
install
command.
I
need
to
specify
a
an
application
instance,
so
I'm
going
to
use
my
app
for
this
case.
I
need
to
pass
it
the
credentials
that
it's
going
to
use
so
we're
going
to
pass
it
cube
cred
and
then
I'm
going
to
change
the
name
space
that
we
were,
that
we're
going
to
be
creating
and
installing
this
application
into.
A
So
it
was
kubecon,
I'm
going
to
change
it
to
hello
kubecon,
so
we
just
need
namespace
equals
hello,
kubecon
all
right.
What
this
is
going
to
do
is
it's
going
to
run
the
installation
process
inside
a
container
or
from
a
container.
So
that
means
that
that
container
has
all
the
tools
and
things
that
it
needs
to
do
this
application
installation
and
I
don't
need
to
have
them
locally
on
my
computer.
A
A
Great
that
says
it
was
a
success.
Portal
will
tell
us
then
inside.
If
you
do
the
portalist
command,
that
my
app
has
been
installed.
The
last
action
was
successful
and
that
was
just
completed
five
seconds
ago
great.
We
can
start
checking
on
the
state
of
our
kubernetes
cluster.
So
if
we
do
get
name
spaces,
we're
expecting
to
see
a
hello
cubecon
namespace
here
yep
there
we
go:
here's
the
new
hello,
cubecon
namespace,
and
if
we
do
a
getall
on
that
namespace,
we
can
see
that
some
of
the
components
have
started
coming
up.
A
All
right,
I'm
back
and
our
wordpress
is
now
running
so
here
we
can
see
we
have
a
mariadb
running
and
a
wordpress
front-end
running.
So
let's
take
a
look.
If
that's
actually
all
up
and
running
on
my
localhost
before
this
demo,
I
open
up
my
my
browser
and
I
navigated
to
localhost
and
obviously
nothing
was
running
there.
Yet,
if
I
just
refresh
this
page,
we
should
see
the
default
wordpress
installation.
So
here
we
go.
A
We
have
a
hello
world
post
and
if
I
click
on
the
sample
page
you'll
see
that
I
just
have
the
default
sample
page
here
so
everything's
running
on
my
local
host
on
kubernetes
great,
so
porta
doesn't
just
handle
the
installation.
It
can
also
do
upgrade
and
uninstall.
Let's
uninstall
this
application.
Now
as
we
don't
need
it
anymore.
A
Now
we're
going
to
see
those
steps
in
reverse,
so
first
we'll
see
helm,
doing
a
delete
and
then
we'll
see
terraform
doing
the
deletion
of
the
namespace
terraform
will
probably
take
a
moment
to
delete
the
namespace
because
it's
going
to
wait
until
the
namespace
is
empty
before
it's
before.
It
completes
the
task,
so
it
probably
takes
about
10
seconds
or
so.
A
Let's
look
at
the
next
interesting
feature
that
we
have
with
cnav
and
porter.
Well,
as
I
said
earlier,
you
can
push
applications
to
registry,
let's
get
one
from
the
registry
and
run
it
locally
without
having
any
other
source.
So
I'm
going
to
navigate
into
my
pull
directory
where
we
don't
have
anything,
so
you
can
see
that
I'm
not
using
another
portal.yaml
or
anything
like
that
on
the
docker
hub
you'll,
see
that
des
labs
have
put
up
a
porter
hello
bundle,
and
basically
this
is
just
a
hello
world
application.
All
it
does.
A
Is
output
hello,
world
text
effectively.
What
we
can
do,
then,
is
we
can
run
the
porter
install
command.
We
can
give
it
an
app
instance,
so,
once
again
I'll
give
it
the
name.
My
app
I'm
going
to
give
it
the
tag
and
I'm
going
to
paste
that
registry
reference
latest
there
you
go
what
this
is
going
to
do
in
the
background,
is
it's
going
to
fetch
the
bundle
and
run
it
and
run
the
installation
process
locally?
A
Oh
that's!
This
is
how
you
know
it's
a
real
demo,
because
I
made
it.
I
made
a
typo
there.
We
go,
that's
already
run,
so
it's
already
downloaded
and
run.
We
can
see
here.
It
ran
the
installation
action
first
and
that
was
that
just
outputs
hello
world
over
here.
If
we
do
a
porter
list,
we
can
see
that
we
have
the
my
app
instance
installed
and
if
we
do
a
portrait
upgrade
of
my
app,
it
doesn't
take
any
parameters
or
anything.
A
We
can
see
that
we
have
now
upgraded
to
world
2.0
and
if
we
do
a
poorer
list
again,
we
should
see
that
the
last
successful
action
was
an
upgrade.
Let's
uninstall
this
now
as
we're
done
with
it
I'm
using
porter
again
so
we'll
just
do
uninstall
of
my
app
and
that'll
remove
it.
I
didn't
need
any
of
the
source
code
or
tools
or
anything
on
my
machine.
It
just
fetched
everything
to
the
registry
and
ran
it
just
like
that.
A
Another
interesting
feature
of
porter
and
of
cnab
is
that
you
can
output
a
bundle
to
disk
so
that
you
can
use
it
offline
or
in
air
gap
scenarios.
So
a
porter
has
the
useful
archive
command
to
do
this,
and
what
that
does
is
creates
a
table
containing
everything
you
need
for
the
application,
so
I'm
going
to
run
a
porter
archive
and
save
it
to
mybundle.tgz
inside
that
directory.
This
will
take
a
moment
so
I'll
be
back.
A
All
right,
it
looks
like
the
archive
is
done.
Let's
navigate
into
that
archive
directory
to
see
what
this
looks
like.
So
as
expected,
we
have
a
bundle.tgz
and
if
we
extract
this,
we'll
see
all
the
files
that
make
up
this.
The
cnab
for
those
familiar
with
oci
you'll
probably
recognize.
This
is
an
oci
image
layout
and
if
we
just
take
a
look
at
the
most
interesting
file
here
from
the
senior
perspective,
it's
the
bundle.json.
A
A
We
stored
all
of
this
inside
the
invocation
image
of
the
cnav,
so
that
I
didn't
need
to
have
any
of
this
on
my
local
machine
and
then
in
terms
of
having
the
same
deployment
environment
everywhere,
because
porter
uses
containers.
It
means
that
we
have
the
same
environment
if
we're
using
mac
windows
or
linux.
So
we
don't
need
to
think
about
what
what
the
developer
or
the
end
user
is
using.
That
is
a
much
better
user
experience
both
for
people
on
your
team,
the
ci
and
for
users.
A
Let's
talk
about
some
of
the
packaging
for
cnap,
so
I
didn't
show
you
inside
the
demo
how
to
push
a
scene
app
to
a
registry,
but
I
can
talk
to
you
about
how
how
this
actually
works.
Each
scene
app
is
represented
by
an
oci
index,
so
this
is
one
of
the
standard
container
objects
that
already
exists.
We've
just
reused:
what
exists
there
from
that
index?
We
reference
a
bunch
of
objects.
A
The
first
object
is
the
bundle
definition,
so
that's
that
bundle.json
file,
we
reference
the
invocation
image
in
in
the
cnap
case
this
or
in
the
porter
case.
This
is
just
a
container
image
and
then
we
also
have
the
components
from
one
to
end
so,
depending
on
which
components
make
up
your
application.
We
can
also
store
those
in
the
registry
because
of
how
those
things
are
stored.
They
are
oci
images
and
each
one
of
those
will
reference
a
list
of
blobs,
which
is
just
binary
data.
That's
stored
as
part
of
that.
A
So
before
we
had
the
application
manifest
on
github,
we
had
the
tooling
on
different
people's
computers
and
on
the
ci
nodes
and
on
our
end
users,
computers,
and
we
had
the
application
components
on
on
the
docker
hub
now,
with
using
existing
oci
standards,
we
can
store
everything
inside
an
oci
compliant
registry
like
the
docker
hub,
or
we
can
store
it
offline
inside
of
towel
going
back
to
what
we
talked
about
as
being
ideal
application
packaging.
Let's
take
a
look.
How
cnet
fits
this
in
terms
of
an
immutable
application?
Artifact?
A
Well,
because
we're
reusing
the
container
infrastructure
that
already
exists,
we're
using
hashes
for
the
components.
So
we
know
that
what
we
stored
is
exactly
what
we'll
be
using
later
on
we're,
also
not
trying
to
reinvent
the
wheel
here,
we're
already
using
things
that
have
been
well
tested
and
exist
widely,
which
is
great.
A
A
A
If
you're
interested
in
storing
things
in
registries,
there's
a
couple
of
talks
that
my
colleagues
and
ex
colleagues
will
be
giving
and
that
I
recommend
the
first
one
is
sharing,
is
caring
by
two
of
my
colleagues
silva
and
george,
who
both
work
at
dhaka.
The
second
one
is
where
to
put
all
that
yaml
and
that's
by
one
of
my
old
colleagues
ryan
abrams.