Moby: No se puede eliminar la red "tiene puntos finales activos"

Este problema parece ser muy intermitente y no ocurre con mucha frecuencia.

@ rmb938 tuvimos algunos problemas con los extremos colgantes y se ha solucionado a través de # 17191. RC2 debería tener una solución para eso (o el último maestro). Para los probadores de RC1 (muchas gracias), es posible que necesitemos una solución adicional para limpiar los estados antes de iniciar RC2. actualizaremos con los documentos adecuados.

Impresionante. Gracias.

@mavenugo Acabo de reproducir esto en 1.10.0:

parece que # 17191 no fue una solución completa ...

¿Tienes una solución alternativa? Incluso rebotar el demonio de la ventana acoplable no parece resolver las cosas.

(y avíseme si puedo obtener más información de depuración, todavía se está reproduciendo en mi máquina)

También reproduje esto en 1.10.3 y llegué aquí a través de Google en busca de una solución. No puedo forzar la desconexión de los puntos finales activos porque ninguno de los contenedores enumerados a través de docker network inspect todavía existe.

Finalmente tuve que volver a crear mi contenedor de cónsul y reiniciar el demonio de la ventana acoplable.

ping @mavenugo ¿desea que se vuelva a abrir este problema o prefiere un nuevo problema en caso de que tenga una causa raíz diferente?

Aclaración, ventana acoplable 1.10.1

Client:
 Version:      1.10.1
 API version:  1.22
 Go version:   go1.4.3
 Git commit:   9e83765
 Built:        Fri Feb 12 12:41:05 2016
 OS/Arch:      linux/arm

Server:
 Version:      1.10.1
 API version:  1.22
 Go version:   go1.4.3
 Git commit:   9e83765
 Built:        Fri Feb 12 12:41:05 2016
 OS/Arch:      linux/arm

Déjame reabrir esto para investigar

Madhu, te asignó, pero siéntete libre de reasignar, de señalar la solución relacionada si ya está allí: sonríe:

@keithbentrup @brendandburns gracias por plantear el problema. Par de preguntas

1. ¿Está utilizando algún controlador de red de múltiples hosts (como el controlador de superposición)? ¿Puedes compartir la salida docker network ls ?
2. Si no usa un controlador de host múltiple, ¿puede compartir el archivo /var/lib/docker/network/files/local-kv.db (a través de algún sitio web de intercambio de archivos) y qué network está tratando de eliminar? ¿Y cómo se creó originalmente la red?

FYI. para un controlador de red de múltiples hosts, Docker mantiene los puntos finales de una red en todo el clúster en KV-Store. Por lo tanto, si algún host en ese clúster todavía tiene un punto final activo en esa red, veremos este error y esta es una condición esperada.

@thaJeztah PTAL mi comentario anterior y según el escenario, esto no tiene por qué ser un error. Estoy de acuerdo en mantener este problema abierto si eso ayuda.

@mavenugo Sí, estoy usando el controlador de superposición a través de docker-compose con un host de enjambre que administra 2 nodos.

Cuando docker network inspect la red en cada nodo individual, 1 nodo tenía 1 contenedor en la lista que ya no existía y, por lo tanto, docker rm -fv no podía eliminarlo usando el nombre o la identificación del contenedor.

@keithbentrup Este es un caso de punto final obsoleto. ¿Tiene el registro de errores cuando ese contenedor que se eliminó originalmente (que dejó el punto final en este estado)?
Por cierto, si se quita el contenedor, pero el punto final todavía se ve, entonces se puede forzar la desconexión del punto final usando docker network disconnect -f {network} {endpoint-name} . Puede obtener el nombre del punto final del comando docker network inspect {network} .

@brendandburns , ¿puedes ayudar a responder a https://github.com/docker/docker/issues/17217#issuecomment -195739573?

@mavenugo perdón por el retraso. No estoy usando afaik de red de múltiples hosts de Docker. Es un raspberry pi de un solo nodo y no he hecho nada más que instalar la ventana acoplable a través de hypriot.

Aquí está la salida que solicitó ( network es la red que no puedo eliminar)

$ docker network ls
NETWORK ID          NAME                DRIVER
d22a34456cb9        bridge              bridge              
ef922c6e861e        network             bridge              
c2859ad8bda4        none                null                
150ed62cfc44        host                host 

El archivo kv está adjunto, tuve que nombrarlo .txt para sortear los filtros github, pero es el archivo binario.

local-kv.db.txt

Creé la red a través de llamadas API directas (dockerode)

Esto ha funcionado (crear y eliminar) varias veces, creo que en este caso, yo docker rm -f <container-id> pero no estoy seguro, podría haber apagado y encendido la máquina ...

Espero que ayude.
--brendan

@mavenugo Si por docker network disconnect -f {network} {endpoint-name} te refieres a docker network disconnect [OPTIONS] NETWORK CONTAINER por docker network disconnect --help , lo intenté, pero se quejó (no es sorprendente) con No such container .

Si se refería a EndpointID lugar del nombre / id del contenedor, no lo intenté (pero lo haré la próxima vez) porque eso no es lo que sugirió --help .

@keithbentrup quise decir la opción -f que está disponible en v1.10.x. La opción Force también considera el nombre del punto final de otros nodos en el clúster. Por lo tanto, mis instrucciones anteriores funcionarán bien con la opción -f si está utilizando Docker v1.10.x.

@brendandburns gracias por la información y es bastante útil para

@mavenugo me alegro de haber ayudado. Mientras tanto, si borro ese archivo, ¿seguirán funcionando las cosas?

Gracias
--brendan

@brendandburns sí. por favor continua. simplemente funcionará bien para ti.

@mavenugo Creo que me -f (verificada en mi historial de shell) en v1.10.x pero con la identificación del contenedor (no la identificación del punto final) b / c, eso es lo que sugiere la ayuda (el contenedor, no el punto final). Si está destinado a funcionar con la identificación del contenedor o la identificación del punto final, entonces es un error porque ciertamente no se desconecta con la identificación del contenedor y la opción -f cuando el contenedor ya no existe.

Pude recrear una condición al intentar eliminar docker_gwbridge que podría aliviar algo de la confusión.
Cuando utilicé el cliente de la ventana acoplable que apuntaba a un administrador de enjambres, experimenté este resultado:

~/D/e/m/compose (develop) $ docker network inspect docker_gwbridge
[
    {
        "Name": "docker_gwbridge",
        "Id": "83dfeb756951d3d175e9058d0165b6a4997713c3e19b6a44a7210a09cd687d54",
        "Scope": "local",
        "Driver": "bridge",
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.18.0.0/16",
                    "Gateway": "172.18.0.1/16"
                }
            ]
        },
        "Containers": {
            "41ebd4fc365ae07543fd8454263d7c049d8e73036cddb22379ca1ce08a65402f": {
                "Name": "gateway_41ebd4fc365a",
                "EndpointID": "1cb2e4e3431a4c2ce1ed7c0ac9bc8dee67c06982344a75312e20e4a7d6e8972c",
                "MacAddress": "02:42:ac:12:00:02",
                "IPv4Address": "172.18.0.2/16",
                "IPv6Address": ""
            }
        },
        "Options": {
            "com.docker.network.bridge.enable_icc": "false",
            "com.docker.network.bridge.enable_ip_masquerade": "true",
            "com.docker.network.bridge.name": "docker_gwbridge"
        }
    }
]
~/D/e/m/compose (develop) $ docker network disconnect -f docker_gwbridge 41ebd4fc365ae07543fd8454263d7c049d8e73036cddb22379ca1ce08a65402f
Error response from daemon: No such container: 41ebd4fc365ae07543fd8454263d7c049d8e73036cddb22379ca1ce08a65402f
~/D/e/m/compose (develop) $ docker network disconnect -f docker_gwbridge 1cb2e4e3431a4c2ce1ed7c0ac9bc8dee67c06982344a75312e20e4a7d6e8972c
Error response from daemon: No such container: 1cb2e4e3431a4c2ce1ed7c0ac9bc8dee67c06982344a75312e20e4a7d6e8972c
~/D/e/m/compose (develop) $ docker network rm docker_gwbridge
Error response from daemon: 500 Internal Server Error: network docker_gwbridge has active endpoints

Primero intenté eliminar el contenedor por el nombre del contenedor (no se muestra), luego por la identificación, luego por la identificación del punto final del contenedor. Ninguno tuvo éxito. Luego inicié sesión en el host de la ventana acoplable y utilicé el cliente de la ventana acoplable local para emitir comandos a través del socket unix de la ventana acoplable:

root@dv-vm2:~# docker network disconnect -f docker_gwbridge 41ebd4fc365ae07543fd8454263d7c049d8e73036cddb22379ca1ce08a65402f
Error response from daemon: endpoint 41ebd4fc365ae07543fd8454263d7c049d8e73036cddb22379ca1ce08a65402f not found
root@dv-vm2:~# docker network disconnect -f docker_gwbridge 1cb2e4e3431a4c2ce1ed7c0ac9bc8dee67c06982344a75312e20e4a7d6e8972c
Error response from daemon: endpoint 1cb2e4e3431a4c2ce1ed7c0ac9bc8dee67c06982344a75312e20e4a7d6e8972c not found
root@dv-vm2:~# docker network rm docker_gwbridge
Error response from daemon: network docker_gwbridge has active endpoints
root@dv-vm2:~# docker network disconnect -f docker_gwbridge gateway_41ebd4fc365a
root@dv-vm2:~# docker network rm docker_gwbridge
root@dv-vm2:~# docker network inspect docker_gwbridge
[]
Error: No such network: docker_gwbridge

1) Observe la salida de swarm vs direct docker client: swarm se refiere a contenedores; docker se refiere a los puntos finales. Eso probablemente debería ser coherente.
2) La única opción exitosa fue proporcionar un nombre de punto final (no el nombre o id del contenedor, ni el id del punto final). El --help debe aclarar que las entradas múltiples o ascendentes deben ser aceptables.
3) No probé el nombre del extremo con swarm, así que no sé si eso hubiera funcionado.

@keithbentrup eso es correcto. como sugerí antes. el docker network disconnect -f {network} {endpoint-name} ... pls usa el nombre del punto final. También podemos mejorar esto para admitir endpoint-id. Pero quería confirmar que al usar la opción de fuerza, pudiste progresar.

@mavenugo pero lo que sugieres no es lo que dice la ayuda. además, carece de la consistencia de la mayoría de cmds donde id / name son intercambiables.

a menos que otros encuentren este hilo, otros repetirán el mismo problema, por lo que antes de agregar soporte para endpoint-id, corrija el --help .

@keithbentrup arreglaremos tanto --help como la funcionalidad.

Acabo de reproducir este problema con la ventana acoplable v1.11.2 mientras intentaba docker-compose down .
Un intento anterior de ejecutar docker-compose down cerró la red app_front.

$ docker-compose down
Removing network app_front
WARNING: Network app_front not found.
Removing network app_back
ERROR: network app_back has active endpoints

$ docker network inspect app_back                                                            
[                                                                                                    
    {                                                                                                
        "Name": "app_back",                                                                  
        "Id": "4a8d557eda7ce06d222fc0a9053069f44e75d25147300796686522a872261245",                    
        "Scope": "local",                                                                            
        "Driver": "bridge",                                                                          
        "EnableIPv6": false,                                                                         
        "IPAM": {                                                                                    
            "Driver": "default",                                                                     
            "Options": null,                                                                         
            "Config": [                                                                              
                {                                                                                    
                    "Subnet": "172.22.0.0/16",                                                       
                    "Gateway": "172.22.0.1/16"                                                       
                }                                                                                    
            ]                                                                                        
        },                                                                                           
        "Internal": false,                                                                           
        "Containers": {                                                                              
            "702e9916e86b7f77af363014134f160a8dcd189399719e062069c10f735cb927": {                    
                "Name": "app_db_1",                                                          
                "EndpointID": "1decedbca5bc704be84f19e287926361d196d20fe2a9bbf092ab15b37b856b3a",    
                "MacAddress": "02:42:ac:16:00:02",                                                   
                "IPv4Address": "172.22.0.2/16",                                                      
                "IPv6Address": ""                                                                    
            }                                                                                        
        },                                                                                           
        "Options": {},                                                                               
        "Labels": {}                                                                                 
    }                                                                                                
]                                                                                                    

información de la ventana acoplable

Containers: 17                                                                                   
 Running: 1                                                                                      
 Paused: 0                                                                                       
 Stopped: 16                                                                                     
Images: 140                                                                                      
Server Version: 1.11.2                                                                           
Storage Driver: aufs                                                                             
 Root Dir: /mnt/sda1/var/lib/docker/aufs                                                         
 Backing Filesystem: extfs                                                                       
 Dirs: 245                                                                                       
 Dirperm1 Supported: true                                                                        
Logging Driver: json-file                                                                        
Cgroup Driver: cgroupfs                                                                          
Plugins:                                                                                         
 Volume: local                                                                                   
 Network: bridge null host                                                                       
Kernel Version: 4.4.12-boot2docker                                                               
Operating System: Boot2Docker 1.11.2 (TCL 7.1); HEAD : a6645c3 - Wed Jun  1 22:59:51 UTC 2016    
OSType: linux                                                                                    
Architecture: x86_64                                                                             
CPUs: 1                                                                                          
Total Memory: 1.955 GiB                                                                          
Name: default                                                                                    
ID: LKRP:E2TX:KNVZ:UD4M:FIGG:ZROO:CIA5:WBKH:RNUB:KXTQ:E6DC:545P                                  
Docker Root Dir: /mnt/sda1/var/lib/docker                                                        
Debug mode (client): false                                                                       
Debug mode (server): true                                                                        
 File Descriptors: 18                                                                            
 Goroutines: 38                                                                                  
 System Time: 2016-06-15T22:44:13.34779866Z                                                      
 EventsListeners: 0                                                                              
Username: tohagan                                                                                
Registry: https://index.docker.io/v1/                                                            
Labels:                                                                                          
 provider=virtualbox                                                                             

Tengo algunos problemas al intentar desconectar los puntos finales de superposición de enjambre,

Respuesta de error del demonio: la red es-swarm-overlay tiene puntos finales activos

@ rmb938, por favor, ¿qué pasa? ¿Puede tener otro problema con estas preguntas?

@mavenugo

docker network disconnect -f  [Network-Name] [Endpoint-Name] 

Esto funcionó para mí.

Es posible que tenga el mismo problema con docker 1.13.0 .

Como nadie en este hilo ha dado un ejemplo de lo que hice, lo publicaré.

Para completa, este es el error que lo inicia. Puede ser porque tengo codekitchen/dinghy-http-proxy:2.5.0 que escucha en el puerto 80.

$ docker-compose -f deploy/docker-compose/docker-compose.yml
Creating network "dockercompose_default" with the default driver
Creating dockercompose_front-end_1
# and so on..

ERROR: for edge-router  Cannot start service edge-router: driver failed programming external connectivity on endpoint dockercompose_edge-router_1 (3ed8fb6cf4bc221dce615a9a3c5b8e4f0f8332e00e6c6d9b9f9bf0b09da57b36): Bind for 0.0.0.0:80 failed: port is already allocated
ERROR: Encountered errors while bringing up the project.

Y tratando de derribarlo todo:

$ docker-compose -f deploy/docker-compose/docker-compose.yml down
Stopping dockercompose_front-end_1
# and so on..
ERROR: network dockercompose_default has active endpoints

Y como maté a la red:

$ docker network inspect dockercompose_default
[
    {
        "Name": "dockercompose_default", # <--- Param 1
        "Id": "dd1326487a637df8a4a7a11856864a0059fca45cb63e8363bfe5196082d42d6e",
        "Created": "2017-02-08T00:22:41.341653339Z",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.18.0.0/16",
                    "Gateway": "172.18.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Containers": {
            "ea7a142c113700145e894c950b18fd4dec8a53e04a45045f1fb71c47eae1a13b": {
                "Name": "dinghy_http_proxy", # <--- Param 2
                "EndpointID": "38f362af8b22e575cc987f68399a97f3ed10abf2c4cc365460dba768f2df8daa",
                "MacAddress": "02:42:ac:12:00:0d",
                "IPv4Address": "172.18.0.13/16",
                "IPv6Address": ""
            }
        },
        "Options": {},
        "Labels": {}
    }
]

$ docker network disconnect -f dockercompose_default dinghy_http_proxy
$ docker network rm dockercompose_default
dockercompose_default

@nicolaiskogheim tiene una solución válida. Sin embargo, mi equipo tiene un archivo docker-compose con ~ 20 contenedores. Entonces encontré otra solución.

Me gustaría agregar que también puede reiniciar el demonio de la ventana acoplable (por ejemplo, systemctl restart docker en centos) y luego los enlaces entre la red y los contenedores desaparecerán. Entonces puede docker system prune -f con éxito.

@mdotson @nicolaiskogheim , abra una nueva edición; aunque el mensaje de error es el mismo, se solucionó el problema original discutido aquí. ¿Solo ves esto cuando usas docker compose? En ese caso, ¿también podría ser un problema en el orden en que Docker Compon realiza acciones?

@thaJeztah Solo con docker-compose. Tuve que ocurrir solo una vez cuando mi caja de Jenkins se quedó sin memoria y apenas logré matar los contenedores de la ventana acoplable. ¿Quizás no había suficiente memoria para asignar para eliminar los enlaces entre los contenedores y la red?

No estoy seguro, pero de cualquier manera, creo que la mayoría de la gente busca en Google un mensaje de error y llegará aquí buscando algunos comandos para copiar y pegar para solucionar su problema.

Tuve el mismo problema que @nicolaiskogheim y @mdotson , mi contenedor influxdb se quedó sin memoria y se volvió insalubre. No pude eliminar, detenerlo o eliminar (logré eliminar con el modo de fuerza).
Después de eso, estaba tratando de comenzar una vez más la ventana acoplable con docker-compose :

# docker-compose -f /etc/docker/docker-compose.yml up -d
Creating influxdb1

ERROR: for influxdb  Cannot start service influxdb: service endpoint with name influxdb1 already exists
ERROR: Encountered errors while bringing up the project.

que trató de eliminar la red:

# docker network rm 834ea759c916
Error response from daemon: network docker_default has active endpoints

y luego probé la solución @nicolaiskogheim :

# docker network disconnect -f docker_default influxdb1

Client:
 Version:      1.13.1
 API version:  1.26
 Go version:   go1.7.5
 Git commit:   092cba3
 Built:        Wed Feb  8 06:50:14 2017
 OS/Arch:      linux/amd64

Server:
 Version:      1.13.1
 API version:  1.26 (minimum version 1.12)
 Go version:   go1.7.5
 Git commit:   092cba3
 Built:        Wed Feb  8 06:50:14 2017
 OS/Arch:      linux/amd64
 Experimental: false

docker-compose version 1.11.1, build 7c5d5e4
docker-py version: 2.0.2
CPython version: 2.7.12
OpenSSL version: OpenSSL 1.0.2g  1 Mar 2016

El reinicio del servicio Docker solucionó el problema por mí.

sudo service docker restart

docker network rm <network name>

Veo el mismo problema al intentar eliminar una pila:

> sudo docker stack rm my-stack
Removing network my-stack_default
Failed to remove network g0450dknntdsfj1o055mk4efm: Error response from daemon: network my-stack_default has active endpointsFailed to remove some resources

Primero había creado la pila así:

sudo docker stack deploy -c docker-compose.yml --with-registry-auth my-stack

Estoy usando esta versión:

Client:
 Version:      17.03.1-ce
 API version:  1.27
 Go version:   go1.7.5
 Git commit:   c6d412e
 Built:        Mon Mar 27 17:14:09 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.03.1-ce
 API version:  1.27 (minimum version 1.12)
 Go version:   go1.7.5
 Git commit:   c6d412e
 Built:        Mon Mar 27 17:14:09 2017
 OS/Arch:      linux/amd64
 Experimental: false

Afortunadamente, sudo service docker restart corrige, pero aún no es el comportamiento ideal.

Lo encontré en 17.07.0-ce, el enfoque disconnect no funcionó, luego reinició la ventana acoplable y ejecutó rm nuevamente con éxito.

También me encontré con esto con un clúster de enjambre 17.06-ce; quedarse sin opciones además de reiniciar.

sudo service docker restart se deshace de él en ubuntu, lo que me permite implementar e iniciar mis contenedores nuevamente.

También funciona si uno de los contenedores se niega a ser asesinado (sucede más de lo que espero). Molesto, ya que me hace bajar todos los servicios debido a un contenedor malicioso.

Tener este problema también en 17.09.0-ce. ¡Vuelve a abrir esto!

Esto me estaba pasando mucho en un entorno de poca memoria. Vea si agregar memoria lo mejorará, mis procesos se detienen normalmente ahora.

@tomholub No, la memoria no es el problema. Pero reinicié el servicio de Docker, luego pude eliminar la red.

Todavía tengo este problema de vez en cuando al intentar detener y eliminar el contenedor que funciona activamente. (Docker para Mac Versión 17.09.0-ce-mac35 (19611) Canal: estable a98b7c1b7c)

Client:
 Version:      17.09.0-ce
 API version:  1.32
 Go version:   go1.8.3
 Git commit:   afdb6d4
 Built:        Tue Sep 26 22:40:09 2017
 OS/Arch:      darwin/amd64

Server:
 Version:      17.09.0-ce
 API version:  1.32 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   afdb6d4
 Built:        Tue Sep 26 22:45:38 2017
 OS/Arch:      linux/amd64
 Experimental: false

$ uname -a
Darwin Alexei-Workstation.local 16.7.0 Darwin Kernel Version 16.7.0: Wed Oct  4 00:17:00 PDT 2017; root:xnu-3789.71.6~1/RELEASE_X86_64 x86_64

Sin embargo, generalmente desaparece si espero una cantidad aleatoria de segundos. Pero sigue ahí.

POR CIERTO. Para mí, sucedió durante docker-compose down --volumes --remove-orphans

todavía viendo estas "redes huérfanas" ¿puedes reabrir @ rmb938 @thaJeztah

Respuesta de error del demonio: la red abcd_default id 3f2f1a6cb1cee2d82f2e2e59d10a099834a12b18eb7e3e48d6482d758bd93617 tiene puntos finales activos

docker version
Client:
 Version:      17.06.0-ce
 API version:  1.30
 Go version:   go1.8.3
 Git commit:   02c1d87
 Built:        Fri Jun 23 21:23:31 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.06.0-ce
 API version:  1.30 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   02c1d87
 Built:        Fri Jun 23 21:19:04 2017
 OS/Arch:      linux/amd64

La única forma de podarlos parece ser reiniciar el motor.

Buena suerte hoy

docker-compose down
Removing network gen365cms_default
ERROR: network gen365cms_default id b6c51b1a83ee2b938ee1c7f7148347dc9ef80a8d8ed93334873f1f84b3f27c04 has active endpoints

docker version
Client:
 Version:   17.12.0-ce-rc4
 API version:   1.35
 Go version:    go1.9.2
 Git commit:    6a2c058
 Built: Wed Dec 20 15:53:52 2017
 OS/Arch:   darwin/amd64

Server:
 Engine:
  Version:  17.12.0-ce-rc4
  API version:  1.35 (minimum version 1.12)
  Go version:   go1.9.2
  Git commit:   6a2c058
  Built:    Wed Dec 20 15:59:49 2017
  OS/Arch:  linux/amd64
  Experimental: true

Esto todavía se puede reproducir en Docker version 18.06.1-ce, build e68fc7a
Parece que incluso cuando se eliminan los contenedores de un archivo de redacción, sus puntos finales a veces no se eliminan, lo que a veces puede ocurrir en caso de pérdida de energía, por lo que la composición no se inicia o se elimina por completo.

Cuando ningún comando funciona, hazlo
sudo service docker restart
Su problema será resuelto

O sudo reboot -f . Funciona al 100%.

Hoy tuve un problema similar. lo que hice fue ejecutar "docker container ls -a" y vi que algunos contenedores aún en ejecución estaban utilizando la red que había lanzado a través de la pila de docker. así que manualmente cuando maté esos contenedores pude eliminar la red

Creo que acabo de encontrarme con el problema que @danwdart mencionó aquí . Estoy en Docker version 18.09.2, build 6247962 y ejecuté docker-compose -f $PATH_TO_MY_CONFIG down , y recibí el siguiente error:

ERROR: error while removing network: network michaelmoore_default id 6838b92e60a83f53c5637065e449f9124a2f297c482f1a7326cf247bfd38f70c has active endpoints

De hecho, dejé que la batería de mi computadora portátil se agotara anoche, lo que rara vez hago, y después de reiniciar la ventana acoplable pude ejecutar el mismo comando de composición "abajo" con éxito.

Esto puede ser obvio para algunos, pero no lo fue para mí, solo pensé en compartirlo.

Solo necesitaba ejecutar docker-compose rm - docker-compose down es lo que normalmente hago y ps -a no mostró contenedores, así que esto realmente me hizo tropezar hasta que ejecuté el rm cmd . Pensé en compartir.

Termino con el mismo problema, ya que la red no pudo eliminar con todas las acciones, notando que ayudó. mi versión es Docker versión 18.09.6, compilación 481bc77

Para solucionarlo, reinicié los servicios de Docker. por "sudo service docker restart" después de eso pude eliminar con "docker network rm {network}"

@danwdart Otra razón para esto es cuando hay contenedores colgando. para eliminarlos, use el comando docker-compose down --remove-orphans que debería funcionar.

Hola desde 2019, @mavenugo Me gustaría transmitir mi más sincero agradecimiento por tener la solución en este 2016.

Esto sigue siendo un problema después de más de cuatro años. ¿Existe alguna forma más sencilla de desconectar todos los contenedores de todas las redes a las que están conectados que un script de shell de más de 10 líneas? FWIW esto parece funcionar:

#!/usr/bin/env bash

set -o errexit -o nounset -o pipefail

trap 'rm --recursive "$workspace"' EXIT
workspace="$(mktemp --directory)"
error_log="${workspace}/error.log"

for container_id in $(docker ps --all --quiet)
do
    readarray -t network_names < <(docker inspect "$container_id" | jq --raw-output '.[] | .NetworkSettings.Networks | if . == null then empty else keys | .[] end')
    for network_name in "${network_names[@]}"
    do
        echo "Disconnecting container ${container_id} from network ${network_name}."
        exit_code=0
        docker network disconnect "$network_name" "$container_id" 2> "$error_log" || exit_code="$?"
        if [[ "$exit_code" -ne 0 ]]
        then
            if grep --fixed-strings --quiet --regexp 'not connected to network' --regexp 'not connected to the network' "$error_log"
            then
                echo 'Ignoring "not connected" error…'
            else
                cat "$error_log" >&2
                exit "$exit_code"
            fi
        fi
    done
done

En resumen:

1. Instale una trampa para eliminar el espacio de trabajo al salir.
2. Crea el espacio de trabajo.
3. Para cada contenedor:
   
   
   
   1. Para cada red con la que está asociado el contenedor:
      
      
      
      
      
      1. Intenta desconectarte.
      
      
      
      2. Si la desconexión falla porque ya no está conectado a la red, ignore el error (desafortunadamente parece ser aleatorio si "el" es parte de ese mensaje de error). De lo contrario, falla.
      
      
      
   
   

Una combinación de la solución @mavenugo y la poda de la red

Otro gracias @mavenugo aquí desde 2020

@mavenugo Si por docker network disconnect -f {network} {endpoint-name} te refieres a docker network disconnect [OPTIONS] NETWORK CONTAINER por docker network disconnect --help , lo intenté, pero se quejó (no es sorprendente) con No such container .

Si se refería a EndpointID lugar del nombre / id del contenedor, no lo intenté (pero lo haré la próxima vez) porque eso no es lo que sugirió --help .

@keithbentrup - El {endpoint-name} en el comando anterior es básicamente el container-id/name en el comando get from below de salida:

$deminem: docker network inspect e60b9386b9e2 donde e60b9386b9e2 es el

[
    {
        "Name": "project-name-master_default",
        "Id": "e60b9386b9e20f5222513bd6166f6d8e3224e72e906e2b07376e88ba79d87b26",
        "Created": "2020-04-02T18:48:29.2694181Z",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.18.0.0/16",
                    "Gateway": "172.18.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": true,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {
            "d435c36e882ec91dff780c55c0399c52b14096baea402647eaff2f1593602df9": {
                **"Name": "project-name-master_monitoring_1"**,
                "EndpointID": "7838e98efd8be4cabccc778707efadbb6194cbd73dc907f0129ee8b9119e4349",
                "MacAddress": "02:42:ac:12:00:0e",
                "IPv4Address": "172.18.0.14/16",
                "IPv6Address": ""
            }
        },
        "Options": {},
        "Labels": {
            "com.docker.compose.network": "default",
            "com.docker.compose.project": "project-name",
            "com.docker.compose.version": "1.25.4"
        }
    }
]

Nota: Como se resalta en negrita. "Name": "project-name-master_monitoring_1" .

Lo acabo de tener con

docker --version
Docker version 19.03.12-ce, build 48a66213fe
uname -a
Linux jotunheim 5.8.5-arch1-1 #1 SMP PREEMPT Thu, 27 Aug 2020 18:53:02 +0000 x86_64 GNU/Linux

en Arch. El reinicio del servicio ayudó.