PRE_ENTRYPOINT_RUN Feature Request

General Discussions Feature Requests
1

Hello,

When derivating an existing image with an existing entrypoint (think apache, mariadb, etc), it is quite common to have some extra process needed to be done at the entry point (aka wiring/glue things), but at this time there is no clean way to prepend operation before the entrypoint.

AFAIK, the current way would be to duplicate the entrypoint script and update it with your own required extra work. The issue with this is that as soon as the entrypoint of the parent image is updated, you can have a broken image. There are also solutions that the parent entrypoint script would provide some extra “extension script” as bundled. But it is almost never the case, and you can not spend your life trying to convince all the image maintainer to do so :wink:

I propose to get somethign like PRE_ENTRYPOINT_RUN.
The idea is that before calling the entrypoint, docker will build a list of PRE_ENTRYPOINT_RUN command and execute them in the parent to child and in the first to last order. Once done, it will do the usual job for ENTRYPOINT.

Doing so, you would be able to derive a existing container including its entrypoint but bring extra glue on it for your extra features of your image without impacting the parent image.

The name of the command PRE_ENTRYPOINT_RUN can be changed … but I think the name is quite clear.

Rgs,
JB

2

This isn’t hard to do with current Docker features. Say you know that the original image declares

ENTRYPOINT ["/entrypoint.sh"]

Then you need to write your own entrypoint script

#!/bin/sh
echo "I'm doing my exciting setup now!"
# then run the original entrypoint
exec /entrypoint.sh "$@"

and in your derived Dockerfile

FROM whateverbaseimage
COPY new-entrypoint.sh /new-entrypoint.sh
ENTRYPOINT ["/new-entrypoint.sh"]
3

Thanks David for this proposition. This is still interresting as a temporary solution. But it has some big drawbacks : it would means an child image is now depending on the ENTRYPOINT of it’s parent to initialize its run context.

As a consequence, any image one made public should never change their entrypoint for any reason, or they should keep at least forever a “legacy entrypoint” that retain compatibility with any potentialy derivated image. The derivated image maintainer will have to make sure that the entrypoint target was not updated at anytime or it can break their existing image (public or private).

This is adding impact on the parent image maintainer. This is adding a real risk on the derivated images.

That is why I only looked for a “prepend run on the entrypoint” (aka PRE_ENTRYPOINT_RUN) which is much simple & safer for maintainer and not a whole entrypoint extension mechanism.

Rgs,
JB