►
From YouTube: Habitat Builder: Cloud Native Application Automation - Elliott Davis & Fletcher Nichol, Chef.io
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18)
Habitat Builder: Cloud Native Application Automation - Elliott Davis & Fletcher Nichol, Chef.io (Habitat.sh) (Beginner Skill Level)
There are a plethora of build tools and package managers out in the universe, but no one way to ensure a happy path from local development to production when you have a system of any interesting complexity. This talk explains why we built Habitat Builder, as an open source cloud native application automation engine, and how you can use it to build and ship your applications with Kubernetes and the packaging tools like Helm that you know and love, for a better development-to-cluster lifecycle. We'll go over existing build tools, their pro's and con's, industry best practices, and what Habitat Builder adds to the mix.
About Fletcher
Software Developer, works on Habitat https://www.habitat.sh/
About Elliott
Elliott is a core maintainer on the Habitat team with a focus on developer experience and cloud native technologies. One of his favorite hobbies is disrupting team stand-ups with dad jokes.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
B
B
I'm
Fletcher
Nichol
I'm,
the
one
on
the
right
here,
I'm
from
the
northernmost
country
in
North,
America
and
so
I'm
from
Canada,
better
Lissa's.
Now
these
are
our
twitter,
handles
I've,
been
working
on
this
project,
habitat
for
I
think
almost
three
years,
so
I'm
pretty
set
in
my
ways.
Maybe
at
this
point
or
pretty
pretty
into
it.
B
So
with
that.
So
our
talk
today
is
to
talk
a
little
bit
about
habitat
a
bit
more
specifically
about
a
particular
aspect
of
it
and
then
how
the
work
that
we're
doing
to
kind
of
help
make
the
experiences
in
kubernetes.
Specifically,
you
know
more
compelling
and
interesting
to
see
kind
of
like
what
does
habitat
sort
of
bring
to
the
table
to
help
out
in
the
community
space,
so
habitat
itself
in
comes
a
lot,
but
we'll
just
sort
of
boil
it
down
to
a
reasonably
small
statement.
B
That's
kind
of
compact,
so
you
can
think
of
habitat,
is
what
we
call
application
automation,
and
this
is
basically
a
way
to
let
application
teams
and
operators
and
release
engineers
kind
of
work
together,
collaborate
to
package,
any
kind
of
application,
so
any
runtime
or
native
code
that
ultimately
could
be
deployed
in
any
environment.
So
this
is,
you
know,
bare
metal
and
servers,
and
in
this
case,
though,
we're
talking
at
a
kubernetes
conference,
so
it
works
really
well
in
kubernetes
and
in
containers
as
well.
It
just
so
happens.
It
works
in
others.
B
The
way
that
we're
we're
doing,
that
is
by
embedding
some
kind
of
smarts
and
automation,
into
an
artifact
that
ships
with
your
with
your
application.
So
this
this
we
call
like
it's
automation
that
travels
with
your
application.
How
we're
doing
this
is
by
having
an
application
package
definition.
So
it's
basically
a
bit
of
a
packaging
story
that
sort
of
feeds
this
whole
system
and
when
you're,
looking
to
package
your
application
or
service
up
in
habitat.
B
B
So
largely
when
you're
working
in
these
environments,
it's
sometimes
hard
to
trace,
who
depends
on
me
or
who
do
I
depend
on
so
that's
kind
of
another
activity
or
thing
that
you're
putting
in
this
application
definition
so
that,
when
we're
producing
sort
of
an
artifact
afterwards,
all
of
that
intent,
information
needs
wants
desires.
Whatever
is
in
that
artifact
that
that
the
other
software
components
in
habitat
can
then
use
to
know
how
the
thing
needs
wants
to
behave.
B
Yeah
so
habitat
as
a
project
is
entirely
open
source.
It's
on
github,
like
many
other
projects,
are
it's
licensed
under
the
Apache
v2
license.
I
would
normally
have
said
before.
It's
also
in
one
repo,
it's
kind
of
a
lot
of
code.
We
have
this
year
done
a
little
bit
of
a
step
in
to
having
a
couple
different
repos
I
think
we're
up
to
three
yeah.
B
Most,
which
has
been
interesting,
but
it's
all
under
the
habitat
organization,
so
kind
of
drilling
into
one
of
these
software
components.
One
of
the
parts
of
habitat
is
what
we
call
habitat
builder
and
at
its
core.
It's
it's
both
a
distributed,
build
system
but
also
sort
of
a
pack
repository
and
the
two
sort
of
are
integrated
in
together.
B
So
in
terms
of
the
the
package
repository,
our
habitat
packages
are
somewhat
unique
given
like
what
we
wanted
to
get
out
of.
The
package
is
mainly
like
the
the
smarts
about
Application
Lifecycle
and
the.
When
the
packages
are
posted
in
in
builder,
they
can
be
promoted
into
what
we
call
release
channels.
So
if,
if
anyone's
used,
any
software
before
that
has
sort
of
like
a
channel
release
model
or
if
you've,
if
you've
tried
that,
like
chromium,
like
dev,
builds
of
your
web
browser
as
opposed
to
the
stable
branch,
it's
kind
of
the
same
thing.
B
It's
it's
sort
of
you
choose
what
you
want
to
consume,
based
on
stability
or
needs
or
environment,
and
that
kind
of
thing,
so
we're
able
to
sort
of
release
or
promote
these
specific
artifacts
into
a
channel
that
other
parts
of
the
system
might
be
consuming
and
looking
for
that's
how
they
would
get
their
updates
and
know.
This
is
when
I
update
and
it's
you
know
this
version
and
that
kind
of
thing
and
sort
of
feeding
into
this
builders
also
integrated
with
like
source
code.
B
If
you
want
to
so
like
to
be
able
to
attach
a
github
repo
that
has
your
source
code
and
the
software
definition
ideally
is
sitting
with
your
code.
So
builder
knows
basically
how
to
check
that
out,
like
on
a
master,
merge
or
some
change
to
rebuild
your
application
and
then
to
store
it
so
that
you
can
choose
to
have
that,
go
off
to
a
test,
environment
or
UAT
kind
of
whatever
you
want
right
now.
We
again
builder
itself
is
also
open
source.
B
B
We've
got
builds
if
your
packages
need
to
private,
they
can
be
private
if
you
want
to
run
parts
of
that
yourself,
we're
kind
of
getting
into
that
territory
of
also
being
able
to
better
support
people
wanting
to
run
parts
of
builder
on
their
own.
It's
not
to
say
that
you
can't
it's
just
that
we
are
on
the
engineering
team,
we're
also
the
operators
of
habitat
and
the
SAS,
so
we
run
builder
using
habitat
self.
B
You
know
consuming
and
building
its
own
packages,
so
we
try
to
keep
it
really
honest
and
in
that
spirit
hopefully
we're
the
Trailblazers
and
we
find
the
rough
edges
first
and
figure
out
what
is
the
best
operable
model
before
we
give
that
off
to
other
people,
so
I
think
we've
we've
it's
something
I
wouldn't
want
to
give
up.
As
an
engineer
is
operating
my
own
product.
In
this
way
the
learning
is
just
too
good
yeah.
B
So
are
we've
kind
of
got
a
lot
of
primary
users
that
we've
got
in
mind,
largely
its
application
teams
and
people
closer
to
the
applications
and
services?
Also,
platform,
services
teams,
because
habitat
can
also
deal
with
packages.
You
don't
write
yourself
like
Postgres
or
MySQL
or
like
third-party
software,
and
basically
anybody
that
it's
going
to
touch
software
or
an
application,
and
it's
like
in
its
lifecycle,
yeah.
A
So
what
the
one
of
the
aims
of
habitat
is
is
to
decouple
your
application
from
the
OS
so
that
you
don't
have
to
do
something
like
from
Ubuntu
or
from
sent
OS
in
the
top
of
your
docker
file
habits
out.
Actually,
when
you
start,
when
you
build
a
container
and
habitat,
it's
actually
from
scratch,
so
it's
just
your
application
in
the
container.
One
of
the
other
issues
that
we
see
in
the
in
the
kubernetes
space
is
like
managing
configuration.
A
A
So
habitat
manages
all
that
for
you,
because
all
the
applet,
all
the
logic
for
that
is
encoded
in
your
application
and
then
the
the
final
problem
that
habitat
aims
to
sort
of
target
is
that
nobody
wants
to
really
rewrite
their
application
to
be
cloud
native
right,
that's
expensive
for
the
business,
and
so
our
aim
is
to
is
to
enable
your
application
to
be
cloud
native
without
having
to
use
something
like
at
CD
or
or
console
to
get
your
applications
configuration
to
you
and
and
your
app
having
to
be
aware
of
how
to
do
that.
Unless.
B
A
What
the
runtime
that
is
going
to
eventually
execute
and
one
of
the
other
tools
that
we
looked
at
was
apt
to
me,
and
so
they
show
that
the
packaging
format
is
super
important
and
that,
if
you
can,
if
you
can
get
the
packaging
format
right,
it's
easy
to
to
distribute
your
application
and
and
I
don't
know.
If
you
haven't
seen
them.
They've
got
a
really
interesting
approach
to
deployment.
Also,
the
the
trouble
is
look
its
app
to
me
this
kubernetes
specific.
B
We
have
a
lot
of
customers.
We've
seen
are
kind
of
they're
sort
of
like
straddling
that
that
sort
of
two
generations
of
sort
of
the
infrastructure
they
have
today
the
runtimes
they
might
want
to
go
to
tomorrow,
potentially
with
the
same
code
base
and
hard
to
know
like
do
you
start
writing
Forks
of
two
apps
or
have
two
different
deployment
models.
So
this
is
something
we're
trying
to
help
with
in
habitat
is
have
a
way
to
still
go
back
to
the
roots
of
how's.
This
thing
work.
B
B
It's
still
a
little
problematic,
at
least
from
from
my
point
of
view,
is
about
the
best
we
can
sort
of
do
is
draw
a
bigger
circle
around
the
application
sort
of
start
from
a
common
base
of
like
maybe
it's
something
that
looks
like
a
minimized,
Ubuntu
installation
or
Alpine,
or
it's
basically
like
some
userland
and
some
libraries.
You
don't
know
if
that's
actually
in
the
runtime
path
of
your
application
or
not,
but
it
tends
to
run
with
it
and
that's
that's!
Alright.
B
You
can
get
into
issues
sometimes
when
you,
you
might
have
some
software
that's
sitting
with
your
application,
you're,
not
if
that's
actually
a
factor
or
not
in
how
it
runs.
So
this
comes
up.
Sometimes
when
vulnerabilities
come
up,
so
you
might
know
that,
like
in
this
docker
image,
I
have
a
troublesome
like
I,
maybe
have
a
version
of
open
SSL
that
I
might
have
a
problem,
but
then
there's
also
the
question
of
like.
Does
my
app
even
use
it?
B
So
if
it
doesn't
use,
it
do
I
still
even
care
with
so
with
habitat,
because
we're
sort
of
we
just
want
to
think
application
first
and
then
everything
flows
down.
Everything
else
is
in
support
of
that
and
it's
our
our
packaging
system.
If
you
don't
use
open
a
cell,
you
don't
get
open
SSL
and
it's
not
installed
alongside.
B
If
it
is,
we
know
the
version,
we
know
what
it
got
linked
to
and
that's
something
that
we
can
provide
like
statically,
just
statically
analyzing
a
package
or
also
sort
of
at
runtime,
with
the
ability
to
sort
of
like
query
that
service
to
ask
like
what
is
a
software
you
have
running.
So
if
you
need
to
do
sort
of
like
fleet
wide,
you
know
like
survey
to
see
like
do,
I
have
a
problem
or
not
right.
A
And
you
know
another
great
example
of
this:
we
were
at
a
co-working
space
on
Monday
or
Tuesday,
and
we
were
talking
to
some
developers
there
and
they
were
saying
man.
You
know
the
other
day
we
we
shipped
out
a
production
deployment
of
our
Python
app
and
one
of
the
developers
added
a
dependency
that
we
didn't.
We
didn't
know
about,
and
we
we
pushed
the
app
out
and
the
the
dependency
wasn't
on
the
OS
that
we
pushed
it
to
so.
Production
got
broken,
and
that
is
that's.
A
B
I
only
laughed
because
I
know
I
got
hit
with
this
even
last
week.
It's
not
a
production
problem.
I
wouldn't
have
a
part
of
like.
Why
is
this
habitat
packaged
breaking?
Oh
somebody
introduced
a
new
native
library
and
they
forgot
to
update
our,
like
definition
of
it.
So
at
the
end
of
the
day
like
if
I
can
catch
more,
that's
at
Build
time
makes
me
happy
exactly.
A
A
A
One
of
the
other
tools
that
we've
recently
written
is
an
operator
for
habitat,
so
that
allows
you
to
manage
your
application
deployments.
Deployment
sets
staple
sets
and
manage
all
the
configuration
changes
that
need
to
happen
for
your
application
and
I'll
get
into
more
detail
about
that
in
a
minute.
I've
got
a
whole
slide
towards
the
end
on
it
and
then
the
last
tool
that
we
provide
for
the
for
the
kubernetes
habitat
integration
is
the
is
an
open
service
broker,
API
implementation.
A
B
It's
like
a
way
to
kind
of
bridge
services
you
might
still
need,
but
either
can't
or
aren't
currently
on.
You
know
on
the
same,
like
runtime,
so
a
way
of
basically
kind
of
bridging
worlds
together
and
we're
never
really
sure
how
to
present
this,
because
it
seems
like
it's
still
sort
of
a
new
thing,
but
I
think
it's
gaining
some
traction
in
the
community.
It's
it
kind
of
came
out
of
cloud
foundry.
B
B
This
is
kind
of
a
bit
of
a
shortened
image
about
sort
of
how
we
think
about
an
application
through
its
lifecycle
and
by
lifecycle.
That's
not
necessarily
like
from
boot
time
Duke
through
that
stage,
it's
kind
of
like
from
from
code
to
running
and
production
to
upgrading
to
health
status
and
all
that
so
at
Build
time,
there's
I,
guess
a
couple
things
going
on.
We
have
again
this
notion
of
a
package
definition
in
habitat.
It's
it's
effectively.
We
call
this
a
plan
which
is
not
too
different,
like
not
too
complicated
thing.
I.
B
Think
we'll
see
an
example.
You
can
check
out
our
website
if
you
want
to
see
kind
of
more
concretely
what
that
looks
like
and
that
gets
fed
into
a
build
system
that
understands
these
plans
and
produces
an
artifacts,
so
kind
of
like
code
plus
plan
equals
artifact
and
and
if
the
artifact
happens,
to
have
a
runnable
service.
B
To
sort
of
do
that
work
without
worrying
about
it's
still
possible
that
you
can
still
make
your
own
pipelines
and
have
you
know,
habitat
builds
discreetly,
but
if
you
don't
care
about
that
so
much
or
if
you
want
to
take
advantage
of
some
of
what
builder
does
sort
of
some
dependency
rebuilding
that's
kind
of
what's
going
on
in
in
builder,
and
so
the
the
next
kind
of
step
on
this
is
deploy.
I
think
for
the
purposes
of
this
talk,
I
kind
of
think
about
it.
B
More
of
like
cross,
publishing
or
exporting
so
again,
I
think
Elliott
mentioned
our
package
exporter.
So
it's
a
way
to
take
sort
of
a
habitat
package
and
then
say
you
know:
I
could
probably
just
you
know,
make
a
docker
image
from
this
or
like
a
tarball
that
contains
all
the
packages.
You
know
relative
to
this,
that
you
could
just
untie
on
a
server
and
then
it
works.
So
we've
got
I'm
not
even
sure
fewer
than
ten
north.
B
I
guess
in,
for
the
benefit
of
this
audience,
we
have
like
an
exporter
to
four
docker
tits
and
make
a
docker
image
one
for
kubernetes,
which
is
like
the
docker
image,
plus
a
deployment
yeah
Mille,
a
helm
exporter
which
gets
you
sort
of
like
the
chart.
I
think
I
got
the
right
term
for
that
and
builder
itself.
Also,
for
a
few
of
these
exporters,
we
have
a
bit
more
of
like
a
sort
of
long-lived
integration
that
you
can
take,
that
you
can
basically
trigger
an
exporter
when
a
package
gets
rebuilt.
B
B
A
And
then,
once
you
get
an
export,
you
want
to
probably
run
the
thing,
and
so
what
we
allow
you
to
do
is
you
can
run
it
on
kubernetes.
You
can
run
it
on
a
VM.
If
you
want,
you
can
deploy
it
out
to
Amazon,
run
it
on
to
VM
and
what's
for
this,
for
the
benefit
of
this
crowd,
what
we
do
when
we
do,
the
export
for
for
kubernetes
I
believe
the
helm
chart.
A
Is
we
actually
embed
that
with
the
habitat
operator
syntax
so
that
allows
the
habitat
operator
to
manage
your
application
inside
of
the
kubernetes
cluster
so
that
we
can
do
things
like
manage?
The
configuration
manage
the
service
bindings
and
things
like
that,
which
leads
me
to
the
habitat
operator
slide
the
one
that
I
promised
earlier.
So
the
habitat
operator
is
just
a
it's
a
kubernetes
controller.
It's
just
like
any
other
operator
like
the
HDD
operator,
the
I
think
rook
has
one
also,
and
it's
designed
to
to
basically
manage
your
application
inside
of
guber
Nettie's.
A
For
you,
what's
great
about
that,
is
you
can
front-load
all
of
the
automation
that
your
application
needs
to
know
about,
and
then
you
don't
have
to
worry
about
orchestrating
any
of
that
automation
on
the
back
end
once
you
deploy
it
and
the
other
thing,
the
other
really
cool
thing
about
the
habitat
operator
is
that
it
can
manage
multiple
services.
So
since
the
habitat
artifact
is
generic
and
it
provides
a
consistent
API,
you
can
have
one
operator
per
namespace
to
any
number
of
running
habitat
services.
A
A
Traditionally,
the
habitat
artifact
will
update
itself
if
it's
running
on
a
VM
infrastructure,
but
that
doesn't
really
fly
in
kubernetes
right.
You
don't
want
your
underlying
container
definition
changing
from
under
you,
so
the
habitat
update
service
will
watch
for
changes
for
habitat
services
that
are
deployed
in
builder
and
once
it
detects
that
a
change
has
been
promoted,
then
it
will
orchestrate
an
update
with
kubernetes
so
yeah
this.
So
right
now,
we've
deployed
the
habitat
op
operator
and
then
we're
getting
the
updater
deployed.
A
A
A
That's
the
other
cool
thing
to
note
about
the
habitat
updater
is
it
is
it
is
a
habitat
package
deployed
with
the
operator,
so
it
will
watch
for
updates
on
itself
and
automatically
upgrade
itself
when
there's
new
versions
published
cool
and
then
we
have
one
more
thing
to
sort
of
show
off,
and
that
is
how
how
does
this
work
into
end
right
like
so
you
you
make
a
change
to
your
code.
You
can
go
ahead
and
yeah.
A
So
you've
made
a
change
to
your
to
your
code
base
here,
I'm
going
to
do
a
change
to
the
to
change
a
config
file
in
one
of
our
habitat
plans.
This
is
Redis
and
so
I
just
turned
protected
mode
on,
because
you
know
security
and,
and
so
I'm
just
gonna
commit
this
change
to
the
master
branch
of
my
personal
repo
I.
A
B
A
Sort
of
did
this
cooking
show
style,
I
cut
out
the
Redis
build
because
it,
you
know,
takes
a
minute
and
so
I'm,
just
gonna
click,
a
button
to
promote
it
to
stable
and
that's
that's
all
I
had
to
do
like
now.
This
is
going
to
get
automatically
deployed
out
to
my
production
environment,
because
my
my
production
infrastructure
is
tracking
the
stable
channel
from
builder
I,
just
paused
it
there,
because.
B
Kind
of
the
payoff,
so
it's
a
way
of
saying
we
made
an
artifact.
You
could
think
of
it
as
a
release
candidate
in
this,
like
CD
sense,
we've
basically
promoted
that.
So
we
want
that
to
be
like
pulled
into
the
system.
That's
the
thing
that
the
updater
is
basically
keying
on.
Looking
four
and
that's
gonna
trigger.
B
Ultimately,
a
kubernetes
deployment
in
the
normal
way
that,
like
kubernetes,
would
do
it's
rolling
deploy
so
there's
no
real
extra
magic,
but
that's
sort
of
how
like
a
package
promotion,
habitat
yields
like
the
kubernetes
deployment
and
that's
how
you
get
the
update
so
I
hope.
That's
like
okay
to
reason
through
but
yeah.
So
to
me,
I
was
really
excited
the
day
that
we
added
the
just
a
little
web
UI
thing
we
do
have
a
CLI
as
well,
and
I'm
I
live
in
my
terminal,
all
the
time,
so
I
don't
know
why.
B
Is
basically
the
updater
that
sees
by
way
of
the
operator
that
oh
I
got
a
Redis
service
going
on
I
should
check
for
updates
so
that,
when
that
happens,
I
can
I
can
basically
coordinate
exact.
So
it's
it's
the
one,
that's
basically
sitting
off
to
the
side.
Looking
at
that,
you
didn't
need
to
tell
the
updater
that
there's
Redis
going
on,
because
that
was
the
operator
that
helped
make
that
happen
exactly
yeah.
A
A
So
normally
what
this
means
in
a
kubernetes
context
is
that
if
you
want
to
deploy
a
configuration,
change,
you're
probably
going
to
have
to
kill
your
container
and
start
a
new
one,
but
what
habits
that
allows
you
to
do
and
what
the
operator
allows
you
to
do.
Is
it's
going
to
manage
that
config
change
for
you
and
it's
going
to
not
rollin
rollin
up
grayed
out,
but
it's
just
going
to
make
that
config
change
inside
the
habitat
package
and
it's
going
to
restart
it
and
update
it
on
the
fly.
A
So
what
this
is
useful
for
is
I.
Think
I
might
have
missed
the
change,
but
basically
I
just
turned
on
debugging
for
Redis
and
the
way
that
you
apply
this
change.
Is
you
base64
encode,
a
tamil
string,
because
that's
the
config
format
that
we
use
and
once
you
apply
that
to
your
kubernetes
yamo,
then
the
operator
will
orchestrate
that
that
change
for
you
and
it'll.
You
can
see
here
that
it
restarted
Redis
and
now
you
can
see
that
debugging
is
enabled
so.
B
Yeah
so
for
Redis
I,
don't
think
it
can
cope
with
like
an
on-the-fly
config
change,
so
the
behavior
for
Redis
is
to
like
restart
your
app.
You
might
be
able
to
send
it
a
cig
up
and
then
maybe
it
can
cope
with
that
change.
All
the
smarts,
though,
and
that
knowledge
those
in
the
habitats
package,
which
is
how
we
can
get
away
with
knowing
how
to
cope
with
a
configuration
change
while
also
not
bringing
that
container
down
like
unnecessarily,
because
maybe
that's
not
a
full
deployment
activity.
You'd
necessarily
need
to
do
cool
and
ok
yeah.