Moby: Невозможно удалить сеть "имеет активные конечные точки"

Эта проблема кажется очень временной и возникает не очень часто.

@ rmb938 у нас было несколько проблем с зависшими конечными точками, которые были решены через # 17191. RC2 должен иметь исправление для этого (или последнюю версию мастера). Для тестировщиков RC1 (огромное спасибо) нам может потребоваться дополнительный обходной путь для очистки состояний перед запуском RC2. мы обновим правильную документацию.

Потрясающие. Спасибо.

@mavenugo Я только что воспроизвел это в 1.10.0:

похоже, что # 17191 не был полным исправлением ...

У вас есть обходной путь? Кажется, даже отскок демона докера ничего не решает.

(и дайте мне знать, если я смогу получить больше отладочной информации, она все еще воспроизводится на моей машине)

Я также только что воспроизвел это в 1.10.3 и приземлился здесь через Google в поисках работы. Я не могу принудительно отключить активные конечные точки. B / c ни один из контейнеров, перечисленных через docker network inspect все еще не существует.

В конце концов мне пришлось воссоздать контейнер консула и перезапустить демон докера.

ping @mavenugo , хотите ли вы, чтобы эта проблема была повторно открыта, или предпочитаете новую проблему, если она имеет другую основную причину?

Уточнение, докер 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

Позвольте мне снова открыть это для расследования

Мадху, назначил вас, но не стесняйтесь переназначить, чтобы указать на соответствующий обходной путь, если он уже есть: smile:

@keithbentrup @brendandburns благодарим за то, что подняли вопрос. Пара вопросов

1. Используете ли вы какой-либо сетевой драйвер с несколькими хостами (например, драйвер Overlay)? Не могли бы вы поделиться результатом docker network ls .
2. Если вы не используете драйвер с несколькими хостами, не могли бы вы поделиться файлом /var/lib/docker/network/files/local-kv.db (через какой-нибудь веб-сайт для обмена файлами) и какой network вы пытаетесь удалить? А как изначально создавалась сеть?

К вашему сведению. для сетевого драйвера с несколькими хостами docker поддерживает конечные точки для сети в кластере в KV-Store. Следовательно, если на каком-либо узле в этом кластере все еще есть конечная точка в этой сети, мы увидим эту ошибку, и это ожидаемое состояние.

@thaJeztah PTAL, мой комментарий выше, и, исходя из сценария, это не должно быть ошибкой. Я могу оставить этот вопрос открытым, если это поможет.

@mavenugo Да, я использую драйвер оверлея через docker-compose с хостом swarm, управляющим 2 узлами.

Когда я docker network inspect сеть на каждом отдельном узле, на 1 узле был указан 1 контейнер, который больше не существовал, и поэтому не мог быть удален с помощью docker rm -fv с использованием имени или идентификатора контейнера.

@keithbentrup Это устаревший случай конечной точки. У вас есть журнал ошибок, когда этот контейнер был первоначально удален (который оставил конечную точку в этом состоянии).
Кстати, если контейнер удален, но конечная точка все еще видна, то можно принудительно отключить конечную точку с помощью docker network disconnect -f {network} {endpoint-name} . Вы можете получить имя конечной точки с помощью команды docker network inspect {network} .

@brendandburns, не могли бы вы помочь ответить на https://github.com/docker/docker/issues/17217#issuecomment -195739573?

@mavenugo извините за задержку. Я не использую docker multi-host network afaik. Это одноузловой Raspberry Pi, и я ничего не сделал, кроме установки докера через hypriot.

Вот запрошенный вами результат ( network - это сеть, которую я не могу удалить)

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

Файл kv прилагается, мне пришлось назвать его .txt, чтобы обойти фильтры github, но это двоичный файл.

local-kv.db.txt

Я создал сеть через прямые вызовы API (dockerode)

Это сработало (создать и удалить) много раз, я думаю, в этом случае я docker rm -f <container-id> но я не уверен, я мог выключить и снова включить машину ...

Надеюсь, это поможет.
--brendan

@mavenugo Если под docker network disconnect -f {network} {endpoint-name} вы имеете в виду docker network disconnect [OPTIONS] NETWORK CONTAINER за docker network disconnect --help , я пробовал это, но он пожаловался (что неудивительно) с No such container .

Если вы имели в виду EndpointID вместо имени / идентификатора контейнера, я не пробовал это (но попробую в следующий раз), потому что это не то, что предлагалось в --help .

@keithbentrup я имел в виду -f которая доступна в v1.10.x. Параметр Force также учитывает имя конечной точки от других узлов в кластере. Следовательно, мои предыдущие инструкции будут отлично работать с опцией -f если вы используете docker v1.10.x.

@brendandburns благодарит за информацию, и это очень полезно для сужения проблемы. Имеется устаревшая ссылка на конечную точку, которая вызывает эту проблему. Устаревшая ссылка, скорее всего, вызвана отключением питания во время очистки конечных точек. мы решим эту проблему несоответствия в 1.11.

@mavenugo рада, что это помогло. А пока, если я сдую этот файл, все еще будет работать?

Благодарность
--brendan

@brendandburns да. пожалуйста, продолжайте. он просто отлично подойдет вам.

@mavenugo Я думаю, вы меня неправильно поняли. Я использовал параметр -f (проверенный в моей истории оболочки) на v1.10.x, но с идентификатором контейнера (а не идентификатором конечной точки) b / c, который предлагает помощь (контейнер, а не конечная точка). Если он предназначен для работы либо с идентификатором контейнера, либо с идентификатором конечной точки, то это ошибка b / c, она определенно не отключается от идентификатора контейнера и опции -f когда контейнер больше не существует.

Мне удалось воссоздать условие при попытке удалить docker_gwbridge, которое могло бы немного облегчить путаницу.
Когда я использовал докер-клиент, указывающий на диспетчер роя, я испытал такой вывод:

~/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

Сначала я попытался удалить контейнер по имени контейнера (не показано), затем по идентификатору, а затем по идентификатору конечной точки контейнера. Ни один из них не увенчался успехом. Затем я вошел на хост докера и использовал локальный клиент докера для выдачи команд через сокет докера unix:

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) Обратите внимание на вывод swarm vs direct docker client: swarm относится к контейнерам; докер относится к конечным точкам. Вероятно, это следует сделать последовательным.
2) Единственным успешным вариантом было указание имени конечной точки (а не имени или идентификатора контейнера или идентификатора конечной точки). --help должно убирать или разрешать ввод нескольких значений.
3) Я не тестировал имя конечной точки с помощью swarm, поэтому не знаю, сработало бы это.

@keithbentrup, это правильно. как я предлагал ранее. docker network disconnect -f {network} {endpoint-name} ... пожалуйста, используйте имя конечной точки. Мы можем улучшить это, чтобы также поддерживать идентификатор конечной точки. Но я хотел подтвердить, что, используя опцию силы, вы смогли добиться прогресса.

@mavenugo, но то, что вы предлагаете, - это не то, что написано в справке. кроме того, ему не хватает последовательности большинства команд, где идентификатор / имя взаимозаменяемы.

если другие не найдут этот поток, другие будут повторять ту же проблему, поэтому перед добавлением поддержки идентификатора конечной точки исправьте --help .

@keithbentrup мы исправим и --help, и функциональность.

Я только что воспроизвел эту проблему с докером v1.11.2 при попытке docker-compose down .
Предыдущая попытка запустить docker-compose down привела к закрытию сети 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": {}                                                                                 
    }                                                                                                
]                                                                                                    

информация о докере

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                                                                             

У меня возникают проблемы при попытке отключить конечные точки наложения роя,

Ответ от демона об ошибке: в сети es-swarm-overlay есть активные конечные точки

@ rmb938 скажите, пожалуйста, что не так? может быть другая проблема с этим вопросом?

@mavenugo

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

Это сработало для меня.

У меня может быть такая же проблема с docker 1.13.0 .

Поскольку никто в этой теме не привел пример того, что я сделал, я опубликую его.

Для завершения это ошибка, которая запускает его. Это может быть потому, что у меня есть codekitchen/dinghy-http-proxy:2.5.0 который прослушивает порт 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.

И пытаясь все это обрушить:

$ 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

И как убил сеть:

$ 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 есть действующее решение. Однако у моей команды есть файл docker-compose с ~ 20 контейнерами. Итак, я нашел другое решение.

Я хотел бы добавить, что вы также можете перезапустить демон docker (например, systemctl restart docker на centos), и тогда ссылки между сетью и контейнерами исчезнут. Тогда вы можете docker system prune -f с успехом.

@mdotson @nicolaiskogheim, пожалуйста, откройте новый выпуск; хотя сообщение об ошибке такое же, первоначальная проблема, обсуждаемая здесь, была исправлена. Вы видите это только при использовании docker compose? В этом случае это также может быть проблемой в порядке, в котором docker compose выполняет действия?

@thaJeztah Только с docker-compose. У меня это произошло только один раз, когда в моем ящике Jenkins закончилась память, и мне с трудом удалось убить контейнеры докеров. Возможно, не хватило памяти для удаления ссылок между контейнерами и сетью?

Не уверен, но в любом случае, я думаю, что большинство людей гуглит сообщение об ошибке и будут приходить сюда в поисках некоторых команд, которые можно скопировать и вставить, чтобы исправить свою проблему.

У меня была та же проблема, что и у @nicolaiskogheim и @mdotson , моему контейнеру infxdb не хватило памяти, и он стал нездоровым. Я не мог удалить, остановить или удалить (удалось удалить в принудительном режиме).
После этого я снова пытался запустить докер с 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.

чем пытался удалить сеть:

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

и чем я попробовал решение @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

перезапуск службы докеров устранил проблему для меня.

sudo service docker restart

docker network rm <network name>

Я вижу ту же проблему при попытке удалить стек:

> 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

Сначала я создал такой стек:

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

Я использую эту версию:

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

К счастью, sudo service docker restart это исправляет, но поведение все еще не идеальное.

Обнаружил это в 17.07.0-ce, подход disconnect не работал, затем перезапустил докер и снова успешно запустил rm .

Я столкнулся с этим и с роевым кластером 17.06. заканчиваются варианты, кроме перезагрузки.

sudo service docker restart избавляет меня от него в ubuntu, позволяя мне снова развернуть и запустить свои контейнеры.

Также работает, если один из контейнеров отказывается быть убитым (случается чаще, чем я бы надеялся). Раздражает, так как заставляет меня отключать все службы из-за одного вредного контейнера.

Имеет эту проблему также в 17.09.0-в. Откройте это снова!

Это часто происходило со мной в среде с малым объемом памяти. Посмотрим, улучшит ли это добавление памяти, теперь мои процессы останавливаются нормально.

@tomholub Нет, проблема не в памяти. Но перезапустил службу докеров, тогда я мог удалить сеть.

По-прежнему возникает эта проблема время от времени при попытке остановить и удалить активно работающий контейнер. (Докер для Mac версии 17.09.0-ce-mac35 (19611) Канал: стабильный 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

Обычно это уходит, если я жду случайное количество секунд. Но он все еще там.

КСТАТИ. Для меня это произошло во время docker-compose down --volumes --remove-orphans

все еще видя эти "осиротевшие сети", не могли бы вы снова открыть @ rmb938 @thaJeztah

Ответ от демона об ошибке: сеть abcd_default id 3f2f1a6cb1cee2d82f2e2e59d10a099834a12b18eb7e3e48d6482d758bd93617 имеет активные конечные точки

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

единственный способ их обрезать, кажется, перезапустить двигатель

Удачи сегодня

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

Это все еще можно воспроизвести на Docker version 18.06.1-ce, build e68fc7a
Похоже, что даже когда контейнеры файла набора удаляются, их конечные точки иногда не удаляются, что иногда может происходить при отключении питания, поэтому композиции не могут быть полностью запущены или полностью удалены.

Когда ни одна команда не работает, выполните
sudo service docker restart
ваша проблема будет решена

Или sudo reboot -f . Работает на 100%.

у меня была аналогичная проблема сегодня. Я запустил «docker container ls -a» и увидел, что несколько все еще работающих контейнеров используют сеть, которую я запустил через стек докеров. поэтому вручную, когда я убил эти контейнеры, я смог удалить сеть

Думаю, я только что столкнулся с проблемой, о которой здесь упоминал @danwdart . Я нахожусь на Docker version 18.09.2, build 6247962 я выполнил docker-compose -f $PATH_TO_MY_CONFIG down и получил следующую ошибку:

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

Прошлой ночью я позволил аккумулятору моего ноутбука разрядиться, что я делаю редко, и после перезапуска докера я смог успешно выполнить ту же команду compose «вниз».

Для некоторых это может быть очевидно, но не для меня, просто подумал, что поделюсь.

Мне нужно было просто запустить docker-compose rm - docker-compose down - это то, что я обычно делаю, а ps -a показывал контейнеров, так что это действительно сбило меня с толку, пока я не запустил rm cmd . Думал, что поделюсь.

У меня возникла та же проблема, так как сеть не смогла удалить все действия, отметив, что это помогло. моя версия - Docker версии 18.09.6, сборка 481bc77

Чтобы исправить это, мне нужно перезапустить службы докеров. "sudo service docker restart" после этого я могу удалить с помощью "docker network rm {network}"

@danwdart Другая причина - наличие болтающихся контейнеров. чтобы удалить их, используйте команду docker-compose down --remove-orphans которая должна помочь.

Привет с 2019 года, @mavenugo. Я хотел бы передать свои искренние, искренние благодарности за то, что в 2016 году

Спустя более четырех лет это все еще проблема. Есть ли более простой способ отключить каждый контейнер от каждой сети, к которой они подключены, чем сценарий оболочки из 10+ строк? FWIW, похоже, работает:

#!/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

В итоге:

1. Установите ловушку, чтобы убрать рабочее пространство при выходе.
2. Создайте рабочее пространство.
3. Для каждого контейнера:
   
   
   
   1. Для каждой сети контейнер связан с:
      
      
      
      
      
      1. Попробуй отключиться.
      
      
      
      2. Если отключение не удается из-за того, что он уже не подключен к сети, игнорируйте ошибку (к сожалению, это кажется случайным, если «the» является частью этого сообщения об ошибке). Иначе не получится.
      
      
      
   
   

Комбинация решения @mavenugo и

Еще одно спасибо @mavenugo здесь с 2020 года

@mavenugo Если под docker network disconnect -f {network} {endpoint-name} вы имеете в виду docker network disconnect [OPTIONS] NETWORK CONTAINER за docker network disconnect --help , я пробовал это, но он пожаловался (что неудивительно) с No such container .

Если вы имели в виду EndpointID вместо имени / идентификатора контейнера, я не пробовал это (но попробую в следующий раз), потому что это не то, что предлагалось в --help .

@keithbentrup - {endpoint-name} в приведенной выше команде в основном представляет собой container-id/name в выводе, полученном из следующей команды:

$deminem: docker network inspect e60b9386b9e2 где e60b9386b9e2 - идентификатор сети.

[
    {
        "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"
        }
    }
]

Примечание: как выделено жирным шрифтом. "Name": "project-name-master_monitoring_1" .

Просто было это с

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

на Arch. Помог перезапуск службы.