Remove phpize deps from permanent image

[estahn]

Just wondering why we require perl in image php:7.1-fpm-stretch?

/usr/lib/x86_64-linux-gnu/perl => 19MB

# dpkg -S /usr/lib/x86_64-linux-gnu/perl
libperl5.24:amd64, perl-base: /usr/lib/x86_64-linux-gnu/perl

# apt-cache rdepends --installed perl
perl
Reverse Depends:
  autoconf
  adduser
  perl-base
  libdpkg-perl
  debconf
  libperl5.24
  perl-modules-5.24
  perl-base
  perl-base
  perl-modules-5.24

It appears to be related to phpize. Is there a need for it to be permanent in the image or could this be moved to a docker-php- script?

It's not relevant in production environments imo.

[estahn]

Seems like this is related to #513 #438 #557 #751 #716 which were all dismissed. Alpine is currently not an option as they have a major issue with DNS resolution (see gliderlabs/docker-alpine#255)

[yosifkit]

could this be moved to a docker-php- script?

#438 (comment)

[wyqydsyq]

Debian does support virtual packages via the equivs utility and so these build-time dependencies should be easily manageable.

This has a disadvantage vs APK in that the virtual packages need to either be pre-baked .debs expressing the dependencies, or equivs will need to be installed and ran (then subsequently removed) in the Dockerfile build

Alternatively, the dependencies could just be explicitly removed after they are used. It's a bit messier but at least prevents bloat

I still don't see any good reasoning for why this support for phpize should even be included by default, it should be in a script or alternative image

[tianon]

I have yet to see a user of this image who didn't need at least one docker-php-ext-install, which requires phpize and the build dependencies to exist.

Our current variant/tag list is already way out of control, so justification for a new variant is going to need to be very strong.

[estahn]

My current solution is to use multi-stage with a builder to add all dependencies and then copy everything (.so and bins etc) I need into the final image:

[brettpappas]

@estahn Would you be able to share your Dockerfile for your multi-stage build? I am in the same boat where I would like to trim the size of the stretch image down. I would love to use the alpine image but my build needs oci8 (w/ oracle instantclient) and it is not compatible with Alpine.

[jmrieger]

I have yet to see a user of this image who didn't need at least one docker-php-ext-install, which requires phpize and the build dependencies to exist.

I think that's an accurate and fair statement, which would also apply to the Alpine images. It doesn't preclude there being a better pattern for handling the build time dependencies - either a multi-stage build that does have the phpize dependencies, or modifying the docker-php-ext-* scripts to handle removing the Debian dependencies after the script is done running, similar to how they already handle apk. It's not the most efficient way to process in terms of build time, but it should be significantly more efficient in reduction of layer size.

I'll try to work out a proof of concept this week.

[tianon]

Alpine was given special treatment here specifically due to the speed/efficiency of the `apk` package manager (especially thanks to having an explicit `--virtual` flag to allow us to cleanly and correctly uninstall only the things we caused to be installed). The same cannot be said of APT (installing a package there is much more heavyweight, and it then becomes more difficult to track which packages *we* caused to be installed versus packages that were already installed).

[axot]

Here is a multi-stage example for generating a compact image, image size has been reduced from 431MB to 155MB.

FROM php:8.0-fpm-bullseye AS build

RUN set -eux; \
    docker-php-source extract; \
    # do pecl install here

    docker-php-source delete; \
    rm /usr/local/bin/phpdbg; \
    rm -rf /usr/local/lib/php/test; \

    # strip
    find /usr/local/bin /usr/local/sbin /usr/local/lib -type f -perm /0111 -exec strip --strip-all '{}' + || true;

RUN set -eux; \
    find /usr/local/lib/php /usr/local/bin /usr/local/sbin -type f -executable -exec ldd '{}' ';' \
        | awk '/=>/ { print $(NF-1) }' \
        | sort -u \
        | xargs -r dpkg-query --search \
        | cut -d: -f1 \
        | sort -u > /PACKAGES

FROM debian:bullseye-slim

ENV PHP_INI_DIR /usr/local/etc/php

COPY --from=build /usr/local/include/ /usr/local/include/
COPY --from=build /usr/local/lib/php/ /usr/local/lib/php/
COPY --from=build /usr/local/bin /usr/local/bin
COPY --from=build /usr/local/sbin /usr/local/sbin
COPY --from=build /usr/local/etc /usr/local/etc
COPY --from=build /PACKAGES /

RUN set -eux; \
    apt-get update; \
    apt-get install -y --no-install-recommends \
    $(cat /PACKAGES) \
    ca-certificates \
    ;\
    rm -rf /var/lib/apt/lists/* /var/cache/*

STOPSIGNAL SIGQUIT

EXPOSE 9000
CMD ["php-fpm"]

[mhkarimi1383]

I'm having the same problem, currently working on that to make a script to clean up build deps and things that are not used on final image

[mhkarimi1383]

@axot
Thanks, your solution worked with some little tweaks, I was able to reduce ~1.5 GB Image size to ~1.1 GB