►
Description
Simplifying Container Operations with Habitat [B] - Michael Ducy, Chef
Container Orchestration Systems make for a great operational experience for deploying and management of containers. But that’s only part of the story when running containers in production. How do you build containers that contain only what you need (like no build systems/tools)? How do you orchestrate configuration of your application after the containers have been launched? How do you make it easy to modify an application config while keeping the containers immutable? How can you give your developers a means to declare dependencies for their applications?
Habitat, our open-source project for application automation, simplifies container management by packaging applications in a compact, atomic, and easily auditable format that makes it easier to deploy your application on various container runtimes
About Michael Ducy
Michael Ducy currently works as a Director of Product Marketing for Chef focusing on helping companies understand Chef, DevOps, and IT transformation. Previously, Michael focused on designing and implementing automation solutions for customer’s Cloud, IT Automation, and Continuous Delivery needs. Michael has also worked in a variety of roles in his career including Cloud Architecture, Systems Engineering , Performance Engineering, and IT Instructor. Michael holds a Masters in Computer Science from the University of Chicago and an MBA from The Ohio State University.
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.
A
So
I'm
Michael
Dulce
I
work
at
chef,
nope
I
mean
I,
do
product
marketing,
but
don't
be
afraid
that
you
have
a
marketer
up
here
in
front
of
you.
I
have
a
long
background
in
technology.
I've
worked
at
chef
for
four
years,
a
lot
of
stuff
in
the
open-source
community
for
a
long
time
used
to
do
a
lot
of
stuff
in
the
cloud
set
community
as
well,
and
you
can
reach
me
on
Twitter.
If
you
want
right
there,
MF
dii,
which
are
my
initials
by
the
way.
A
So
we're
going
to
talk
about
simplifying
container
operations
with
an
open
source
project
that
we
have
at
chef.
So
chef
actually
has
three
open
source
projects
that
we
maintain
the
one
that
we're
known
for
chef,
one
called
in
spec
and
another
one
called
habitat
and
I
want
to
talk
about
the
latter
one
habitat
today
and
how
it
can
help
with
container
operations.
So
agenda
will
talk
about
some
of
the
problems
in
the
world
of
containers.
Give
you
a
quick
overview
of
habitat
well,
not
or
30
minute
overview
of
habitat.
A
A
If
you
want
to
take
a
picture
of
this
real,
quick
or
if
you
want
to
look
at
any
of
these
links
while
I
go
here,
are
the
useful
links
that
I'll
also
put
up
at
the
end
as
well.
But
if
you
have
your
laptop
open
or
something
like
that,
and
you
just
want
to
check
out
what
I'm
talking
about
while
I
talk
about
it,
some
useful
links
for
you.
So
yesterday
we
saw.
Did
everyone
get
that
all
right?
A
So
yesterday
we
saw
this
during
the
keynote
I
forget
who
did
the
presentation,
but
it
was
one
of
the
evening
keynotes
and
she
talked
about
how
we've
kind
of
progressed
from
using
a
broom
to
a
vacuum.
And
now
kubernetes
is
like
a
Roomba
right
and
Roombas
are
cool
because
you
can
just
have
them
go
around
and
it
feels
really
good
because
you
don't
have
to
do
much
work
anymore.
So
what
do
you
do?
A
So
this
is
kind
of
like
you,
when
you're
starting
to
playing
around
with
kubernetes
and
you're
like
get
out
of
my
face,
Enterprise
ops
team-
and
you
just
you
know
just
kind
of
thank
you
the
and
then
you
kind
of
maybe
take
to
the
next
level
and
you
throw
on
a
shark
suit
and
you're
like
yeah
badass,
with
what
I'm
doing
with
containers
and
kubernetes.
And
then
you
know,
Enterprise
ops,
of
course,
wants
to
try
and
get
out
on
the
party.
So
they
put
it,
you
know
they
all.
A
They
think
they
need
to
do
is
put
on
a
shark
suit
as
well,
but
the
reality
of
the
situation
is
a
little
bit
different
right.
So
this
is
actually
a
video
online
I
just
took
some
screen
caps
and
so
just
showing
and
playing
the
video
for
you
you'll
be
able
to
search
for
it
after
I
tell
you
what's
actually
going
on
so
we
can
see
here
we
have
a
dog
and
the
dog
is
relieving
themself
in
the.
A
This
is
actually
a
really
common
problem.
Well,
dogs,
having
accidents,
but
what
I'm
going
to
show?
You
is
a
common
problem
and
then
the
dog
you
know,
as
all
dogs
do
kind
of
sniff
it
to
make
sure
like
he's
like
oh
where'd,
this
poop
come
from
and
it
is
like.
Oh
I,
guess
it's
mine,
but
this
is
actually
a
really
important
thing.
A
So
you
just
want
to
make
sure
that
you're
paying
attention
to
those
things
and
then,
of
course,
it's
time
to
vacuum
and
the
Roomba
just
is
coming
through
and
doing
its
thing
right
and,
of
course,
what's
the
room,
we're
gonna
go,
do
it's
gonna
pick
up
the
mess
and,
of
course
you
know
it's
probably
a
little
moist
and
sure
enough.
There
goes
the
Roomba
and
there
you
go.
A
You
have
a
nice
new
clean
floor,
don't
you
right
and
of
course,
that's
kind
of
your
feeling
when
you're
messing
around
with
new
technology
and
especially
technology
in
the
container
space
and
the
scheduler
space,
it
makes
you
question
all
of
the
assumptions
that
you've
had
of
how
you've
been
doing
operations
and
development
for
the
last
20
years.
Right
and
all
of
the
paradigms
that
we've
had
for
many
many
years
are
not
the
same
anymore
and
we
kind
of
Illustrated
this.
A
This
is
a
co-worker
of
mine
who
I
tweeted
and
stole
credit
for
his
drawing,
but
is
we
call
it
kind
of
this
cliff
of
learning
right
when
you
have
containers
and
we're
not
picking
on
docker
intentionally?
We
just
that's
what
we
happen
to
write
on
the
whiteboard,
that
you
could
replace
that
with
containers
in
general,
right,
the
packaging
format,
and
it's
as
Kelsey
Hightower
likes
to
point
out.
It's
a
lot
more
about
the
packaging.
It's
it's
much
more
than
the
packaging
format.
A
So
some
of
the
things
that
you
see,
as
you
start
to
ask
yourself
how
do
I
run
containers
effectively
in
production?
So
one
of
the
things
that
you
hear
a
lot
of
is
how
do
I
D
couple?
The
application
build
from
the
final
production
ready
container
and
a
great
example
of
how
you
do
that?
There's
a
project
called
rocker
which
lets
you
have
one
container
image
use
for
the
build,
and
then
you
can
create
your
artifacts
and
then,
after
that
you
can
actually
take
that
artifact
and
put
it
into
another
container
image.
A
So
that's
an
example
of
how
you
can
split
your
build
from
your
actual
running
container.
Anyone
ever
like
do
an
app
get
install
and
you
got
to
put
in
you
know
core
utils,
a
GCC
and
all
these
other
things,
and
then
you
don't
remove
them
in
the
end
and
you
just
ship
it
on
into
production.
That's
what
we're
talking
about
splitting
the
build
from
the
actual
production
ready
container.
A
We
know
that
it's
crap,
like
the
Roomba
example,
is
because
there
are
all
these
environmental
things
that
you
have
to
inject
at
runtime
to
change
the
running
configuration
for
the
environment
that
should
actually
go
in
and
running
it.
One
solution
is,
you
could
create
five
different
container
images
for
each
two
different
environment.
You
could
use
environment
variables
to
change
configuration
settings
that
gets
tricky
when
you're
going
to
start
putting
secrets
into
environment
variables,
which
is
a
bad
idea
right.
So
how
do
you
do
those
things
I'll
talk
about
how
we
address
that
problem
with
habitat?
A
How
do
we
orchestrate
the
application
launch
order
in
topology
required?
So
kubernetes
is
really
good
at
making
sure
the
containers
are
up
and
running,
but
once
the
containers
are
up
and
running,
there's
actually
something
inside
of
that
container.
That
needs
to
be
orchestrated
as
well,
and
that's
the
application
itself
right.
So
how
do
I,
how
do
I
have
the
application
come
up
and
maybe
a
certain
clustering,
topology
and
other
things
like
that,
and
then
also?
This
is
another
thing,
and
you
see
this
with
the
shift
to
alpine
linux.
That's
happened
over
the
years.
A
Is
how
do
you
build
containers
with
a
minimum
viable
s?
How
many
people
build
containers
with
a
minimum,
viable
OS?
It's
basically
like
make
the
container
image
as
small
as
possible.
So
a
few
hands
went
up.
How
many
have
container
images
that
are
like
four
gigs?
You
don't
need
to
raise
your
hand
because
I
know,
there's
probably
a
lot
of
you
in
the
room.
A
A
So,
if
you
think
about
how
we
build
and
run
or
how
you
want
to
build
and
run
modern
applications,
and
especially
in
a
continuous
delivery
context,
what
you
want
to
be
able
to
do.
Is
you
take
a
source
code,
repo
that
source
code
repository
goes
through
CI
and
a
CD
pipeline?
You
end
up
creating
that
artifact
that
artifact
gets
stored
in
an
artifact
repository
and
then
you're
going
to
go
and
run
that
artifact
on
a
variety
of
different
platforms.
A
It
could
be
and
depending
upon
your
needs
right
so
bare
metal,
you
might
want
to
run
it
inside
of
a
container.
A
cloud
instance
or
a
VM
in
your
own
data
center
right,
so
we
call
this
kind
of
process
or
the
cycle
is.
How
do
you
build,
deploy
and
manage
your
application
and
habitat
focuses
on
each
one
of
those
areas
in
a
different
way?
A
So
the
first
thing
that
we
do
in
habitat
is
we
create,
what's
called
a
plan
we,
so
we
have
a
plan
and
it's
called
a
plan
SH
and
if
you're
at
docker
con,
if
you're
gonna
be
a
docker
con
stop
by
our
booth
and
we're
gonna
have
a
great
sticker
that
turn
kind
of
takes
that
truck.
Everyone
knows
what
that
van
is
right.
It's
the
a-team
right
all
right.
So
this
is
what's
called
a
plan,
and
so
a
plan
is
written
in
bash
right.
A
So
it's
a
dot
Sh,
and
why
did
we
choose
bash
as
the
language
for
this?
Well,
how
many
people
know
Python
in
the
room?
How
many
people
know
Ruby?
How
many
people
know
Perl
right?
How
many
people
know
bash
right?
So
now
we
get
a
more
consistent
set
because,
like
half
of
the
room
to
do,
Ruby,
half
of
the
room
knew
Python,
but
everybody
knows
bash
right,
so
it's
very
accessible
and
approachable,
and
so
what
we
do
here
is
that
we're
going
to
do
we're
gonna,
basically
name.
These
are
just
metadata
that
we're
setting
up.
A
We
have
the
source
code
repository
that
we're
going
to
pull
the
source
code
from
we
have
our
build
dependencies
and
our
build
dependencies
are,
of
course
different
than
our
runtime
dependencies,
and
so
we
have
G
Lib
C.
So
what
this
is
going
to
do
is
when
you
run
this
plan
through,
it's
gonna
go
and
run
make,
and
it's
gonna
build
the
binaries
for
Redis
right
and
we'll
get
the
read
of
binaries
packaged
up.
For
me,.
A
So
compare
this
with
a
docker
file
right.
It's
very
kind
of
a
similar
concept,
however,
instead
of
starting
with
a
infrastructure
component
or
an
operating
system
I'm
starting
with
the
application
and
then
defining
what
the
applications
need
need
and
then
go
from
there
and
then
resolve
the
pendants
ease
down
versus
this
other
method
of
where
you
kind
of
resolve
the
dependencies
top
or
a
bottom
up
and
I'll
talk
about
that
here
in
a
second.
A
So
when
you
build
take
this
plan,
you
build
it
inside
of
what's
called
the
studio
and
the
studio
is
a
cleanroom
environment,
it's
safe
by
default
and
it
will
install
automatically
any
dependencies
that
you
need
to
actually
go
and
build
your
application.
So
anyone
ever
have
the
problem
of
you,
get
a
source
code
for
or
a
binary
from
a
developer
and
you
go
and
you
actually
go
and
try
and
run
it
on
their
machine
and
they're
like
or
are
I'm
sorry
on
a
production
machine
or
another
machine,
and
it's
not
working.
A
And
then
you
find
out
there
were
some
things
that
they
installed
on
their
laptop
that
they
didn't.
You
didn't
know
that
need
to
be
installed
in
production
right,
so
the
studio
hopes
to
get
around
that
problem
by
having
this
cleanroom
environment,
where
you
do
all
your
build
work
inside
of
that
any
dependencies
are
automatically
resolved
by
habitat
and
pulled
in
for
you.
A
A
Sh
is
actually
there's
a
bunch
of
different
methods
and
if
you
stop
by
the
booth,
there's
actually
a
cheat
sheet,
that
gives
you
all
of
those
methods
and
what
those
methods
do
and
all
you
need
to
do
is
override
those
methods
for
the
lifecycle
of
your
build
lifecycle
of
your
application
right
and
the
resulting
thing
that
you
get
is
called
an
application,
artifact
or
a
habitat
package
right.
So
after
I
do
that
build
I'll
have
a
habitat
package
containing
Redis
and
then
I
can
actually
take
that
package
and
I
can
go
run
it.
A
So
you
take
that
package.
You
ship
it
up
into
a
Depot,
it's
a
central
location,
that's
publicly
hosted,
and
we
have
this
idea
of
channels
so
that
you
could
create
different
view
of
what
packages
that
you
might
want
to
be
using
in
different
environments
right,
so
you
might
have,
as
you
progress
an
artifact
up
through
a
different
environment.
A
A
Let's
see
application
so
what's
going
to
happen
is
is
when
I
install
it,
it
will
go
and
install
this
version
of
G,
let's
see
and
what
I've
done
in
this
case,
I've
decoupled
myself
from
the
operating
system,
so
I'm
no
longer
dependent
upon
the
binaries
or
the
libraries
that
the
operating
system
is
providing
for
me,
I'm
having
habitat.
Actually
we
resolve
all
of
those
dependencies
for
me,
you
have
everything's
installed
by
a
command
called
hab.
It's
an
easy
pattern.
A
That
kind
of
follows
this
kind
of
noun
action
or
noun
verb
type
format
that
we've
had
in
our
tools
for
a
long
time.
So
if
you've
ever
used,
knife
you're
definitely
familiar
with
that
and
then
also
when
you
install
a
package,
you
can
have
increasing
specificity,
I'm,
not
saying
that
right,
but
we'll
go
with
that.
I'm
sorry
I
had
a
language
thing
when
I
was
young,
so
it's
hard
for
me
pronounce
things.
I
really
did.
But
what
you
can
do
is
that
you
can
say
you
notice.
A
So
it
has
the
metadata
that
we
saw,
but
it
also
has
config,
and
what
happens
is.
Is
you
ship
that
binary
and
the
configuration
all
in
one
package
versus
traditionally
the
way
things
a
lot?
A
lot
of
things
that
are
done,
especially
in
the
DevOps
space
nowadays,
is
that
you
ship
the
application
artifact
and
then
you
ship
config
and
something
like
a
cookbook
or
a
puppet
manifest
or
something
like
that
right
and
then
you
have
this
decoupling.
A
A
So
all
you
have
to
do
is
say,
install
package
core
Redis
and
it
will
go
and
download
it
from
the
Depot
it'll
install
any
dependencies.
If
they're
not
there
are
ready
and
then
you're
able
to
actually
go
in
and
start
the
application.
And
you
start
the
application
through,
what's
called
the
supervisor,
so
in
supervisors
will
install
everything
that
you
need
men
automatically
and
that's
what
we
saw
here
well,
this
is
actually
the
HAP
package
will
install
things
automatically.
We
didn't
need
to
actually
do
that.
A
We
could
actually
just
say,
have
start
core
Redis
and
it
would
start
Redis
for
me
and
anything
that
it
needed
to
download
it
would
download,
including
the
core
Redis
package
for
me
right.
It
makes
sure
that
things
stay
running
and
it
also
helps
manage
your
configuration
as
well.
So
we
talked
about
environment
configuration
so
there's
a
couple
different
ways
that
you
can
do
environment
configuration.
So
what
we
do
is
you
have
the
ability
to
query
any
package
and
find
out
what
its
configuration
is.
A
A
What's
configurable
of
what
that's
about
this
particular
package,
and
then
you
can
do
it
in
a
twelve
factor
way
with
that
you're
going
to
be
overriding
environment
variables
or
you
can
have
config
externally
enforced,
so
the
supervisor,
so
the
supervisor
comes
up,
runs
that
listens
on
the
network
and
then
you
can
inject
configuration
into
that
running
supervisor
to
change
the
live
running
configuration
of
that
application
that
you
have
right.
I'll.
A
So
the
supervisor
helps
solve
this
problem
of
how
do
I
in
boot.
How
do
I
build
immutable
infrastructure,
but
how
do
I
still
for
allow
for
these
safe?
Last
mile
configuration
changes
so
b8
by
being
able
to
go
and
inject
configuration
into
the
supervisor
at
runtime,
or
once
the
supervisors
already
up
I'm
able
to
make
these
configuration
changes.
A
So
this
instance
is
form
what's
called
a
server
or
gossip
ring
and
they
communicate
back
and
forth
and
they
share
a
couple
pieces
of
different
information
Erin
from
about
the
ring
itself,
so
who's
the
members
of
the
ring
they
can
also
share
information
about
other
rings,
so
rings
can
talk
to
one
another.
You
can
bind
rings
together
and
then
you
can
share
information
across
rings.
So
why
would
you
want
to
do
that?
Do
you
ever
run?
A
Then
the
other
thing
about
the
ring
is
actually
I
talked
about
the
CERN
ahsoka.
The
supervisor
also
provide
what's
called
a
restroom
Rus
based
API,
and
this
rest-based
API
allows
you
to
do
different
things,
so
it
allows
external
actors
to
query
the
health
of
the
application.
It
allows
you
to
go
in
and
find
out
information
about
the
supervisor
itself,
and
then
the
other
thing
that
you
can
do
is
if
you
had
a
load
balancer
or
something
like
that,
it
could
query
the
health
check
and
then
automatically
pull
that's
service
in
and
out.
A
A
Is
it
so
late
and
other
things
like
that,
so
you're
able
to
query
the
other,
this
API
to
actually
find
out
what
versions
of
libraries
that
you're
using
and
then
maybe
go
and
rebuild
your
images?
If
you
need
to
and
then
the
thing
that
I
think
is
super
cool
and
I,
think
it's
probably
more
most
relevant
when
you're
talking
about
things
in
the
scheduler
world?
Is
this
ability
to
support
different
topologies,
and
so
what
you
can
do
is
that
the
supervisors
can
self-organize.
A
So
all
you
need
to
do
is
tell
the
supervisor
that
you
want
to
run
in
a
certain
topology,
and
what
will
happen
is
is,
as
the
supervisors
come
up
and
begin
to
communicate
with
one
another.
They'll
do
a
couple
things
so.
First
they'll
make
sure
that
there's
enough
supervisors
running
in
the
ring
to
run
this
particular
application,
so
they
make
sure
that
they
have
quorum
and
once
that
they
have
quorum,
they
can
do
a
leader
follower
election.
A
So
they
can
say
that
somebody's
going
to
be
a
master
and
somebody's
going
to
be
the
replicas
in
the
case
of
Redis,
which
I'll
show
that
to
you
at
the
end.
So
you
don't
have
to
have
different
container
images
for
the
different
roles
that
your
application
service
would
play
or
a
yup
play.
They
can
automatically
figure
that
out
themselves
when
the
container
is
launched
right
or
when
the
application
service
is
launched,
and
then
the
other
thing
that
the
supervisors
provide
is
an
update
strategy
right.
A
So,
maybe
for
some
reason
you
want
to
have
that
image
updated
automatically
without
necessarily
needing
to
rebuild
the
image
you
can
actually
have
habitat
watch
the
depot
and
when
a
new
version
of
a
package
is
published
to
the
Depot,
you
can
automatically
have
the
light
running
service
update
with
that
new
version
of
the
package
you
can
also,
if
you're,
not
running
inside
of
containers.
This
is
really
useful
if
you're
running
habitat
on
a
VM,
so
habitat
can
run
in
a
variety
of
different
places.
A
So
you
can
begin
to
have
all
of
these
benefits
of
habitat
without
necessarily
going
full-blown
on
containers,
and
it's
also
useful,
if
you're
doing
data
services
that
you
might
want
to
be
running
on
a
VM.
And
then
you
have
the
container
services
that
are
actually
communicating
back
and
you
get
the
rest
based
API
you
get
the
ability
to
do
configuration
management,
you
get
the
ability
to
do
the
leader
follower
and
the
topologies
and
update
strategies
as
well.
The
other
super
cool
thing
that
we
can
do
is
one
at
a
time.
A
So
if
you
have
many
different
services,
I'm
sorry
supervisors,
running
they'll
do
an
election
to
figure
out
who
will
get
updated
first
and
then
kind
of
just
do
a
rolling
deploy
of
that
application
throughout
that
ring.
So
how
do
you
orchestrate
the
application
launch
order
and
topology?
So
we
provide
a
configure
where
autonomous,
self-organizing
peers
with
built-in
topologies
for
clustering
strategies
right
and
then
the
other
thing
which
is
most
relevant
to
the
talk,
is:
how
can
you
actually
get
this
out
in
a
reusable
format
right
or
a
different
packaging
format?
A
So
what
you
can
do
is
you
can
do
have
package
export
and
you
can
specify
an
export
format.
You
could
do
docker
a
CI
or
mesosphere,
which
mesosphere
is
just
a
tarball
with
the
appropriate
yamo
file.
You
can
also
export
a
tarball
as
well.
If
you
just
want
to
plane,
tarball
anyone
and
deploy
that
as
your
deployment
mechanism,
and
then
you
can
just
take
that
docker
image
or
a
CI
image
and
have
kubernetes
launch
it
and
it
will
come
up
for
you
and
then
you
get
the
benefits
of
the
supervisor.
A
So
one
thing
that
I
kind
of
had
talked
about
is
this
idea
of
application,
dependent
or
I'm
sorry
dependency
resolution
and
how
we're
a
little
bit
different
when
we
go
and
export
that
container,
so
we
don't
have
much
layering
built
in
so
we're
an
early
open
source
project,
we're
definitely
looking
for
more
contributors.
We
have
a
lot
of
contributors
inside
of
chef.
We
also
have
external
contributors
and
we
have
some
external
core
maintainer
z--
now
as
well.
A
A
Anyone
still
running
rl6
sure
somebody
is
yes
right
and
what
version
of
Ruby
does
that
ship
with
187
or
something
like
that
right?
It's
a
really
really
super
old
version
and
that's
bad
right.
You
don't
you
want
to
control
your
release,
cadence,
not
the
operating
system
vendor,
and
then
you
have
application
libraries
and
the
application
itself.
What
we,
what
we
do
when
we
export
a
container
is
we
start
with
the
application,
and
then
we
resolve
all
the
dependencies
and
all
the
dependencies
are
provided
by
habitat.
A
A
Letting
you
take
a
picture
so
if
you
think
about
it,
what
you
want
is
you
want
to
be
somewhere
on
this
sliding
scale
right
and
over
here.
This
is
kind
of
traditionally
how
we've
done
things
for
a
really
long
time
like
VMs
bare
metal
systems
am,
is
all
of
that.
We
have
a
really
large
operating
system
and
the
Opera
you're
only
really
putting
on
a
slice
of
the
application
which
you
want
to
try
and
move
towards.
A
Is
this
idea
of
aesthetically
if
you
can't
a
statically
linked
binary
with
virtually
no
operating
system
or
no
operating
system
right?
There's
the
blog
post
from
2014
that
Kelsey
Hightower
did
where
you
just
build
a
go
binary
and
you're
just
running
the
go
binary
inside
of
the
container
and
you're
not
actually
have
no
operating
system
at
all.
You
build
from
scratch
right
and
that's
the
goal
of
what
you
want
to
try
and
get
to.
But
of
course
you
can't
do
that
with
every
single
language
that
you
have
right.
A
A
So
if
I
do
LS,
you
can
see
all
of
the
core
plans,
and
these
are
all
the
tools
that
we
actually
go
and
publish
for
you
and
provide
for
you
right.
So
I
can
go
in
and
look
at
H
a
proxy
for
instance.
So
if
I
look
inside
of
H
a
proxy
I've
got
my
plan,
SH
I
have
a
default
tunnel
and
a
config
directory
right.
So
inside
of
my
plan
SH,
if
I
look
at
it,
you
can
see
that
metadata
that
I
talked
about
at
the
top.
A
I'm
gonna
do
is
I'm
gonna
export,
front-end,
dot,
port-to-port
and
then
I'm
going
to
status
port
will
be
status
port
as
well.
You
can
also
see
what
we
expose,
so
this
is
actually
just
something
that
we're
providing
if
you're
going
to
be
exporting
to
a
container
format.
So
you
have
your
exposés
setup
right
and
then
we
also
have
something
called
binds.
A
So
by
default,
I
have
some
configuration
that
I'm
providing
as
well-
and
you
can
see
here
everything
that
you
would
expect
what
servers
I
would
possibly
want
front-end,
back-end
information
as
well
status,
page
and
so
forth.
So
by
default,
the
status
page
is
not
going
to
be
enabled
right
by
default.
The
status
page
is
going
to
listen
on
port
9000
right
and
then
what
happens
is.
A
Is
that
defaults
get
put
into
the
H
a
proxy
configuration
file
and
if
I
look
inside
of
here,
what
you
can
see
is
a
mustache
template,
and
so
you
can
see
here
is
that
if
status
is
enabled,
then
we're
going
to
do
this
block
right
and
so
by
default.
What's
going
to
happen,
this
blocks
not
going
to
get
in
my
config
file
right.
You
can
also
see
up
here
where
we
have,
if
I've
bound
to
a
back-end,
then
I
want
to
iterate
through
all
of
the
backend
members
and
print
this
out,
if
it's
alive
right.
A
So
let's
actually
build
H
a
proxy,
and
so
all
I
need
to
do
is
run,
build
H,
a
proxy,
and
so
this
is
going
to
take
a
minute
because
it's
got
to
download
things,
but
luckily
I'm
not
running
on
this
is
an
AWS.
All
I
need
is
an
SSH
connection.
Hopefully
the
internet
here
has
not
been
friendly
to
us.
Has
it
all
right?
So,
while
this
is
building.
A
B
B
B
A
Yes,
well
so
the
different
versions,
but
then
you
also
have
this
thing
called
the
origin
key.
So
anything
core.
So
that's
the
beginning
part.
So
you
saw
chorus.
Slash
Redis
core
basically
means
it's
provided
by
habitat
or
it's
provided
by
chef,
and
then
you
create
your
own
origin
for
the
packages
that
you
want
to
build
and
basically
your
packages
will
be
in
your
origin,
name
name
of
your
package
right
and
then,
if
you're
sharing
an
Origin,
you
could
actually
have
two
different
builds
and
they
would
be
two
different
build
timestamps
right.
A
So
you
would
have
to
wait,
but
people
shouldn't
actually
be
building
the
software
right.
What
should
be
building
the
software
is
something
like
a
pipeline
and
you
can
make
sure
that
those
collisions
aren't
necessarily
happening.
But
the
reason
why
you
want
that
build
timestamp
to
be
different,
because
you
might
build
the
software
with
different
flags
from
one
time
to
the
other
when
you
actually
go
and
actually
build
the
software.
A
Weave
in
would
you
like
to
speak
about
Nix
I
mean
we
have
some
in
for
inspiration
from
Nix,
but
because
we're
not
actually
all
about
providing
a
whole
fledged
operating
system.
Perhaps
the
paradigm
I,
don't
think
translates
cleanly
one-to-one
always
right
when
you're
trying
to
compare
nicks
and
habitats
right.
So,
of
course
my
internet
is
funny.
A
All
right
so
I
built
a
package
earlier
and
you
can
see
here
that
I've
got
the
H
a
proxy
package.
So
now
what
I
can
do
is
I
can
do
a
hab
sup
config
back
on
and
I
can
query
this
package
to
find
out.
What's
configurable
about
it,
so
I
don't
have
the
supervisor
installed.
So
it's
going
to
go
and
automatically
do
that.
For
me.
A
Alright,
the
Internet's
not
working
well
so
I'll
switch
to
this
other
local
demo
that
I
have
so.
Let's
talk
about
so
I,
say
I.
Take
that
H
a
proxy
package
and
then
I
do
a
half
package
export
and
it
will
export
it
into
a
container
for
me
right.
So
now
what
we
can
do
is
you
can
actually
have
a
scheduler
go
and
run
it.
A
So
what
we
did
is
we
actually
took
the
guestbook
application
that
kubernetes
uses
for
a
lot
of
things
and
we
rebuilt
it
in
habitat
and
when
I
say
we
I
mean
our
friends
over
at
container
solutions.
Did
this
work
for
us
there
CTOs
in
the
back?
So
thank
you
for
that
work,
and
so
now
we
have
this
Redis
cluster
and
also,
if
you
look
at
deployments,
we
also
have
the
guestbook
front
end
and
the
guestbook
front-end
is
going
to
talk
to
the
backend
and
you
can
see
we
have
read
sha.
A
So
let
me
show
the
example
that
is
actually
kind
of
cool
and
pretty
powerful.
If
I
go
in
and
look
at
this
log,
you
can
see
that
Redis
is
running
and
there's
master
replicas
set
up
between
the
two.
So
if
I
look
at
weave
scope,
I
can
figure
out
who's
the
master
in
this
scenario,
so
everyone
seems
to
be
talking
to
this
container,
so
this
container
must
obviously
be
the
master.
So
what
is
that
the
vvk?
A
So
if
I
go
over
here
and
I
kill
this
container
and
of
course,
I
kill,
this
container
kubernetes
is
going
to
bring
it
back
up
right,
no
big
deal
about
that.
But
how
is
my
application
going
to
heal
itself
right?
That's
kind
of
the
important
thing
that
habitat
will
help
you
do
so
if
I
go
over
here
and
refresh
you
can
see.
A
What
happens
here
is
is
that
we
notice
that
we've
lost
connection
with
the
master
here
and
then
you
can
also
see
that
we
go
and
we
start
to
do
a
new
election
right
and
then
once
the
election
is
done,
you
can
see
that
Redis
brings
itself
or
habitat
brings
Redis
back
up
with
a
new
configuration,
and
then
you
can
see
that
the
master
replicas
have
begun.
Syncing
data
once
again
as
well
and
if
I
go
over
a
weave
scope.
A
You
can
see
that
there's
a
new
container
and
the
new
container
taken
the
role
of
master
right
and
that's
all
built
into
the
ability
inside
of
habitat
and
have
it
supervisors.
Another
thing
that
I
could
do
running
out
of
time
is:
you
could
do
a
hab
config
apply
and
with
a
hab
config
apply.
You
point
it
at
one
of
the
supervisors
and
you
can
inject
new
configuration
into
that
live
running
container.
A
You
can
also
look
at
the
information
in
the
rest
based
API,
so
this
is
some
of
the
information
that
you
get
from
the
rest
based
API.
You
can
see
what
version
of
the
package
that
a
service
is
running.
You
can
also
see
all
of
the
other
services
that
we
might
be
binding
to.
You
can
find
all
of
my
dependencies
through
this
API
as
well.
I
can
also
go
directly
into
the
service
itself
and
I
can
see
what
is
the
live,
running
config
of
my
service.
A
So
if
you
wanted
to
go
and
query
to
see
what
your
config
that
your
containers
are
actually
running,
then
you
can
hit
the
habitats
API
and
get
that
information
back.
So
if
you're
interested
in
contributing
or
if
you're
interested
in
working
with
habitat,
so
it's
all
open
source
everything
I've
shown
today
is
open
source.
Well,
except
for
software,
that's
not
mine,
I,
don't
know
what
Weeds
licenses
it's
all
based
on
the
Apache
License
and
if
you
are
interested
in
contributing
these
are
the
useful
links.
There's
a
pretty
active
slack
channel.
A
A
So
if
you
come
by
the
booth,
we're
right
next
to
VMware
and
across
from
weave,
we
have
a
cheat
sheet
and
some
other
information
as
well,
and
you
can
get
all
these
links
on
a
card
for
you
as
well
and
stickers
and
we
have
a
bunch
of
t-shirts
we're
trying
to
get
rid
of
so
do
you
want
a
t-shirt
like
this
come
back,
but
if
you
have
any
questions,
I'll
hang
out
outside
and
we
can
answer
questions
that
way.
Thanks
a
lot.