skip to Main Content

I have this docker compose in my repo

version: "3.9"

services:
  service:
    image: <REGISTRIY_LINK_TO_IMG>
    platform: linux/x86_64
    build:
      context: .
      dockerfile: Dockerfile
    ports:
      - "8080:8080"
      - "8081:8081"

  gql-schema-verify:
    image: <REGISTRIY_LINK_TO_IMG>
    entrypoint: []
    volumes:
      - ./service/src/main/resources/graphql:/home/node/updated
    environment:
      - VALIDATED_SERVICE=core
    command: /bin/bash validate

Here is the .gitlab-ci.yml

validate_schema:
  services:
    - docker:dind
  stage: package
  image: <REGISTRIY_LINK_TO_IMG>
  variables:
    DOCKER_IMAGE_NAME: <REGISTRIY_LINK_TO_IMG>
  before_script:
    - aws configure set aws_access_key_id $AWS_ACCESS_KEY_ID
    - aws configure set aws_secret_access_key $AWS_SECRET_ACCESS_KEY
    - aws configure set region $AWS_REGION
    - $(aws ecr get-login --region $AWS_REGION --no-include-email)
    - echo "AWS login ok"
    - echo "Getting the latest short commit hash for API GQL GW"
    - apt-get update -y && apt-get install -y jq 
  script:
    - docker-compose -p $DOCKER_IMAGE_TAG up --build -d service
    - sh ./docker-build-check.sh "${DOCKER_IMAGE_TAG}_service_1" 70

    # Additional debug output
    - echo "Listing contents of ./service/src/main/resources/graphql:"
    - ls -la ./service/src/main/resources/graphql

    # schema check
    - docker-compose -p $DOCKER_IMAGE_TAG run --rm verify-gql

  after_script: # docker cleanup
    - docker-compose -p $DOCKER_IMAGE_TAG rm --stop -v --force
  tags:
    - internal-docker-dind

What is not working is that, even tho the # Additional debug output shows the right files …

$ ls -la ./service/src/main/resources/graphql
total 24
drwxrwxrwx    2 root     root          4096 Feb 23 15:47 .
drwxrwxrwx    5 root     root          4096 Feb 15 19:00 ..
-rw-rw-rw-    1 root     root            17 Feb 10 18:34 test.graphqls

However -the /home/node/updated … it’s empty

On the schema check (last step in the script) … this is the verify-gql

#!/bin/sh

ls -la /home/node/updated

the ls -la shows empty directory:

drwxr-xr-x 2 root root 4096 Feb 23 15:38 .
drwxr-xr-x 1 node node 4096 Feb 23 18:08 ..

Any idea why??

2

Answers


  1. Since you are using a Bind Mount instead of a Docker volume you need to make sure the correct permissions.

    In this can you are mounting ./service/src/main/resources/graphql so check that you have the right permissions.

    For a quick and dirty check run the following:

    find ./service/src/main/resources/graphql -type d -exec chmod 777 {} ;
    find ./service/src/main/resources/graphql -type f -exec chmod 666 {} ;
    

    Note, you may want to further review these permissions to be as secure as possible.

    Also it would be safer to use absolute paths insetad of relative paths (Eg /home/someuser/service/src/main/resources/graphql)

    Login or Signup to reply.
  2. The issue in this circumstance is that your runner configuration has the host’s docker socket (/var/run/docker.sock) mounted into the job container. Your job is using this socket rather than the docker:dind service. This means that when the docker client specifies bind mount locations, the daemon (on the host) only understands them as paths on the host filesystem, not within the job container’s filesystem. Therefore, the mounts won’t work how you expect in this scenario.

    Instead, you want to make sure you’re using the docker daemon provided by the docker:dind service container. To do this, you can add the following environment variables to your job (or runner configuration):

    variables:
      DOCKER_HOST: "tcp://docker:2375"
      DOCKER_TLS_CERTDIR: ""
    

    This will ensure you are using the docker:dind service container as your docker daemon and bind mounts specified in your docker-compose.yml file will work as expected when communicating with the ‘remote’ daemon (the service container) over TCP.


    Note: this configures communication without TLS. See the GitLab documentation for more information about other ways to configure dind using TLS.

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search