Docker compose does not adapt on bridge driver changes

neumann-nico commented 2 years ago

[x] I have tried with the latest version of Docker Desktop
[x] I have tried disabling enabled experimental features
[x] I have uploaded Diagnostics
Diagnostics ID: 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 use docker network prune to delete the cached one first. The problems could be verified by a friend of mine with the same configuration.

Information

macOS Version: 12.3
Intel chip or Apple chip: Apple M1 Pro
Docker Desktop Version: 4.6.0 (75818)

Output of `/Applications/Docker.app/Contents/MacOS/com.docker.diagnose check`

Not sure why I get these errors, my docker images are starting fine.

> /Applications/Docker.app/Contents/MacOS/com.docker.diagnose check
Starting diagnostics

[PASS] DD0027: is there available disk space on the host?
[PASS] DD0028: is there available VM disk space?
[PASS] DD0031: does the Docker API work?
[PASS] DD0004: is the Docker engine running?
[PASS] DD0011: are the LinuxKit services running?
[FAIL] DD0016: is the LinuxKit VM running? vm is not running: vm has not started
[PASS] DD0001: is the application running?
[PASS] DD0018: does the host support virtualization?
[FAIL] DD0017: can a VM be started? vm has not started: vm has not started
[PASS] DD0015: are the binary symlinks installed?
[PASS] DD0003: is the Docker CLI working?
[PASS] DD0013: is the $PATH ok?
[PASS] DD0007: is the backend responding?
[PASS] DD0014: are the backend processes running?
[PASS] DD0008: is the native API responding?
[PASS] DD0009: is the vpnkit API responding?
[PASS] DD0010: is the Docker API proxy responding?
[PASS] DD0012: is the VM networking working?
[PASS] DD0032: do Docker networks overlap with host IPs?
[SKIP] DD0030: is the image access management authorized?
[PASS] DD0019: is the com.docker.vmnetd process responding?
[PASS] DD0033: does the host have Internet access?

Please investigate the following 1 issue:

1 : The test: can a VM be started?
    Failed with: vm has not started: vm has not started

The Docker engine runs inside a Linux VM. Therefore we must be able to start Virtual Machines.

Steps to reproduce the behavior

I created an example docker compose file as demonstration:

version: '2'
services:
  nginx:
    image: nginx:latest
    ports:
      - "80:80"
    networks:
      nginx_bridge:
        ipv4_address: 10.6.0.6
    container_name: nginx_container

networks:
  nginx_bridge:
    driver: bridge
    ipam:
     config:
       - subnet: 10.6.0.0/30  # tried /30 first, then changed to 10.6.0.0/29 -> still failes

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
- Error is intended to be like this because the IP does not belong to the network -> change /30 to /29
docker compose -f docker-compose.yaml up or docker 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
- This error should not occur anymore as we changed the subnet mask
docker network prune
docker compose -f docker-compose.yaml up
- Now it is starting

stale[bot] commented 1 year ago

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.

neoacevedo commented 1 year ago

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.

stale[bot] commented 1 year ago

This issue has been automatically marked as not stale anymore due to the recent activity.

ndeloof commented 1 year ago

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.

nbrugger-tgm commented 1 year ago

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

AlekseyMalyshev commented 1 week ago

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 docker network rm <name>. I figured that I need to run sudo docker-compose stop --remove-orphans and then start it over.

docker / compose