Use 'strip -s` in docker-php-ext-enable to save disk space

[c0deright]

Hi,

I was just wondering why docker-php-ext-enable isn't doing a strip -s on the .so files?

I just reduced the disk usage of /usr/local/lib/php/extensions/no-debug-non-zts-* directory from 12MB to 3MB just by running strip -s on the .so files there.

Please consider stripping unnecessary symbols this way.

[estahn]

@adminblogger Does this possibly interfere with xdebug?

[c0deright]

@estahn Not that I know of. I just added

strip -s $module

in docker-php-ext-enable as the last command in for module in $modules; do loop.

My coworkers are using several of my PHP-FPM builds and they even use xdebug with an IDE for debugging - so far no issues.

I even went so far and added the line

&& { find /usr/local/lib -type f -print0 | xargs -0r strip --strip-all -p 2>/dev/null || true; } \

right after installing libraries, pecl install ... and docker-php-ext-install ....

This saved me even some more disk space and never had a problem with it.

[tianon]

Given #533, this would actually be feasible now (and likely would've mis-detected Zend Extensions previously, causing them to fail to load properly). If we start stripping binaries, we should do so across the board IMO (both in the Dockerfile for the pre-installed binaries, and in docker-php-ext-install for the after-the-fact installations).

I'm not 100% convinced we can safely do this unilaterally without breaking anyone, but I'd be interested in more evidence to help us come to a conclusion (since this is something I'd be interested in seeing, given the potential space savings)!

[andrew-s]

It'd be good to see this as an implementation (potentially a new tag? maybe stripped or something). With using PHP templates on FaaS systems, it'd be good to try and get the smallest image size.

[tianon]

Well, for the binaries included in the base image, they're already stripped:

php/Dockerfile-debian.template

Line 176 in d3beb19

find /usr/local/bin /usr/local/sbin -type f -executable -exec strip --strip-all '{}' + || true; \

So the ~365MB we're at is likely the smallest we can go for Debian variants (~77.6MB for Alpine). This is about whether we can safely add strip to docker-php-ext-install, which I think is more of a stretch and is something users can trivially implement themselves, ala:

FROM php:7.2-cli-stretch

RUN docker-php-ext-install json \
	&& find "$(php -r 'echo ini_get("extension_dir");')" \
		-type f -executable -exec strip --strip-all '{}' +

This takes json.so from ~49K down to ~43K.

I'm not exactly convinced this is worthwhile. Even the example above going from 12MB down to 3MB isn't very compelling IMO -- when Docker transfers the layers (through docker push and docker pull), they're compressed, so we're probably comparing something like ~6MB to ~2MB or something with compression applied (often even more aggressive than that).

[glensc]

Now that #533 is merged, I see no issues with proceeding with strip all build artifacts.

Reading libraries externally is what made #533 break, php runtime itself is not messing with ELF symbols, it's fine with stripped objects. Linux distros doing that for decades.

Getting size down concern is not only your bandwith, it's multiplied by disk storage in zillions of installs ;), But this is just opinion, each has their own.

[jontro]

Stripping the grpc extension brings it down from 121M to 5M. Maybe it could be added as a command line flag? See grpc/grpc#23626