Проблема
Мой стек docker-compose состоит из 'postgresql', 'redis' и 'Python api server' наряду с несколькими другими, такими как opentracing и т. Д., Нопроблемная зона ограничена вышеупомянутым.
Точка входа в моем файле компоновки - это сценарий оболочки, который динамически создает несколько файлов и папок, считывая переменные окружения среди других вещей, которые он должен делать. Теперь создание этих файлов работает как чудо, но права доступа к файлам и папкам этих динамически генерируемых файлов становятся интересными. В macos эти динамически генерируемые файлы и папки принадлежат пользователю без полномочий root, который запустил docker-compose up. Но на машине с Linux, работающей под управлением Ubuntu 19.01, эти файлы и папки принадлежат root, несмотря на то, что Dockerfile явно делает chown non-root-user:non-root-group для всей папки проекта и устанавливает активного USER как non-root-user
Контейнер postgres монтирует себя по указанному пути, но владелец этого каталога уже не тот, кто его создал, а какой-то странный systemd-coredump Я думаю, это потому, что userID и группа в Dockerfile Postgres отображаются на это имя пользователя на моем linux-сервере? Если да, каков рекомендуемый способ избежать этого?
Поскольку пользователь без полномочий root, который запустил docker-compose up, не может сохранить права доступа к файлам и папкам на хост-компьютере, я столкнулся с проблемами permission denied. Хотя chmod 777 помогает справиться с этой проблемой, я считаю, что chmod 777 никогда не решает никаких проблем.
Повторяя, что все это проблема только на машине с Linux. На Macos под управлением Docker-For-Mac как существующие, так и динамически сгенерированные файлы / папки сохраняют пользователя, не являющегося пользователем root, вошедшего в систему как своего владельца, так и внутри контейнера, назначенный пользователь USER в Dockerfile остается владельцем всех ранее существующихкоторые передаются через COPY) и недавно созданные динамические файлы / папки.
Пример
Пример изменения владельца файла и папки:
drwxrwxr-x 13 sparkle_deployment_2 sparkle_deployment_2 4096 Nov 21 01:00 PROTON/
drwx------ 19 systemd-coredump docker 4096 Nov 21 01:00 proton_db/
Сверху, proton_db - это место, где Postgres долженсмонтировать на. Эта папка изначально была создана пользователем - sparkle_deployment_2. После docker-compose up владелец и группа меняются на system-coredump и docker соответственно.
Вот часть моего: docker-compose.yaml
version: "3.4"
services:
pg:
container_name: proton_postgres
restart: always
image: postgres
environment:
- POSTGRES_USER=${PG_USERNAME}
- POSTGRES_PASSWORD=${PG_PASSWORD}
- POSTGRES_DB=${PG_TARGET_DB}
volumes:
- ${PROTON_POSTGRES_VOLUME_MOUNT}:/var/lib/postgresql/data
ports:
- ${PG_TARGET_PORT}:${PG_TARGET_PORT}
redis:
container_name: proton_redis
restart: always
image: redis
volumes:
- ${PROTON_REDIS_VOLUME_MOUNT}:/data
ports:
- ${REDIS_TARGET_PORT}:${REDIS_TARGET_PORT}
proton:
container_name: proton
restart: always
image: proton_stretch
ports:
- ${PROTON_TARGET_PORT}:${PROTON_TARGET_PORT}
expose:
- ${PROTON_TARGET_PORT}
volumes:
- .:/PROTON
- ${PROTON_SQLITE_VOLUME_MOUNT}:/PROTON/proton-db
depends_on:
- pg
- redis
entrypoint: ["./proton.sh"]
И,Вот Dockerfile моего API-сервера:
FROM python:3.7.3-stretch
RUN apt-get update
RUN apt-get install bash
RUN apt-get install -y gcc g++ unixodbc-dev
RUN groupadd -g proton_user_group
RUN useradd -G proton_user_group default_proton_user
RUN mkdir -p /PROTON
WORKDIR /PROTON
COPY . /PROTON
RUN python3 -m pip install -r requirements.txt --no-cache-dir
RUN chown -R default_proton_user:proton_user_group /PROTON
USER default_proton_user
EXPOSE 3000/tcp
Как вы видите, я делаю chown, чтобы явно иметь каталог, принадлежащий некорневому пользователю. Несмотря на это, когда есть файлы / папки, которые генерируются динамически, они получают root как их владелец. И это происходит только в Linux.
Win
Как и в MacOS, я хочу, чтобы узел без полномочий root на машине linux сохранял право владения всеми существующими идинамически генерируемые файлы / папки, следовательно, не приводящие к проблемам «отказано в разрешении».
Плюс тот же узел без полномочий root на машине linux, чтобы сохранить право собственности на место, куда монтируется том контейнера Postgres.