Reduces image size of resulting Docker Perl image #53
Conversation
By using a multi-stage strategy the resulting image can be brought down
to ~100MB instead of ~800MB.
By running the following commands we can create two images, a build
image and a slim image:
docker build -t perl:<tag> --target build .
docker build -t perl:<tag>-slim .
This can be further optimized by only installing cpanm in another stage.
It is a nice to have while building an image, but you don't need cpanm
on a running container.
|
Hi @waterkip, thanks for this! Currently the main blocker now is the lack of support for multi-stage builds in hub (see docker-library/official-images#3383.) I appreciate the effort though! |
generate.pl
Outdated
| LABEL maintainer="Peter Martini <[email protected]>, Zak B. Elep <[email protected]>" | ||
|
|
||
| COPY *.patch /usr/src/perl/ | ||
| WORKDIR /usr/src/perl | ||
|
|
||
| RUN curl -SL {{url}} -o perl-{{version}}.tar.{{type}} \ | ||
| RUN apt-get update && apt-get install --no-install-recommends less \ |
There was a problem hiding this comment.
I saw on a docker build for 5.18 that is was complaining that less wasn't found. So I added it.
There was a problem hiding this comment.
Right, just tried a rebuild here:
...
perl-5.18.4.tar.bz2: OK
patching file ext/Errno/Errno_pm.PL
patching file hints/linux.sh
First let's make sure your kit is complete. Checking...
Locating common programs...
./Configure: 2469: ./Configure: less: not found
Checking compatibility between /bin/echo and builtin echo (if any)...
Symbolic links are supported.
Checking how to test for symbolic links...
You can test for symbolic links with 'test -h'.
...
It doesn't seem essential to the build though (it still gets us a working perl, and image users can just install less later) so it can probably be left off.
There was a problem hiding this comment.
I removed it. But I saw a whole lot of activity in issue #52, so I guess this PR will not be merged.
There was a problem hiding this comment.
Still, thanks a lot for getting this moving! 👍
There was a problem hiding this comment.
No problem, good to see things moving 👍
| @@ -222,3 +223,10 @@ =head1 DESCRIPTION | |||
| WORKDIR /root | |||
|
|
|||
| CMD ["perl{{version}}","-de0"] | |||
|
|
|||
| FROM debian:{{_tag}}-slim as runtime | |||
There was a problem hiding this comment.
As noted in docker-library/official-images#3383 (comment) we end up with
- having to make builds at least twice per version/architecture
- a less-transparent dependency between the build base image and the runtime (unless we use the exact image layer ids here; @yosifkit @tianon can probably elaborate more)
I'm thinking of doing something similar to what https://github.com/travis-perl does (have prebuilts in a repo under here which we can fetch from the bashbrew builds) but I'm not sure if that's a correct (or supported) approach...
There was a problem hiding this comment.
I'm not really sure I follow all the comments (of #3383). As to your two remaining points
- The two builds should be fairly quick as they make use of the cache.
- You could also make a build-image based on debian:-slim.
There was a problem hiding this comment.
Yep, the second point is what we're exploring now in #52; I'll have a PR and perhaps a few demo images up on my own Docker Hub namespace for people to test.
There was a problem hiding this comment.
If you have something, I'd be happy to test this. Just let me know.
There was a problem hiding this comment.
Thanks! I've just pushed #54, please try it out! I've triggered builds for 5.28-slim and 5.28-slim-threaded in my own hub repo, though its taking a while so it might be better to build these locally :)
By using a multi-stage strategy the resulting image can be brought down
to ~100MB instead of ~800MB.
By running the following commands we can create two images, a build
image and a slim image:
This can be further optimized by only installing cpanm in another stage.
It is a nice to have while building an image, but you don't need cpanm
on a running container.