Support running only the WordPress installation part from the entrypoint

[calind]

Currently, the entry point installs WordPress from /usr/src/wordpress only if the container is started with Apache or php-fpm.

My use case is to run the WordPress installation part in a Kubernetes init container, then, at runtime, have /var/www/html mounted read-only.

What I'm proposing is to have a way to run the installation part if the container CMD is something like install or a WORDPRESS_INSTALL_ONLY env variable is set.

[tianon]

Can you elaborate a little bit more on your actual use case? What's the end goal?

If your goal is a fully read-only install (ie, no file uploads, auto-upgrade, etc), I think https://github.com/docker-library/docs/tree/master/wordpress#static-image--updates-via-redeploy is probably a better solution than a read-only volume (especially since then you can actually apply upgrades). 😅

[calind]

The aim is to use the official WordPress image while allowing for platform-level customizations. The platform supplies WordPress along with custom mu-plugins, mounted as read-only. Users can still interact with WordPress normally — installing, upgrading, and editing plugins as usual (plugins, themes, upgrade, uploads, cache are mounted read-write).

However, with PHP-FPM deployments, static image updates aren't practical because both the Nginx and PHP containers need access to the same WordPress files — for example, Nginx must serve WordPress’s JavaScript assets.

In Kubernetes, this shared content can be managed using a shared volume, but that volume must include the content generated during the entrypoint's installation phase (there is no way to directly share /usr/src/wordpress with nginx container).

In a broader scope, this would enable a way to use static image updates for PHP-FPM + nginx in Kubernetes deployment scenarios. As it stands, I don’t see a way to support that setup, as the lack of a mechanism to share /usr/src/wordpress with the Nginx container prevents it.

[tianon]

Ah hmm, yeah, that's a good point. In newer runtimes, you can use https://kubernetes.io/docs/tasks/configure-pod-container/image-volumes/ slash moby/moby#48798 to directly mount the WordPress image content into a second container, but without that this is kind of annoying. You could have a one-liner initContainer that replicates the image contents into a volume that's then shared, but it's a little bit annoying. I think directly mounting the image content is probably the best long-term solution, but maybe there's something we should consider for the interim.

@yosifkit the two main ways I can think of to implement this are a way to have the existing script do the copy and then exit (as implemented in #970) or to have a separate script more like docker-library/postgres#1150 (but with the notable benefit that the behavior here is much more straightforward so it'd really be lifting the existing implementation into a second script and the first script can just invoke it directly) -- do you have a preference? I've got a slight lean to the latter, but I think I could be convinced of the former.

[yosifkit]

Since I don't want a magic command or an extra environment variable, I'd vote for the second script.

So, the default entrypoint would basically be this (move everything but the first if and exec to the new script)? Is that really it? 🙈

#!/usr/bin/env bash
set -Eeuo pipefail

if [[ "$1" == apache2* ]] || [ "$1" = 'php-fpm' ]; then
 run-new-script.sh
fi

exec "$@"

[tianon]

Oh right, I should've actually looked at the script, that does seem a little silly. Ok, alternative proposal: we make a symlink to the script, and add something to that if so that it runs that behavior on our new script name too -- exec without arguments should no-op, so it should work fine as an "ensure wordpress is installed" function, and then it's simple to implement, debug, and most importantly, maintain. Then the only hard part is what to name the symlink version. 😄

[anxo-outeiral]

@calind there's a PR approved #971 with a feature that you requested. were you able to check it out?