3.5 things you should undesrtand about your openshift routes

Routes in openshift are tricky when your working on a new app.

if you don't know the differences between these routes, and why they don't collide, then you shouldnt be using openshift.  

1)  Know if you need to passthrough or not. Your app might have built to use https at the gateway.  In that case, openshift routers will possibly want to use the 'passthrough' attribute.  EVEN IF you use https:// to access the openshift router, if you use edge termination without passthrough, your connection type will change to http once it hits the server,  and your apps expectation of https will probably return an error (i.e. a 503 service available error, saying "http request was sent to an https-only endpoint").

2) Know how and where your damn routers are exposed ! You NEED to make sure your Routers are exposed outside the cluster.  NodePorts and magical CloudLoadbalancers proabably don't exist, as viable options, in your on prem openshift installation.

3) Know why Xip.io is awesome.  Testing DNS is tricky, and needing to debug DNS issues along side openshift route issues is impossible.  To solve this, first off use XIP.IO as a way to verify that your routes work properly.  XIP.IO is always gauranteed to resolve, from anywhere, to the ip you embed inside it, For example: If you try to curl from an openshift route: curl -H 'Host: hub.172.31.36.155.xip.io' --insecure https://hub.172.31.36.155.xip.io/.   (the -H thing is just for good measure, its not really required). 

4) Know what the difference between 'Service unavailable' and 'Connection Refused' are. This is easy to gloss over.  Svc Unavailable means you not going to the right URL, but that your probably accessing the router correctly.  If your confused about this, make sure and go back to (2).   When using xip.io, as above, your client will resolve the URL to 127...155, and then access it.  Make sure curl command matches the exact location of your openshift routes associated HOSTNAME field ! If you DONT then it wont go to the right place:


[ec2-user@ip-172-31-43-131 ~]$ curl -I --insecure http://172.31.36.155.xip.io
HTTP/1.0 503 Service Unavailable

Will work.  But if you try the same command w/ just the IP, it will fail.  The reason is simple... Openshift wants you to map a hostname into the router, and will look at that hostname when the router tries to forward a packet from the openshift router into the corresponding service.

So, back to the top - why are those routes different?
- One is passthrough, one is not.  The one that isn't will use HTTP to talk to your service.  If you want minimally complex HTTPS, use passthrough.

- The have different hostnames.  Thats the primary key for routing.  If you change the hostname, you change the router destination.