Closed fthorns closed 5 years ago
Hi, the /tmp
folder is required by some middlewares (ex: buffering)
Hi, thanks for the explanation. Would it be generally advisable to put /tmp/ on a persistent volume? Right now it seems that the volumes are not reused in any of the documentation's examples, so the data could as well just stay in the ephemeral storage of the container. The current documentation leads to a huge number of orphaned volumes over time, so it might be worth to either drop the volume or advice handling it correctly. Not sure which way is the preferable one, though.
Fabian
I agree with fthorns: Either this volume should be removed from the Dockerfile, or the documentation should explicitely specify it should me mapped.
Would it be generally advisable to put /tmp/ on a persistent volume
I don't think this is required...
could as well just stay in the ephemeral storage of the container
This could cause a performance issues... so using a volume is preferable I think...
Perhaps we could just add some documentation mentioning which middlewares needs this facility ... then it's simple to mount tmpfs or some other storage where required...
could as well just stay in the ephemeral storage of the container
This could cause a performance issues... so using a volume is preferable I think...
Perhaps we could just add some documentation mentioning which middlewares needs this facility ... then it's simple to mount tmpfs or some other storage where required...
If it boosts performance for certain middlewares it might be worth documenting it as a tuning tip (it's still possible to mount a volume to any path, even without the path being explicitly declared in the Dockerfile). If the user is aware of the volume they might even consider preserving it across container restart to avoid building up the cache over and over again.
The buffering middleware is an example of why this volume is needed.
If there is no /tmp
directory, the buffering middleware will fail. We generate this volume to ensure that the directory is present due to being based off a scratch image.
We had a choice to make a bare directory or a volume for this, and we chose to make a volume due to flexibility and giving more options to operators.
We had a choice to make a bare directory or a volume for this, and we chose to make a volume due to flexibility and giving more options to operators.
Is this documented anywhere? I found a large list of empty Docker Volumes in my Docker Swarm today and found my Traefik service was the one creating these every time it was restarted.
With that said, is there any need to have the /tmp directory be persistent between restarts? This use of the VOLUME instruction doesn't seem to be the correct use in this case.
Hi, The usage of the VOLUME
instruction in a Dockerfile is really different than the kind of "mount" to be used:
The instruction VOLUME
is a metadata telling that this directory will carry data with a lifecycle different than the container's. It is expressed at build time in a portable way. This is why we use this: to express that the data read/written into the directory /tmp
is different than the default filesystem of the container (like the binary). Docker's documentation is really explicit about this: https://docs.docker.com/engine/reference/builder/#notes-about-specifying-volumes
The "mount type" is expressed at runtime. It express "how" you want the data layer of a given volume to be implemented, depending on the execution context. It's generally a combined matter of I/O performances + persistence properties. In the case of /tmp
, the best is to do a tmpfs
mount, so data is ephemeral, does not survive container restarts, and the I/O is really efficient. SO you don't have long term persistence AND you have to be careful on the amount of data written to not exhaust your RAM.
BUT there are numerous cases where tmpfs is not an option for bind mounting a volume. So Docker assumes, by default, that a "VOLUME" (as declared in the container metadatas) is still having a different lifecycle than container's FS, by using a local anonymous volume.
A very good practise is to run container with the flag --read-only
which will lock in read-only the container's filesystem, allowing writing only on volumes and mounts. 2 reasons for such a practise:
/tmp
requires: performances. So using a volume is the solution.docker run --read-only=true traefik
, the user experience is terrible, as Traefik will crash immediately because not able to write in /tmp, so not starting.From these theoretical concerns, a few tasks should be done:
VOLUME
instruction of Traefik to meet ALL the folders where it could write by default (I'm not sure if /var/run
is not required)./tmp
(and /*/run
) as tmpfs.docker system prune
with the right option to efficiently clean up anonymous volumes. Because Traefik is not the only one container with such behavior, as it follows the Docker good practises, as explained in Docker's documentation: https://docs.docker.com/config/pruning/About advertising "how to handle" these volumes, it's a complicated topic, as it is a general matter to ALL projects using Docker containers. Should Traefik's project tell its user how to use Docker? This would be a huge effort, and would lead to a never-up-to-date documentation right? However, it's open source, do not hesitate to propose a change in the doc, understanding that the community of maintainers will have to carry such a change ("No is temporary, Yes is definitive").
Is this behaviour only related to the scratch base image or alpine too?
Just to confirm, this is enforced because it avoids extra steps by the user to ensure they're mounting tmpfs?
Is there a way for a user to override the approach here that still works but avoids creating anonymous volumes each time? I'm pretty sure I've used a container in the past that would write to /tmp on the host but it wasn't piling up anonymous containers mentioned here :/
@polarathene , the behavior is the same for both images, because of the use of instruction "VOLUME
" in both Dockerfiles.
You can definitively avoid anonymous volumes by providing a name for each mountpoint:
docker run -v tmp-for-traefik:/tmp .... traefik
But again, you strongly should run a docker system prune -f --volumes
everyday to cleanup dangling images, anonymous volumes, unused networks, so you keep your Docker engine clean and lean.
I want use tmp disk in memory (tmpfs). What max size can be for this tmp disk? and what will happen if out free space?
Hi there,
the Dockerfile requests a volume to be mounted at /tmp. In case no volume is explicitly mounted when the container is started, Docker creates a new volume every time the container is created. Since the documentation does not advice to mount a volume to /tmp, it seems that this volume is not needed. It would be great if someone could confirm that there is no need for the /tmp volume and drop the VOLUME clauses from the Dockerfiles.
Regards,
Fabian