Reduced image size by 50%

[hgiesenow]

With two small hacks, the image size can be reduced from 380 to 167 MB

1. Use debian-slim image to save the first 44 MB
2. Only install the build tools, when they are actually needed save another 170 MB

[yosifkit]

This is basically what we do in the alpine-based images. It was a conscious decision to not do this for Debian since the apt packages take significantly longer to install/uninstall and don't uninstall cleanly (especially since in Alpine we install/uninstall the same PHPIZE_DEPS in some of the docker-php-ext-* scripts).

[hgiesenow]

Alpine is sadly no option for me (as i need the ioncube loader). I just want a decent feature set with a decent image size and not extremes with either missing features or gigantic size.
Even if the apt packages don't uninstall cleanly, a lot of disk space can be saved as you see.
The build time is not a problem for me, as we use automated builds by Docker Hub.

[mikk150]

@kuborgh-hgiesenow ioncube loader has no OS dependency, so alpine images should work for you

[mdeboer]

@mikk150 that's not entirely true as Alpine doesn't include glibc, which is what ioncube depends on. I was never able to get ioncube running on alpine based images and for that situation debian-slim seems like a fine alternative for me.

[hairmare]

I wouldn't bet on ioncube ever supporting a distro that isn't based on glibc. If you're a paying customer, raising an issue might have a chance of getting ionCube to address your issue (ie. being runnable on alpine). Otherwise, I'd recommend you to steer clear of any solutions that depend on obfuscation/encryption ala ionCube.

[mdeboer]

@hairmare I'm not sure I'm following ... why is the requirement of glibc relevant to me using ioncube (or software that is encrypted with it)?

I'm simply saying that the comment of @mikk150 is not entirely correct. There is no OS dependency but it requires glibc which alpine doesn't offer. Therefore, I wonder if there's any problem with offering a debian-slim based image as alternative to alpine.

[tianon]

See also #513 (comment), which is a good summary of my own thoughts on the matter:

One of the main hurdles to doing this is precisely that APT doesn't have something like APK's --virtual. With APK, when we do apk add --virtual .xyz foo bar baz, and then later do apk del .xyz, it will only remove those packages which were not already installed or required by something else. With APT, doing apt-get purge on packages the user installed will simply remove them, and in some cases error out completely if they're dependencies of something else, so while this would be feasible to implement in a single script (where we could, for example, track the output of apt-mark showmanual and/or dpkg-query to determine what was already installed to some extent), it's a lot less feasible across multiple scripts (as we require, given the nature of the relationship between configure and install). Additionally, the logic to duplicate some of that virtual functionality is non-trivial, and likely to simply be an additional source of bug reports from our users.

As a final thought, the primary reason we were willing to do this for Alpine/APK wasn't actually because of the --virtual functionality (which simply came in extremely handy for actually implementing this behavior in a sane way that's not likely to break users), but was instead because APK is so much faster at installing dependencies than APT is, and one of the explicit goals of the Alpine-based images is to be as small/minimal as possible.

[tuananh]

can we at least offer debian-slim variant images?

[sadok-f]

Any chance to get a debian-slim image?

[tianon]

Any chance to get a debian-slim image?

Not sure I understand the request; the current images are based on -slim Debian variants:

php/7.2/stretch/apache/Dockerfile

Line 7 in 74b59e1

FROM debian:stretch-slim

[sadok-f]

ah sorry didn't notice that
Thank you :)

[firecow]

@tianon Would you be open to a PR that adds php:8.3.8-zts-nophpizedeps etc. etc. ?

[firecow]

For others that visits this thread and want to reduce their image size, and want to use the official php images, here is a little trick that helps out.

FROM php:8.3.9-zts-bookworm AS php-setup

RUN <<EOF
  set -e

  # Install extentions
  builddeps="$PHPIZE_DEPS perl libzip-dev"
  runtimedeps="libzip4"
  apt-get update
  apt-get --no-install-recommends -qqy install $runtimedeps $builddeps
  # Install php extensions
  docker-php-ext-install zip

  # Cleanup buildeps and apt-get
  apt-get purge --auto-remove -y $builddeps
  apt-get clean
  rm -rf /var/lib/apt/lists/*
EOF

# Since official php debian images has dev tools in them, we remove them in php-setup stage and copy / to scratch
FROM scratch AS main

ENV PHP_INI_DIR=/usr/local/etc/php

# Copy php + pecl extension debian build
COPY --link --from=php-setup / /

Notice runtime libs needs to be explicitly set in apt-get install
apt-get purge $builddeps will actually remove libs needed by your pecl extensions.

[tianon]

Would you be open to a PR that adds php:8.3.8-zts-nophpizedeps etc. etc. ?

#1367 (comment)

Unfortunately adding more variants of PHP is not something we want to support and maintain. Full build time of what we already have is around 2-3 hours (on each architecture). We do not have bandwidth for more PHP variants (#530 (comment), #879 (comment)).

[shinsenter]

@hgiesenow

I've made my own PHP Docker images based on the official ones, adding useful extensions, Composer, and more. I've also made the images much smaller than the originals, thanks to the docker-squash project.