ARTEMIS-3042 Add docker multistage build

[SamTV12345]

Added multistage docker image build

This adds the possibility to create an artemis image with just the command:

docker build -f Docker-alpine -t artemis_alpine .

Furthermore it has the smallest attack surface compared to the other images as it is based on alpine and only contains the jre, bash and libaio for running the application.

When releasing a new version simply adjust the arg value at the top and run above command to build a more recent version.

[jbertram]

How is this related to https://issues.apache.org/jira/browse/ARTEMIS-4045 (i.e. the Jira referenced in the PR title)?

[SamTV12345]

Sorry my bad. Didn't get that the number refers to a jira ticket.

[jbertram]

Is this related to https://issues.apache.org/jira/browse/ARTEMIS-3042? The PR's title seems to correspond. If it is related please include the Jira in the commit message. If not, please create a Jira for this change and include it in the commit message. You can read more details about how to format commit messages in the hacking guide.

[SamTV12345]

Thanks for the hint. I added a message according to your guidelines. This pr solves exactly that issue.

[SamTV12345]

If there are any further questions I am more than welcome to answer them.

[jbertram]

It's not clear to me how your changes are directly related to https://issues.apache.org/jira/browse/ARTEMIS-3042 aside from just the wording. Your commit is just adding a new Dockerfile which is similar to the three other Dockerfiles which are already present. These three Dockerfiles were also already present when ARTEMIS-3042 was opened originally. The Jira description even says, "The current docker image build is not really user friendly or convenient at all." Therefore, adding another version of what already exists doesn't seem to help resolve the issue. Can you shed any light on this?

[jbertram]

To be clear, I am happy to merge your commit eventually. I just want the Jira/commit association to be clear for posterity's sake.

[SamTV12345]

It's not clear to me how your changes are directly related to https://issues.apache.org/jira/browse/ARTEMIS-3042 aside from just the wording. Your commit is just adding a new Dockerfile which is similar to the three other Dockerfiles which are already present. These three Dockerfiles were also already present when ARTEMIS-3042 was opened originally. The Jira description even says, "The current docker image build is not really user friendly or convenient at all." Therefore, adding another version of what already exists doesn't seem to help resolve the issue. Can you shed any light on this?

A docker multistage build contains one or multiple steps of building an image and one final image that is used during runtime. A multistage build has the advantage that some components are only needed during build time leading to a smaller footprint. It also has the charm that I don't need to know anything about building this image. Everything is handled during build process.

Before my pr you had to follow the guides, run the script, cd into the _TMP/artemis/version folder and start the build process. This can be teadious and result in user errors: At first I forgot to change to that directory I had to read through the proprietary instructions to this project.

Now you can start directly with building. Just use the Dockerfile as you would with any other Dockerfile and execute docker build -t myartemis -f Dockerfile-alpine . You don't need to go through any instructions and have a standardized process of building images.

If you agree I would remove the other Dockerfiles as they are not needed anymore and may confuse the end user.

[SamTV12345]

The other two files are solved. Seems Windows/IntelliJ doesn't add a newline to the file.

[SamTV12345]

Seems like the failing test is not the cause of my commit. The other pr is also failing.

[SamTV12345]

When will this be merged? Is there something to do from my side?

[jbertram]

At this point two main things are not clear in your commit:

1. How to use your new Docker file.
2. How your new Docker file fits with the other Docker files already available.

To resolve # 1 you should probably just add some documentation. You could do this, for example, in the artemis-docker/readme.md.

To resolve # 2 you might also just add documentation. However, if the approach you've taken in this new Docker file is superior to the approach offered by the existing Docker files then it may be worth updating those to use your new approach so that users don't need to run prepare-docker.sh manually but they still have the option of using CentOS & Ubuntu with JDK or JRE.

[SamTV12345]

I'm done. I adapted the README.md to reflect the changes in the build process and added the multistage capability to every Dockerfile.

[SamTV12345]

I guess this pr can be merged.

[jbertram]

I'm still in the process of testing all the changes locally. I have other priorities on my plate at the moment so progress has stopped at the moment.

@SamTV12345, is there any particular rush to get this merged? If so, how come?

[jbertram]

@clebertsuconic, can you take a look at this as well since I believe you originally created the Docker files.

[SamTV12345]

Thanks for reporting back. I'd like to get this pr merged as soon as possible so I can move on to the next ticket. I guess it doesn't make much sense that I create a lot of pr's that don't get merged at the end. But I can understand that you have other priorities. I'll wait till I hear back from you.

[jbertram]

I'd like to get this pr merged as soon as possible so I can move on to the next ticket.

Is this PR a dependency for another task you're working on?

I think most folks work on tasks in parallel. Once they send a PR they move on to their next task knowing that the PR will be reviewed and merged asynchronously.

I guess it doesn't make much sense that I create a lot of pr's that don't get merged at the end.

Have you created other PRs that haven't been merged? I looked through the list of open and closed PRs and I don't see any others from you. Perhaps you used a different account when you created those?

[clebertsuconic]

This looks nice, although I was not able to build the distribution I am building itself. and I'm a bit confused on how I am supposed to use this.

I just built it. Went to artemis-distribution/target/apache-artemis-2.28.0-SNAPSHOT-bin/apache-artemis-2.28.0-SNAPSHOT

and typed:

podman build -f ../../../../artemis-docker/Dockerfile-alpine -t clebert-alpine .

I was not able to build it. got an error

If I removed the . I would always build a 2.17 image

I'm puzzled on how I'm supposed to use your change.

I will defer this PR to next version (that shouldn't be long)

[SamTV12345]

This error seems to be correct. I currently download the jar from the apache downloads and copy it into the alpine/centos/ubuntu image. But if you use it for development I have two options:

1. Create a new Dockerfile for building the image.
2. Modify the existing Dockerfile.

Which one do you prefer?

I would appreciate if you could post the commands to build the project. I took a look at the hacking doc but couldn't really understand on how to build and run the server.

[jbertram]

@SamTV12345, FWIW instructions on how to build are in the "Building" chapter of the Hacking Guide:

To build the full release with documentation, Javadocs, and the full web site:

$ mvn -Prelease package

To install it to your local maven repo:

$ mvn -Prelease install

I would add -DskipTests to speed up the build significantly.

[SamTV12345]

When I do a build I get this error: io.netty:netty-tcnative:jar:${os.detected.classifier}:2.0.54.Final . @jbertram Do you know where that comes from and are there more of these properties?

[jbertram]

@SamTV12345, I'm not sure where that's coming from. Searching the code-base for os.detected.classifier turns up 0 results. What exact command did you execute and what branch are you on? Also, what's the full error message?

[SamTV12345]

I executed mvn dependency:resolve-plugins dependency:go-offline on my branch to cache dependencies.

[jbertram]

I reproduced the error by executing mvn dependency:go-offline. It's not clear to me whether the problem is in the ActiveMQ Artemis pom.xml or in one of Netty's. What happens if you just run mvn -Prelease install -DskipTests?

[SamTV12345]

That should work without a problem. But you need to be aware that this will always download every dependency when you make a change in any file of the project.

[jbertram]

Looks like this can be fixed by adding this to the <build> of the main pom.xml:

      <extensions>
         <!-- Generate os.detected.classifier property -->
         <extension>
            <groupId>kr.motd.maven</groupId>
            <artifactId>os-maven-plugin</artifactId>
            <version>1.7.1</version>
         </extension>
      </extensions>

[jbertram]

I rarely (if ever) use Maven's offline mode as downloading dependencies isn't a problem for me, but I sent #4355 to support those who need it. Hope that helps!

[SamTV12345]

Thanks for creating the pr. I will checkout your commit hopefully this week. It seems like the release profile really takes a long time. 4GB weren't enough for testing. So the question is how many times would somebody do that when it takes more than 10 minutes to compile.

[jbertram]

Those numbers seem excessive to me. When I eliminate the time required to download artifacts by first using mvn dependency:go-offline and then run:

mvn -o clean install -Prelease -DskipTests

It finishes in half the time you're reporting:

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  05:18 min
[INFO] Finished at: 2023-01-31T17:32:56-06:00
[INFO] ------------------------------------------------------------------------

Also the maximum heap usage is barely over 2G: I'm running this on a laptop that's not particularly fancy.

For what it's worth, I probably build a release several times a day on average.