devon4j
devon4j copied to clipboard
Use Jib as maven plugin to simplify the docker image building
As a developer, I want use Jib so that the containerization will be easier.
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?
Was voted as a quickwin in DA meeting, so presumably on the roadmap for next release...
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?
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, 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 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..
As we meanwhile have spring-boot 2.4.0 in devon4j we should revisit their container build feature.
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)
It does not need to be a public repository https://dzone.com/articles/how-to-publish-docker-images-on-private-nexus-repo-1
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
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.
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,
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.
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]
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...
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.