renew-anon-volumes

[basz]

a flag (--renew-anon-volumes) to docker-compose was just added and i was wondering if there are any plans to add it to docker stack deploy as well.

https://github.com/docker/compose/pull/5596 (merged) https://github.com/docker/compose/issues/5400

[vdemeester]

cc @dnephin @thaJeztah @cpuguy83

I'm not sure it makes sense in docker stack deploy and swarmkit.

[cpuguy83]

Does not apply to swarm. Anonymous volumes are different for every task.

[thaJeztah]

When re-deploying a stack, new containers are created, and docker stack deploy does not attempt to keep the old volume if it's an anonymous volume.

@basz do you have more information about this request? perhaps an example where docker stack deploy did not work as expected?

[basz]

I might have confused anonymous with named volumes. Although I read they behave the same:

"When you mount a volume, it may be named or anonymous. Anonymous volumes are not given an explicit name when they are first mounted into a container, so Docker gives them a random name that is guaranteed to be unique within a given Docker host. Besides the name, named and anonymous volumes behave in the same ways." (docker.com)

Anyway here's why I would appreciate an option like this for named volumes in a docker stack deploy context. https://github.com/docker/compose/issues/5400#issuecomment-355398912 Most fundamentally I'm using containers to deploy code to a volume and have service containers access that. When the image changes but the named volume already exists its contents isn't updated. If there are better practices which solve this problem, please let me know...

[dnephin]

I'm using containers to deploy code to a volume

I would suggest not using a volume for code. Code should be tied to a specific version of dependencies in an image. Trying to separate the code from the dependencies will make it a lot harder to update dependencies.

Put the code into the image and re-deploy the image.

[basz]

@dnephin I'm listening... I am under the impression that it is good practice to either create one image with all services contained in it (like a gitlab image does) and that is a great fit for fast deployment by third parties or create containers for each service needed by an application. I'm trying to do the later - as we will update source much more often then its services. In our case a PHP based application needs an nginx container and php-fpm image. It also uses some long running PHP processes that would also sit in their own containers. Each of the services mentioned above would require access to the source and that is where my setup comes from... a named volume with the source mounted by several containers that need it. See what I'm getting at? Please enlighten me if you still think I'm doing this wrong... Sort of newish to this and I found it hard to find a good tutorial

[dnephin]

create one image with all services contained in it

I would not consider that a good practice. I would create an image for each service and use docker-compose to bring them up. It's probably fine as a quick way to demo software, but I wouldn't want to use it for day-to-day development or production.

create containers for each service needed by an applicatio

:+1:

Each of the services mentioned above would require access to the source and that is where my setup comes from

Do they need read-only access or read-write access?

Read-only is easy, just COPY . . as the last step in each image (or copy a subset of files if the service doesn't need all of them).

For read-write in a development environment you can use a "bind mount volume" instead of a named volume. That will enable some services to pickup code changes without re-deploying.

Named/Anon volumes are really for data that changes independently from the application. They persistent after containers/services are stopped. Code is part of the application so fits much better as part of the image.