devon4j icon indicating copy to clipboard operation
devon4j copied to clipboard

Use Jib as maven plugin to simplify the docker image building

Open sujith-mn opened this issue 4 years ago • 15 comments

As a developer, I want use Jib so that the containerization will be easier.

sujith-mn avatar Apr 27 '20 09:04 sujith-mn

Thanks for the suggestion. I assume you mean this: https://github.com/GoogleContainerTools/jib

We will consider this as it seems very valuable for devon4j / java projects. What is the expectation?

  • Integrate/preconfigure it in devon4j archetype (devon4j-template-server)
  • Add a guide with documentation how to use it?

For the best-practices:

  • Should projects have a separate module container to build the image with jib? As a profile that can be disabled?
  • Or should the server module build a container instead of a WAR/JAR as final artifact?

hohwille avatar May 29 '20 10:05 hohwille

Was voted as a quickwin in DA meeting, so presumably on the roadmap for next release...

hohwille avatar May 29 '20 10:05 hohwille

I think we should make it as part of the server module within a profile. This can be easily understood and does not need to introduce another module. Even the server module is a module where people tend to ask were is it for?

maybeec avatar May 29 '20 13:05 maybeec

We figured out that spring-boot-maven-plugin has been extended to support building docker images (OCI): https://docs.spring.io/spring-boot/docs/2.3.0.RELEASE/maven-plugin/reference/html/#build-image

This is already available in the spring-boot release we are using so it is not blocked by #311

hohwille avatar Nov 17 '20 09:11 hohwille

@hohwille, if I get that right, we should not invest any further into that as it will be already provided right? Simply needs to be documented once. @sujith-mn please take care that we don't do duplicate work here.

maybeec avatar Nov 18 '20 08:11 maybeec

@maybeec the development and testing of the JIB is done already, IMHO we should go with it now as we do not have time to try spring boot for this release..

sujith-mn avatar Nov 18 '20 10:11 sujith-mn

As we meanwhile have spring-boot 2.4.0 in devon4j we should revisit their container build feature.

hohwille avatar Jan 21 '21 14:01 hohwille

Jib has a great feature where we can use it without docker being installed, as long as you store the Container Image on an external Container Registry (like DockerHub or the Google Cloud Container Registry)

sujith-mn avatar Mar 01 '21 11:03 sujith-mn

It does not need to be a public repository https://dzone.com/articles/how-to-publish-docker-images-on-private-nexus-repo-1

maybeec avatar Mar 01 '21 17:03 maybeec

Moving conversation to this issue:

The jib configuration which we discussed last time is not working as expected The below configuration added in the core :

     <profile>
      <id>container</id>
      <activation>
        <activeByDefault>true</activeByDefault>
      </activation>
      <build>
        <plugins>
          <plugin>
            <groupId>com.google.cloud.tools</groupId>
            <artifactId>jib-maven-plugin</artifactId>
            <version>${​​​​​​​jib.version}​​​​​​​</version>
            <configuration>
            <from>
              <image>${​​​​​​​jib.container.image}​​​​​​​</image>
            </from>
            <to>
              <image>${​​​​​​​project.name}​​​​​​​/java:${​​​​​​​project.version}​​​​​​​</image>
            </to>
            <container>
              <mainClass>com.devonfw.application.testapp.SpringBootApp</mainClass>
              <ports>
                <port>${​​​​​​​jib.app.port}​​​​​​​</port>
              </ports>
              <format>OCI</format>
            </container>
          </configuration>
            <executions>
              <execution>
                <phase>${​​​​​​​jib.phase}​​​​​​​</phase>
                <goals>
                  <goal>${​​​​​​​jib.goal}​​​​​​​</goal>
                </goals>
              </execution>
            </executions>
          </plugin>
        </plugins>
      </build>
    </profile>

the below configuration is in the parent

​ <plugin>
          <groupId>com.google.cloud.tools</groupId>
          <artifactId>jib-maven-plugin</artifactId>
          <version>${​​​​​​​jib.version}​​​​​​​</version>
        </plugin>
      </plugins>
    </pluginManagement>
  </build>
  <profiles>
    <profile>
      <id>release</id>
      <properties>
        <jib.goal>dockerBuild</jib.goal>
        <jib.phase>install</jib.phase>
      </properties>
    </profile>

it is creating the tar file but not running.. it is not considering the core configuration.. the filename is appearing as "jib-image.jar" this is the default name Ideally it should consider below name from the configuration: ​

<to>
<image>${​​​​​​​​project.name}​​​​​​​​/java:${​​​​​​​​project.version}​​​​​​​​</image>
</to>

​> Here is a multi-module example from google:

https://github.com/GoogleContainerTools/jib/tree/master/examples/multi-module

hohwille avatar Mar 16 '21 08:03 hohwille

The regular mvn compile should trigger buildTar as we concluded. This should be in a profile that is active by default. As you sayed earlier this goal will work without docker being installed.

it is creating the tar file but not running.

Can you explain this? What did you do with the tar and what error did you get? Or are you just saying that the name jib-image.jar is used what you consider as an error?

The actual install should then install/deploy the image to the container registry. If this is not working by default, it should happen in a profile that needs to be triggered manually.

hohwille avatar Mar 16 '21 08:03 hohwille

it is working with the multimodule configuration link which is shared.

Only the parent pom will have the JIB configuration, other modules does not need a configuration unless it is not to be containerized.

Skip configuration is needed for the module which does not require any containerization,

sujith-mn avatar Mar 16 '21 08:03 sujith-mn

The regular mvn compile should trigger buildTar as we concluded. This should be in a profile that is active by default. As you sayed earlier this goal will work without docker being installed.

it is creating the tar file but not running.

Can you explain this? What did you do with the tar and what error did you get?

Tar file created without docker demon. But the generated file is not getting loaded to my local docker demon.

image

Looks like the tar file did not get generated properly, could be a plugin configuration issue.

Or are you just saying that the name jib-image.jar is used what you consider as an error?

The file name is always jib-image.tar, there is no issue in that. I have pointed out this wrongly by thinking tar file should get the name of module.

Also getting the below error while using the compile build goal with the help of docker demon.

Caused by: java.lang.NoClassDefFoundError: javax/servlet/Filter
        at java.base/java.lang.Class.getDeclaredMethods0(Native Method) ~[na:na]

sujith-mn avatar Mar 16 '21 14:03 sujith-mn

So if buildTar is not working or creating an image as result that is not working, it does not seem to be our solution.

Do I get this right that you are proposing to add jib to parent POM and add skip to every module that is not to build a container (api and server)? Will that work? Have you tested this?

Actually to be honest, I have the feeling that we are missing the solid principle here (https://github.com/devonfw/devon4j/blob/develop/documentation/architecture.asciidoc#key-principles). We might end up with a somehow working solution that rushes into the release but the first project that wants to use this in a real-life scenario might suffer... However, just a gut feeling. It would be better to have a project first that verifies the approach before shipping this as new release feature...

hohwille avatar Mar 16 '21 20:03 hohwille

It is seems there is some issues with OCI format and tar file building. once the configuration <format> OCI </format> removed, the no such file or directory issue is NOT appearing. But while running the image, servlet/filter dependency issue is still there.

IMHO, configure the plugin on parent pom and skip the unwanted modules is the working approach. This has been tested and working fine.

sujith-mn avatar Apr 05 '21 04:04 sujith-mn