I'm creating a Containerfile where I receive an input folder from the host that contains files I need inside my container.
The best way I know would be passing it through a volume like:
-v /host/path:/opt/input.
But I'd like to abstract the /opt/input from the container's user the same way it's possible pass a volume name:
-v volume-name:/opt/input.
The VOLUME doesn't quite work like this, but what I'm trying to achieve is:
VOLUME ["input-data": "/opt/input"]
So the user may do:
-v /host/path:input-data
And making easier to evolve the container file without breaking compatibility if I someday need to change that path.
Is there some other alternative that I couldn't yet figure out?
Neither Docker nor Podman has any way to abstract a container path the way you suggest.
I tend to treat the container-side filesystem paths and container ports as part of the image's externally-visible interface. That is, the right-hand side of {docker,podman} run -v and -p options are well-known fixed values. If you as the image author decide to change these paths, you're changing the command that a user needs to use.
If you control these paths, I might try picking a short and obvious path, maybe just /input as opposed to /opt/input. You might be able to set an ENV variable or RUN ln -s create a symlink if the application by default expects the input somewhere else.
sudo docker run -u $(id -u) -v "$PWD/input:/input" ...
# this path is known and fixed ^^^^^^
You do not need a Dockerfile VOLUME for places you expect external content to be mounted. This directive has two effects: when you run a container, if nothing else is mounted there, the container runtime creates an anonymous volume for you; and future RUN commands can't change the directory. You can docker run -v mount external content over any container directory, regardless of whether or not it's a Dockerfile VOLUME. If you're not sure on any of the semantics or details around VOLUME, it's generally safe to just delete the Dockerfile directive entirely.