Como se menciona en los comentarios, no hay una solución integrada para esto. Desde Dockerfile, no puede ver el valor del CMD o ENTRYPOINT actual. Es bueno tener una solución run-parts si controla la imagen base ascendente e incluye este código allí, lo que permite que los componentes descendentes realicen sus cambios. Pero docker hay un problema inherente que causará problemas con esto, los contenedores solo deben ejecutar un único comando que debe ejecutarse en primer plano. Por lo tanto, si la imagen ascendente se inicia, seguirá ejecutándose sin dar a sus pasos posteriores la oportunidad de ejecutarse, por lo que le quedan complejidades para determinar el orden en que se ejecutarán los comandos para garantizar que un solo comando finalmente se ejecute sin salir.

Mi preferencia personal es una opción mucho más simple y codificada, para agregar mi propio comando o punto de entrada, y hacer el último paso de mi comando para exec el comando ascendente. Aún deberá identificar manualmente el nombre del script para llamar desde el Dockerfile ascendente. Pero ahora en tu start.sh , tendrías:

 #!/bin/sh # run various pieces of initialization code here # ... # kick off the upstream command: exec /upstream-entrypoint.sh "$@"

Al usar una llamada exec , transfiere el pid 1 al punto de entrada ascendente para que las señales se manejen correctamente. Y el "$@" final pasa a través de los argumentos de la línea de comandos. Puede usar set para ajustar el valor de $@ si hay algunos argumentos que desea procesar y extraer en su propio script start.sh .

Si la imagen base no es suya, lamentablemente debe llamar al comando principal manualmente.

Si posee la imagen principal, puede probar lo que sugiere la gente de camptocamp aquí .

Básicamente, utilizan un script genérico como punto de entrada que llama run-parts en un directorio. Lo que hace es ejecutar todos los scripts en ese directorio en orden lexicográfico. Entonces, cuando extiende una imagen, solo tiene que colocar sus nuevos scripts en esa misma carpeta.

Sin embargo, eso significa que tendrá que mantener el orden anteponiendo sus scripts, lo que podría salirse de control. (Imagínese que la imagen principal decide agregar un nuevo script más tarde...).

De todos modos, eso podría funcionar.

Actualización #1

Hay una larga discusión sobre este problema de composición de la ventana acoplable sobre el aprovisionamiento después de la ejecución del contenedor. Una sugerencia es envolver su docker ejecutar o componer comando en un script de shell y luego ejecutar docker exec en sus otros comandos.

Si desea utilizar ese enfoque, básicamente mantiene el CMD principal como el comando de ejecución y coloca el suyo como un ejecutivo de la ventana acoplable después de ejecutar la ventana acoplable.

Usando la imagen mysql como ejemplo

docker inspect mysql/mysql-server:5.7 y vea que:

• Config.Cmd="mysqld"
• Config.Entrypoint="/entrypoint.sh"

que ponemos en bootstrap.sh (recuerda chmod a+x):

 #!/bin/bash echo $HOSTNAME echo "Start my initialization script..." # docker inspect results used here /entrypoint.sh mysqld

Dockerfile es ahora:

 FROM mysql/mysql-server:5.7 # put our script inside the image ADD bootstrap.sh /etc/bootstrap.sh # set to run our script ENTRYPOINT ["/bin/sh","-c"] CMD ["/etc/bootstrap.sh"]

Cree y ejecute nuestra nueva imagen:

• docker build --rm -t sidazhou/tmp-mysql:5.7 .
• docker run -it --rm sidazhou/tmp-mysql:5.7

Salidas:

 6f5be7c6d587 Start my initialization script... [Entrypoint] MySQL Docker Image 5.7.28-1.1.13 [Entrypoint] No password option specified for new database. ... ...

Verás que esto tiene el mismo resultado que la imagen original:

docker run -it --rm mysql/mysql-server:5.7

 [Entrypoint] MySQL Docker Image 5.7.28-1.1.13 [Entrypoint] No password option specified for new database. ... ...