-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add multi-stage build support #3383
Comments
Same demand to build optimal Node.js image in nodejs/docker-node#362 as Windows isn't as good in cleaning up temp files/packages/cached MSI.
|
Here is a list we came up with so far, feel free to comment with more. Positive points:
Counter points:
This is more complex than just the Docker version of the systems building the images.
|
Thanks @yosifkit for the comprehensive list of pros/cons to get a better understanding of what has to be considered. |
If you have an expedient way to build busybox, can't you just still do that? You don't have to use multi-stage builds where it doesn't make sense.
Only to the second base image, no? If the first one is the same, you could presumably re-use the first artifact. If your build-boxes are ephemeral you can cache intermediary build artifacts in a registry: moby/moby#26839
I think deciding whether to further slim down the slim images is a separate discussion. Even if we don't use this as an opportunity to make more images single-binary, multi-stage builds are useful. |
tl;dr: multi-stage build helps to clear removed artifacts and reduces the image size
I think it is better to use more space on build servers than the traffic that is wasted by removed artifacts left in layers. A prime example is the Ubuntu image, where apt artifacts are deleted but still remain in the first So a simple multi-stage build in the Ubuntu example can decrease the image size by 26MB. The compressed image on Docker Hub would be decreased by 5 MB. That is 5MB lower traffic for each pull. You can imagine what that means for a base image that has already 10M+ pulls. 😄 |
A new point was made by @jouve on my multistage copy proposal in the ubuntu image repo, so I just drop it here as an update. 😞 It has serious issues... and therefore is not usable.
|
Here is my opinion on multi-stage build based on my experience with the node image. At the moment, node needs to be compiled for Alpine linux and this process is LOOOONNG, around 40 minutes per version. In order to reduce this build time we are implementing ccache. Basically our Travis build remembers parts of the build and can reuse those. It bring down the build time from 40-50 minutes to less than 5-10. The catch however is two fold, first we need to copy the cache files and the then build adds the new cache files. In order for caching to work we need to extract the new cache from the image, which is not possible at build time. And this is where multi-stage comes to the rescue. The first stage builds node, the second one copies the build result to the final image. We then can create a container with the first stage image (which is entirely independent of the final image), extract the cache files (and any other build related files for debugging) and then delete that image. |
Hi all. The use of multi-stage builds allows for a clean WebSphere Liberty image that has a different linux OS while still using the official Ubuntu-based WebSphere Liberty images to build the IBM JRE and WebSphere Liberty - this way I am not duplicating code that builds the IBM JRE / Liberty content. The dockerfile is here: https://github.com/WASdev/ci.docker/blob/master/ga/developer/centos/Dockerfile The PR to get it integrated is: PR #4326 Are there issues with this approach? |
Yes, similar to what @yosifkit has outlined above regarding multi-stage builds in general -- this creates an implicit dependency between two otherwise disparate images that's difficult for our tooling to extract. |
hi @tianon - In this case the Would this be a better fit for the Docker Store instead of Docker Hub? |
Here is a scenario where multi-stage build support would be very helpful. I'm building a docker image for the Pachyderm CLI client which hopefully can become and official image. The client is written in GO. Using multi-stage, I was able to create really small images that don't need the entire |
First step towards being able to actually support this is up at #5929. |
#5929 and https://github.com/docker-library/faq#multi-stage-builds implement the basics of this -- there are still a few dangling scripts that have edge cases (as noted above) but we're finding/fixing them as we go |
Hi folks,
I'm opening this issue to track multi-stage builds support in official-images.
Any ETA on this ?
The text was updated successfully, but these errors were encountered: