Feature/m1 docker build support

[vordimous]

Description

The primary issue I found was the eclipse-temurin:20-alpine issue only shows support for the amd64 platform.

These changes are meant to improve the usability and cross-platform support for the zilla docker images.

The cross-platform changes are based on the maven plugin docs to add a property for the supported platforms. I replaced the alpine build image for the eclipse-temurin:20 based on ubuntu:jammy a more suited build environment. The build image doesn't need to be as lean and is best to match the build purpose. This made building on both platforms able to use the same dockerfile. It isn't an industry standard to require apline images for all stages when using multistage builds.

command when running a build on an M1 architecture:
./mvnw -DskipTests clean install -Ddocker.platforms=linux/arm64

I included some metadata I have seen to be best practice. For now, a maintainer label and version env var following the nginx image template. There are other recommended labels, but I didn't want to add too much.

The remaining challenge is when the alpine image copies the necessary binaries, they are not able to be found but the running container. I am not sure if it is an Ubuntu -> Alpine issue or a user ownership issue. If the base image for the app container is ubuntu:jammy, matching the build image, everything works as expected when both build and app images are alpine versions.

Fixes # (issue)

[attilakreiner]

The remaining challenge is when the alpine image copies the necessary binaries, they are not able to be found but the running container. I am not sure if it is an Ubuntu -> Alpine issue or a user ownership issue. If the base image for the app container is ubuntu:jammy, matching the build image, everything works as expected when both build and app images are alpine versions.

I tried this approach and reached the same conclusion, unfortunately it doesn't work this way; the zilla built with zpm on one distro can't be executed on the other. I don't have a deep enough understanding to give a detailed explanation, but I think it has to do with the fact that the files/libraries required to run java are laid out differently on Ubuntu vs Alpine (even when using the same java distro/version).

[vordimous]

example of multi OS build management: https://github.com/emqx/emqx-builder

[vordimous]

After looking into how other repos manage this, I believe the solution is to publish a multi-platform image as the base image tagged with the semver [x.x.x]. This would mean using the base images from this PR ubuntu:jammy as the default images.

Then users who want to use the alpine version, which eclipse-temurin:alpine is only linux/x86_64 compatible, could still use that build specifying the alpine suffix [x.x.x-alpine]. There are M1 alpine images but practically alpine is only needed on hosted servers which don't use arm so we can cross that bridge later if we want.

Implementing that would mean keeping both versions of docker files in this PR and specifying one as the default image and one as the alpine image. Then when building the default image, we would specify both platforms -Ddocker.platforms=linux/arm64,linux/x86_64, and when building the alpine version only the -Ddocker.platforms=linux/x86_64

@jfallows @attilakreiner what do you think?

[jfallows]

This may also help if we decide to perform release of different platform docker images via GitHub Actions workflows.

github/roadmap#528

[vordimous]

arm support for alpine discussion: adoptium/containers#158

[vordimous]

Attempted the suggested alternate image bellsoft/liberica-openjdk-alpine-musl:20 and ran into a module not found error: Module jdk.jdwp.agent not found

Looking at how adoptium builds their alpine images, they use their own java binaries and don't have an aarch64_alpine binary built. https://github.com/adoptium/temurin20-binaries/releases
In the dockerfile:line 44 there is a check to prevent builds on alpine for arch.

[vordimous]

@jfallows I think this PR is ready for review, but the builds are failing. I am not sure what to look for since the build works locally. Please advise.

Also my maven skills are pretty rusty so I think there is something missing her to make sure both release and alpine profiles are built.

[vordimous]

The docker-maven-plugin docs specify the need to create a multi-platform buildx builder named maven so it will use that to compile the different platform layers. Here is the command I used:

docker buildx create --platform linux/arm64,linux/amd64 --name maven --bootstrap --use

local build and deploy to personal docker hub worked as intended: https://hub.docker.com/repository/docker/vordimous/zilla/tags?page=1&ordering=last_updated

./mvnw -DskipTests -Dmaven.deploy.skip clean deploy -U -Drelease

[vordimous]

The incubator edge alternate tag is to match a more docker friendly naming scheme for the latest development work.

I am not in love with having the incubator-alpine directory but at least it is consistent with release? Local builds with then have both image version options if needed:

Any ideas on how to setup the pom differently are welcome.