Народ. В docker-entrypoint создаётся папка но при этом она создаётся

от root'a а не от www-data. Какие причины могут быть ? Контейнер создаёт gitlab-runner —user root - это может быть причиной ?

по факту может запускаться от другого юзера, также в entrypoint.sh могут быть какие-то перопределния юзеров но я ваще не советую создавать какие-то файлы в рантайме

php: container_name: "${PROJECT}_dev_php" restart: unless-stopped build: context: . dockerfile: Docker/remote/php/Dockerfile ports: - 9000 depends_on: - db environment: - APP_ENV=prod - APP_SECRET=19f3fb6105fd4e6e3c8a2b72de334623 - MAILER_DSN=${MAILER_DSN} - DATABASE_URL=pgsql://${PROJECT}:${DB_PASSWORD}@db/${PROJECT} volumes: - "shared:/var/www/html/:rw" networks: - dev nginx: container_name: "${PROJECT}_dev_nginx" build: context: . dockerfile: Docker/remote/nginx/Dockerfile environment: PROJECT: ${PROJECT} volumes: - "shared:/var/www/html/:rw" depends_on: - php - db tty: true ports: - ${WEB_PORT}:80 networks: - dev

к сожалению это необходимость, обновлять базу при создании контейнера иначе изменения в репозитории могут не сработать при деплое

добавь выполнение команды id в entrypoint. И она распечаает от какого юзера запускается entrypoint. Ваще тут строго говоря не видно что новые папки создаются. Я бы проверил не существовали они до запуска ./bin/console. Возможно папки уже вшиты в образ и у них права рута То есть я бы добавил #!/usr/bin/env bash set -e id ls -la /var/www/html ... В начало entrypoint, и посмотрел бы что там будет А в целом создавать папки в контейнере для миграций не нужно, весь стейт миграций можно хранить в базе, и еще база позволяет лочить миграции, на мой вкус плохая практика мигратору полагаться на файлы и хранить в них стейт. Когда надо будет > 1 бэкенда запускать, будет больно с таким подходом

Спасибо. Ща попробую после перекура. Насчёт миграций - пхп фреймворки срздают миграции автоматом, сравнивая базу и модели. Стейт как таковой не сохраняетя а генерится

Кстати а то что я делаю chown в докерфайле на всю папку при копировании и потом отдельно на папку var это не влияет разве ?

В базе хранятся только версии миграций

не очень на мой вкус

Ну это так как это работает из коробки. Переписывать схему - муторно и гемор

всё равно

chown может рекурсивно пройтись по папкам, а может и нет. Зависит от опций

кароче ты был прав во время билда создаётся папка

можно как-то сделать ls- la в докерфайле чтобы увидеть структуру и доступы во время билда ?

добавь в RUN, там просто при втором прогоне оно закешится, но это не проблема, достаточно чутка менять слой с RUN. Ваще можно закоментить все слои после интересущего тебя слоя, собрать образ, запустить. И смотреть что там

по неизвестной мне причине chown отрабатывает прекрасно на всём кроме двух папок

Слушай вопрос другого типа - есть репозиторий там я билжу images для проекта. В gitlab-ci несколько работ которые тригеряться по тегам. То есть если мне надо новый image или я модифицирую старый я пушу бранч с докерфайлом и следом тег. Это неочень удобно. Может есть какие статьи как лучше сделать ?

надо решить как хочется, чтобы было удобно. Удобно это же субъективный параметр. Как по мне такая схема удобна. master/main пушится в latest тег, теги пушатся в одноименныем теги в registry; У тебя вроде тоже самое, только больше latest'ов как я понял

нууу идеально как по мне - один джоб который будет получать скажем тег, билдить его (т.к. теги принадлежат бранчам) и пушить в репку. Но тоесть максимум автоматизации

ну сделай так