Problem with external network (when executing the command docker compose down)

[maxbur89]

Description Problem with external network when executing the command "docker compose down"

Steps to reproduce the issue:

docker compose -f lubimovka_frontend_develop_deploy.yml --env-file /usr/local/src/develop/.github_vars down
[+] Running 0/0
 ⠿ Network develop_swag_network  Error                                                                                                                                                                                                                                     0.0s
 ⠿ Network develop_db_network    Error                                                                                                                                                                                                                                     0.0s
failed to remove network 1bca0c197facf1c42f2762c6a3b3412ab1798a4a7076e0195ce5ab8054bc36a3: Error response from daemon: error while removing network: network develop_swag_network id 1bca0c197facf1c42f2762c6a3b3412ab1798a4a7076e0195ce5ab8054bc36a3 has active endpoints

Network defined as external:

networks:
  develop_swag_network:
    external: true
    name: develop_swag_network

The documentation says that the external network is not deleted. https://docs.docker.com/compose/reference/down/ "Networks and volumes defined as external are never removed."

At the same time, the old version 1.29.2 works fine:

docker-compose -f lubimovka_frontend_develop_deploy.yml --env-file /usr/local/src/develop/.github_vars down
WARNING: Found orphan containers (swag_develop, backend_develop, postgres_develop, migrations_develop) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up.
Network develop_swag_network is external, skipping

lubimovka_frontend_develop_deploy.yml:

version: '3.8'

services:
  frontend_develop:
    image: "${IMAGE_FRONT}:${IMAGE_FRONT_TAG}"
    container_name: frontend_develop
    environment:
      BASE_URL: ${FRONT_BASE_URL}
      API_BASE_URL: ${DEVELOP_API_BASE_URL}
    networks:
      - develop_swag_network
    ports:
      - "3005:3000"
    restart: always
  frontend_test:
    image: "${IMAGE_FRONT}:${IMAGE_FRONT_TAG}"
    container_name: frontend_test
    environment:
      BASE_URL: ${FRONT_BASE_URL}
      API_BASE_URL: ${TEST_API_BASE_URL}
    networks:
      - develop_swag_network
    ports:
      - "3004:3000"
    restart: always

networks:
  develop_swag_network:
    external: true
    name: develop_swag_network

Describe the results you received:

Describe the results you expected:

Additional information you deem important (e.g. issue happens only occasionally):

Output of docker compose version:

Docker Compose version v2.2.3

Output of docker info:

docker info
Client:
 Context:    default
 Debug Mode: false
 Plugins:
  app: Docker App (Docker Inc., v0.9.1-beta3)
  buildx: Docker Buildx (Docker Inc., v0.7.1-docker)
  compose: Docker Compose (Docker Inc., v2.2.3)
  scan: Docker Scan (Docker Inc., v0.12.0)

Server:
 Containers: 4
  Running: 3
  Paused: 0
  Stopped: 1
 Images: 4
 Server Version: 20.10.12
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 7b11cfaabd73bb80907dd23182b9347b4245eb5d
 runc version: v1.0.2-0-g52b36a2
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: default
 Kernel Version: 5.4.0-42-generic
 Operating System: Ubuntu 20.04.3 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 2
 Total Memory: 3.844GiB
 Name: temp-test-deploy-server-lub
 ID: HWNU:5MTB:36V6:SWPY:LCKV:FJ3J:LC57:35PQ:FP2D:EAQK:SZ3U:VJBQ
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: No swap limit support

(paste your output here)

Additional environment details:

[larssb]

Anyone on this? I just tried with the --compatibility flag to get docker-compose v2 to work as v1 did. But, no cigar.

See:

This is on v2.2.3 of Docker-compose

---

Thank you

[larssb]

https://github.com/docker/compose/issues/9172 also likely solves this. So can we close?

[InCogNiTo124]

@larssb Actually, the bug still persists for me. Docker Compose version v2.6.0

EDIT: Also somehow fails with Docker Compose version v2.9.0 :/

[stumpylog]

I'm also seeing this with v2.11.0.

Inspecting the network, I see "Internal": false, is set, the compose file has the network declared with external: True as well.

[laurazard]

Hi @stumpylog, I'm having trouble replicating this in v2.11.0. Could you share a Compose file that reproduces this, along with how you're creating the external network and any other relevant steps?

[stumpylog]

It's only occurring on one Compose file so far, which has information in it I can't share. Attempts to replicate it with a shareable example have failed so far.

Maybe relevant, when I inspect the network in question, I see it has labels, which other created networks do not:

        "Labels": {
            "com.docker.compose.network": "reverse-proxy",
            "com.docker.compose.project": "traefik",
            "com.docker.compose.version": "2.9.0"
        }

It was created a month ago, but I believe it was just docker network create reverse-proxy

[InCogNiTo124]

Maybe relevant, when I inspect the network in question, I see it has labels, which other created networks do not:

Yup, same here. Seems like Docker Compose added some labels to the network somehow...

        "Labels": {
            "com.docker.compose.network": "default",
            "com.docker.compose.project": "traefik",
            "com.docker.compose.version": "2.6.0"
        }

[ndeloof]

Such labels indeed will confuse compose as this makes those resources look like they're managed by compose, not external, and could explain this issue. Sounds to me network has been created using some compose up command with a modified compose file, not using docker network create ..., and so resources metadata are incorrect.

[ndeloof]

This should have been fixed by https://github.com/docker/compose/pull/10555 If the issue persist after next release (v2.17.4, to be released soon) feel free to comment or create a follow up issue