Problem with using jib maven plugin offline for building docker container

Question

I'm following Spring Boot Docker Tutorial from here.

I got the exact result while having an internet connection. Now I need to produce the same result in an environment without an internet connection. I copied maven repositories and docker image into the new environment. I'm quite sure maven and docker is up and running.

When I tried to run following command com.google.cloud.tools:jib-maven-plugin:dockerBuild -Dimage=eureka I'm getting error messages. I guess there are some files plugin cannot locate but not sure which ones.

I'm adding the error message

[INFO] Scanning for projects...
[INFO]
[INFO] ---------------------------< com.ays:eureka >---------------------------
[INFO] Building eureka 0.0.1-SNAPSHOT
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- jib-maven-plugin:2.1.0:dockerBuild (default-cli) @ eureka ---
[INFO]
[INFO] Containerizing application to Docker daemon as eureka...
[WARNING] Base image 'gcr.io/distroless/java:8' does not use a specific image digest - build may not be reproducible
[ERROR] I/O error for image [gcr.io/distroless/java]:
[ERROR]     org.apache.http.conn.ConnectTimeoutException
[ERROR]     Connect to gcr.io:443 [gcr.io/64.233.184.82] failed: connect timed out
[INFO] Executing tasks:
[INFO] [============                  ] 40,0% complete
[INFO] > building image to Docker daemon
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  22.409 s
[INFO] Finished at: 2020-04-13T16:37:23+03:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal com.google.cloud.tools:jib-maven-plugin:2.1.0:dockerBuild (default-cli) on project eureka: Connect to gcr.io:443 [gcr.io/64.233.184.82] failed: connect timed out -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException 

Can somebody point me where should I look or is there anything I'm missing at this point?

Here is my DockerFile

FROM openjdk:8-jdk-alpine
RUN addgroup -S spring && adduser -S spring -G spring
USER spring:spring
ARG DEPENDENCY=target/dependency
COPY ${DEPENDENCY}/BOOT-INF/lib /app/lib
COPY ${DEPENDENCY}/META-INF /app/META-INF
COPY ${DEPENDENCY}/BOOT-INF/classes /app
ENTRYPOINT ["java","-cp","app:app/lib/*","hello.Application"]`

I didn't change anything in DockerFile.

Unexpressed

Answer 1

If you do not specify a base image, Jib 3.0+ by default uses adoptopenjdk:8-jre as a base image for Java 8 apps. (Prior to 3.0, Jib used gcr.io/distroless/java:8 as the default.)

When you are not using a specific image digest (such as gcr.io/distroless/java@sha256:...) but instead use a tag (:8 in your case with Jib < 3.0) for a base image, the tag can point to different images over time. That is, if you build an image sometime later on a different machine, Jib may pick up a slightly different base image than you used before. Hence the following warning:

[WARNING] Base image 'gcr.io/distroless/java:8' does not use a specific image digest - build may not be reproducible

For this reason, when you are not using a digest, Jib reaches out to the registry (gcr.io) and checks if the locally cached image (not in the local Docker engine cache but Jib's own cache) is up to date. If not, Jib will download the updated image. This is why you are getting the error when you're offline.

You have two options.

1. Pass --offline to Maven on the command-line. Then, Jib will use the cached base image; there will be no online connection. Of course, for this to work, Jib should have cached the base image before; you need to run Jib at least once online beforehand.

2. Use a digest to pin down a specific base image. For example, in your pom.xml,

   <configuration>
     <from><image>adoptopenjdk@sha256:9cb8bc7356ec2d9de56f3be3d8204a846ca0a3220af059aa67c35d53c7138e17</image></from>
   </configuration>
   

   If you prefer, you can specify both tag and digest. However, the tag will have no effect and only serve as a comment in this case.

   <from><image>adoptopenjdk:8-jre@sha256:9cb8bc7356ec2d9de56f3be3d8204a846ca0a3220af059aa67c35d53c7138e17</image></from>
   

   To find out which digest to use, check the adoptopenjdk Docker Hub repository. Another way is to run Jib once online. After the warning, you will see a message reporting the current digest for the tag.

   [WARNING] Base image 'adoptopenjdk:8-jre' does not use a specific image digest - build may not be reproducible
   [INFO] Using base image with digest: sha256:9cb8bc7356ec2d9de56f3be3d8204a846ca0a3220af059aa67c35d53c7138e17
   

Another option when you're running a local Docker daemon is to make Jib use an image from the daemon by prefixing docker:// to the base image (for example, <image>docker://openjdk:11-jre-slim</image>). However, depending on circumstances, this can be a little bit slower than using a remote base image (but probably not so much even in that case).

---

Lastly, you can delete your Dockerfile. Jib does not use Dockerfile, Docker CLI, or Docker daemon.

Weise

I'm accepting your answer since my question is where should I look for error. I'll also edit my comment when I tried your suggested options. – Unexpressed

You can delete your Dockerfile. Jib does not use Dockerfile, Docker CLI, or Docker daemon. – Weise

im not able to modify pipeline command, so is there a way to config --offline on pom? if is possible offline only for jib plugin – Pythagorean

@Pythagorean you can set offline in settings.xml. That is the only way I am aware of. baeldung.com/maven-offline – Weise

Can I somehow globally set docker:// for all jib image pulls? – Reunion

@Reunion unfortunately, there's no way to do that. – Weise