Volumes are not limited to store data in /var/lib/docker/volumes/{volumename}. They can do more than that: they can be used to mount remote fileshares or bind any local path (this is not the same as a bind-mount). Also -v /host/path:/container/path is not realy a volume, it is a bind-mount, which does nothing else than the shell command mount --bind {source path} {target path}. A bind-mount gets mounted on top of the target folder, which makes the previous content of the target folder unavailable to the container…
Like zacharyhdb wrote: Seperating the services by concern is the way to go. Use docker-compose.yml to orchestrate your container zoo.
When it commes to your commands:
Make sure to understand the difference of entrypoint scripts and commands in docker. Make sure you understand that your commands can only be provided when the container is created. Due to that your stop command doesn’t make sense.
Take a look at how sameersbn solved it for his gitlab image: https://github.com/sameersbn/docker-gitlab/blob/master/entrypoint.sh. He provides examples that create a oneshot container to execute a command and get removed again when finished: docker run --name gitlab -it --rm [OPTIONS] sameersbn/gitlab:13.0.3 app:rake gitlab:backup:create
I realy like that you think about the operation part of the process as well. Seeing someone anticipates backup/restore in the image design is realy nice.