-
Notifications
You must be signed in to change notification settings - Fork 5.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Docker compose does not adapt on bridge driver changes #9203
Comments
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. |
More than 1 year later, I'm starting to face the same issue. Trying to use the subnet mask /29 in some cases raises this issue. My guess is the network is not recreated with the new settings as the container is recreated when any change in the docker compose is made. |
This issue has been automatically marked as not stale anymore due to the recent activity. |
compose reconciliation logic only applies to services, so changes made to networks won't force those to be recreated. This is something we should fix. |
Volumes are a little more dangerous since they can contain persistent non-recreatable information but there are probably settings that can be applied to already created volumes. But it is unexpected that changes in networks and volumes are not picked up at all |
This is actually a nasty issue. There are multiple discussions about this on the internet forums, but nobody seems to realize that docker leaves the old network after shutdown. Furthermore - the containers still refer to the old network ids even after removing it with |
04396BFA-5693-459C-8E26-2827491CDD7E/20220220130300
Expected behavior
Network bridge should adapt to the new changes automatically.
Actual behavior
I am using the bridge network driver inside a docker compose file to interact between services. When changing the subnet of the bridge and starting the compose file again with
docker compose -f docker-compose.yaml up --force-recreate
, the subnet does not change and instead uses the old cached one. I need to usedocker network prune
to delete the cached one first.The problems could be verified by a friend of mine with the same configuration.
Information
Output of
/Applications/Docker.app/Contents/MacOS/com.docker.diagnose check
Not sure why I get these errors, my docker images are starting fine.
Steps to reproduce the behavior
I created an example docker compose file as demonstration:
docker compose -f docker-compose.yaml up
Error response from daemon: Invalid address 10.6.0.6: It does not belong to any of this network's subnets
/30
to/29
docker compose -f docker-compose.yaml up
ordocker compose -f docker-compose.yaml up --force-recreate
Error response from daemon: Invalid address 10.6.0.6: It does not belong to any of this network's subnets
docker network prune
docker compose -f docker-compose.yaml up
The text was updated successfully, but these errors were encountered: