Open NReilingh opened 1 year ago
Nice catch. Compose indeed check service configuration has changed (using a hash) to detect need to recreate, but doesn't check the networks or volumes mounts match the global project configuration.
Actually, while I expected we did, volumes don't get re-created on configuration change - this involves a risk to loose data, so would at least require an explicit flag or user to confirm volume replacement.
@ndeloof Hm, that doesn't seem consistent with what I'm experiencing.
services:
changer:
image: ealen/echo-server
container_name: changer-container
volumes:
- changer-vol:/changervol
volumes:
changer-vol:
name: first
changee-vol:
name: second
If I docker compose up -d
this configuration, then the first
volume is created. Then if I change line 6 from changer
to changee
and re-run docker compose up -d
, the container is recreated using the second
volume, which is created. first
is not deleted, but persists on the host.
@NReilingh because you change volume name
(which is equivalent to defining another volume). If you change another configuration attribute in a volume, this won't get detected.
@ndeloof I might just not be getting this, but isn't that consistent with my initial issue? The only change was the name
attribute, so the original volume should not have been recreated (causing data loss), but the container should have been recreated.
Initial:
services:
changer:
image: ealen/echo-server
container_name: changer-container
volumes:
- changer-vol:/changervol
volumes:
changer-vol:
name: first
Change causes container re-creation:
services:
changer:
image: ealen/echo-server
container_name: changer-container
volumes:
- changed-vol:/changervol # <- Modified
volumes:
changed-vol: # <- Modified
name: second # <- Modified
Change does not cause container re-creation:
services:
changer:
image: ealen/echo-server
container_name: changer-container
volumes:
- changer-vol:/changervol
volumes:
changer-vol:
name: second # <- Modified
The only change was the name attribute, so the original volume should not have been recreated (causing data loss)
name
is not just a configuration attribute, but actually the unique ID for a volume, changing this means you ask Compose to switch to a distinct volume. basically
services:
changer:
volumes:
- foo:/path
volumes:
foo:
name: bar
is equivalent to:
services:
changer:
volumes:
- bar:/path
volumes:
bar: {}
name
should be used to target an existing volume you want to mount, this has no real benefits if you want compose to manage volume lifecycle for you.
As any attribute under services
definition is updated, the configuration hash changes and compose detect container needs to be recreated. But using the volume.name attribute to change the volume ID you made this invisible to service configuration - this is something we must fix.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically marked as not stale anymore due to the recent activity.
Description
Docker compose up is supposed to observe the state of running containers, compare this to the service definition, and recreate containers that need to be converged to the definition.
The options
--force-recreate
and--no-recreate
are meant to override this behavior, so they are not specified when you want containers only to be recreated if a change is needed to bring them in line with the service definition.When a service definition references a named volume defined in the top level element, currently a change to that volume configuration does not result in existing containers using that named volume being recreated.
Steps To Reproduce
This is tested on Docker Desktop Mac (Apple Silicon)
volumes: changer-vol: name: first
Docker Environment
Anything else?
No response