docker-entrypoint.sh noops without $1 = "apache2" || "php-fpm", blocking image extension

[pnloyd]

This is preventing the creation of images that can do things like running an instance of nginx alongside php-fpm controlled by some process manager. You kind of need to be able to change the CMD for that to work smoothly, but because of the current behavior you lose all the valuable work that's done inside of docker-entrypoint.sh, which kinda seems like the whole point of these images.

I'm curious what the use case is for calling docker-entrypoint.sh without php-fpm, which literally does nothing. And how that use case is so valuable that it is worth blocking the extension of this image. If it was really important that the contents of docker-entrypoint.sh where not executed, ENTRYPOINT could just be changed to something else.

I've seen maintainers dismiss multiple requests for nginx images on the premise that it is against the "seperated services" design pattern, but I don't see a clean way for people to make their own images with nginx with the way it is right now.

[pnloyd]

I understand there're workarounds like making the CMD start with apache2, but still this feels odd when apache2 isn't present in the image. Perhaps allowing a more generic prefix would at least allow for better semantics. alt-daemon, alt-start, maybe something like that..

[yosifkit]

We have it skip everything in the entrypoint on non apache/fpm binaries because of the requirement for a consistent interface for official images. As far as making it easier to extend to have it always do init stuff before the exec, I'm not sure what you'd want that would keep the consistent interface. Maybe we split the startup script and init part so that it could be called directly?

[pnloyd]

Ya that would think that would would address the use case I'm talking about.

I have to comment, the notion of what a consistent interface means in this case must be flying over my head. I don't think moving wordpress into /var/www/html or other init details impedes the functionality of docker run myimage bash.

Also I can't imagine why with all of the Docker images available for so many different purposes, someone would go and choose the one designed to run wordpress on php-fpm, and try to use it for a purpose that did not require the init details in docker-entrypoint.sh to run.

It seems to me that this is making the interface inconsistent with the purpose of the image. I'm very new to Docker (just a few weeks) so maybe there're some fundamental concepts I need to understand better. In either case, splitting out the init logic into a separate file would allow an option for use case of running nginx alongside php-fpm and still taking advantage of the images docker-entrypoint.sh work so that would be good.

[tianon]

Sorry for the long tail.

I'd like to back up a little bit and clarify the original issue -- what is it that you're trying to accomplish that is difficult to do today? What sort of additional behavior are you attempting to add?

[joeldeteves]

We're in a similar position as @pnloyd - we've extended the Alpine FPM image using FROM, nginx + supervisord - it seems to be a nice balance as it is still somewhat 'self-contained' while consuming a lot less memory than the Apache image does. So I tend to agree having additional logic other than apache2 for the entrypoint would be nice. BTW our workaround for now is to just copy the entrypoint script from the repo and add the logic to it ourselves.

[gwynnarth]

+1 for more flexibility here.

We run a image that is based on wordpress image, but runs some custom initialization scripts.
Currently we have to do this:

FROM wordpress:5.0.1-fpm

# UGLY fix :(
# We need docker-entrypoint.sh to work its magic and then pass control to our custom start script
# But by default only "apache2" and "php-fpm" are allowed
RUN sed -i 's/^if \[\[ "$1" == apache.*$/if \[ true \]; then/' /usr/local/bin/docker-entrypoint.sh
[...]
# Startup scripts and configs
COPY scripts /scripts
[...]
CMD ["docker-entrypoint.sh", "/scripts/start.sh"]

We don't want to override docker-entrypoint.sh completely, because it does a lot of useful stuff (and we want that stuff to be done PRIOR to our custom setup script executes; we need wp-config.php to be in place and ready when /scripts/start.sh executes.

Currently I don't see a different option than disabling that check via the ugly sed command (better ideas are welcome).

[joeldeteves]

@Attis the SED is a lot less ugly than copying the script so thank you for that!