Review additional architecture support about docker-jetty HOT 23 CLOSED

@tianon, I'll update the PR later today

from docker-jetty.

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

from docker-jetty.

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

from docker-jetty.

@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.

from docker-jetty.

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?

from docker-jetty.

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.

from docker-jetty.

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. 😄 👍

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. 👍

from docker-jetty.

See also znc/znc-docker#3 (comment) for more thoughts/links. 😇

from docker-jetty.

@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.

from docker-jetty.

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

from docker-jetty.

@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.

from docker-jetty.

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

from docker-jetty.

@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.

from docker-jetty.

@gregw It's not support arm64?

from docker-jetty.

@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.

from docker-jetty.

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.

from docker-jetty.

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

from docker-jetty.

@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.

from docker-jetty.

I see #72 is open to solve the setuid issue -- anything more we can do to help move this along? 🙏 ❤️ 👍

from docker-jetty.

So, the setuid issue appears to be fixed -- does that mean we can multiarch now? 🙏 😄

from docker-jetty.

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. 😄

from docker-jetty.

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

from docker-jetty.

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?

from docker-jetty.