I have a mavenized springboot application which I successfully dockerized by using GoogleContainerTools jib. But it fails to properly connect when I type the address of http://localhost:8080
into browser on the host.
Section in maven build
...
<plugin>
<groupId>com.google.cloud.tools</groupId>
<artifactId>jib-maven-plugin</artifactId>
<version>${jib-maven-plugin.version}</version>
<configuration>
<to>
<image>springboot-test</image>
</to>
<container>
<ports>
<port>8080</port>
</ports>
<environment>
<spring.datasource.url>jdbc:postgresql://172.17.0.1:5432/postgres</spring.datasource.url>
<spring.mongo.url>mongodb://172.17.0.1:27017/mongo</spring.mongo.url>
</environment>
<creationTime>USE_CURRENT_TIMESTAMP</creationTime>
<format>OCI</format>
</container>
</configuration>
</plugin>
...
I run the setup by maven clean compile jib:dockerBuild -f pom.xml
.
I do have a postgres database and mongodb connected to other containers as well, which properly starts up as the log tells.
The image build properly and runs as container as the log on Docker Desktop do claim.
When inspecting the container in my Docker Desktop it says on Port section that the port 8080/tcp
is Not bound
. Accessing on the host system in the browser http://localhost:8080
does not reach anything.
When reading deeper into port exposure there is differences between publish
and expose
. So far I got publish
is for the exposure to the host and expose
handles port access among different containers.
For example, I cannot really understand how to granularly setup this difference like having the containerized webapp (springboot-web) running on port 8080 and publish it to port 80 on the host system.
What am I missing?
(I am running everything on a Macbook with a Java 17 setup)
Your maven command builds the container, not runs it.
You still need to explicitly map the ports, whether or not they are exposed/published in the build definition of the Docker image
docker run -p 8080:8080 image
Also, you shouldn't use IP addresses for other services in a Docker network, nor should you hard-code them as default environment variables