blog post on telepresence & openshift

telepresence-openshift

# Telepresence: Fast, local development and debugging on Kubernetes and OpenShift

OpenShift makes it easy to deploy your containers, but it can also slow down your development cycle.
The problem is that containers (or microservices) running on OpenShift are running in a different environment than your laptop.
Your container may talk to other containers running on OpenShift, or rely on platform features like volumes or secrets, and those features are not available when running your code locally.
How then can you debug them with a debugger, how can you get a quick code/test feedback loop during initial development?

There are a [variety of approaches](https://www.datawire.io/guide/deployment/development-environments-microservices/
) to setting up your development environment for microservices. In this blog post we'll demonstrate how you can have the best of both worlds, the OpenShift runtime platform and the speed of local development, by using an open source tool called [Telepresence](http://www.telepresence.io).
Telepresence lets you proxy a normal, local process running your laptop to an OpenShift or Kubernetes cluster, both minishift/minikube and remote clusters.
Your local process will have transparent access to the full OpenShift environment: networking, environment variables, [volumes](http://www.telepresence.io/howto/volumes.html).
Plus, network traffic from the cluster will be routed to your local process.

## Initial setup

Before we begin, you will need to:

1. [Install Telepresence](http://www.telepresence.io/reference/install.html).
2. Make sure you have the [oc](https://docs.openshift.org/latest/cli_reference/get_started_cli.html) command-line tool installed.
3. Have access to an OpenShift cluster, e.g. by using [minishift](https://www.openshift.org/minishift/).

## Running in OpenShift

Let's say you have an application running inside OpenShift; you can start one like so:

```console
$ oc new-app --docker-image=datawire/hello-world --name=hello-world
$ oc expose service hello-world
```

You'll know it's running once the following shows a pod with `Running` status that *doesn't* have "deploy" in its name:

```console
$ oc get pod | grep hello-world
hello-world-1-hljbs   1/1       Running   0          3m
```

To find the address of the resulting app you can run:

```console
$ oc get route hello-world
NAME          HOST/PORT
hello-world   example.openshiftapps.com
```

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:

```console
$ export HELLOWORLD=http://example.openshiftapps.com/
$ curl http://example.openshiftapps.com/
Hello, world!
```

**Remember, 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 has a new version which returns a different response. Create a file called `helloworld.py` on your machine with this code:

```python
from http.server import BaseHTTPRequestHandler, HTTPServer

class RequestHandler(BaseHTTPRequestHandler):
    def do_GET(self):
        self.send_response(200)
        self.send_header('Content-type', 'text/plain')
        self.end_headers()
        self.wfile.write(b"Hello, world, I am changing!\n")
        return

httpd = HTTPServer(('', 8000), RequestHandler)
httpd.serve_forever()
```

Typically testing this new version of your code would require pushing to upstream, rebuilding the image, redeploying the code, and so on.
This can take a while.

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:

```console
$ telepresence --swap-deployment hello-world --expose 8000
@myproject/192-168-99-101:8443/developer|$ python3 helloworld.py
```

In another terminal we can query the OpenShift service we already started, and this time requests will be routed to our local process, which is running the modified version of the code:

```console
$ oc get route hello-world
NAME          HOST/PORT
hello-world   example.openshiftapps.com
$ curl http://example.openshiftapps.com/
Hello, world, I am changing!
```

(Remember your URL will be different, make sure you use yours.)
The traffic is being routed to the local process on your machine.
Your local process can also, in turn, access other OpenShift services, just as if it was running inside the cluster.

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

## Conclusion

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

To get started, check out the [OpenShift quick start](http://www.telepresence.io/tutorials/openshift.html) or tutorial on [debugging a Kubernetes service locally](http://www.telepresence.io/tutorials/kubernetes.html). If you're interested in contributing, read [how it works](http://www.telepresence.io/discussion/how-it-works.html), the [development guide](http://www.telepresence.io/reference/developing.html), and join us on our [Gitter chat](https://gitter.im/datawire/telepresence)!