Description

Description:
I am experiencing an issue with Docker Compose 2.24.6 on Windows, using Docker version 25.0.3. The problem revolves around how these versions handle network connections to a pre-made NAT network after a system restart. This behaviour is inconsistent with that observed in Docker Compose 1.29.2 and when using Docker commands directly (docker run), which manage the scenario as expected.

To observe the behaviour, follow the steps described in the "Steps To Reproduce" section for both versions 2.24.6 and 1.29.2.

Steps To Reproduce

1. Use the following docker-compose.yml configuration:

services:
  mongo:
    image: mongo
    restart: unless-stopped
    networks:
      - nat
networks:
  nat:
    external: true

2. Start the container with Docker Compose using docker-compose up -d
3. Inspect the network mode of the container with docker inspect --format='{{.HostConfig.NetworkMode}}' mongo
4. Restart the Windows operating system.
5. Check if the container is up and running. If not, investigate the failure reason.

Findings:

• For Docker Compose 1.29.2:

1. The container starts correctly
2. The command docker inspect returns nat, indicating a connection by network name.
3. After a system restart, the container continues to operate correctly.

• For Docker Compose 2.24.6:

1. The container initially starts correctly.
2. However, docker inspect returns a network ID (e.g., 96d6b0255d82eb1f904a9a502f333957a5260bee69fd16b2ecf5f337a23f72de), showing a connection by network ID rather than by name.
3. After a system restart, the container fails to start with an error indicating that the network with the specified ID could not be found:
   Error: "could not find a network matching network mode 96d6b0255d82eb1f904a9a502f333957a5260bee69fd16b2ecf5f337a23f72de: network 96d6b0255d82eb1f904a9a502f333957a5260bee69fd16b2ecf5f337a23f72de not found."

Core Issue:
The difference in the output of docker inspect between versions 1.29.2 and 2.24.6 is crucial. It reveals that version 1.29.2 connects to the network using its name, as anticipated, while version 2.24.6 uses the network ID for connection. This approach poses a problem after a system restart because the NAT network, though persistently present, is regenerated with a new ID. Consequently, this leads to a failure for containers expecting the network to retain the ID it had before the restart.

Temporary Workaround:
I have temporarily addressed this issue by transitioning from Docker Compose to a script that utilizes docker run. This method consistently delivers the expected behaviour, similar to Docker Compose version 1.29.2, by connecting to the network using its name.

Compose Version

Docker Compose version v2.24.6

Docker Environment

Client:
 Version:    25.0.3
 Context:    default
 Debug Mode: false

Server:
 Containers: 1
  Running: 0
  Paused: 0
  Stopped: 1
 Images: 1
 Server Version: 25.0.3
 Storage Driver: windowsfilter
  Windows:
 Logging Driver: json-file
 Plugins:
  Volume: local
  Network: ics internal l2bridge l2tunnel nat null overlay private transparent
  Log: awslogs etwlogs fluentd gcplogs gelf json-file local splunk syslog
 Swarm: inactive
 Default Isolation: process
 Kernel Version: 10.0 17763 (17763.1.amd64fre.rs5_release.180914-1434)
 Operating System: Microsoft Windows Server Version 1809 (OS Build 17763.5458)
 OSType: windows
 Architecture: x86_64
 CPUs: 4
 Total Memory: 16GiB
 Name: WinServer2019-2
 ID: da86a901-e074-4baf-97df-bcacd34ca4e5
 Docker Root Dir: C:\ProgramData\docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false
 Product License: Community Engine

Anything else?

This issue renders the solutions specified in the following issue unusable: docker/for-win#3076