Reduced the size of the image by about %23

[armen]

It bzips the /usr/src/php to reduce the size of the image. bzip2
package is moved outsize of the $buildDeps just for backwards
compatibility otherwise one would have needed to add bzip2 into
their Dockerfile as build dependency.

[md5]

I was going to ask whether this breaks the docker-php-ext-install script, but I see now that you updated that script and the companion *-configure script to uncompress the directory as needed. Looks like the docker-php-ext-* scripts are covered by a test (which I apparently wrote and didn't recall...).

LGTM

[thaJeztah]

Nice idea! LGTM

[yosifkit]

Hmmm... it looks like a good idea, but I see a problem. After running docker-php-ext-install, the src is tarred and zipped again. This would produce a new version of the tar that is not that same as the tar in the image. This would be tracked as a new file in this docker layer, and grow the size of the end image. Are there changes after install in the src directory that need to be kept for later?

FROM php:apache
RUN apt-get update && apt-get install -y \
        libfreetype6-dev \
        libjpeg62-turbo-dev \
        libmcrypt-dev \
        libpng12-dev \
    && docker-php-ext-install iconv mcrypt \
    && docker-php-ext-configure gd --with-freetype-dir=/usr/include/ --with-jpeg-dir=/usr/include/ \
    && docker-php-ext-install gd
# this RUN would end with a new tar of /usr/src/php (with the configure options zipped in)
# now the image takes the space of two bzipped php source tars

[tianon]

docker-php-ext-configure gd --with-freetype-dir=/usr/include/ --with-jpeg-dir=/usr/include/ is a perfect example of something that makes changes for the following docker-php-ext-install gd, and will thus balloon image sizes here by duplicating that tarball every layer 😢 (even just mtime changes get stored as a brand new file)

[md5]

It seems like just removing the tar step would make things OK. In the case of @yosifkit's example, I'd do something like this:

FROM php:apache
RUN apt-get update && apt-get install -y \
        libfreetype6-dev \
        libjpeg62-turbo-dev \
        libmcrypt-dev \
        libpng12-dev \
    && docker-php-ext-configure gd --with-freetype-dir=/usr/include/ --with-jpeg-dir=/usr/include/ \
    && docker-php-ext-install iconv mcrypt gd

That way the unbzipping would only happen once in docker-php-ext-configure and /usr/src/php would be removed from the image in the docker-php-ext-install call. Any subsequent calls to docker-php-ext-configure or docker-php-ext-install would still have to redo unbzipping as needed. This would result in a slower build of the image, but it would not result in the image getting extra copies of the tar file or the unbzipped source getting left around unless someone were to run docker-php-ext-configure without a subsequent docker-php-ext-install or if they were to run them in different RUN statements.

On that last point, something like this would be pretty pathological:

FROM php:apache
RUN apt-get update && apt-get install -y \
        libfreetype6-dev \
        libjpeg62-turbo-dev \
        libmcrypt-dev \
        libpng12-dev
RUN docker-php-ext-configure iconv
RUN docker-php-ext-install iconv
RUN docker-php-ext-configure mcrypt
RUN docker-php-ext-install mcrypt
RUN docker-php-ext-configure gd --with-freetype-dir=/usr/include/ --with-jpeg-dir=/usr/include/
RUN docker-php-ext-install gd

I think you'd end up with three copies of /usr/src/php in the image, each one whited out after the docker-php-ext-install steps.

[yosifkit]

Well, it seems we have at least 13 users that would be affected (github search). There are around 100-400 that use the install and configure scripts.

[armen]

@md5 I've removed tar step and I think it'll work

@yosifkit But I can't see how they would be affected?

If you mean this:

RUN docker-php-ext-configure gd --with-png-dir=/usr --with-jpeg-dir=/usr
RUN docker-php-ext-install pdo pdo_mysql mcrypt gd mbstring

Since the /usr/src/php is deleted at the end of docker-php-ext-install it still will work

[yosifkit]

Yes, /usr/src/php/ would be deleted on the second RUN but it would have already been committed to the image in the previous layer and so this second layer will apply a "whiteout" and the src will still take up the space.

[armen]

@yosifkit I see, that makes sense, I thought you mean the change wouldn't be backwards compatible for those users.
@yosifkit Please correct me if I'm wrong, I think this patch would be beneficial in general but certainly the documentation has to be updated to point out your point. docker-php-ext-configure and docker-php-ext-install should be used in a single RUN otherwise the image would grow in size.

RUN docker-php-ext-configure gd --with-png-dir=/usr --with-jpeg-dir=/usr && docker-php-ext-install pdo pdo_mysql mcrypt gd mbstring

[armen]

@yosifkit On the second thought now I understand what you mean by affected users, they might end up with bigger image with this patch, is that correct?

[md5]

@armen Yep. I see a few existing Dockerfiles in @yosifkit's search that have the configure and install steps in different RUN directives (as well as some cases of multiple installs in different RUN directives). Those users would indeed end up with bigger images with this change.

[shouze]

ping @armen I've explored another way to do things in #234.

[shouze]

ping @armen as #256 has been merged, I guess you can close this PR ;)

[armen]

Fantastic, thanks @shouze great job