CODEWITHSUNDEEP
dockeropenshift
rookie099
rookie099

Reputation: 2607

"oc new-app" does not expose port altough the input image does

I'm exploring OpenShift 3.9 and have managed to get a first container built and running with oc new-app and the Docker build strategy. My Dockerfile includes the command EXPOSE 5432.

After the rollout oc describe istag/my_app:latest | grep ^Exposes reports Exposes Ports: 5432/tcp, so that looks good: the image exposes port 5432. But oc describe po/my_app-1-some_id | grep "^\s*Port" reports Port: <none>, so overall it seems as if the port is exposed at the level of Docker, but not yet the level of Kubernetes/OpenShift.

The OpenShift documentation says the following:

The new-app command attempts to detect exposed ports in input images. It uses the lowest numeric exposed port to generate a service that exposes that port. In order to expose a different port, after new-app has completed, simply use the oc expose command to generate additional services.

Why does oc new-app not expose port 5432 in this situation (in fact it does not create any service resource either) and how can I make it do so automatically, as the input image already does and as seems possible judging from the documentation?

UPDATE Here is more detail on how the new application was created:

oc new-app ssh://my_account@my_git_server/my_path/my_repo.git
  --context-dir=my_dir --strategy=docker --name my_app

The Git repository contains a so far trivial my_dir/Dockerfile, and it in turn contains the command EXPOSE 5432.

Upvotes: 5

Views: 1954

Answers (1)

rookie099
rookie099

Reputation: 2607

In the end, the problem "suddenly" went away and oc new-app now indeed exposes the port (as the documentation says). I am so far using a trivial Dockerfile such as this

FROM debian:stretch
EXPOSE 5432

COPY start.sh /usr/local/bin/start.sh
CMD ["start.sh"]

where startup.sh calls sleep infinity. In terms of explanation, I can only guess that I had made some secondary and transient error that caused an interference.

Here are lessons learned while attempting to diagnose and solve the issue (big thanks to @GrahamDumpleton):

  • If all goes well with oc new-app, oc get all should indicate port 5432/TCP for resource svc/my_app and should also list new OpenShift (and Kubernetes) resources of types deploymentconfigs, buildconfigs, builds, imagestreams , po, and rc.
  • This automatic mechanism exposes the port only inside the cluster, i.e. svc/my_app has (and listens on) a cluster-IP (not: external-IP).
  • Additional arguments --dry-run -output json cause oc new-app to conduct a dry-run and print an exact description (in JSON format) of what resources it would normally create.

Upvotes: 2

Related Questions