How do I debug an Open Shift 503 Service Unavailable error

Question

I have a node app that I'm trying to deploy to Open Shift. It's basic express, pretty much vanilla from the express generator. It runs locally. When I push to OpenShift I get the following error:

503 Service Unavailable
No server is available to handle this request.

Now I'm not surprised there are errors because I've pushed a whole new application on to open shift in one go, but what I want to know is how do I go about finding them?

How do I go about debugging this? How do I crack open the server and see what's going on?

Gravois

The 503 message in openshift is absolutely terrible. It could give a message back of: health check failed, or app didn't respond or anything. This issue has been plaguing me for weeks, no way to debug. – Chopping

Answer 1

You can try the following things:

• rhc tail <app_name> to view the log files on the server
• Connect to the server with SSH look at the logs in ~/app-root/logs
• If this is a scaled application, go to http://<app_name>-<your_namespace>.rhcloud.com/haproxy-status to view the status of your scaled gears

Discernible

Answer 2

I know this is kind of old, but I just had an issue with this 503 error. My log tail showed the app was fine, but the HA Proxy Status link showed the site as being down. I'm running a Node Express app that handles requests to specific endpoints, and I had no handler defined for the root "/" request. I ended up adding

app.get('/', function (req, res) {
    res.status('200').send('Service is up');
});

and all is well.

Certainty

Answer 3

I got stuck on a similar "503 Service Unavailable" today while deploying a Simple Spring Boot app to Minishift (i.e. the local Openshift).

For me the problem was that I did not have an "EXPOSE" line in the Dockerfile that I used to create the Docker image.

I overlooked this at first, but the "oc new-app" command actually hints at this:

* The image does not expose any ports - if you want to load balance or send traffic to this component
    you will need to create a service with 'expose dc/sb-test --port=[port]' later

Gertrudis

It seems there are lots of situations causing this problem, I've exposed my port but I still have this issue, without any logs. – Abstriction

Answer 4

Consider these items and make sure they are OK:

• The hostname and the URL path were typed correctly, a route matching this hostname exists, and the route was created using the desired path.

• The resources exposed by this route (pods, services, deployment configs, etc) have at least one pod running.

• Service selectors match a pod

• Pods are passing the readiness probe so that they won't be removed from the Service endpoint

In one case, I added router=public label to my route and changed its TLS settings by adding code below to spec:

  tls:
    termination: edge
    insecureEdgeTerminationPolicy: Allow

It still can be from other networking or configuration issues that prevented the Service from connecting with the pods.

Reading this article can be helpful.

Abstriction