Telepresence For Local Development

OpenShift makes it easy to deploy your containers, but it can also impact your development cycle. The core problem is that containers running in a Kubernetes cluster are running in a different environment than the development environment, for example, on your laptop. Your container may talk to other containers running in Kubernetes or rely on platform features like volumes or secrets, and those features are not available when running your code locally.

So, how can you debug them? How can you get a quick code/test feedback loop during the initial development?

In this blog post we’ll demonstrate how you can have the best of both worlds, that is, the OpenShift runtime platform and the speed of local development. We will be using an open source tool called Telepresence.

Telepresence lets you proxy a local process running on your laptop to a Kubernetes cluster, both Minishift/Minikube as well as remote clusters. Your local process will have transparent access to the live environment: Networking, environment variables, and volumes. Plus, network traffic from the cluster will be routed to your local process.

In the above output the address is http://example.openshiftsapps.com, but you will get a different value. It may take a few minutes before the route goes live; in the interim you will get an error page. If you do, wait a minute and try again. Once it’s running you can send a query and get back a response:

$ curl http://example.openshiftapps.com/
Hello, world!

Remember in the above setup that you need to substitute the real address for that to work.

Local development

The source code for the above service looks mostly like the code below, except that this code has been modified slightly. It now has a new version which returns a different response. Create a file called helloworld.py on your machine with this code:

Typically, testing this new version of your code would require pushing to upstream, rebuilding the image, redeploying the code, and so on and this can take a bit. With Telepresence, you can just run a local process and route traffic to it, allowing you a quick develop/test cycle without going through slow deploys.

We’ll swap out the hello-world deployment for a Telepresence proxy, and then run our updated server locally in the resulting shell:

The traffic is being routed to the local process on your machine. Also, note that your local process can now access other services, just as if it was running inside the cluster.

When you exit the Telepresence shell the original code will be swapped back in.

Wrapping Up

Telepresence gives you the quick development cycle and full control over your process you are used to from non-distributed computing; that is, you can use a debugger, add print statements, or use live-reloads if your web server supports it. At the same time, your local processes have full networking access, both incoming and outgoing, as if it were running in your cluster, as well as have access to environment variables and—admittedly a little less transparently—to volumes.