28
-V, --renew-anon-volumes   Recreate anonymous volumes instead of retrieving
                               data from the previous containers.

Does docker-compose up -V not apply to named volumes?

I have a service that, at image build time, pulls some files from SVN. It then creates a named volume. I can docker-compose build --no-cache to recreate the image and pull latest files from SVN. But the volume doesn't get updated on docker-compose up -V, unless I remove it beforehand.

I just want a clean and simple way to update files in a named volume

Sure, I could manually remove the volume, and then run everything, but I really wanted it to be compose-driven. This leads me to a second problem.

There is a docker-compose down -v that will also remove volumes, but I cannot run that against a single service (only all or nothing).

So I need to somehow figure out the named volumes of just 1 service from compose-file, and then use some extra command (docker volume rm?) to remove just that one volume.

Slav
  • 27,057
  • 11
  • 80
  • 104
  • What if you have an entrypoint script for that service that updates files? – Stefan Golubović Mar 24 '20 at 18:44
  • @StefanGolubović I considered that, but I thought that it was bad practice to have an immutable container that depended on an online resource to start. What if SVN is down when I start container? Sure, I can have entrypoint fail silently, but then I am in a position that I don't even know if the service updates files or not (without digging through logs). – Slav Mar 24 '20 at 20:45
  • I'm facing this exact problem. Have you found an elegant solution to this @Slav ? – Lucas Apr 18 '22 at 20:07
  • 1
    @Lucas sorry I haven't – Slav Apr 19 '22 at 23:13

1 Answers1

20

If you don't care about the content of a named volume, either don't create it in the first place (remove the named volume line in the compose file) or delete it when you stop the project with:

docker-compose down -v
BMitch
  • 231,797
  • 42
  • 475
  • 450
  • 3
    Thanks. Sorry, I edited the question after you replied. I can't use `down -v` cause there are other services/volumes in the compose file – Slav Mar 24 '20 at 18:20
  • Then either delete the named volume from your compose file so it doesn't get created in the first place, or you're back to manually deleting that volume between builds. – BMitch Mar 24 '20 at 18:21
  • 1
    You may also be interested in the volume caching scripts in this repo: https://github.com/sudo-bmitch/docker-base – BMitch Mar 24 '20 at 23:20
  • Mmm @BMitch, that looks very useful – Slav Mar 25 '20 at 00:40
  • 1
    The problem with removing the named volume from the compose file is sometimes you need multiple containers to share the same files but don't want any changes to be persistent. See: https://stackoverflow.com/q/66385965 – Richard Hansen Mar 15 '22 at 19:37
  • There are use cases where you _do care_ about the named volume, and destroying it does not actually remove the data. For example, modifying options for an rclone-backed volume is currently very cumbersome, and having a way to force it to get recreated would help in tuning volume parameters. – Andrew Theken Dec 17 '22 at 12:31
  • @AndrewTheken I get the desire to have a new feature in the upstream project, but the most I can do here is describe what capabilities already exist in that project. To request a new feature, consider opening an issue or PR on the compose project. – BMitch Dec 17 '22 at 14:16