xip.io in action on openshift.

Elmiko showed me some good tricks today w/ xip.io.  In general, its never been clear to me why people actually needed it.   For me, its clear that it works: it can parse an IP out of a header and resolve it.  But - my question was: why not just use the damn IP if you already know it?  To help me understand I dug into some openshift routes being used for the oshinko-rest-server.


My question: Why would you ever need a mock DNS resolver if you already know your IP address ?

The ultimate reason is because in multitenant/real-world load balancer / router situations, i.e. in a PAAS like openshift, you create internal hostnames, using an interface like this.

If you look at open shift routes, you might get something like this.

Typcially users will look at openshift routes, displaying a table like this.  The interesting part is the "rest.10.1.236.12.xip.io" host.

Going into the details, you can see all the metadata:

[cloud-user@192 openshift-spark]$ oc get routes -o=yaml
apiVersion: v1
items:
- apiVersion: v1
  kind: Route
  metadata:
    creationTimestamp: 2016-06-06T15:12:13Z
    labels:
      name: oshinko-rest-ycse
    name: oshinko-rest-ycse
    namespace: elmiko
    resourceVersion: "69683"
    selfLink: /oapi/v1/namespaces/elmiko/routes/oshinko-rest-ycse
    uid: 0c3a3840-2bf9-11e6-b4bb-fa163ea94473
  spec:
    host: rest.10.1.236.12.xip.io
    to:
      kind: Service
      name: oshinko-rest-ycse
  status:
    ingress:
    - conditions:
      - lastTransitionTime: 2016-06-06T15:12:13Z
        status: "True"
        type: Admitted
      host: rest.10.1.236.12.xip.io
      routerName: router
kind: List
metadata: {}

What happens when we curl ? 

When we curl down rest.10.1.236.12.xip.io , we actually embed the hostname in the request itself.  To some people (like me) this is easily forgotten.  So, if you don't believe me, look for yourself:


[cloud-user@192 openshift-spark]$ curl -v rest.10.1.236.12.xip.io
* About to connect() to rest.10.1.236.12.xip.io port 80 (#0)
*   Trying 10.1.236.12...
* Connected to rest.10.1.236.12.xip.io (10.1.236.12) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: rest.10.1.236.12.xip.io

Having the "rest" portion in the IP gaurantees that this curl call goes to the "rest" application that is specified in the openshift router.  Without it, the openshift virtual router may have 100s of applications that are servable on port 80 on 10.1.236.12. 

In a cloud environment, the IP address as an entry way to an application server is a suboptimal interface.  Using a dns name (like that provided by xip.io) allows you to host multiple, named applications on the same IP, and even the same port (80).  This means that you can expose a single external ingress to an openshift / kubernetes / etc cluster - and use the entire domain name to separate applications.    xip.io , in short, is usable to embed the hostname meta data into a request which resolves to an ip of YOU'RE choosing, because xip.io publically resolves to a server which does nothing other than parse the IP out of your hostname.