Do more at once to make image smaller

[frioux]

This is just a PR to get a conversation going. When I made this change my build reduced by more than 100M. Is this something that we can do? Is there a reason to leave the old stuff behind?

[frioux]

woops, I forgot to remove the block following what I did. I'll fix it if I can get a +1 from a maint (and apply the change to the other builds.)

[zakame]

You probably want to remove the succeeding RUN line if this were the case.

Alternatively, I think we should ought to put the command chain on this RUN into its own script and just put in arguments to what perl to build and how many procs, like e.g.

COPY build-perl.sh /tmp/build-perl.sh
RUN sh -x /tmp/build-perl.sh https://cpan.metacpan.org/authors/id/S/SH/SHAY/perl-5.20.1.tar.bz2 $(nproc)

[tianon]

COPY has depressing Docker cache behavior, so I'd recommend sticking to the
multiline RUN even though it's not exactly pretty

[PeterMartini]

I like the idea of bundling it into a build script instead of mixing it together

[PeterMartini]

Err, running between tasks, that was a little briefer than I meant. Anyway, +1 to getting rid of build debris in whatever way's best

[frioux]

Ok, I'll send a fresh set of changes tomorrow with a single script called

by RUN

sent from a rotary phone, pardon my brevity
On Jan 27, 2015 8:54 PM, "Peter Martini" notifications@github.com wrote:

Err, running between tasks, that was a little briefer than I meant.
Anyway, +1 to getting rid of build debris in whatever way's best

—
Reply to this email directly or view it on GitHub
#8 (comment).

[tianon]

I really, really recommend you don't, especially since there's already a
single simple script that generates these Dockerfiles:

docker-perl/generate.pl

Line 109 in c7af0df

FROM buildpack-deps

If you make a separate script just to build Perl, you'll have to copy it
into every single subdirectory, and you'll be dealing with COPY's cache
semantics (ie, mtime is enough to break the cache).

[yosifkit]

I would also recommend against a file that contains these commands as that would obfuscate the build for a user who pulls the image and does a docker history. Even though the file would be in the image, it would not be easy without the Dockerfile to know what was run and that is only available by coming here to this repository.

[frioux]

Ok, I'll tweak the script that generates them.

sent from a rotary phone, pardon my brevity
On Jan 27, 2015 9:22 PM, "Tianon Gravi" notifications@github.com wrote:

I really, really recommend you don't, especially since there's already a
single simple script that generates these Dockerfiles:

docker-perl/generate.pl

Line 109 in c7af0df

FROM buildpack-deps

If you make a separate script just to build Perl, you'll have to copy it
into every single subdirectory, and you'll be dealing with COPY's cache
semantics (ie, mtime is enough to break the cache).

—
Reply to this email directly or view it on GitHub
#8 (comment).

[zakame]

Maybe outside this PR but

@tianon can you shed more light on that COPY cache semantics issue? Is there are ticket on docker for it already, if it is such a severe issue? Just saw moby/moby#1996 among others

@yosifkit as you said it, the file is in the image, so the user could just do a docker run -i -t perl /bin/bash and inspect the script on their own; an extra step, yes, but I'd disagree that it would be obfuscating. Maybe the script should be in /home instead of /tmp, so that docker history will show that the build was run locally, no need to go here in this repo.

[frioux]

Ok, I refactored this to be done in the right place. Again, as far as I can tell this saves about ~100M of space. I am a little bummed it's not more, but buildpack-deps is pretty fat as is.

[tianon]

+1 ❤️

[tianon]

As for fatness, we've actually got several images that have a "slim" variant for people who don't want as much included by default:

https://github.com/joyent/docker-node/blob/master/0.10/slim/Dockerfile
https://github.com/docker-library/python/blob/master/3.4/slim/Dockerfile
https://github.com/docker-library/ruby/pull/33/files

The basic idea being that it's roughly the same as the default Dockerfile (same Debian version, etc), but instead of having all the "batteries included" (ie. buildpack-deps), it's just the bare minimum to get the language up and going so that experienced users can use that to chart their own destiny and get images that are exactly the right size for their use case.

[frioux]

Yeah, I'm of two minds about slimmer variants. On the one hand, it means that if you only use perl it's nice and small, but on the other hand, if everyone uses buildpack-deps, it's a shared root that can save some space. But I've seen enough churn in buildpack-deps that I don't think it's really worth it.

[yosifkit]

@frioux There should not be any more churn in buildpack-deps aside from security updates in the base debian images. We have it at a nice spot.