Docker Volumes Error

Hey, @kcollins I’m setting a test environment to simulate a multiple gateway system.

I pulled the code from GitHub - thirdgen88/ignition-docker: Ignition Docker Development Environment. When I run the docker-compose.yml, I get the following error:

[+] Running 0/0

  • Volume “_hub_data” Error 0.0s
    Error response from daemon: create _hub_data: “hub_data" includes invalid characters for a local volume name, only "[a-zA-Z0-9][a-zA-Z0-9.-]” are allowed. If you intended to pass a host directory, use absolute path

Any insight as to why this is happening? I noticed that in the error path an “_” appears as a prefix before the volume name.

It ran properly initially, however I stopped it to make changes to the .yml file (different initial modules and 2 full gateways rather than 1 full and 1 edge). When running the docker compose up command again, I get the error listed above.

Running on windows 10, Docker version 20.10.13, build a224086, Docker Compose version v2.3.3.

Good morning! I’m making the assumption that you’re referring to the thirdgen88/ignition-examples repo, specifically the ignition-gwnetwork example.

When use Compose to bring up a solution, it will typically create the volumes based on the containing folder (which is used as the “project” name). Is there anything special about the parent folder name (containing the docker-compose.yml)? If it is named from that repo, I’d expect the computed volume name to be something like ignition-gwnetwork_hub_data.

I tried spinning up that solution on both macOS and a Win11 machine with both docker-compose (original Docker Compose based on Python) and docker compose (using the new Compose V2 CLI Plugin), and even with a space in the parent project name, the solution still comes up. Perhaps a screenshot of the whole docker compose up -d would help provide more context clues? (you might run a docker compose down -v first to clear things out)

I also re-read your post, perhaps something went wrong with the edits to the YML file, can you share the YML contents here?

Morning Kevin!

That is correct, I was referring to the ignition-gwnetwork example.

To get this test going, I just have my docker-compose.yml om the root of my C Drive. It hasn’t had any issues finding it there the file but it sounds like this is the cause of my problems.

Here is the contents of my docker-compose.yml

version: “3”
services:
hub:
image: kcollins/ignition:latest # You can change latest to a specific version, e.g. 8.0.5
ports:
- “8088:8088”
volumes:
# - ./gateway_backup.gwbk:/restore.gwbk
- hub_data:/var/lib/ignition/data
environment:
GATEWAY_SYSTEM_NAME: hub
GATEWAY_ADMIN_PASSWORD: password
GATEWAY_NETWORK_AUTOACCEPT_DELAY: 120

spoke1:
image: kcollins/ignition:latest
ports:
- “8089:8088”
volumes:
# - ./gateway_backup.gwbk:/restore.gwbk
- spoke1_data:/var/lib/ignition/data
environment:
GATEWAY_SYSTEM_NAME: spoke1
GATEWAY_ADMIN_PASSWORD: password
GATEWAY_NETWORK_0_HOST: hub

spoke2:
image: kcollins/ignition:latest
ports:
- “8090:8088”
volumes:
- spoke2_data:/var/lib/ignition/data
environment:
GATEWAY_SYSTEM_NAME: spoke2
GATEWAY_ADMIN_PASSWORD: password
GATEWAY_NETWORK_0_HOST: hub

volumes:
hub_data:
spoke1_data:
spoke2_data:

Picture of the error:

It is hard to discern the indentation of your YAML (though assuming that is correct, it looks like it should be working), perhaps try encapsulating it with a code block (using three back-ticks ``` on start/end of the block), like below:

version: "3"
services:
  hub:
    image: ...

One comment right off the bat is that you should place the docker-compose.yml file in a parent directory that represents the “project” you’re looking to spin up. It establishes a context that is used for naming everything (and also keeping things segregated between multiple Compose solutions you might want to have on your system). Consider making a C:\Users\jonah\Docker\ignition-gwnetwork folder and placing it there. (again, probably should try cleaning everything out again with a down -v before moving it). Then, you can do an up -d from that folder and see if you get better results.

Additionally, you might try restarting Docker Desktop to see if that helps… Past that, I’d take the approach of seeing what constructs have been created (and cleanup as necessary) with commands like docker ps -a and docker volume ls.

Looks like that was the issue! I created a folder at ‘C:\Users\jonah\Docker\ignition-gwnetwork’ like you suggested. Then tried using

docker compose -f C:\Users\jonah\Docker\ignition-gwnetwork\docker-compose.yml up -d'

In the details of the cmd prompt I could see that docker was automatically searching for the file in ‘C:\Users\jonah’ So I adjusted the path in my command and it worked.

Used:

docker compose -f Docker\ignition-gwnetwork up -d

Looks like I’m on the right track now, the multi-gateway network is up and running and communicating!

Thanks for all the help Kevin!

Here’s the yml code pasted again if you still want to see it properly.

version: "3"
services:
  hub:
    image: kcollins/ignition:latest  # You can change `latest` to a specific version, e.g. `8.0.5`
    ports:
      - "8088:8088"
    volumes:
      # - ./gateway_backup.gwbk:/restore.gwbk
      - hub_data:/var/lib/ignition/data
    environment:
      GATEWAY_SYSTEM_NAME: hub
      GATEWAY_ADMIN_PASSWORD: password
      GATEWAY_NETWORK_AUTOACCEPT_DELAY: 120

  spoke1:
    image: kcollins/ignition:latest
    ports:
      - "8089:8088"
    volumes:
      # - ./gateway_backup.gwbk:/restore.gwbk
      - spoke1_data:/var/lib/ignition/data
    environment:
      GATEWAY_SYSTEM_NAME: spoke1
      GATEWAY_ADMIN_PASSWORD: password
      GATEWAY_NETWORK_0_HOST: hub

  spoke2:
    image: kcollins/ignition:latest
    ports:
      - "8090:8088"
    volumes:
      - spoke2_data:/var/lib/ignition/data
    environment:
      GATEWAY_SYSTEM_NAME: spoke2
      GATEWAY_ADMIN_PASSWORD: password
      GATEWAY_NETWORK_0_HOST: hub

volumes:
  hub_data:
  spoke1_data:
  spoke2_data:
'''

Glad you got it working! Yes, that is one of the aspects of Compose that I suppose is intended to be intuitive–it works against whichever local folder you invoke it from by default. As you’ve found, you can be explicit regarding both the location of (one or more, including override) YML and the project name (instead of inferring based on parent folder name). I use this strategy to bring up services I’ve documented in Compose YAML files that I’ve got collected in a single folder. For example, I typically run a local Traefik instance and have it defined by a stack-proxy.yml (alongside some other files). I spool it up (or update it) via:

docker compose -f ~/Docker/stack-proxy.yml -p proxy up -d

Hope you enjoy using containers even more now that things are cooking! :smiley:

1 Like