►
From YouTube: Episode 10: Intro to HashiCorp Waypoint
Description
Yuval Kohavi digs into the recently announced HashiCorp Waypoint, a new open source project for developers. Waypoint provides a consistent workflow to build, deploy, and release applications across any platform.Get apps from development to production in a single file and deploy using a single command.
A
All
right
good
afternoon,
everybody,
I
hope
everybody
can
hear
me
well
welcome
to
another
episode
of
hoot
with
me,
you
valve
from
solo
io
here
with
you
to
give
you
some
technology
updates
and
in
today's
episode,
we'll
be
talking
about
hashicorp's
new
product,
a
waypoint
which
I'm
excited
to
talk
about.
I
like
hashicorp
products,
they
usually
have
a
very
products,
are
very
thoughtful
in
the
way
how
they
solve
the
problem
they
sold.
A
Now,
I'm
by
no
means
a
waypoint
expert.
It's
only
been
out
for
a
couple
months,
so
I'll
be
also
talking
about
how
you
know
my
approach
into
learning,
about
new
products
and
how
I
evaluate
them
and
of
course,
if
there's
any
questions,
obviously
feel
free
to
ask-
and
I
will
you
know,
answer
them
live
as
as
I
usually
do
all
right
before
we
get
started
with
the
house
cleaning.
A
A
So
let's
talk
a
bit
a
little
bit
about
waypoints,
so
what
is
a
waypoint
waypoint
is
a
product
from
hashicorp,
and
let
me
get
my
little
slides
here
going
that
the
goal
of
it
is
to
help
part
of
the
development
life
cycle
right,
so
development
life
cycle
in
general.
You
know
you
build
the
code,
you
write
some
unit
tests,
you
do
all
that,
then
you
need
to
kind
of
deploy
it
into
prod
or
into
dev
or
into
test
environment,
and
that's
where
the
problem
that
waypoint
wants
to
solve.
A
So
as
far
as
I
understand
it,
it's
kind
of
the
thing
that
we
today
hack
around
with
make
files
and
scripts.
They
try
to
give
a
more
uniform
abstraction
to
the
developers,
and
so
they
don't
have
to
think
you
know
which
make
command.
They
need
to
run
how
what
home
command
they
need
to
run.
They
just
want
you
to
do.
Waypoint
up
and
you'll.
A
Have
your
application
up,
and
so
that's
kind
of
the
the
general
idea
so
think
preview,
environments
in
ci
deployment
to
dev
or
prod
and-
and
you
can-
I
really
recommend
you
watch
the
introduction
that
mitchell
they
do
to
waypoint
to
understand
more
the
use
case
they're
targeting
so
what
I
gather.
They
don't
really
target
the
they
can
do
it,
but
I
don't
think
that's
the
main
use
case
of
a
you
know,
laptop
environment.
A
It's
something
that
tools
like
draft
or
scaffold,
do
for
you,
but
more
where
the
environments
are
shared
in
a
dev
cluster
in
a
test
cluster
in
a
product
cluster,
and
you
need
some
more
management
around
the
deployment
right.
So
that's
kind
of
my
own
personal
impression
and
again
the
caveat
that
I'm
by
no
means
expert,
and
you
should
definitely
seek
out
more
opinions.
If
you
plan
to
to
use
this.
A
So
when
you
we
we're
gonna
go
into
a
bit
to
the
technicals
in
a
sec
when
you
deploy
essentially
with
waypoint,
they
have
this
nice
run
service.
That
gives
you
a
url
that
you
can
access
your
deployment
and
see
it
running
live
it's
by.
I
obviously
wouldn't
use
it
for
production,
but
it's
a
good
getting
started
experience
and
I
think
that's
one
of
the
things
that
hashicorp
do
really
well.
Is
they
give
you
a
way
to
just
get
started
right
like,
for
example,
console
has
a
dev
mode.
A
You
want
to
run
console
and
don't
want
to
fuss
around
too
much.
You
do
console
dev
mode
or
console.dev,
something
like
that
and
just
runs
so
in
some
idea.
This
run.
Url
just
gives
you
something
to
get
started,
so
you
can
move
on
and
and
make
some
progress
on
your
project
and
we'll
see
that
url
in
a
second
when
when
we
get
to
it,
so
yes,
let's
talk
a
little
bit
about
how
it's
structured
and
this
diagram
is
from
their
docs.
A
We
should
also
review
a
little
bit
in
a
sec
now
the
way
and-
and
that's
part
of
the
reason
why
I
think
the
main
use
case
for
waypoint
is
not
kind
of
the
laptop
scenario,
because
it
does
have
a
server
and
that
server
does
have
persistent
state.
This
is
a
database
that
you
need
to
come
back
up
if
you
want
to
have
it
be
long
running
right,
so
you
have
the
command
line.
The
command
line,
talks
to
the
waypoint
server,
and
you
know
the
server
for
every
deployment.
A
Every
deployment
has
a
component
injected
to
it
and
we're
going
to
talk
about
this
also
a
little
bit
more
and
that
component
kind
of
streams
logs
and
debug
data
to
the
server
right.
So
essentially,
when
you
build
something
with
a
command
line,
you
build
your
application,
because
waypoint
also
does
the
build
part.
They
actually
inject.
A
This
entry
point
binary
into
your
container
into
your
docker
container
and
then,
when
it
deployed
it,
has
this
entry
point
binary
that
can
communicate
with
the
waypoint
server
and
you
know,
send
the
logs
and
allow
exact
information
right,
so
exec
would
have
started
a
cli
go
through
the
server
and
through
the
entry
point
now,
the
advantage
of
this
will
work
in
environments
that
are
not
kubernetes
right.
It's
a
generic
way
to
get
logs
and
exits,
something
that
kubernetes
might
give
you
already.
A
But
it's
a
way
to
do
it
for
any
type
of
platform.
Kubernetes
c2
or
noma:
it's
a
way
to
do
it
in
a
way.
That's
a
consistent
to
the
developer,
experience
right
and
when
I'll
do
the
demo,
I
have
some
more
thoughts
on.
You
know
the
security
aspects
of
that.
But
that's
that's.
I
believe
the
motivation
for
why
it's
the
architecture
looks
how
it
looks
like
all
right.
So
what
else
I
want
to
say
about
the
architecture,
talk
about
the
entry
point.
A
Yes,
android
can
be
disabled,
but
then
you'll
have
obviously
some
functionality
lacking
right.
You
cannot
get
the
logs.
You
cannot
do
exec.
It
will
make
the
experience
less
enjoyable,
all
right.
So
now
I
want
to
a
little
bit
talk
about
how
you
know
it's
a
new
project.
How
do
they,
you
know,
go
about
understanding?
A
What
is
it
doing?
How
does
it
do
in
it
and
all
that
and
then
we
kind
of
I
have
a
waypoint
set
up
in
my
test
cluster,
I'm
going
to
play
around
with
it
see
what
what
it
does,
and
so
the
general
flow
is
that
you
have
a
project.
The
project
can
have
one
or
more
app
and
each
of
these
apps
you
can
deploy
a
release,
build
build,
deploy,
release
and
you
can
have
hooks
to
customize
the
behavior
right.
A
So
usually,
when
you
deploy
an
app
you
don't
necessarily
want
to
release
it
and
by
release
I
mean
you
know,
making
it
publicly
available.
So
you
can
use
something
like
a
hook
to
add
some
tests
between
after
the
deploy
phase
and
before
the
release
phase
right.
These
hooks,
let
you
customize
the
behavior
between
each
of
these
steps
of
a
build,
deploy,
release
all
right.
So
that's
kind
of
like
the
background.
A
I
hope
it
all
makes
sense
and
we're
going
to
review
some
of
their
documentation
now
and
then
going
to
review
some,
how
you
know
I'm
going
to
play
around
a
little
bit
with
the
command
line
and
see
how
it
all
works.
So,
let's
go
to
the
web
browser
and
if
there's
any
question,
I'm
looking
at
the
chat
so
feel
free
to
ask.
A
All
right,
this
is
a
our
website
just
so
you
have
a
reference
all
right.
Let's
go
to
the
waypoint,
so
usually
when
I
need
to
evaluate
a
new
open
source
project,
a
good
starting
point
is
actually
their
their
github
repo
right.
So
when
I
look
at
the
at
the
repo
I
I
don't
necessarily
straight
they
delve
into
the
code,
because
it's
a
lot
to
learn.
You
know
a
new
code
base.
I
look
for
a
few.
You
know
key
indicators,
let's
call
it
so.
A
And
then
I
look
at
the
kind
of
general
directory
structure
and
it
looks
a
very
standard
go
structure,
a
cmd
folder
for
the
binaries,
and
you
can
see
that
you
have
the
waypoint
and
the
entry
point
binary
and
you
have
an
internal
endpoint
where
all
the
rest
of
the
go
code
lives,
and
you
can
see
that
each
package
has
a
meaningful
name,
so
it
already
shows
kind
of
like
they
know.
What
they're
doing
as
far
as
the
development?
A
A
A
I
might
not
even
continue
to
look
at
it
because
you
don't
want
to
use
a
project,
that's
not
maintained,
and
now
on
the
some
projects.
Don't
have
a
lot
of
documentation,
but
hashicorps
projects
usually
have
a
good
and
fair
amount
of
documentation.
So
that's
the
next
step
I
would
go
when
I
evaluate
the
project
and
I
would
look
in
their
documentation
website
and
they
really
have
good
documentation
here,
and
I
recommend
you
read
it
specifically.
A
A
All
right-
and
you
can
see
that
this
this
code
is
set
up
with
the
a
waypoint
examples,
repo
that
has
an
example
and
we'll
specifically
look
at
the
kubernetes
node.js
example,
and
this
is
the
waypoint
hcl
file.
Now
I
already
installed
waypoint
I'll
have
the
the
commands
that
I
used
to
install
it
in
the
show
notes
in
in
github
after
the
episode,
along
with
a
summary
of
my
thoughts
on
the
project,
so
feel
free
to
read
and
comment.
A
And
yes,
so,
let's
talk
a
bit
about
the
structure
of
this
application,
so
you
can
see
it's
a
node.js
application,
I'm
not
a
node.js
programmer,
so
I
might
be
misrepresenting
how
the
node.js
part
work
but-
and
it
starts
with
an
index.js
and
a
package
json
that
describes
how
to
package
it.
It's
all
all
the
the
public.
The
views
are
part
of
the
note
application.
A
The
waypoint
related
is
this
waypoint
hcl
file,
so
we'll
focus
on
that
all
right.
So
we
can
see
that
it
starts
with
a
project
right
and
if
you
recall,
that's
kind
of
the
hierarchy
of
a
waypoint,
it
has
projects
and
a
project
can
have
one
more
application.
So
you
can
see,
there's
an
application
stanza
in
here
and
each
application
has
this
step.
So
we
talked
about
build,
deploy
and
release
right.
Let
me
minimize
the
console
for
now:
do
we
need
it
so
build?
A
A
The
deploy
part
creates
a
deployment
in
kubernetes
right,
and
this
is
a
where
to
do
the
liveness
probe.
So
this
will
create
a
deployment
and
the
release
part
will
expose
it
with
a
load
balancer,
essentially
all
right.
So
this
is
pretty
straightforward
and,
like
other
hashicorp
products,
waypoint
is
also
extendable
right.
That's
one
thing
I
really
like
about
hashicorp
product.
They
really
thought
about
extendability,
it's
very
easy
to
create
a
plug-in
and
extend
it
to
more
use
cases.
A
So
with
that
file,
it's
pretty
simple,
pretty
straightforward.
I
do
like
the
fact
that
it
kind
of
abstracts
away
all
the
the
scripter
is
so
usually
when
we
want
to
build
stuff,
there's
not
a
lot
of
good
options
to
abstract
it,
so
we
usually
just
revert
back
to
using
make
files
and
create
make
targets
that
are
easier
to
consume
than
the
docker
command.
A
You
need
to
remember
in
order
to
do
something,
and
so
I
like
that,
the
cleanness
here
and
to
deploy
this
we
just
do
a
waypoint
up
kind
of
like
you
know,
vagrant
app
right
and
now,
let's
see
what
this
step
does.
Let's
maximize
the
terminal
here
and
in
the
meantime,
of
course,
docker
permission:
it's
not
a
show
without
a
technical
issue,
so
it
uses
docker
and
I'm
using
fedora
and
with
fedora,
and
they
don't
come
with
docker
anymore.
A
So
the
main
thing
I
wanted
to
look
show
here
is
that
it's
using
the
heroku
and
node.js
build
pack.
It
detected
it's
a
node.js
application
right,
so
it's
getting
all
the
node
stuff
and
it's
using
the
build
pack
to
build
it
and
then
we'll
build
a
docker
image
with
with
node
in
it
right
and
let
this
thing
move
on
a
little
bit.
A
A
It
after
it
build
the
image
using
the
build
pack,
it
injects
its
own
entry
point
component
on
to
the
image
right.
So
it
takes
the
docker
image
and
it
modifies
it
by
adding
an
entry
point
binary
and
setting
that
binary
to
be
the
image
entry
point
and
we
look
and
how
it's
deployed
on
the
cluster
and
I'll
show
you
what
what
I
mean
by
that.
A
A
Easy
I
gotta
say
and
pretty
nice
experience
overall,
the
let's
go
back
to
the
code
here,
but
one
thing
that
I
didn't
notice
that
waypoint
doesn't
have
at
least
for
now.
I'm
I'm
pretty
sure
I'm
assuming
they're
going
to
fix
it
is
that
I
didn't
see
any
way
of
having
some
sort
of
access.
Control
of
you
know
this
user
can
deploy
to
that
cluster
or
to
that
environment
or
this
application.
A
I
would
assume
that
would
come
in
the
future.
I
know
that
waypoint
is
very,
very
young
project.
They
just
you
know,
announced
it
version
0.1
a
few
months
ago,
and
but
that's
something
I
noticed
that
kind
of
like
was
missing.
If
I
wanted
to
use
this,
as
my
main,
you
know
deployment
driver
and
it
does
give
a
very,
very
nice
experience
now.
Let's
look
a
little
bit
on
the
cluster
and
see
what
got
deployed.
A
A
A
B
A
Being
bashed-
and
here
you
can
see
that
you
have
the
waypoint
entry
point
running-
is
pid
1
right,
that's
the
entry
point
in
the
container
and
that
runs
npm
and
all
that
and
in
addition,
if
we
look
at
at
the
socket
select,
you
can
see
waypoint
talking
to
the
waypoint
server
right.
So
this
is
how
they
kind
of
do
the
magic
of
getting
all
the
logs
and
all
the
the
executability
configuration.
A
A
And
you
can
see
that
when
you
install
waypoint
and
again
it'll
be
in
the
show
notes
explanation:
how
to
do
it.
It's
a
project
and
project.
You
get
the
access
to
the
ui,
you
can
see.
There
is
a
project.
This
is
the
project
I
just
deployed
and
you
can
see
the
the
logs
coming
in
you
can
see.
The
latest
builds
releases,
so
a
nice
ui.
It's
read
only
as
far
as
I
can
tell,
but
still
your
eyes
are
kind
of
nice
to
have.
A
You
can
see
the
deployment
I
just
did.
Click
around
you
cannot,
you
can
just
log
into
the
service,
willingly
use
the
command
line
to
create
a
token
to
authenticate
with
it.
So
this
is
nice,
so
you
know
you
can
just
deploy
it
and
and
not
worry
about
random
people
deploying
stuff
on
there
on
your
waypoint
server.
A
A
A
And
I
want
to
conclude
with
some
final
thoughts,
so
I
do
recognize
the
gap
they're
trying
to
solve
right
doing
a
waypoint
app
is
way
easier
than
doing
a
helm,
install
release
repo
chart
set
this
value
to
that
value
right.
It's
nice
that
everything
all
the
options
you
need
to
deal
with
are
already
configured
in
a
config
file
and
you
as
a
new
developer
in
the
company,
don't
need
to
think
too
much.
You
just
do
waypoint
up
and
things
magically
work
same
for
waypoint
logs.
A
It's
way
easier
to
do,
waypoint
logs,
then
now
the
alternative
is
oh.
If
you're
in
kubernetes,
you
need
to
know
where's
the
kubernetes,
where
is
it
deployed
what
pod,
what
namespace?
What
this?
What
that
right?
So
that's
kind
of.
I
really
like
the
experience
they're
trying
to
get
to
achieve
here.
I
do
see
some
drawbacks
technically
right,
I
think
there's!
No.
I
at
least
I
couldn't
find
any
way
to
restrict
access
any
access
control,
and
so
it's
kind
of
a
have
access
or
not
have
access,
which
is
not
ideal.
For
you
know
larger
teams.
A
I
do
find
the
need
to
inject
that
entry
point
to
get
those
extra
features
a
bit
awkward,
especially
if
you
target
you
know
if
you
want
to
change
your
existing
deployments,
it'd
be
kind
of
if
you
already
have
a
build
pipeline
and
you
just
want
to
use
it
to
for
the
logs
exit
debugging
features.
It
is
a
bit
annoying
that
you
have
to.
A
A
That
is
pretty
much
all
I
have
for
today.
So
if
there's
any
questions
feel
free
to
ask
them
now,
if
not,
you
can
always
join
our
slack.
I'm
there
you
can
post
issues
on
our
github
repo
to
ask.
You
know,
suggest
episodes
or
make
a
suggest
other
suggestions,
our
next
hoot.
I
believe
it's
going
to
be
about
it's
your
multi-cluster.
A
A
Our
next
would
be
advanced
issue
configuration
with
android
crds,
hosted
by
scott
weiss,
and
it's
going
to
be
on
january.
12
2021
we're
gonna,
do
a
little
bit
of
a
holiday
break
until
the
holidays
end,
and
I
hope
everybody
have
a
great
day.
Thank
you
for
joining
me
and
I'm
looking
forward
to
see
you
next
time.
A
A
I
don't
think
it's
meant
to
be
used
instead
of
but,
like
I
said,
I'm
by
no
means
an
expert,
so
the
demo
I've
seen
is
that
you
know
you
have
a
pull
request
and
there's
a
git
of
action
that
uses
waypoint
to
deploy
the
modified
code
of
the
you
know
with
the
suggested
change
included
in
it
into
a
different
and
provide
you
with
an
environment
just
for
that
pull
request.
So
you
can
kind
of
check
that
the
changes
make
sense
before
you
approve
the
the
pull
request.