I am trying run docker compose down using jenkins job.
"sudo docker-compose down –remove-orphans"
I have used –remove-orphans command while using the docker-compose down.
Still it gives below error.
Removing network. abc
error while removing network: network id ************ has active endpoints
Failed command with status 1: sudo docker-compose down –remove-orphans
Below is my docker compose:
version: "3.9"
services:
abc:
image: <img>
container_name: 'abc'
hostname: abc
ports:
- "5****:5****"
- "1****:1***"
volumes:
- ~/.docker-conf/<volume>
networks:
- <network>
container-app-1:
image: <img2>
container_name: 'container-app-1'
hostname: 'container-app-1'
depends_on:
- abc
ports:
- "8085:8085"
env_file: ./.env
networks:
- <network>
networks:
<network>:
driver: bridge
name: <network>
5
Answers
To list your networks, run
docker network ls
. You should see your<network>
there. Then get the containers still attached to that network with (replacing your network name at the end of the command):For the various returned container id’s, you can check why they haven’t stopped (inspecting the logs, making sure they are part of the compose project, etc), or manually stop them if they aren’t needed anymore with (replacing the
<cid>
with your container id):Then you should be able to stop the compose project.
There is a situation when there are no containers at all, but there is an error. Then
systemctl restart docker
helped meMy Problem was solved only by restarting the docker and then deleting the container manually from the docker desktop.
This can also happen, when you have a db instance running on separate container and using the same network. In this case, removing the db instance using the command
will stop the container. We can find the container id that is using the network by using the command provided by @BMitch
But in my case, when I did that, it also made that postgres instance "orphaned". Then i did
After that, I booted up a new db instance (postgres) using docker compose file and mapped the volume of data directory of that to the data directory of the previous db instance.
I believe you could use:
to disconnect problematic container (if you know its name) from the network, as per: https://docs.docker.com/network/bridge/#disconnect-a-container-from-a-user-defined-bridge: