Как правильно объявить сохранение артефакта с томами Docker?

Question

[EmachinesDIMA]

1. тома даёт создавать только в директории сборки.
2. путь на хосте для тома не создаётся автоматически, поэтому создаю директорию ${CI_PROJECT_DIR} и её указываю как путь для артефактов.
3. том содержит путь : "путь_на_хосте_в_папке_сборки : путь_в_контейнере : права_чтения_записи"

4. сборка проходит. артефакт "создаётся". В кавычках, потому что внутри по пути артефакта пусто.

0. оф и не оф мануалы перечитал вдоль и поперёк.

Получаю ошибку:

Uploading artifacts... found 1 matching files and directories ...
Uploading artifacts as "archive" to coordinator... ok id=632087 responseStatus=201 Created token=roSNWzgE
+ exit 0

Есть успешный вывод и якобы артефакт есть:

Job artifacts
These artifacts are the latest. They will not be deleted (even if expired) until newer artifacts are available.

Но там "empty" ...

----------------------------------------------

Структура объявления тома:

docker-compose.yml

services:
  app:
    build:
      dockerfile: Dockerfile
      context: .
    volumes:
      - "vlm:/var/www/app:rw"

volumes:
  vlm:
    external:
      name: /var/www/app

.gitlab-ci.yml

upload:
  variables:
    COMPOSE_FILE: docker-compose.yml
    CI_DEBUG_TRACE: "true"
  tags:
    - docker
  stage: upload
  script:
    - echo $CI_JOB_STAGE
    - mkdir -p ${CI_PROJECT_DIR}/tmp/var/www/app
    - docker-compose build --force-rm --no-cache
  artifacts:
    name: "artifact-$CI_JOB_NAME-$CI_COMMIT_REF_NAME"
    paths:
      - ${CI_PROJECT_DIR}/tmp/var/www/app
    expire_in: 1h
    when: always
  when:
    manual

Answer 1

[mureevms]

Предположение 1:
> Uploading artifacts... found 1 matching files and directories

Он нашел одно совпадение. Быть может это именно каталог ${CI_PROJECT_DIR}/tmp/var/www/app, в котором не обнаружил файл artifact-$CI_JOB_NAME-$CI_COMMIT_REF_NAME. Для решения попробовать указать вместо вашего варианта, так. Не понятно как и какой файл создается в этом каталоге, вы этого не показывает, вероятно он просто не подходит под шаблон.

artifacts:
    when: always
    paths:
      - "${CI_PROJECT_DIR}/tmp/var/www/app/*" # именно в кавычках

Предположение 2:
Раннер запускается от своего пользователя, а файл создается от пользователя, под которым запускается процесс в контейнере, как правило, это рут, поэтому имеет смысл попробовать перед docker-compose дать 777 права на этот каталог:

script:
    - chmod 777 ${CI_PROJECT_DIR}/tmp/var/www/app

Предположение 3:
Маловероятно, вы же проверили, но на всякий случай проверьте еще раз, смущает частое упоминание /var/www/app в разных вариациях и не уверен, что это один и тот же каталог для хоста и контейнера. Например, ${CI_PROJECT_DIR}/tmp/var/www/app каталог для раннера это не одно и тоже, что и для контейнера.

И последнее:
Вы монтируете каталог /var/www/app, а создаете ${CI_PROJECT_DIR}/tmp/var/www/app

Comments

[EmachinesDIMA]

Спасибо что отозвались!
Директория "/var/www/app" фигурирует для передачи в неё данных.
Я разделяю многоступенчатую сборку Docker на отдельные Dockerfile , чтобы можно было независимо обновлять данные . А как их подгружать в nginx (второй этап) - использую Docker Volume и хранилище артефактов. Вот каркас моего Dockerfile для многоступенчатой сборки.

FROM node as builder
WORKDIR /home/node/
COPY app .
RUN npm run build

FROM nginx-alpine
# COPY --from=builder /home/node/dist /var/www/app
COPY ${CI_PROJECT_DIR}/tmp/app /var/www/app
...

Предположение 1 не помогает.
С "Предположение 2" тоже проблем нет.
А о третьем ответил в самом начале.

Однако!
Я нашёл вот такое интересное обсуждение:
https://gitlab.com/gitlab-org/gitlab-foss/-/issues...

пользователь "Joost" комментирует:
For anyone who is still facing this issue, in gitlab ce 11.6 the warning is still very cryptic which let me to this issue. The folder you specify in your gitlab-ci.yml file:

artifacts:
    paths:
    - build/

Is relative to /builds/$CI_PROJECT_PATH/. So in my case the artifacts would have to be in /builds/$CI_PROJECT_PATH/build

и меня вводит в заблуждение данное действие (из обсуждения по мной указанной ссылке):
- mv -v ${APP_HOME}/app* $PACKAGE_PATH

...
вот думаю и не понимаю ... пока не получается с путями разобраться.

[mureevms]

и меня вводит в заблуждение данное действие (из обсуждения по мной указанной ссылке):

Как раз это 3 и 4 пункты.

COPY ${CI_PROJECT_DIR}/tmp/app /var/www/app

Попробуйте для начала не использовать volumes, просто монтируйте текущий каталог (т.е. каталог проекта в котором находится раннер при выполнении скриптов).
Т.е. перепишите докерфайлы и протестируйте локально. Если дело не в правах, то в путанице с каталогами

Затем, поскольку раннер уже запускает скрипты в $CI_PROJECT_PATH и при создании каталога надо просто сделать примерно так:

script:
    - echo $CI_JOB_STAGE
    - mkdir -p artifacts
    - docker-compose build --force-rm --no-cache
  artifacts:
    when: always
    paths:
      - "artifacts/*"

При этом, сам контейнер должен класть артефакты в artifacts

[EmachinesDIMA]

mureevms, указал, как Вы и предложили, но ..

WARNING: artifacts/*: no matching files

Да, надо подумать что же не так ...

В любом случае спасибо!
а пока ломаю голову с корректностью путей ...

[mureevms]

EmachinesDIMA, можно легко проверить создав файл из докерфайла, положив его в нужный каталог и собрать контейнер, в ходе выполнения будет видно (а если не будет, то добавить какой-нибудь ls для проверки) где он его создает и проверить потом его наличие.

[EmachinesDIMA]

mureevms, я проанализировал работу с томами и монтированием каталогов, но добиться чудес не удаётся. Общий вывод:

# ============================================================================================================================================ #
### --- mounts --- ###
#
# services:
# ...
# - type: bind
#    source: ../../../artifacts_path
#
# volumes: <- и закомментированный блок определения volumes
# ...

# --- при монтировании я нахожу нужный каталог, всё ок. 
# Но вот особенность монтирования в том, что нельзя "синхронизировать" данные между хостом и контейнером, для этого придумали тома volume.

# ============================================================================================================================================ #
### --- volumes --- ###
#
# services:
# ...
# - type: volume
#   source: upload_app_volumes
#
# volumes:
#   upload_app_volumes:
#      ...
#      o: 'bind'
#      device: 'artifacts_path'

# --- а вот при подключении тома volume не удаётся смонтировать куда требуется:
# "device: 'artifacts_path'" находит точку монтирования начиная с корня проекта, поэтому и тут внимательнее с иерархией.
# Однако "source" монтируется в хостовое хранилище томов volume - ":/var/lib/docker/volumes/app_upload_app_volumes/_data". 
# Решения указания монтировать внутрь контейнера не нахожу.

# ============================================================================================================================================ #

а здесь наблюдения и результаты:

Выжимка из работы с каталогами и томами Docker:

>>>>>>>>>>>>>> но чтобы понапрасну не читать, знай: <<<<<<<<<<<<<<<<<<
>>>>>>>>>>>>>> монтирование не имеет режима read-write, поэтому данные между хостом и контейнером НЕ будут синхронизированы. <<<<<<<<<<<<<<<<<<<<<<<<<<<

1. монтировани. (bind)
большинство инструкций ссылаются на рабочий вариант монтирования.

``` bash
# ВНИМАТЕЛЬНО изучи в какой директории $(pwd) создаёшь папку! И следи какой уровень вложенности указал для монтирования в docker-compose

mkdir -p ./path_on_host_into_project_workdir

cat <<EOF > docker-compose.yml
---
version: "3.7"

services:
  app:
    build:
      dockerfile: Dockerfile
      context: .
    volumes:
      - type: bind
        source: ./path_on_host_into_project_workdir
        target: /path_on_container
EOF

```

Пояснение.
Для монтирования необходимо предварительно создать директорию, которую собираемся подключить к контейнеру.
указываем что используем модуль "mount" - 'type: bind'
указываем где наша папка для подключения - 'source'
указываем куда подлючиться внутри контейнера - 'target'

<<<<<<<<<<<<<<<<<<<<<<<<<<<<< но у меня это не сработало. >>>>>>>>>>>>>>>>>>>>>>>..
ошибка: 
ERROR: for app  Cannot create container for service app: invalid mount config for type "bind": bind source path does not exist: /home/dmitry/workdir2/wordpress/docker/app/path_on_host_into_project_workdir
ERROR: Encountered errors while bringing up the project.


...........................................................

2. тома - (volumes) 

убеждение что том - "type: volume".
Для томов необходимо определить конструкцию volumes. И там описываем что куда к чему о чём по чём.

``` docker-compose.yml
---
version: "3.7"

services:
  app:
    build:
      dockerfile: docker/app/Dockerfile
      context: ../../
    volumes:
      - type: volume
        source: ./path_on_host_into_project_workdir
        target: /var/www/app_app

volumes:
  upload_app_volumes:
    driver: local
    driver_opts:
      type: 'none'
      o: 'bind'
      device: './path_on_host_into_project_workdir'

```


``` bash
$ docker-compose up -d
```
ошибка : 
ERROR: for app  Cannot create container for service app: invalid mount config for type "bind": bind source path does not exist: /home/dmitry/workdir2/wordpress/docker/app/path_on_host_into_project_workdir
ERROR: Encountered errors while bringing up the project.

И можем посмотреть на содержимое тома
``` bash
$ docker inspect $(docker ps -lqa) | jq '.[]|.Mounts' 
[
  {
    "Type": "volume",
    "Name": "app_upload_app_volumes",
    "Source": "/var/lib/docker/volumes/app_path_on_host_into_project_workdir/_data",
    "Destination": "/var/www/app_app",
    "Driver": "local",
    "Mode": "z",
    "RW": true,
    "Propagation": ""
  }
]
```

[mureevms]

> Но вот особенность монтирования в том, что нельзя "синхронизировать" данные между хостом и контейнером, для этого придумали тома volume
Суть в том, что если каталог с тачки монтируется в контейнер, то синхронизация не требуется, файлы просто читаются и пишутся, они примонтированы.

> монтирование не имеет режима read-write, поэтому данные между хостом и контейнером НЕ будут синхронизированы.
Это не соответствует действительности. У меня в проде на нескольких проектах работает именно так.

> ERROR: for app Cannot create container for service app: invalid mount config for type "bind": bind source path does not exist: /home/dmitry/workdir2/wordpress/docker/app/path_on_host_into_project_workdir
Собственно, проблема не устранена, но она в пути каталогов, как я и говорил ранее.