Remove php src the right way for lightweight containers

[shouze]

Hi guys,

in the same way we do for alpine packages in #206... maybe we can think about removing /usr/src/php from the produced container image & make things easy to restore it?

Basically, I was thinking about:

• Add some && rm -rf /usr/src/php here
• Create a new script named for example docker-grab-php-source.sh that can manage the whole download/gpg check & so on
• Like in install build time deps from docker-php-ext-install for alpine #206 provide a mecanism to grab php source code each time we want to install some extension.

As /usr/src/php for php7 weights around 190M inside a running alpine image, I guess we can reduce the final image size by 10 to 20M (which is about the sizes of compressed php releases source code artifacts.).

To sum up, this can be around 25 to 50% gain for the final image size.

Also, this can be applied to non Alpine Linux images I guess, as it was tried with a non working approach in #96.

ping @tianon @ncopa what do you thing about that?

[yosifkit]

I didn't think that the src was that huge:

REPOSITORY          TAG                IMAGE ID            CREATED             VIRTUAL SIZE
# current size
php                 alpine             bdae0b0de098        3 days ago          191.5 MB

# sans all source
<none>              <none>             537592e5c872        53 seconds ago      44.3 MB

# keep the php src xz
<none>              <none>             cb1f5c08b4f9        50 minutes ago      55.79 MB

I am leaning on the side of keeping the source tar around rather than hammering the php.net servers.

[shouze]

@yosifkit yes indeed this is an interesting alternative & would avoid download roundtrips 👍

[shouze]

ping @yosifkit ok so I've made a PR for #237.

I can make a PR to fix this issue (not removing the tar, just the source from the container).

[andypost]

Suppose better to download src when needed, all containers that will be inherited from official ones also needs source only for build time in 99% use-cases

[shouze]

@andypost yes... but in fact if we download again the source, should be done once during the build of a derived container. With my initial proposal it's not optimized at all as it download source each time you try to install or configure some php ext.

So... I guess I could refine the proposed docker-grab-php-source.sh script, first by renaming it docker-php-source and having following functionalities passed as arg to control it:

• download: will download the source tarball unless already downloaded (because at the end of the download, will touch some file eg /tmp/docker-php-source-downloaded to flag that it's already have been downloaded).
• extract: will extract the source from the tarball unless already done (so in docker-php-ext-install & docker-php-ext-configure and so on, we can wrap by docker-grab-php-source download && docker-grab-php-source extract before each ext configuration or installation).
• delete: command which can take another argument:
  • source: rm -rf /usr/src/php (can be done at the end of each docker-php-ext-install or docker-php-ext-configure call)
  • tarball: rm $PHP_FILENAME && rm /tmp/docker-php-source-downloaded (this is kind of cherry on the cake, if we don't call it in derived containers then the container will keep the tarball but it won't break existing derived containers from the official one).

ping @yosifkit @andypost does it look like the best of both worlds?

[andypost]

@shouze I think there's no need to keep to store "flag-file" because you can always check for tarball file and extracted folder instead.
The rest of suggestion looks great

[shouze]

@andypost yup, file existence should be sufficient... in fact a flag file could be created only to automate deletion of source and/or tarball only if the source & tarball haven't been downloaded/extracted by docker-php-ext-install or docker-php-ext-configure scripts. This allow to create derived container in wich you download & extract source at the begining & explicitly remove everything at the end (for example, when you have to run custom pecl install). This allow full BC for containers that were only using docker-php-ext-install and/or docker-php-ext-configure with the instant container image size reduction.

It's a bit similar than in #239 to illustrate.
I will start the PR and we will be able to discuss it ;)