Docker Community Forums

Share and learn in the Docker community.

I keep getting random ghost volumes when I docker-compose up even though I have a volume named and configured

  node-express:
    container_name: node-express-dev
    build:
      context: ./
      dockerfile: Dockerfile.dev
    ports:
      - "5000:5000"
    volumes:
      - .:/src/app
    depends_on:
      - mongodb-node-dev
    restart: always
  mongodb-node-dev:
    container_name: mongodb-node-dev
    image: mongo:4.2.6
    restart: always
    ports:
      - "27018:27017"
    volumes:
      - mongodbdata:/data/db
volumes:
  mongodbdata:

I have the above ‘volumes’ named, but I’m still getting new volumes added to my volumes list when I use docker volume ls. I don’t understand why I’m getting this kind of ghosting.

When I run docker volume ls I get this:

DRIVER              VOLUME NAME
local               a696c50e761d87af6b1e108d7fb56d98faa1675195cc7b29dd6a5d319ec89f42
local               mongodbdata

I’m baffled that I have more than 1. If I run docker-compose up that I get two volumes, the one I created; fine, but then this other one. If I run docker-compose down and then up again I’ll get another volume added for 3 in total. It keeps adding another one.

One thing I’m coming around to understanding is that I should only use docker-compose up once and the rest of the time it should be docker-compose start or stop and down I guess is for when the project is likely over…I think. Still learning, but regardless of that part I’m still baffled by the two volumes, versus just the 1.

Feel free to expand or really anything on any assistance since I’m very new I’m working hard to learn as much as I can. No knowledge shared is wasted here.

Please and thank you!

Every VOLUME declared in the Dockefile of an image (regardless wether you wrote it yourself, or pull a premade image from dockerhub) will result in an anonymous volume, when no volume is mapped against the declared target folder.

There is no problem in using docker-compose up -d to deploy or re-deploy a stack. While stop just stops the containers of the stack, down wil delete the containers of the stack.

Configuration options that are applied at build time.

build can be specified either as a string containing a path to the build context:

version: “3.8”
services:
webapp:
build: ./dir
Or, as an object with the path specified under context and optionally Dockerfile and args:

version: “3.8”
services:
webapp:
build:
context: ./dir
dockerfile: Dockerfile-alternate
args:
buildno: 1
If you specify image as well as build, then Compose names the built image with the webapp and optional tag specified in image:

build: ./dir
image: webapp:tag
This results in an image named webapp and tagged tag, built from ./dir.

Hi @lewish95 sorry man I’m trying to read your code and get what you are alluding too, but it’s lost on me. I do appreciate your effort and will re-read it a couple more times and try figure it out, but regardless your effort is appreciated and respected. Always.

@meyay hmmm I’m trying to get what you are putting down; let me see if I interpret it correct. Understand that I’m new to Docker and could totally f this up.

You are alluding to the fact that perhaps in this example the official MongoDB is producing a volume as part of it’s image instructions when I create a container and therefore I am building a container with a volume from MongoDB’s official image as well as during my docker-compose build my own volume.

Is that a correct interpretation?

@lewish95 maybe the above is something you can build off of? Not sure if I’m moving closer to what you are thinking either.

Regardless thank you both for what you’ve all contributed to this point. Even now I feel like I at the worst case I at least have new paths to work down towards a solution and best case I feel like I’m lots closer. Thank you.

Just ignore the response of lewish95. 95% of his/her/its? answer are ignoring the context of the question.

I am saying if the image has defined volume declaratiosn that are “unused” (as in nothing is mapped into them), then you get anonymous volumes.

You can check the volumes for an image with a command like this:
docker image inspect {imageid or name:tag} --format {{.Config.Volumes}}

Every entry you get listed requires a volume, either you provide them with your own conditions and naming or docker creats them for you.

@meyay that was a really helpful addition. I was close at the beginning with what you said, but this clarification is really perfect. I completely understand. I’ll start using that sequence of commands with this project and in the future with other Images in particular DBs.

Cheers!