Container Service: Developing an Application - Troubleshooting

OpenShift documentation on debugging commands can be found here.

Debugging Pods In "crash loop back-off"

On of the benefits of a system like OpenShift is that it will automatically restart applications that are failing. But that can also make debugging more difficult, as the pod in which your application runs may only exist for a few seconds. OpenShift provides functionality to allow inspection of failing pods. This catches the next restart of a failing pod and allow its to exist for an hour, overriding system commands to destroy the pod. This is a nice option to inspect the state of variables or execute commands within the failing pod.

To debug in the UI:

  • On the 'Pod' page, click on the pod you wish to debug.
  • Under Status ... Restart Count, click on the anchore to "Debug in Terminal".

To debug in the CLI:

  • oc debug resource/name e.g oc debug dc/my-deployment-config-name
  • oc debug -f pod-config.yaml

Application Builds Successfully Local But Fails to Build in OpenShift

Container Service customers occasionally find that the underlying distribution of the base image being used by their application is different when building on their laptop than when they build in OpenShift. The Container Service provides base images from both Docker Hub (typically debian-based) and Red Hat in the openshift namespace within the integrated registry. Unless the tag has a suffix at the end of its name, you can assume that tag is debian-based. For example Red Hat images have a -rhel suffix affixed to the end of the tag name:

python:3.6-rhel

Last Updated: 
Saturday, July 11, 2020