"Extending" Dockerfile to modify a file, caused sonarqube to fail - docker

Question

I am attempting to use Sonarqube with CloudRun, and for that I need to support the use of an environment variable PORT when starting the docker image. So I tried to "extend" my Dockerfile like:
FROM sonarqube:7.9-community
WORKDIR $SONARQUBE_HOME
COPY sonar.properties $SONARQUBE_HOME
COPY run.sh ./bin/
EXPOSE 8080
ENTRYPOINT ["./bin/run.sh"]
I modified sonar.properties to include a line like:
sonar.web.port=__PORT__
Then I modify run.sh with the line:
sed "s/__PORT__/$PORT/g" ./sonar.properties > conf/sonar.properties
And tried starting the server like:
docker run -e PORT=8080 sonarqube-custom
The logs shows nothing wrong ...
2019.11.15 02:55:04 INFO web[][o.s.s.q.ProjectsInWarningDaemon] Counting number of projects in warning is enabled.
2019.11.15 02:55:04 INFO web[][o.s.s.p.p.PlatformLevelStartup] Running Community Edition
2019.11.15 02:55:04 INFO web[][o.s.s.p.Platform] WebServer is operational
2019.11.15 02:55:04 INFO app[][o.s.a.SchedulerImpl] Process[web] is up
2019.11.15 02:55:04 INFO app[][o.s.a.ProcessLauncherImpl] Launch process[[key='ce', ipcIndex=3, logFilenamePrefix=ce]] from [/opt/sonarqube]: /usr/local/openjdk-11/bin/java -Djava.awt.headless=true -Dfile.encoding=UTF-8 -Djava.io.tmpdir=/opt/sonarqube/temp --add-opens=java.base/java.util=ALL-UNNAMED -Xmx512m -Xms128m -XX:+HeapDumpOnOutOfMemoryError -Dhttp.nonProxyHosts=localhost|127.*|[::1] -cp ./lib/common/*:/opt/sonarqube/lib/jdbc/h2/h2-1.3.176.jar org.sonar.ce.app.CeServer /opt/sonarqube/temp/sq-process3988720795271274831properties
2019.11.15 02:55:04 INFO web[][o.s.s.q.ProjectsInWarningDaemon] Counting number of projects in warning will be disabled as there are no more projects in warning.
2019.11.15 02:55:05 INFO ce[][o.s.p.ProcessEntryPoint] Starting ce
2019.11.15 02:55:05 INFO ce[][o.s.ce.app.CeServer] Compute Engine starting up...
2019.11.15 02:55:06 INFO ce[][o.e.p.PluginsService] no modules loaded
2019.11.15 02:55:06 INFO ce[][o.e.p.PluginsService] loaded plugin [org.elasticsearch.join.ParentJoinPlugin]
2019.11.15 02:55:06 INFO ce[][o.e.p.PluginsService] loaded plugin [org.elasticsearch.percolator.PercolatorPlugin]
2019.11.15 02:55:06 INFO ce[][o.e.p.PluginsService] loaded plugin [org.elasticsearch.transport.Netty4Plugin]
2019.11.15 02:55:07 INFO ce[][o.s.s.e.EsClientProvider] Connected to local Elasticsearch: [127.0.0.1:9001]
2019.11.15 02:55:07 INFO ce[][o.sonar.db.Database] Create JDBC data source for jdbc:h2:tcp://127.0.0.1:9092/sonar
2019.11.15 02:55:07 WARN ce[][o.s.db.dialect.H2] H2 database should be used for evaluation purpose only.
2019.11.15 02:55:08 INFO ce[][o.s.s.p.ServerFileSystemImpl] SonarQube home: /opt/sonarqube
2019.11.15 02:55:08 INFO ce[][o.s.c.c.CePluginRepository] Load plugins
2019.11.15 02:55:10 INFO ce[][o.s.c.c.ComputeEngineContainerImpl] Running Community edition
2019.11.15 02:55:10 INFO ce[][o.s.ce.app.CeServer] Compute Engine is operational
2019.11.15 02:55:10 INFO app[][o.s.a.SchedulerImpl] Process[ce] is up
2019.11.15 02:55:10 INFO app[][o.s.a.SchedulerImpl] SonarQube is up
But when I try to access the URL localhost:8080 it fails

Answer 1

If you start your container as docker run -e PORT=8080 sonarqube-custom you're not going to be able to contact anything on localhost:8080 because you haven't published any ports (using e.g. the -p option to docker run).
It's important to note that you probably don't need to modify the sonarqube configuration at all: you could just docker run -p 8080:9000 ... to expose the service on port 8080 on your host, despite it running on port 9000 inside the container.

Answer 2

You need to understand the difference between expose flag(-e) and publish flag(-p). Imagine your container like a computer and your docker stack (The collection of services) like a network. You have a computer firewall and a network firewall in place.
The computer firewall opens the port to allow ingress traffic when you expose your port. So, as long as the port is not exposed, the service listening on the port is only accessible from inside the container (or computer in our reference). This configuration is helpful for cases where you want your service to be accessible from inside the network only. For example, a database that interacts with the business-logic layer but, should not be exposed to the open internet. When it is exposed, the traffic from other containers of the same stack (or other computers on the same network) can access the service but, it cannot be accessed from other networks as the network firewall doesn't allow any ingress traffic.
This is where port publish comes in. When you expose and publish your port, the service listening on the network can now be accessed not only from containers other services in the stack (other computers in the network) but also from outside the network. This configuration is good for services with which the users interact. For example, the user-interface layer of your applications.