docker-entrypoint.sh conditional check prevents extension of CMD

[mattjbrent]

We recently encountered an issue with this image where we wanted to run supervisord to run CRON and sshd on the same image.

High level description
The entire entrypoint script is dependent on apache2* and php-fpm* commands being called in the CMD directive in the Dockerfile. Given the nature of docker and it's default of extensibility, any command passed to CMD effectively causes the entrypoint to not execute, breaking the image as WordPress install files do not get copied over.

Possible fixes or suggestions
There are a couple of approaches

1. Not change the entrypoint. But improve the documentation so this unusual behavior is clearer
2. Modify the entrypoint so that it creates some kind of default if the first command in CMD doesn't start with apache2* or php-fpm* (for eg default to apache2
3. Alternatively, you could split out the generic logic in the entrypoint script into another script. and have this new script called by separate entrypoints for both php-fpm and apache images. This would do away the need for that variable check at the top and also provide more flexibility in the future.

[tianon]

The intention is that the copied WordPress install lives in a persistent volume (especially so that WordPress itself can do automatic security updates, for example).

Is there a reason you're not including your volume in the cron container? Without it, anything that might change wp-content in any way won't be affected correctly either (nor will any custom themes, plugins, code, etc exist). 😬

I'm also very suspect of running sshd inside a container -- what's the logic for that? If there's a reason for it, why not use multiple containers instead of adding another process supervisor underneath the existing supervisors of Docker itself and whatever init system runs Docker?

[mattjbrent]

Hey @tianon thanks for replying on this.

Is there a reason you're not including your volume in the cron container? Without it, anything that might change wp-content in any way won't be affected correctly either (nor will any custom themes, plugins, code, etc exist).

I actually disagree with this - we treat the WordPress install itself as ephemeral. wp-content is volume mounted in using a fileshare. If we want to upgrade WP then we just update the container version through the Docker tag. Its much easier to test WP this way and run upgrades with 0 risk on the production environment.

I'm also very suspect of running sshd inside a container -- what's the logic for that? If there's a reason for it, why not use multiple containers instead of adding another process supervisor underneath

SSHD is a requirement for log extraction for our cloud hosting provider. I understand the generic rule but clearly (as in this case) there are use cases where process per container is unnecessary. In short, i dont want the images we use to dictate whether we run more than one process in a container.

A simple change to this file would make your container more extensible and easier to user for a wider range of use cases.

[yosifkit]

The check was added so that running the image like docker run -it --rm wordpress bash just works for exploring the image or running any other binary (even a supervisor) without requiring everything to be set like a normal WP container would need. Added in #91. This is a common requirement of all official images.

The entrypoint provides basically one thing, copying the contents of /usr/src/wordpress to the current working directory with the correct ownership (along with rename/copy of wp-config-docker.php). This can be worked around in the same way that the "Static image" section of the Docker Hub README does; by creating an image that isn't dependent on the copying that the entrypoint provides.