Docker - mounting docker-entrypoint.sh as a bind volume

[JerryMungo]

.

 

[SauRoNZA]

I don’t use Docker this way but I’m pretty sure the file IS on the host file system already as it starts up and sets parameters for the Docker at runtime.

So there should be no need to bind.

If you meant to alter the file from inside the Docker image, then simply mouth the path of the file inside the Docker file system like you would any other folder and you’ll have access to it.

 

[dadecoza]

Is it possible to mount docker-entrypoint.sh as a bind volume to a file on the host file system to allow dynamic updates to the docker-entrypoint.sh file?

Why?

you don't need to run the entry point when starting the container ...

docker run --entrypoint='' someimage 'command you want to execute within container'

 

[SauRoNZA]

Great, that entrypoint parameter, does it point to a file on the host or in the container?

The container doesn’t exist yet when that command is run, so it must be on the host.

 

[dadecoza]

Great, that entrypoint parameter, does it point to a file on the host or in the container?
I'm assuming a file on the container that I can then map to a file on the host.

in the container.

do you use a custom Dockerfile?

 

[SauRoNZA]

I think the entrypoint exists in the container if I'm not mistaken. It should be baked into the image.

It’s a weird thing I don’t quite understand the purpose of.

Have never needed it and hence don’t quite see the point.

 

[SauRoNZA]

It's useful for setting up the environment, e.g. I can deploy an updated tomcat .war from my host whenever the container starts up. I can poll the database container and keep polling it until it's up before I launch tomcat, etc.

Aah right it makes sense for bespoke solutions running multiple things, so I can see that now.

For me Docker runs a singe application only and so Tomcat itself would have been the Docker that would update whenever a new version is available etc.

Then multiple Dockers talk to each other.

But I have seen setups like you mention where it’s an entire OS with multiple layers and closer to a VM so I can see the use case there.

 

[dadecoza]

Kind of yes, but its built by a third party.

I'm not sure exactly what you want to do? You can create a new entrypoint file and update the Docker file to copy it over when the image is built.

Or you can copy a file over to a running container from the host ie ... docker cp myshellscript.sh containerid:/
and then you can run the script to copied to the container by running ... docker exec -t -i containerid /myshellscript.sh

or you can just mount the volume with all your scripts when you "run" the container and then when the container is running log into it by doing a docker exec -t -i containerid /bin/bash and cd to the mount point and run the script you want ( i use this method while doing dev)

hope it makes sense.

 

[Chiller89]

Thanks, what I'm trying to achieve is be able to automate the startup of the container, modify the environment, etc. and perform tasks before the main executable is launched... I want to be able to change that start up on the fly without making changes to the container that require commits and redeployment of containers.

I'd definitely recommend having a standardised entrypoint script that executes what you need to execute, but takes in parameters from the entrypoint command using something like "$@" (if the entrypoint script is bash)
That way, your entrypoint script remains consistent across docker builds, but you can modify the entrypoint command on the fly to pass in different parameters for boot up as required (via docker run, the compose "command" argument, or something similar.)

Quite tough to give an exact solution without knowing quite what you need to modify/what differs between boot commands though. Additionally, changing the boot command of the container is going to require it to restart regardless, so I am unsure how you would achieve changing the start up on the fly without a restart/redeployment, it would require it either way.

 

[dadecoza]

hmmm okay, maybe you should then use environment variables and update entrypoint to perform the tasks based on the environment variable values.

docker run -e DOTASK1=1 -e DOTASK2=1 -e DOTASK3=0 ...

in your enrypoint script ...

if [ "$DOTASK1" == "1" ]
then
echo "performing task1"
fi

if [ "$DOTASK2" == "1" ]
then
echo "performing task2"
fi
...

echo "continue with tasks that will always execute ...."

 

[Chiller89]

I think the main thing is that I don't like the default entry-point that comes with the image so I want to use my own without having to push changes to the container / image every time I deploy an image update if that makes sense.

The image is basically a postgis enabled postgresql server.

Then I would recommend building your own image, baking your custom entrypoint script into the image at build time, which accepts parameters (something like what @dadecoza mentioned above) and using that custom image, as opposed to continuing to use the untouched upstream image.

 

[dadecoza]

i don't like it but what you can try ...

assuming you have a /home/daruk/scripts directory containing your docker-entrypoint.sh script ...

untested ...

docker run -v /home/daruk/scripts:/scripts --entrypoint='/scripts/docker-entrypoint.sh' imagename

 

[dadecoza]

That's pretty much what I'm going to try, thanks for the input. That will allow me to update the script and not have to keep applying it to the updated image when the Dev releases it.

Any reason you don't like it?

The entrypoint script should be contained within the container as part of the image.