EXPOSE 8080

[vorburger]

Unless I'm missing something in how this is to be used, don't we need to have a way to specify which port, in addition to 8778 and 9779, is to be EXPOSE'd in the Dockerfile for the "microservices with a flat classpath" (quote from README) to be accessible by a Service and Route?

Because without hacking that, I cannot get e.g. this to work:

oc new-app fabric8/s2i-java~https://github.com/vorburger/s2i-java-example
oc expose svc/s2i-java-example --port=8080
oc status -v
...
Warnings:
  * route/s2i-java-example has a port specified (8080) but svc/s2i-java-example has no such targetPort.

PS: An oc expose svc/s2i-java-example will create a route on port 8778, which of course isn't what one would want.

[vorburger]

@rhuss / all: if PR #117 is not the right solution for this problem, then how does one do the above right if not direct Docker but with OpenShift oc new-app - how is an example like this (above) supposed to work without an EXPOSE?

[rhuss]

@vorburger what's about

oc expose svc/s2i-java-example --port=8080 --target-port=8080

?

Actually I'm not sure how to reliably define a default port to expose in the s2i builder image as this is supposed to run all sort of Maven builds and obviously the builder image can not know the port of the application which is build with this image in advance.

I wonder, whether the S2I mechanism itself has an answer for this as I suppose to be an issue for any s2i source build. I think there should be a s2i config which defines this port and which uses the s2i build mechanism to expose on the final image it creates after a build.

Let me research a bit ...

[gunnarmorling]

Hey @rhuss, any further insights on that one? What you suggest above doesn't seem to work for me, as the image doesn't export port 8080. So I'm wondering how I'd e.g. use this image to run WildFly Swarm on OpenShift. Glad about any ideas you may have :)

[rhuss]

Actually in a Dockerfile EXPOSE is always a recommendation. You always can export any port from the container without declaring it first in the Dockerfile/Image.

Historically the only reason why EXPOSE was introduced in Dockerfiles is, that a docker run -P can find all ports exposed. Still, you can use docker run -p <any local port>:<any container port> without previously declaring.

And sorry, haven't done my homework yet. Not sure whether there is an S2I mean to provide this meta data for the resulting image.

[vorburger]

oc expose svc/s2i-java-example --port=8080 --target-port=8080

error: cannot use --target-port with --generator=route/v1

I still don't understand how this was ever supposed to work - I cannot get the basic example running on OpenShift without manually editing the Service YAML and adding port 8080 - this somehow feels stupid.

[gunnarmorling]

Hey @rhuss, any news on this one? I currently need to patch each application using that S2I builder:

oc patch service my-app -p '{ "spec" : { "ports" : [{ "name" : "8080-tcp", "port" : 8080, "protocol" : "TCP", "targetPort" : 8080 }] } } }'

It'd be really cool if this could be simplified a bit.

[rhuss]

@gunnarmorling sorry, no yet. It looks like that the --target-port options is only available for a service generator, but since the service has been already generated by oc new-app, this doesn't help.

Instead, we need to convince oc new-app that when it creates a service additional ports need to be taken into account. This needs to be somehow specified as the generic s2i image has no insight into the app and which ports are exposed by the build app. Propbably this can be don by some env vars which allows the assemble script to give the service generation mechanism of oc new-app some hints for the service to export. Still I have to find out how it really works. Also wonder, how the productised Java S2I image from CE allows to expose application specific ports.

@goldmann any idea how a custom port can be exposed by an s2i builder image so that it's picked up for the service generated via oc new-app ?

[vorburger]

@rhuss @gunnarmorling @edewit @alexkieling @goldmann how crazy would it be if I seriously suggested that we "resolve" this 'annoying' issue by simply adding a hard-coded EXPOSE 8080 to the Dockerfile (just like 9779 for JMX already is).

It's not "perfect", because yes one could run whatever one runs to listen in this container on another port, but the default of Spring Boot and Thorntail.io probably is 8080, and this would be a useful simplification IMHO.

It's not a big "problem" to add this hard-coded, because if you run it on another port, you'll have to customize anyway, to add your own port, and you could then also drop the 8080 - for people who know what they are doing. There is no "harm" in having the 8080 exposed by default?

[edewit]

@vorburger I think it's a good idea it's a sensible default

[vorburger]

Merged. FTR: I've not really tested if, how and where one can customize that new EXPOSE_PORT.

[vorburger]

FTR: It's not actually customizable; for now, EXPOSE_PORT got removed again due to #206.

[vorburger]

FTR: It's not actually customizable; for now, EXPOSE_PORT got removed again due to #206.

strike that, I reverted that, so EXPOSE_PORT is back; see full story in #206.

[brian316]

How is this still an issue in 2022. What if the application defaults to a different port like for mysql server? or javascript frameworks? I have to manually update the services target port for it to work but it doesnt let you in the command line...