Intercept Specification Golden Path

Why?

Telepresence can be difficult to adopt Organization-wide. Each developer has their own local setup and adds many variables to running Telepresence, duplicating work amongst developers.

For these reasons, and many others we recommend using Intercept Specifications.

How?

When using an Intercept Specification you write a YAML file, similar to a CI workflow, or a Docker compose file. An Intercept Specification enables you to standardization amongst your developers.

With a spec you will be able to define the kubernetes context to work in, the workload you want to intercept, the local intercept handler your traffic will be flowing to, and any pre/post requisties that are required to run your applications.

Lets look at an example:

I have a service quote running in the default namespace I want to intercept to test changes I've made before opening a Pull Request.

I can use the Intercept Specification below to tell Telepresence to Intercept the quote serivce with a Personal Intercept, in the default namespace of my cluster test-cluster. I also want to start the Intercept Handler, as a Docker container, with the provided image.

You can then run this Intercept Specification with:

You can see that the Intercept was started, and if I check the local docker containers I can see that the Telepresence daemon is running in a container, and your Intercept Handler was successfully started.

Key Learnings

• Using Intercept Specification enables you to create a standardized approach for Intercepts across your Organization in an easy to share way.
• You can easily leverage Docker to remove other potential hiccups associated with networking.
• There are many more great things you can do with an Intercept Specification, check those out here