docker 无法使用 docker-compose 将主机目录安装到 docker 容器

Question

I'm unable to mount a host directory (on a rasberry pi) to a docker container api_service . Even with host chmod -R 777 .

I was able to mount it running the api_service from commandline docker start --mount type=bind,src=/data/yarmp-data,target=/data/yarmp-data docker_api_service_1 and docker inspect containerId in this case the mount section was telling me the mount was done and inside the container it was the case. But I'd like to achieve that with docker-compose .

I tried different syntaxes into the docker-compose.yaml file but never achieving it. Every time removing all containers, images, then docker-compose build and docker-compose up .

What am I missing? is there a way to trace the mount options at startup of the container? Should the target directory have been created into the target image before mounting it on docker-compose.yaml ?

docker-compose.yaml

#Doc: https://github.com/compose-spec/compose-spec/blob/master/spec.md
version: '3.2'
services:
        api_service:
                build: ./api_service
                restart: always
                ports:
                        - target: 8080
                        published: 8080
                depends_on:
                        - postgres_db
                links:
                        - postgres_db:yarmp-db-host # database is postgres_db hostname into this api_service
                volumes:
                        - type: bind 
                        source: $HOST/data/yarmp-data #Host with this version not working
                        source: /data/yarmp-data #Host absolute path not working
                        #source: ./mount-test #not working either
                        target: /data/yarmp-data
                        #- /data/yarmp-data:/data/yarmp-data # not working either
        postgres_db:
                build: ./postgres_db
                restart: always
                ports:
                        - target: 5432
                        published: 5432
                env_file:
                        - postgres_db/pg-db-database.env # configure postgres
                volumes:
                        - database-data:/var/lib/postgresql/data/ 

postgres_db/Dockerfile

FROM postgres:latest
LABEL maintainer="me@mail.com"

RUN mkdir -p /docker-entrypoint-initdb.d
COPY yarmp-dump.sql /docker-entrypoint-initdb.d/

api_service/Dockerfile

FROM arm32v7/adoptopenjdk
LABEL maintainer="me@mail.com"

RUN apt-get update
RUN apt-get -y install git curl vim
CMD ["/bin/bash"]


#csv files data
RUN mkdir -p /data/yarmp-data #Should I create it or not??

RUN mkdir -p /main-app
WORKDIR /main-app
# JAVA APP DATA
ADD my-api-0.0.1-SNAPSHOT.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar","/main-app/app.jar"]

Answer 1

Seems my entire docker-compose.yaml file was not correct.

As pointed out by @xdhmoore there was an indentation issue , and others.

I figured out by:

1. validating the docker-compose.yaml with docker-compose config
2. Tabs are NOT permitted by the YAML specs, USE ONLY SPACES FOR INDENTATION
3. Note that vim default configuration file /usr/share/vim/vim81/ftplugin/yaml.vim was right replacing tabs with spaces...
4. The indentation of long syntax was done on my editor with tabs when 2 spaces before were working. Here my final docker-compose.yaml

docker-compose.yaml

version: '3.2'
services:
api_service:
    build: ./api_service
    restart: always
    ports:
    - target: 8080
        published: 8080 #2 spaces before published
    depends_on:
    - postgres_db
    links:
    - postgres_db:yarmp-db-host
    volumes:
    - type: bind 
        source: /data/yarmp-data #2 spaces before source, meaning same level as previous '- types:...' and add 2 spaces more
        target: /data/yarmp-data #2 spaces before target
postgres_db:
    build: ./postgres_db
    restart: always
    ports:
    - target: 5432
        published: 5432 #2 spaces before published
    env_file:
    - postgres_db/pg-db-database.env # configure postgres
    volumes:
    - database-data:/var/lib/postgresql/data/
volumes:
    database-data: 

Answer 2

This is based on the YAML in your answer. When I plug it into this yaml to json converter , I get:

{
   "version": "3.2",
   "services": null,
   "api_service": {
      "build": "./api_service",
      "restart": "always",
      "ports": [
         {
            "target": "8080\npublished: 8080"
         }
      ],
      "depends_on": [
         "postgres_db"
      ],
      "links": [
         "postgres_db:yarmp-db-host"
      ],
      "volumes": [
         {
            "type": "bind\nsource: /data/yarmp-data"
         }
      ]
   },
   "postgres_db": {
      "build": "./postgres_db",
      "restart": "always",
      "ports": [
         {
            "target": "5432\npublished: 5432"
         }
      ],
      "env_file": [
         "postgres_db/pg-db-database.env"
      ],
      "volumes": [
         "database-data:/var/lib/postgresql/data/"
      ]
   },
   "volumes": {
      "database-data": null
   }
}

You can see several places where the result is something like "type": "bind\nsource: /data/yarmp-data" . It appears that YAML is interpreting the source line here as the 2nd line of a multiline string. However, if you adjust the indentation to line up with the t in - type , you end up with:

...
      "volumes": [
         {
            "type": "bind",
            "source": "/data/yarmp-data",
            "target": "/data/yarmp-data"
         }
      ]
...

The indentation in YAML is tricky (and it matters), so I've found the above and similar tools helpful to get what I want. It also helps me to think about YAML in terms of lists and objects and strings. Here - creates a new item in a list, and type: bind is a key-value in that item (not in the list). Then source: blarg is also a key-value in the same item, so it makes sense that it should line up with the t in type . Indenting more indicates you are continuing a multiline string, and I think if you indented less (like aligning with - ), you would get an error or end up adding a key-value pair to one of the objects higher up the hierarchy.

Anyway, it's certainly confusing. I've found such online tools to be helpful.