docker compose down doesn't shutdown / remove container - docker

Having a simple problem with docker compose down that I've already researched, but can't find a solution for. Any guidance is appreciated.
docker compose up works fine, but when I try to down the project, one container won't shutdown / remove. This causes an error while removing network: ... has active endpoints error during docker compose down.
Here's how I start the containers:
yarn docker:compose:test:up, which runs "docker compose -f docker-compose.test.yml up". Everything starts fine, and life goes on.
Here's the entire docker-compose.test.yml file:
---
services:
redis:
networks:
- redis-network
command:
- redis-server
- "--appendonly"
- "yes"
- "--requirepass ${REDIS_PASSWORD}"
image: redis
container_name: resonate-redis
restart: always
expose:
- 6379
ports:
- "${REDIS_PORT}:6379"
api:
networks:
- api-network
- redis-network
build: .
command: /bin/sh -c "yarn && yarn migrate:test && yarn start:dev"
container_name: resonate-api
environment:
- NODE_ENV=test
depends_on:
- redis
- pgsql-test
ports:
- "4000:4000"
restart: always
volumes:
- ./:/var/www/api
- ./data/media/incoming:/data/media/incoming
- ./data/media/audio:/data/media/audio
- ./data/media/images:/data/media/images
pgsql-test:
image: postgres:14-alpine
env_file:
- .env
volumes:
- ./data/pgsql-test:/var/lib/postgresql/data
- ./data/pgsql-test-backups:/backups
container_name: resonate-pgsql-test
networks:
- api-network
ports:
- '${POSTGRES_TEST_LOCAL_MACHINE_PORT}:5432'
nginx:
restart: always
container_name: resonate-nginx
networks:
- api-network
build:
context: ./nginx
ports:
- "${NGINX_PORT}:80"
networks:
api-network:
driver: bridge
# app-network:
# driver: bridge
redis-network:
driver: bridge
volumes:
certbot-etc:
certbot-var:
htpasswd:
driver: local
driver_opts:
type: none
device: "${PWD}/htpasswd/"
o: bind
web-root:
driver: local
driver_opts:
type: none
device: "${PWD}/public/"
o: bind
dhparam:
driver: local
driver_opts:
type: none
device: "${PWD}/dhparam/"
o: bind
version: "3.7"
Later, I run docker compose down and end up with this output:
(base) iMac:api imac$ docker compose down
[+] Running 4/5
⠿ Container resonate-nginx Removed 0.3s
⠿ Container resonate-api Removed 0.5s
⠿ Container resonate-redis Removed 0.3s
⠿ Network api_redis-network Removed 0.1s
⠿ Network api_api-network Error 0.0s
failed to remove network api_api-network: Error response from daemon: error while removing network: network api_api-network id ... has active endpoints
The pgsql-test container is not removed, and the network can't stop because of this.
I have no idea why this is happening, or what to do in order to fix it. Any help is appreciated.
Thanks!

Just had this happen to me.
failed to remove network ots_djangoapp: Error response from daemon:
error while removing network: network ots_djangoapp id 1450efd2df6c
has active endpoints
Had been working for years, but it looks as though one of the updates changed things. Possibly in the 2.7.0 bug fixes https://docs.docker.com/compose/profiles/
My yml config utilized profiles
https://docs.docker.com/compose/profiles/
Which I would start with docker-compose --profile prod up -d and docker-compose down respectively.
I got it working again by simply adding the explicit --profile argument to the down command.
docker-compose --profile prod down
-cheers

Related

Failed to add interface to sandbox

I'm trying to run two Docker containers attached to a single Docker network using Docker Compose.
I'm running into the following error when I run the containers:
Error response from daemon: failed to add interface veth5b3bcc5 to sandbox:
error setting interface "veth5b3bcc5" IP to 172.19.0.2/16:
cannot program address 172.19.0.2/16 in sandbox
interface because it conflicts with existing
route {Ifindex: 10 Dst: 172.19.0.0/16 Src: 172.19.0.1 Gw: <nil> Flags: [] Table: 254}
My docker-compose.yml looks like this:
version: '3'
volumes:
dsn-redis-data:
driver: local
dsn-redis-conf:
driver: local
networks:
dsn-net:
driver: bridge
services:
duty-students-notifier:
image: duty-students-notifier:latest
network_mode: host
container_name: duty-students-notifier
build:
context: ../
dockerfile: ./docker/Dockerfile
env_file: ../.env
volumes:
- /etc/timezone:/etc/timezone:ro
- /etc/localtime:/etc/localtime:ro
networks:
- dsn-net
restart: always
dsn-redis:
image: redis:latest
expose:
- 5432
volumes:
- dsn-redis-data:/var/lib/redis
- dsn-redis-conf:/usr/local/etc/redis/redis.conf
networks:
- dsn-net
restart: always
Thanks!
The network_mode: host setting generally disables Docker networking, and can interfere with other options. In your case it looks like it might be trying to apply the networks: configuration to the host system network layer.
network_mode: host is almost never necessary, and deleting it may resolve this issue.

docker compose up with customized volumes on azure container instance

I am trying to docker compose up to Azure Container Instances, but nothing shows up, and no docker container is created. As below
CCSU_ACA_COMP+tn3877#CCSU-ND-909264 MSYS ~/source/cab/cab-deployment (master)
$ docker compose up
CCSU_ACA_COMP+tn3877#CCSU-ND-909264 MSYS ~/source/cab/cab-deployment (master)
$ docker ps
CONTAINER ID IMAGE COMMAND STATUS PORTS
Following is my docker-compose.yaml file
version: "3.8"
services:
cassandra:
image: cassandra:4.0.0
ports:
- "9042:9042"
restart: unless-stopped
volumes:
- hi:/home/cassandra:/var/lib/cassandra
- hi:/home/cassandra/cassandra.yaml:/etc/cassandra/cassandra.yaml
networks:
- internal
cassandra-init-data:
image: cassandra:4.0.0
depends_on:
- cassandra
volumes:
- hi:/home/cassandra/schema.cql:/schema.cql
command: /bin/bash -c "sleep 60 && echo importing default data && cqlsh --username cassandra --password cassandra cassandra -f /schema.cql"
networks:
- internal
postgres:
image: postgres:13.3
ports:
- "5432:5432"
restart: unless-stopped
volumes:
- hi:/home/postgres:/var/lib/postgresql/data
networks:
- internal
rabbitmq:
image: rabbitmq:3-management-alpine
ports:
- "15672:15672"
- "5672:5672"
restart: unless-stopped
networks:
- internal
volumes:
hi:
driver: azure_file
driver_opts:
share_name: docker-fileshare
storage_account_name: cs210033fffa9b41a40
networks:
internal:
name: cabvn
I have an Azure account and a Fileshare as below
I am suspecting the volume mount is the problem. Could anyone help me please?
The problem is in the "volumes" object inside the YAML config.
Make sure to use indentation to represent the object hierarchy in YAML. This is a very common problem with YAML and most of the time the error messages are missing to address this, or they are not informative.
Previous solution with wrong indentation
volumes:
hi:
driver: azure_file
driver_opts:
share_name: docker-fileshare
storage_account_name: cs210033fffa9b41a40
Correct solution
volumes:
hi:
driver: azure_file
driver_opts:
share_name: docker-fileshare
storage_account_name: cs210033fffa9b41a40

docker-compose how to persist mongodb-database

I am using docker-compose and here is my docker-compose.yaml file:
version: "3.7"
services:
node:
container_name: my-app
image: my-app
build:
context: ./my-app-directoty
dockerfile: Dockerfile
command: npm run dev
environment:
MONGO_URL: my-database
port: 3000
volumes:
- ./my-app-directory/src:/app/src
- ./my-app-directory/node_modules:/app/node_modules
ports:
- "3000:3000"
networks:
- my-app-network
depends_on:
- my-database
my-database:
container_name: my-database
image: mongo
ports:
- "27017:27017"
networks:
- my-app-network
networks:
my-app-network:
driver: bridge
I expect to find a clear and newly created database each time I run the following command:
docker-compose build
docker-compose up
But this is not the case. When I bring the containers up with docker-compose up, my database has the exact state of the last time I shut it down with docker-compose down command. And since I have not specified a volume prop in my-database object, is this normal behaviour? Does this mean that no other action to persisting database state is required? And can I use this in production if I ever choose to use docker-compose?
The mongo image define the following volumes:
/data/configdb
/data/db
So docker-volume will create and use a unamed volume for data/db.
If you want to have a new one, use:
docker-compose down -v
docker-compose up -d --build
Or use a mount point mounted on the volume location like:
volumes:
- ./db:/data/db:rw
And drop your local db directories when you want to start over.

Can i run cmd command in docker compose outside of container?

I have 2 docker-compose files that build a dockerfile, and i want join those docker-compose files
so, i created other docker-compose that goes up these 2 images
version: "3.4"
services:
frontend:
image: frontend-image
depends_on:
- backend
ports:
- "3000:80"
networks:
- teste-network
backend:
image: backend-image
ports:
- "5001:80"
networks:
- test-network
networks:
test-network:
driver: bridge
but, this docker-compose file not build the images
then i created a bash command that build these images
bash -c "docker-compose -f ./frontend/docker/docker-compose.yml build
&& docker-compose -f ./backend/docker/docker-compose.yml build"
I want to run this script before up containers, just typing docker-compose up
i assume that you have 2 dockerfiles - one for the frontend and the other for the backend, where each of which resides in the corresponding folder from your post, that is:
frontend/docker/Dockerfile
backend/docker/Dockerfile
then you can leverage docker-compose to build and run your images. all you have to do is to tell docker-compose where are the dockerfiles, which you can do by utilizing the build configuration.
version: "3.4"
services:
frontend:
image: frontend-image
build: ./frontend/docker
depends_on:
- backend
ports:
- "3000:80"
networks:
- test-network
backend:
image: backend-image
build: ./backend/docker
ports:
- "5001:80"
networks:
- test-network
networks:
test-network:
driver: bridge
then running docker-compose up frontend will build the docker images (if they do no exist), and then start them.

Docker-compose bridge network & host remote port forwarding at the same container

I'm trying to make service that can forward remote database port to container and at the same time can be accessible by alias hostname from other containers to work with them.
I am think that make all containers communicate by host network is bad practice, so i am trying to setup that configuration.
When i am triyng to add to php-fpm service network with driver: host, docker says
only one instance of "host" network is allowed
When i am trying to set php-fpm service with this
networks
- host
Docker says that he cant find out network with this name.
When i try to define network in docker-compose by id of built-in host, it just cant start this container.
This is my docker-compose:
version: '3.2'
networks:
backend-network:
driver: bridge
frontend-network:
driver: bridge
volumes:
redis-data:
home-dir:
services:
&app-service app: &app-service-template
build:
context: ./docker/app
dockerfile: Dockerfile
volumes:
- ./src:/app:rw
- home-dir:/home/user
hostname: *app-service
environment:
FPM_PORT: &php-fpm-port 9001
FPM_USER: "${USER_ID:-1000}"
FPM_GROUP: "${GROUP_ID:-1000}"
APP_ENV: local
HOME: /home/user
command: keep-alive.sh
networks:
- backend-network
&php-fpm-service php-fpm:
<<: *app-service-template
user: 'root:root'
restart: always
hostname: *php-fpm-service
ports: [*php-fpm-port]
environment:
FPM_PORT: *php-fpm-port
FPM_USER: "${USER_ID:-1000}"
FPM_GROUP: "${GROUP_ID:-1000}"
APP_ENV: local
HOME: /home/user
entrypoint: /fpm-entrypoint.sh
command: php-fpm --nodaemonize -R -d "opcache.enable=0" -d "display_startup_errors=On" -d "display_errors=On" -d "error_reporting=E_ALL"
networks:
- backend-network
- frontend-network
nginx:
build:
context: ./docker/nginx
dockerfile: Dockerfile
restart: always
working_dir: /usr/share/nginx/html
environment:
FPM_HOST: *php-fpm-service
FPM_PORT: *php-fpm-port
ROOT_DIR: '/app/public' # App path must equals with php-fpm container path
volumes:
- ./src:/app:ro
ports: ['9999:80']
depends_on:
- *php-fpm-service
networks:
- frontend-network
Network scheme (question about green line):
Host works on Debian 7 (updates prohibited) and conainer works with lastest Alpine

Resources