#250: Jib maven plugin added to make the containerization easier. #317

sujith-mn · 2020-12-03T08:22:28Z

Implements issue #250

hohwille

github review has some UX problem: I did this review already but was interrupted and never submitted the final result. As it seems until then all my review comments remain invisble for others. Sorry, we are short on time and I wasted some more...

hohwille · 2020-12-03T15:15:49Z

templates/server/src/main/resources/archetype-resources/pom.xml

+    <profile>
+      <id>docker</id>
+      <build>
+        <plugins>
+          <plugin>
+            <groupId>com.google.cloud.tools</groupId>
+            <artifactId>jib-maven-plugin</artifactId>
+            <version>2.6.0</version>
+            <configuration>
+              <from>
+                <image>adoptopenjdk/openjdk11:jre-11.0.4_11-alpine</image>
+              </from>
+              <to>
+                <image>${project.name}/java:${project.version}</image>
+              </to>
+              <container>
+                <mainClass>com.devonfw.application.mtsj.SpringBootApp</mainClass>
+                <ports>
+                  <port>8081</port>
+                </ports>
+                <format>OCI</format>
+              </container>
+            </configuration>
+            <executions>
+              <execution>
+                <phase>package</phase>
+                <goals>
+                  <goal>dockerBuild</goal>
+                </goals>
+              </execution>
+            </executions>
+          </plugin>
+        </plugins>
+      </build>
+    </profile>


shouldnt we put this into the server module?
This is the only place where it makes sense to build a container from...

Configured the server pom and tested, there is no image created and no error also.
With the parent pom, there are three images getting created for api, core and server. configured api and server pom to skip image creation.
Image created successfully with core and able to run the container..

actually neither api nor core should build the docker image but only server. The docker image must not only build but it also should work (run the application). This can only work for the bootified artifact what is only available in server.
I can not support this right now but I guess we have some missunderstanding or lack of maven detailed insights knowledge here. Maybe we move this to the next release, even though it is almost complete...

The image is tested and the application worked. Forgot to mention it in the previous comment. Anyway let's have a detail study and plan for next release.

hohwille

@sujith-mn Could you please catch up again on this PR? It also needs to be merged with master.
If you want, you can also reach out and have a call with me to discuss...

hohwille · 2021-01-29T10:52:11Z

templates/server/src/main/resources/archetype-resources/api/pom.xml

+        <artifactId>jib-maven-plugin</artifactId>
+        <configuration>
+          <!-- we don't want jib to execute on this module -->
+          <skip>true</skip>


That is what I wrote in my review comment. It is not so good to add it to then parent pom and then having the need to disable (skip) it in all other modules. Please therefore move the plugin only to the server module that provides the deliverable of the entire app by design.

JIB plugin configured in server/pom.xml

Devon mvn clean package – builds the image successfully.

docker run --publish 8081:8081 not running, no error message also.

Alternatively tried different way to build:

mvn compile jib:build – build is failing, jib plugin is not found. the plugin is configured in the server-pom.

hohwille · 2021-01-29T10:54:18Z

templates/server/src/main/resources/archetype-resources/pom.xml

+              <licenseMerge>Apache Software License, Version 2.0|The Apache Software License, Version 2.0|Apache
+                2.0|Apache License, Version 2.0</licenseMerge>


It is great that you now format all the code.
Sorry, to still bother you...
But is our XML formatter in devonfw IDE missconfigured? Auto-wrapping in XML can cause damage. Are we sure this change will not break anything as maybe then Apache 2.0 will not match anymore (as a newline is now expected).

hohwille · 2021-01-29T10:55:59Z

templates/server/src/main/resources/archetype-resources/pom.xml

+                <image>${project.name}/java:${project.version}</image>
+              </to>
+              <container>
+                <mainClass>com.devonfw.application.mtsj.SpringBootApp</mainClass>


This is wrong as this is the Classname of the My-Thai-Star application. However, this is the template to create a new application for a project that will reside in a different package. See spring-boot plugin where the same is already configured. For all these things you should consider using variables to avoid redundancies.

hohwille · 2021-01-29T10:56:41Z

templates/server/src/main/resources/archetype-resources/pom.xml

+          <plugin>
+            <groupId>com.google.cloud.tools</groupId>
+            <artifactId>jib-maven-plugin</artifactId>
+            <version>2.6.0</version>


we should always use variables for such versions. This is the only way for us to make devon java migrate being able to properly update such things.

hohwille · 2021-01-29T10:57:33Z

templates/server/src/main/resources/archetype-resources/pom.xml

+            <version>2.6.0</version>
+            <configuration>
+              <from>
+                <image>adoptopenjdk/openjdk11:jre-11.0.4_11-alpine</image>


this is IMHO also like a dependency with a version. We need to keep this up-to-date and have our eyes on it to close CVEs in the future. Please also use a variable in toplevel pom of the archetype.

hohwille · 2021-01-29T10:59:15Z

templates/server/src/main/resources/archetype-resources/pom.xml

+              <container>
+                <mainClass>com.devonfw.application.mtsj.SpringBootApp</mainClass>
+                <ports>
+                  <port>8081</port>


Please also use a variable here. We wont need to change this in devon java migrate in the future but if you use a variable this allows to tweak it easily on the commandline (mvn package -Dapp.container.port=8088) giving more flexibility if needed.

hohwille · 2021-01-29T10:59:54Z

templates/server/src/main/resources/archetype-resources/pom.xml

+                <ports>
+                  <port>8081</port>
+                </ports>
+                <format>OCI</format>


I assume there are not many other reasonable options here so we can leave this "hardcoded".

JIB uses exploded deployment to build docker, packaged deployment is not yet support with WAR creation. Thus configuring in the server module may not work as expected.
The other option is to keep the exploded classes from the server module to tomcat container (eg: tomcat:8.5-jre8-alpine).

As Jorge suggested, the regular deployment to external servlet container is discouraged by devon4j. With this configuration we may loose several features of spring boot.

So planning to keep the current JIB configuration.

hohwille

@sujith-mn Thanks for the rework. Looking quite good now 👍
Remaining questions:

how could one provide JVM parameters for the container?
how could one provide a customized application.properties for the container?

@maybeec and @maihacke any concerns or feedback (jib bs. spring-boot approach)?

maybeec · 2021-03-05T09:26:52Z

In my opinion, both questions which you raised Jörg could even be ignored.
You can easily inject / configure JVM properties by environment variables when starting the container.
Same for application.properties, which can be easily in JSON format injected or simply be mounted into the container by any cloud facilitator.

maihacke · 2021-03-05T10:17:16Z

In my opinion, both questions which you raised Jörg could even be ignored in my opinion.
You can easily inject / configure JVM properties by environment variables when starting the container.
Same for application.properties, which can be easily in JSON format injected or simply be mounted into the container by any cloud facilitator.

I think @maybeec is right, this a general problem which is solvable by spring-boot configs mechanism (overwrite with env params, use spring-cloud-config, ...). We should explain this in the devonfw docs and give hints what to use.
I'm a bit surprised why we specify the port in the build script. Is this the internal port of the app or some exposed port of the container?

sujith-mn · 2021-03-05T10:40:30Z

In my opinion, both questions which you raised Jörg could even be ignored in my opinion.
You can easily inject / configure JVM properties by environment variables when starting the container.
Same for application.properties, which can be easily in JSON format injected or simply be mounted into the container by any cloud facilitator.

I think @maybeec is right, this a general problem which is solvable by spring-boot configs mechanism (overwrite with env params, use spring-cloud-config, ...). We should explain this in the devonfw docs and give hints what to use.
I'm a bit surprised why we specify the port in the build script. Is this the internal port of the app or some exposed port of the container?

This is internal port of the app, that can be mapped while running the container.

hohwille · 2021-03-05T12:50:21Z

In my opinion, both questions which you raised Jörg could even be ignored.
You can easily inject / configure JVM properties by environment variables when starting the container.
Same for application.properties, which can be easily in JSON format injected or simply be mounted into the container by any cloud facilitator.

Fine. So we could add some hints on this to the documentation and are done.
For spring-boot I am convinced this will work. However, it is IMHO an anti-pattern to provide secrets as env variables. How would I safely pass passwords (encrypted) to spring-boot app?
What would be the variable honored by JIB for JVM options? JAVA_OPTS or something else?

Further we had this discussion about spring-boot-maven-plugin vs. jib.
I had been convinced for jib because I was told that it does not require a local docker to build the container. However, as now clarified this is wrong. So are there any further arguments on this choice or is the decision already done for jib and against spring-boot-maven-plugin?

hohwille · 2021-03-05T12:55:45Z

I had been convinced for jib because I was told that it does not require a local docker to build the container. However, as now clarified this is wrong.

https://spring.io/blog/2018/11/08/spring-boot-in-a-container#jib-maven-and-gradle-plugins

So it is possible. So what are our missunderstandings then @sujith-mn ? We could have the container build active by default then...

maybeec · 2021-03-06T07:50:05Z

@hohwille not sure what you mean. I cannot read from the link what you stated in the comment. It's written there as well.... You can bould without docker being installed

sujith-mn · 2021-03-08T05:07:05Z

Spring boot maven plugin requires docker demon.

https://docs.spring.io/spring-boot/docs/current/maven-plugin/reference/htmlsingle/#build-image

hohwille · 2021-03-08T09:38:36Z

@hohwille not sure what you mean. I cannot read from the link what you stated in the comment. It's written there as well.... You can bould without docker being installed

@sujith-mn told that the build is not working without docker being installed and hence the activation by default has been removed:

devon4j/templates/server/src/main/resources/archetype-resources/core/pom.xml

Line 245 in fdc44d3

<id>container</id>

This should be clarified:

Either the build works without docker being installed and the activation should be enabled by default
Or we should clarify why JIB is claimed to support this but in reality it is not working

sujith-mn · 2021-03-08T12:08:54Z

The JIB docker build can be done in 3 ways.

1. Build the image and run locally
Docker daemon required to be running locally.

mvn compile jib:build

2. Build the image and upload to the registery
Docker daemon is not required in this case. But the registery url and credentials should be configured in settings.xml or pom.xml

mvn compile jib:dockerBuild

3. Build the image as tarball
Docker daemon is not required.
This saves the image to target/app-image.tar

mvn compile jib:buildTar

https://github.com/GoogleContainerTools/jib/tree/master/jib-maven-plugin

hohwille · 2021-03-08T17:12:53Z

If 2. can build the image without docker, why can't it be build without deploying to a docker registry?
What would otherwise be the benefit of this feature of portability to build without local docker installation?
I am still confused.

maybeec · 2021-03-08T18:21:18Z

What you are addressing is simply buildTar (#3).
#2 is simply a comfort function to directly build and deploy your docker image.

sujith-mn · 2021-03-09T07:44:02Z

buildTar can build the tar ball and it can pushed to repository manually.
Image can be loaded to docker daemon using :

docker load --input target/jib-image.tar

hohwille · 2021-03-09T09:10:32Z

Already above I linked this:
https://docs.spring.io/spring-boot/docs/current/maven-plugin/reference/htmlsingle/#build-image
Citation:

Probably the most interesting thing is that you don’t need docker to run it - it builds the image using the same standard output as you get from docker build but doesn’t use docker unless you ask it to - so it works in environments where docker is not installed (not uncommon in build servers).

So is this a lie or not? Cant be so hard to clarify if this this true or not.

hohwille · 2021-03-11T08:25:28Z

Conclusion:

we have the container profile and in there we have the features for containerization with JIB
jib:buildTar runs in compile phase.
jib:dockerBuild should be in a separate execution in install phase.
documentation guide should be updated accordingly
as a separate story a katacoda tutorial shall be added

…ev_jib

sujith-mn requested a review from hohwille December 3, 2020 08:23

hohwille requested changes Dec 4, 2020

View reviewed changes

hohwille linked an issue Dec 10, 2020 that may be closed by this pull request

Use Jib as maven plugin to simplify the docker image building #250

Open

hohwille changed the title ~~Jib maven plugin added to make the containerization easier.~~ #250: Jib maven plugin added to make the containerization easier. Dec 10, 2020

hohwille changed the base branch from develop to master January 7, 2021 15:56

hohwille requested changes Jan 29, 2021

View reviewed changes

hohwille reviewed Mar 5, 2021

View reviewed changes

CORP\sujithna and others added 9 commits March 15, 2021 11:28

google jib added to create image using maven

8e2985b

google jib added to create image using maven

f4e58ea

variables added for the base image and version. prepared user guide.

d5b4e72

version upgraded

31e226a

fixing the format

f3d28b1

formatted

4ca1a2a

version upgraded

9ea62b1

formatted, added to batch

d03ff89

Updated guide

0f7f5a4

sujith-mn and others added 16 commits March 15, 2021 11:35

Update guide-jib.asciidoc

fad6f19

Update guide-jib.asciidoc

11fff2c

Update guide-jib.asciidoc

52e7f61

Update guide-jib.asciidoc

a3e5c6c

fixed indendation

bed4bf2

version upgraded

6c7dcd3

Update pom.xml

7c81de5

Merge branch 'master' into dev_jib

0327cc6

Merge branch 'master' into dev_jib

4be5ac6

Merge branch 'master' into dev_jib

8f561ae

Merge branch 'master' into dev_jib

912d38e

Merge branch 'master' into dev_jib

4eb6da0

Merge branch 'master' into dev_jib

3cca1de

Merge remote-tracking branch 'upstream/master' into dev_jib

07c5767

updated pom

d1eaad4

Merge branch 'dev_jib' of https://github.com/sujith-mn/devon4j into d…

e1ef0fb

…ev_jib

This pull request was closed.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

#250: Jib maven plugin added to make the containerization easier. #317

#250: Jib maven plugin added to make the containerization easier. #317

sujith-mn commented Dec 3, 2020 •

edited by hohwille

Loading

hohwille left a comment •

edited

Loading

hohwille Dec 3, 2020

sujith-mn Dec 7, 2020 •

edited

Loading

hohwille Dec 10, 2020 •

edited

Loading

sujith-mn Dec 11, 2020

hohwille left a comment

hohwille Jan 29, 2021

sujith-mn Feb 3, 2021 •

edited

Loading

sujith-mn Feb 3, 2021 •

edited

Loading

hohwille Jan 29, 2021

hohwille Jan 29, 2021

hohwille Jan 29, 2021

hohwille Jan 29, 2021

hohwille Jan 29, 2021

hohwille Jan 29, 2021

sujith-mn Feb 10, 2021

hohwille left a comment

maybeec commented Mar 5, 2021 •

edited

Loading

maihacke commented Mar 5, 2021 •

edited

Loading

sujith-mn commented Mar 5, 2021

hohwille commented Mar 5, 2021

hohwille commented Mar 5, 2021

maybeec commented Mar 6, 2021

sujith-mn commented Mar 8, 2021 •

edited

Loading

hohwille commented Mar 8, 2021

sujith-mn commented Mar 8, 2021 •

edited

Loading

hohwille commented Mar 8, 2021

maybeec commented Mar 8, 2021 •

edited

Loading

sujith-mn commented Mar 9, 2021

hohwille commented Mar 9, 2021

hohwille commented Mar 11, 2021 •

edited

Loading

		<licenseMerge>Apache Software License, Version 2.0\|The Apache Software License, Version 2.0\|Apache
		2.0\|Apache License, Version 2.0</licenseMerge>

#250: Jib maven plugin added to make the containerization easier. #317

#250: Jib maven plugin added to make the containerization easier. #317

Conversation

sujith-mn commented Dec 3, 2020 • edited by hohwille Loading

hohwille left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sujith-mn Dec 7, 2020 • edited Loading

Choose a reason for hiding this comment

hohwille Dec 10, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hohwille left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sujith-mn Feb 3, 2021 • edited Loading

Choose a reason for hiding this comment

sujith-mn Feb 3, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hohwille left a comment

Choose a reason for hiding this comment

maybeec commented Mar 5, 2021 • edited Loading

maihacke commented Mar 5, 2021 • edited Loading

sujith-mn commented Mar 5, 2021

hohwille commented Mar 5, 2021

hohwille commented Mar 5, 2021

maybeec commented Mar 6, 2021

sujith-mn commented Mar 8, 2021 • edited Loading

hohwille commented Mar 8, 2021

sujith-mn commented Mar 8, 2021 • edited Loading

hohwille commented Mar 8, 2021

maybeec commented Mar 8, 2021 • edited Loading

sujith-mn commented Mar 9, 2021

hohwille commented Mar 9, 2021

hohwille commented Mar 11, 2021 • edited Loading

sujith-mn commented Dec 3, 2020 •

edited by hohwille

Loading

hohwille left a comment •

edited

Loading

sujith-mn Dec 7, 2020 •

edited

Loading

hohwille Dec 10, 2020 •

edited

Loading

sujith-mn Feb 3, 2021 •

edited

Loading

sujith-mn Feb 3, 2021 •

edited

Loading

maybeec commented Mar 5, 2021 •

edited

Loading

maihacke commented Mar 5, 2021 •

edited

Loading

sujith-mn commented Mar 8, 2021 •

edited

Loading

sujith-mn commented Mar 8, 2021 •

edited

Loading

maybeec commented Mar 8, 2021 •

edited

Loading

hohwille commented Mar 11, 2021 •

edited

Loading