Review additional architecture support

[md5]

As of https://github.com/docker-library/openjdk/pull/121, the openjdk base image supports additional architectures where the JRE is available on the given base OS. In practice, this means amd64, arm32v7, arm64v8, i386, ppc64le, and s390x for JRE 7 and 8, as well as amd64 for JRE 8 on Windows.

To the extent possible, I think we should have variants of the jetty image for these additional platforms and architectures.

[gregw]

To support this, should we change to a build that always runs an update.sh style script to generate all the variants and then build the images from the generated directories?

[md5]

My understanding is that the bashbrew tool used to build the official images should cover most cases without adding new Dockerfile variants.

If you take a look at the PR I linked for openjdk, you'll see that all they changed was the generate-stackbrew-library.sh file.

In the case of Jetty, I think we mainly need to worry about the native code bits. Since the build relies on having those libraries build already in jetty-distribution, the Dockerfile may need to change to build them itself. I'm also not sure exactly how Windows support works, though I think it's still running Debian on top of Windows for openjdk (which may not be worth supporting if you can't do Windows-specific stuff).

I mainly wanted to open this to get it on the radar. Maybe if @tianon can find a few minutes to spare he can add his two cents.

[tianon]

Indeed -- please don't create a separate Dockerfile per architecture if it's avoidable.

We've converted most of the docker-library images to support multiarchitecture, and so far, only the "base" images really need separate sources (Debian, BusyBox, etc); most other differences can be handled from a single Dockerfile source, which makes both maintenance and review easier. :smile: :+1:

Regarding Windows, that's based on either windowsservercore or nanoserver depending on which variant is used (https://github.com/docker-library/openjdk/tree/999017cf65e9a9fc975c39fd75a8841bf4955b4a/8-jdk/windows), and should be a fully-functional Windows environment. :+1:

[tianon]

See also https://github.com/znc/znc-docker/pull/3#issuecomment-308184441 for more thoughts/links. :innocent:

[gregw]

@tianon can you suggest a good exemplar of a multiarchitecture Dockerfile and I'll have a go at converting jetty to use best practises... and include arm64 along the way if possible.

[longquan7]

@gregw I know the node image is support different architecture and you can look at this https://github.com/nodejs/docker-node/tree/c044d61e6d02756bb8ed1557b2f0c7a0d7fead6f

[md5]

@longquan7 the node image is pulling down prebuilt versions of Node, packages for each architecture.

For Jetty, there would have to be versions of setuid.so for each architecture, along with a working version of JNR. Greg can correct me if there are other non-JDK native dependencies. We also need to consider musl v. glibc due to the Alpine image.

[longquan7]

@md5 ok, I understand, Please let me know if there's any progress

[gregw]

@md5 The next 9.4 release will add a conscrypt module. We use the uber jar, but that only has support for:

• windows-x86_64
• osx-x86_64
• linux-x86_64

Note that other the setuid, the other native dependencies are all optional. Even for setuid, we could change user prior to running jetty and avoid the native code. We bind to 8080, so starting as root is probably an unnecessary complication.

[longquan7]

@gregw It's not support arm64?

[gregw]

@longquan7 I can't see a conscrypt build for arm64, but as an optional module I don't think that is a big issue as you can run with java SSL (like jetty has up until 9.4.7).

However, we don't build a setuid.so for arm64. We could do that, but I'd be more inclined to stop using setuid rather than restrict our architectures to what it is available on.

[gregw]

I just did a quick test and it works fine (for simple testing) to remove the setuid module and add a USER jetty to the Docker file.

That would remove the only native dependency in the default settings.

ALPN would be the most common other native dependency. However once jdk9 is available there will be ALPN support in the JVM, plus there is some talk of having that back ported to jdk8.

[longquan7]

@gregw I just develop on the arm64 architecture,So I hope that some images can be support arm64 architecture

[md5]

@gregw I'm fine changing the default behavior to immediately run as jetty, as long as it's all well documented how to start as root and use setuid if that's what someone wants to keep doing for some reason.

[gregw]

I opened #70 to remove setuid as a separate issue to supporting additional architectures

[tianon]

I see https://github.com/appropriate/docker-jetty/pull/72 is open to solve the setuid issue -- anything more we can do to help move this along? :pray: :heart: :+1:

[gregw]

@tianon, I'll update the PR later today

[tianon]

If you're still looking for a decent example that's more similar to Jetty, Tomcat is probably worth taking a look at: https://github.com/docker-library/tomcat/blob/8a2acf4ccfa691465fa41c0828ab6ea47225dfd0/8.5/jre8/Dockerfile

[tianon]

So, the setuid issue appears to be fixed -- does that mean we can multiarch now? :pray: :smile:

[gregw]

@tianon it is indeed my intention to keep taking steps towards multiarch support, but currently lacking time and test environments to even review exactly what the best approach is.

For my part I think this is something that can be looked at over the quiet months of December, January.. to at least restructure the build to better support multiarch. But then individual arch might still need more help to ensure they are tested etc. But don't let my limited time prevent anybody else from progressing contributions that may assist.

[tianon]

I've just successfully tested 9.4-jre8/Dockerfile building/running on arm64v8, and even ran the jetty-hello-web test (https://github.com/docker-library/official-images/blob/9ff50a0ebaff4429c6844bf3d7ee843b7866979a/test/tests/jetty-hello-web/run.sh) against it with a passing result, so that's a good sign. :smile:

[vaibhavsood]

Have done the same for ppc64le, both build and run of the ppc64le container pass for 9.4-jr8/Dockerfile as well as the jetty-hello-web test

[vaibhavsood]

Hi @gregw,

I'm at IBM and can help with getting a public CI nightly build setup for jetty on ppc64le

Want to check if that will be useful?