Remove phpize deps from permanent image

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.

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)

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

#438 (comment)

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

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.

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:

@estahn

@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.

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.

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).

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"]

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

@axot

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

Analyzing the image with dive, I also discovered that even the slim CLI-only image is getting bloated due to debug & CGI variants being included:

Given the containerized nature of the build, do we really need ancient CGI binary as well as development-only phpdbg?

Currently the recommended Debian-based php:8.4-cli is at 546MB, while the Alpine variant is 109MB. The common argument of shared image bases doesn't seem to work that great in practice. Over multiple docker hosts, with a fair share of containerized PHP apps, PHP images take a lot of space - each app uses a bit different version of PHP, with each one building their own PHP extensions in their container layers.

Not to be an old grumpy man, but I think we made a mistake somewhere if 1k SLOC lines utility ends up using a close to a gigabyte of space to just run ;)

php-cgi: Enable CGI for CLI variant #649
phpdbg: Explicitly enable phpdbg in CLI images and *disable* it in all others #1259

php-cgi: Enable CGI for CLI variant #649

phpdbg: Explicitly enable phpdbg in CLI images and disable it in all others #1259

I appreciate you for providing links for reasoning, thank you for that. I expanded my reasoning a bit below. If you would like to, we can open a separate discussion regarding these, unless it's a hard "no".

CGI

After reading the PR and mentioned issues I still wonder about the validity of the argument of including CGI, after 7 years has passed. My usage or experience may not be representative however, the last time I used CGI was at least a decade ago and even then it was legacy. Looking through the original request #280 from 9 years ago, it seems like the primary use case back then was php-pm. The project now appears abandoned and replaced by solutions that don't rely on php-cgi. Given the recent PHP's Foundation support for FrankenPHP with the worker model, I think it's safe to say the general direction the community is moving has changed.

I certainly don't think adding another image variant is sensible. I would argue that maybe PHP_EXTRA_CONFIGURE_ARGS should include --disable-cgi by default in new reeleases, as it appears that php-cgi is a very niche thing.

phpdbg

This is an area which I don't have a lot of experience with, as my whole career I was an xdebug user. However, I honestly struggled to find wider audience with usecases for phpdbg. I am 100% sure there are some, but seeing as one of the most popular ones - fast code coverage calculations - has been officially removed I think the situation may be similar to CGI.

Why do I care about it?

Alpine is hugely popular because of its minimalism, enhancing security by limiting the footprint as a side-effect. However, it's a bit of an elephant in the room that musl libc causes a lot of issues. In both Go and PHP the real-world performance differences are sometimes substantial, not to mention subtle but annoying to debug and sometimes impossible to fix bugs are cropping up a bit too often. The alternative is obviously using a small glibc base, like debian:*-slim, however image sizes for PHP are quite large. This is why I think tripling the size of the core binary components is not a good compromise.

Alternatives

Build custom image from scratch

While certainly building my own images from scratch is always an option, I try to stick with official builds for core components like the execution environment or a database - both professionally and personally. This is simply due to stability and much larger install base allowing for bugs to be found and ironed-out much quicker. In my opinion, the complex list of build flags used here, with reasoning for each one of them, is the best testimonial of why rolling your own build isn't a good solution most of the time :)

Slimming-down from base image

The solution suggested by @axot is to me a genius workaround to get a small but production-ready image, after all extensions are installed. However, I am not sure how temporally stable this approach is.

Normally I would suggest existence of an official -slim variant, bug given the already huge number of tags and load on the build servers this probably isn't feasible.

The justifications you've provided are exactly why these things are only found in the CLI variants, which are much less likely to be run as persistent services (and much less likely for size to be of critical importance). 😅

Navigation Menu

Repository navigation

Remove phpize deps from permanent image #769

CGI

phpdbg

Why do I care about it?

Alternatives

Build custom image from scratch

Slimming-down from base image

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Remove phpize deps from permanent image #769

Description

Activity

estahn commented on Jan 2, 2019

yosifkit commented on Jan 17, 2019

wyqydsyq commented on Jan 17, 2019

tianon commented on Jan 18, 2019

estahn commented on Jan 18, 2019

brettpappas commented on Mar 12, 2019

jmrieger commented on Aug 1, 2019

tianon commented on Aug 1, 2019

axot commented on Oct 12, 2021

mhkarimi1383 commented on Sep 25, 2024

mhkarimi1383 commented on Oct 1, 2024

kiler129 commented on Jul 4, 2025

tianon commented on Jul 7, 2025

kiler129 commented on Jul 8, 2025

CGI

phpdbg

Why do I care about it?

Alternatives

Build custom image from scratch

Slimming-down from base image

tianon commented on Jul 9, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions