►
Description
Telepresence is an open source project hosted by the Cloud Native Computing Foundation and originally created by Datawire. Telepresence is currently a Cloud Native Computing Foundation sandbox project.
Telepresence is licensed under the Apache 2.0 License.
Telepresence allows you to run your code locally while still:
(a) Giving your code access to Services in a remote Kubernetes cluster.
(b) Giving your code access to cloud resources like AWS RDS or Google PubSub.
(c) Allowing Kubernetes to access your code as if it were in a normal pod within the cluster.
Come to this Ask-Me-Anything session, get a introduction to and demo of Telepresence in action, and ask your questions!
B
B
So,
if
we
think
about
development,
we
can
actually
think
about
loops
or
cycles,
and
the
first
one
where
we
all
work
in
is
a
so-called
inner
loop.
So
this
is
everything
what
happens
prior
to
commit
and
push.
So
essentially,
we
translate
our
great
ideas
into
into
code.
We
run
them,
we
validate
them.
If
we
see
some
problems,
we
probably
debug
them
and
the
cycle
goes
on
and
in
the
world
of
monoliths
that
was
fairly
straightforward
task.
B
It
was
quite
easy
to
reason
about
the
code
base.
It
was
easy
to
debug
and
it
was
most
importantly,
very
easy
to
spin
up
the
whole
app
locally
and
as
we
move
to
the
distributed
systems,
we
kind
of
assume
that
this
will
work
the
same
way
and
obviously,
if
we
start
small-
and
we
just
have
a
bunch
of
containers
and
tools
like
code,
ready,
containers
or
mini
cube,
it's
actually
fairly
simple
to
spin
up
the
whole
cluster
and
just
work
with
the
with
the
app.
B
B
B
B
So
that's
where
telepresence
brings
you
a
very
fast
local
development
without
making
your
machines
wet
or
set
on
fire,
but
then,
when
we
are
done
with
our
local
changes,
we
most
likely
would
like
to
validate
them
against
the
bigger
picture
and
here's
where
the
so-called
outer
loop
kicks
in.
So
this
is
what
happens
after
the
push
so
that
we
build
our
new
code
on
the
ci
server.
We
run
some
integration
tests
we
deploy
and
eventually
we
accept
it's
manually
or
automatically
and
we
ship
it.
B
B
Then
there
are
obvious
extra
costs,
let
it
be.
We
have
to
have
people
who
maintain
that
and
we
actually
have
to
have
infrastructure
to
run
this
whole
stuff
and
at
the
end
of
the
day,
we
are
not
really
sure.
If,
when
we
promote
the
changes
to
production,
this
will
still
work,
because
it
can
be
different
down
to
the
infrastructure
to
the
infrastructure
level,
so
that
we
can
hit
some
unforeseen
issues.
B
B
So
we
came
both
from
a
product
which
we
or
project,
which
was
a
software
as
a
service,
and
we
learned
all
the
pains
of
working
with
the
cloud
environment
and
with
all
these
challenging
bits
which
I
just
have
mentioned.
So
we
thought
we
need
to
find
some
way
to
make
this
easy
and
to
make
developers
productive
again.
B
So
we
started
with
three
simple
goals:
the
first
one
was
easy
way
of
validating
your
changes,
but
without
messing
around
with
other
services
and
user,
but
we
wanted
to
actually
use
the
services
in
the
cluster.
We
didn't
want
to
run
everything
on
our
local
machines
and
obviously,
as
we
all
have
our
favorite
tools
of
choice
when
it
comes
to
writing
software,
we
wanted
to
use
them.
We
didn't
want
to
have
something
enforced
or
some
other
thing
which
we'll
have
to
use.
B
B
But
in
order
to
really
to
fulfill
the
goal
of
not
messing
up
with
the
others,
tell
a
presence
on
its
own.
It's
not
enough
because
it
targets
the
given
deployment,
but
it's
all
or
nothing
so
it
will
replace
the
deployment
and
then
the
whole
traffic
will
go
through
it,
which
means
not
only
us
will
be
able
to
see
it.
But
everyone
else
who
is
using
this
cluster
will
also
be
using
this
new
changes.
B
B
Let
this
request
go
to
this
new
service,
which
we
just
developed
and
all
the
other.
So
let's
say
the
regular
traffic
will
still
go
to
the
known
half
so
before
we
dive
into
the
demo
and
show
you
everything
in
action.
Let's
just
have
a
quick,
30,
000
ft
overview
of
what
kind
of
app
we
are
dealing
with
here.
So
it's
a
fairly
sophisticated
micro
app,
which
consists
of
three
services,
and
what
you
are
about
to
see
is
following
we're
gonna
work
in
two
areas.
B
We
will
have
a
local
development
on
the
recommendation
service
by
using
telepresence
and
we'll
be
introducing
our
changes
locally,
but
we
will
also
show
you
a
way
of
validating
your
changes
which
are
coming
in
the
pull
request.
So
we
will
change
two
services
as
a
pull
request
and
also
have
a
very
similar
way
of
validating
it.
Only
for
those
who
can
not
for
everyone,
and
as
we
are
talking
about
pull
requests,
we
obviously
need
some
machinery
to
make
it
happen,
so
we're
gonna
use
tacton
as
a
part
of
our
demo.
B
B
C
C
Laptop
and
start
up
a
local
instance
of
the
weapon
service
and
it's
then
going
to
be
running
within
the
cluster,
so
we're
actually
calling
a
command
called
ike
develop
and
we're
saying
that
we're
gonna
use
the
the
deployment
preference
version,
one
that
is
in
the
workspace
demo
namespace
and
it's
a
quark
is
based
app.
So
we're
gonna
run
the
quirks
command.
C
A
new
service
has
been
deployed
and
it's
about
to
start
locally.
We
have
a
little
watch
script
that
we
have
here
so
the
first.
The
first
section
is
the
production
route.
The
second
one
is
one
of
the
routes
and
the
next
one
and
the
third
one
is
the
pull
request
route
that
I'm
going
to
show
later
it's,
but
actually
what
it
does.
It's
just
doing:
a
curl
on
the
specific
domain
names.
So
it's
the
ice
demo
io,
which
is
the
production
one,
and
then
it's
the
feature
y
demo
and
the
feature
x.
C
So,
as
far
as
you
can
see
on
the
watch,
there's
no
difference
between
the
two
routes
at
the
moment,
and
the
reason
for
that
is
that
we're
running
the
same
version
of
the
preference
servers
in
production
as
we're
doing.
Hopefully,
if
we
go
into
the
reference
service,
the
source
code
and
make
a
change,
markers
will
pick
up
a
change
in
download
and
we
can
now
see
that
the
local,
the
local
route
changed
as
well.
C
Project
which
the
command
line
is
creating.
That
consists
of
of
essentially
saying
that
we
want
to
target
the
preference
service
version
one.
We
want
to
use
the
telepresence
strategy
and
we
want
to
route
it
on
some
specific
headers
beyond
that,
it's
just
kind
of
printing
out
what
it
changed.
So
we
can
see
that
it
has
created
a
new
deployment.
It
has
modified
a
destination
rule,
it's
modified,
a
gateway
and
it's
modified
to
at
two
different
virtual
services.
C
So
if
you
look
at
the
virtual
services,
what
has
actually
happened
is
that
originally
it
only
had
a
route
to
the
preference
service
version
one,
but
our
operator
then
went
in
and
and
added
a
specific
match
so
that
it
was
if
a
certain
header
is
present
that
that
traffic
will
be
rerouted
to
the
version.
One.
C
C
C
C
C
D
C
C
D
D
C
C
C
And
we
can
now
see
that
there's
something
happening,
at
least
in
a
few
seconds.
We
should
have
the
local,
the
local
recommendation
service
up
and
running
and
receiving
requests
on
requests
to
requests.
So
that's
the
production
instance
of
the
customer
service
calling
the
preference
service
instance
that
was
built
by
the
poll
request
and
then
calling
into
the
local
local
version
of
the
recommendation
service.
C
C
D
C
C
There
there
we
go
so
now.
This
route
is
a
production
version
of
customer,
calling
the
local
version
of
preference,
calling
production
version
of
recommendation
and
and
this
route
is
a
production
version
of
customer
calling
a
pull
request,
version
of
the
preference
service
calling
a
local
version
and
looking
in
kyali,
it
looks
a
little
bit
like
this
university
of
keali
orders,
those
a
bit
strangely,
but
anyway,
we
have
the
customer
service.
C
On
the
the
left
hand,
the
preference
service
in
the
middle
and
the
recommendation
service
on
the
right,
and
we
can
see
there's
two
version
or
three
versions
of
the
weapon
service.
It's
the
production
version,
the
pull
request
version
and
a
local
version
and
for
the
recommendation
service
and
it's
the
production
version
and
the
the
the
local
version,
which
is
part
of
the
google
request
version.
C
C
D
A
D
A
Just
use
that
as
a
jumping
off
place
for
folks
to
have
conversation
and
questions,
but
so,
as
you
know,
anyone
who
ever
looks
at
the
cncf
landscape
document
gets
confused
like
right
off
the
bat.
There
are
so
many
projects
out
there
so
and
and
when
you
go
to
github.
This
is
in
maestro
right,
that's
correct!
B
Okay,
so
maestro
is
our
downstream
name
or
code
name
for
all
the
projects
istio
we
are
doing
so.
We
do
have
the
openshift
service
mesh
and
that's
the
red
hat
version
of
istio
and
this
as
far
as
the
code
sits,
is
in
the
maestro
org
right,
so
we
do
contribute
patches
upstream.
Obviously,
we
work
with
the
community,
but
we
also
do
have
our
own
things,
which
need
some
space
to
exist,
and
this
is
the
maestro
orc.
Essentially.
B
Our
project
is
called
istio
workspace,
it's
not
part
of
istio,
it's
a
standalone
component,
it
leverages
istio
and
it
leverages
stellar
presence.
So
this
is
where
those
two
meet
as
we
were
demonstrating
in
the
live
demo,
so
we
use
the
telepresence
to
give
you
local
development
experience
and
we
leverage
istio
to
have
a
safe
way
of
doing
so
in
the
cluster.
B
There
is
a
getting
started,
which
explains
step
by
step.
What
needs
to
be
done
in
order
to
have
ike,
which
is
the
cli
name
of
istio
workspace
running.
As
you
can
see,
it's
not
that
many
steps
you
need
to
do.
I
mean
obviously
it
requires
telepresence
to
be
installed,
so
you
will
have
to
follow
the
guides
from
telepresence.
C
So
currently,
there's
not
much
excuse
me
so
currently,
the
as
far
as
developer
needing
access.
The
only
access
he
requires
is
to
be
able
to
create
the
session
object
plus.
What
is
it
pod,
exec
or
something
beyond
that?
It's
the
operator
that
actually
does
the
changes
to
the
deployments
and
all
the
other
services,
but
not
something
the
developer
needs
access
to
yeah.
A
B
A
And
so
I,
and-
and
this
I
think,
is
probably
some
of
the
the
setup
for
this
ama
was
a
little
confusing.
So
I
apologize
for
that
because
I
I
I
was
expecting
something
slightly
different
today,
so
and
and
that's
okay
and
and
I
actually
really
am
impressed
with
the
istio
workspace
stuff.
So
that's
this
is
rocking
awesome,
so
the
telepresence
project
is
that
one
you
guys
are
contributing
to.
Are
you
just
leveraging
it
the
same?
A
B
We
do
both,
so
we
wanted
to
have
this
running
smoothly
on
openshift,
so
we
started
using
telepresence
and
we
started
contributing
patches,
so
we
fixed
the
thing
or
two
over
the
last
year
or
so
so
it's
not
that
we
are
just
consuming
it
and
using
it
as
a
part
of
steel
workspace.
We
are
actively
in
involved
in
making
sure
that
this
works
as
good
as
vanilla
kubernetes
on
openshift.
B
B
A
I
know
that
someone
should
write
the
test
harness
for
that,
like
here's,
your
project,
boot
up,
99,
kubernetes
and
test
your
test
yourself.
That
would
be
an
interesting
test,
harness
to
get
organized
and
set
up.
Maybe
that's
a
cnc
yeah,
I
have
to
be
that'd,
be
massive
and
they
constantly
changing
in
different
flavors
and
different
value,
ads
and
different
versions.
So
it
might
be
the
impossible
task
so
where?
A
B
B
So
we
did
demo
the
tacton
part
and
we
also
have
a
integration
with
github
actions,
but
we're
definitely
looking
for
some
feedback
from
people
using,
for
example,
jenkins
or
something
else,
because
we
definitely
would
like
to
make
sure
that
this
is
as
useful
as
all
the
other
platforms
we
tried
so
far.
So
these
are
like
the
main
two
themes
which
we.
A
B
C
It
started
looking
at
the
what
is
it
called
service
mesh
api
or
the
kind
of
the
standard
definitioner,
and
it
seems
like
there
are
at
least
a
couple
of
features
in
that
specification
that
that
seems
like
it
will
be
able
to
at
least
do
parts
of
what
we
want
to
do,
not
the
complete
the
complete
picture
yet,
but
at
least
part
of
the
happy
split
and
so
on.
So
it
should
be
doable
and
we're
probably
going
to
move
to
try
to
follow
that
specification.
At
some
point.
A
You
know,
that's
you
put
out
an
api
in
a
standard
and
you
got
to
make
people
work
on
it,
but
yeah.
That
was
the
other,
because
there
are
a
couple
of
other
at
least
emerging
envoy
based
service
message.
So
if
you
get
that
dependence
dependency
on
envoy,
then
the
the
microsoft
effort
around
open
service
meshes
coming
it's
starting
to
mature,
as
well
as
there's
kuma
kong.
But
you
know
the
other.
One
is
linker
d.
A
There's
it'd
be
interesting
from
a
community
development
point
of
view,
which
is
where
I'm
I
come
from,
is
to
see
this
work
where,
wherever
and
to
have
one
unified
cli
for
all
of
this
and
point
it
at
whichever
one
we
needed
or
people
were
working
with
there's
another
question:
that's
just
come
in
the
telepresence
extension
will
be
like
wsl
or
ssl
extension
and
vs
code.
Have
you
explored
that.
C
I
think
the
whole
remote-
yes
part
if
I
remember
currently
correctly,
it's
kind
of
based
on
moving
the
file
system
out
into
the
remote
thing
and
do
a
false
position.
Think
telepresent
yeah.
I
guess
that
does
that
essentially
as
well,
but
in
a
bit
of
a
different
way
but
like
yeah,
we
were
actually
looking
at
it
earlier.
But
whether
or
not
it
would
make
sense
to
use
that
new
remote
api.
But
it's
a
while
ago-
and
I
don't
quite
remember
what
we
concluded,
but
it's
an
option
possibly.
A
B
A
Well,
I
I'm
I'm
curious
to
see
where
you
guys
end
up
going
with
this
and
and
who,
how
how
it
all
ends
up
working
with
all
of
the
other
developer
tools
at
open.
That
openshift
has
as
well
all
the
code,
ready,
workspaces
and
other
things.
So
I
think
this
is
really
nice
enhancement
to
the
to
the
efforts
that
people
are
doing
to
make
it
easier
for
developers
to
make
our
lives
simpler.
So
I'm
grateful
for
that.
I'm
not
seeing
any
other
questions
out
there
in
the
universe,
so
you
must
have
done
an
awesome
job.
B
No,
I
mean
you
well,
so
we
don't
really
have
a
twitter
channel.
So
that's
I
mean
as
far
as
the
feedback
from
usage
is
concerned,
that's
the
right
place
for
sure.
So
we
can
open
issues
or
raise
questions
right,
and
this
is
essentially
where
we
live
right
now
we
do.
We
have
any
other
channel
last
flag.
A
A
B
Well,
I
mean
essentially,
we
are
addressing
developer
experience
gap
in
the
cloud
environment,
so
I
think
this
can
become
can
be
perceived
as
a
more
development
tools,
effort
than
anything
else.
As
a
matter
of
fact,
we
are
talking
with
code,
ready
workspaces
and
chat
people
about
how
we
could
integrate.
A
Okay,
so
I
think
that's
that'll
that'll
be
interesting
to
see
how
all
that
comes
together,
I
mean
I
I
for
one
would
love
to
see
it
out
there
so
that
it
works
with
multiple
service
meshes,
not
just
istio,
but
others.
I
think,
and
then
that
would
be
cool
and
then,
if
we
can
get
it
integrated
in
with
the
code
ready
workspace
experiences.
That
would
be
super
awesome
for
everybody,
easy
easy
for
people
to
access
it
and
find
this
work.
How
how
old
is
this
project
like?
A
B
B
A
All
right!
Well,
I
I
think
this.
What
I'll
try
and
do
is
I'll
reframe,
the
the
paragraph
that
I
wrote
up
with
kevin
about
what
this
talk
was
all
about
and
see
if
we
can't
push
this
out
and
and
get
some
feedback
and
more
people
using
it
and
and
see
see
if
we
can
get
you,
you
know
some
more
issues,
hopefully
not
painful
ones,
to
fix,
but
good
feedback
on
the
project.
A
It
looks
like
something
that's
incredibly
useful,
so
I'm
really
glad
that
you
guys
came
today
and
made
this
happen
and
then
clarified
a
few
bunch
of
a
bunch
of
things
for
me
and
I
hopefully
for
a
lot
of
other
people
as
well.
So
thanks
again
for
your
time
today
and
much
appreciated,
and
if
you,
when
it
come
when
it
comes
back
to
another
iteration,
please
feel
free
to
come
back
and
we'll
do
it
again.