Repository navigation
Some improvements about Docker - #13059
Conversation
|
After switching to JRE 11, we need to use |
| RUN wget https://github.com/robxu9/bash-static/releases/download/5.1.016-1.2.3/bash-linux-x86_64 -O /bin/bash \ | ||
| && chmod 755 /bin/bash |
There was a problem hiding this comment.
how much work would it be to fix the script to not use bash specific constructs?
If we are going to install bash or other things, maybe it would make sense to switch to a openjdk debian-slim image that already includes it
There was a problem hiding this comment.
I also agree with you that we switch to another base image. There're two reasons:
- Installing bash in this way makes it hard to support ARM64 in the future
- gcr.io/distroless image can't be directly accessed in mainland Chain due to network restriction, developers in China has to use some proxy servers to download this base image.
But distroless has some advantages such as smaller size, more security.
So currently I don't have an opinion on which we should use.
There was a problem hiding this comment.
how do others feel about switching base images? I agree installing bash is not multi-arch friendly, plus we do run tests against ARM64 today, so it would be nice to also do that for docker. cc @gianm
There was a problem hiding this comment.
It's better to have ARM64 supported. There are some feedback that ask for ARM64 images(see #11820), and someone made it by themselves.
To support ARM64, we need be able to build and run on ARM64 based machines.
Current Dockerfile uses amd64 busybox which blocks build image to run on ARM64 machines. It's easy to solve.
Another problem is even we solve that, we still can't build the image on Mac M1. Current the web-console dependency still prevents us from doing this, see #13012
There was a problem hiding this comment.
we still can't build the image on Mac M1
We can tackle building on arm and providing arm docker images separately. It should be possible to cross-compile the console until the node.js issue is resolved. That means building on M1 would be slower due to emulation, but I think that's better than not building at all.
Current Dockerfile uses amd64 busybox
it looks like you solved that problem by pointing to a multi-arch build of busybox.
I think the only issue left to solve is whether we want to switch to debian-slim, or if we want to add the logic to download the right arch binary for bash-static. The latter one might be simpler for now and we can do that by adding an if statement checking the value of $TARGETARCH (see https://docs.docker.com/engine/reference/builder/#automatic-platform-args-in-the-global-scope) to pick the right bash-static binary.
There was a problem hiding this comment.
@gianm What's your opinion on changing the base image from distroless to debian-11?
There was a problem hiding this comment.
@xvrl Actually I tried to build image on my Mac M1 by adding --platform=linux/amd64 to the docker build command several days ago, and I didn't make it. It takes more than 20 minutes and it seems it's stuck at building the source.
There was a problem hiding this comment.
@xvrl Let's download the bash-static based on the target arch in this PR.
Co-authored-by: Xavier Léauté <xl+github@xvrl.net>
|
I have built and run the image on my intel MacBook and M1 MacBook, both are OK. |
Co-authored-by: Xavier Léauté <xl+github@xvrl.net>
|
@gianm Do you have any comments on these changes? If no, I will merge it once the CI finishes. |
|
@FrankChen021 you can go ahead and merge this, I don't think there is anything controversial about it. Adding bash-static is already backported as part of #13063. The biggest change is the switch to JDK 11, so we should probably mention that fact in the PR description and also make sure we add it to the release notes. |
|
Thank you @xvrl very much for you helpful review. |
3 participants
These some improvements about Docker, including:
3.8.4-jdk-11-slimto the latest3.8.6-jdk-11-slimamd64/busybox:1.30.0-glibctobusybox:1.35.0-glibcThis PR has: