Compose: Docker Compose는 명명된 볼륨을 '루트'로 독점적으로 탑재합니다.

나는 이것이 도커 엔진에서 지원되지 않는다고 생각하므로 API에 추가될 때까지 Compose에서 지원할 수 있는 방법이 없습니다. 그러나 이 기능을 추가할 필요는 없다고 생각합니다. 항상 올바른 사용자에게 파일을 제공할 수 있습니다.

version: '2'
services:
  web:
    image: alpine:3.3
    volumes: ['random:/path']

volumes:
  random:

$ docker-compose run web sh
/ # touch /path/foo
/ # ls -l /path
total 0
-rw-r--r--    1 root     root             0 Apr  5 16:11 foo
/ # chown postgres:postgres /path/foo
/ # ls -l /path
total 0
-rw-r--r--    1 postgres postgres         0 Apr  5 16:11 foo
/ # 

$ docker-compose run web sh
/ # ls -l /path
total 0
-rw-r--r--    1 postgres postgres         0 Apr  5 16:11 foo

직면하고 있는 문제는 명명된 볼륨 초기화에 관한 것입니다. 이것은 분명히 Compose에서 처리하는 것이 아니지만(어느 정도 범위를 벗어났기 때문에) docker cli를 사용하여 docker-compose up 를 실행하기 전에 명명된 볼륨을 초기화할 수 있습니다.

이것이 Docker인지 Compose 문제인지 확실하지 않았습니다. 잘못 제출했다면 죄송합니다.
이것은 Docker API의 계획입니다. 거기에 문제를 제기해야 합니까?

컨테이너에 수동으로 로그인하고 'postgres' 사용자에게 볼륨을 chown -ing할 수 있는 가능성을 이해합니다. 하지만 제 경우에는 Compose를 사용하여 새 클라이언트( docker-compose -p client_name up )에 대한 새 컨테이너를 즉시 인스턴스화할 수 있고 Compose는 사용자 지정 네트워크 client_name_default 를 생성하고 컨테이너를 생성합니다. 이름이 client_name _appserver_1 및 client_name _server-postgresql_1 이고 _더 중요하게는_ client_name_db-data 볼륨이 생성됩니다. 이 모든 작업을 수동으로 수행할 필요가 없으므로 클라이언트 등록을 처리하는 스크립트에서 실행할 수 있습니다.

설명하신 솔루션(볼륨 레이블에 sh 및 chown 을 사용하여 컨테이너에 _수동으로_ "로깅")을 사용하면 새 클라이언트를 추가하는 간단한 절차를 수행할 수 없으며 이는 반드시 손으로 보살핌을 받으십시오.

이것이 내가 이 기능을 구현해야 한다고 생각하는 이유입니다. Docker API에서 볼륨을 마운트할 때 ro 또는 rw (읽기 전용 또는 읽기-쓰기용) 권한을 지정할 수 있습니다. user:group 을 지정할 수 있어야 한다고 생각합니다

내 요청이 의미가 있다고 생각하십니까?

사실 나는 뉴스를 가지고 여기에 왔는데, 내가 달성하려고 하는 것은 할 수 있는 것 같지만 이것이 기능인지 버그인지 모르겠습니다. 변경한 이유는 다음과 같습니다.

내 Dockerfile 에서 _사용자 'postgres'로 변경하기 전에_ 다음을 추가했습니다.

# ...
RUN    mkdir /volume_data
RUN   chown postgres:postgres /volume_data

USER postgres
# ...

이것이 하는 일은 /volume_data 디렉토리를 만들고 사용자 'postgres'가 쓸 수 있도록 권한을 변경하는 것입니다.
Dockerfile 부분입니다.

이제 docker-compose.yml 에서 아무 것도 변경하지 directory_name_db-data 하고 이를 /volume_data 마운트 하고 권한은 유지됩니다! .
즉, 이제 명명된 볼륨이 _pre-existing_ 디렉토리 /volume_data 에 마운트되어 권한이 보존되어 'postgres'가 쓸 수 있습니다.

그렇다면 이것이 의도된 행동 또는 보안 위반이라면? (이 경우에도 도움이 됩니다!)

명명된 볼륨이 이를 사용하는 첫 번째 컨테이너에서 초기화되도록 이것이 Docker 1.10.x에 추가되었다고 생각합니다. 예상되는 행동이라고 생각합니다.

또한 Dockerfile에 소유권이 설정되어 있는 명명된 볼륨을 수행하고 있으며 user: postgres 추가하여 루트가 아닌 사용자가 PID 1도 소유하도록 합니다.

Docker-compose 에 대해 volumes 가 driver_opts 옵션을 제공합니다.
chmod , chown 드라이버에도 local 와 같은 옵션이 있는 것을 보는 것이 좋습니다.
그리고 특히 시작 시 존재하지 않는 경우 로컬로 생성된 호스트 디렉토리에도 적용되기를 원합니다.

관련(어느 정도) https://github.com/moby/moby/pull/28499

누군가가 이미 Moby 프로젝트에서 문제를 열었습니까?

@dnephin 의 답변이 작동하지 않습니다. 문제는 컨테이너를 표준 사용자로 실행 중이고 chown 또는 chmod 명령이 실패하고 볼륨이 루트 소유이므로 표준 사용자가 권한을 변경할 수 없기 때문입니다.

@jcberthon 제안된 방법은 루트를 시작 사용자로 사용하여 컨테이너를 실행한 다음 chown/chmod 다음에 USER 명령을 사용하여 기본적으로 "권한 삭제"가 되도록 하는 것입니다.

Docker 이미지를 제어할 수 있지만 실제로 옵션이 아닌 기존 이미지를 사용하는 경우 괜찮습니다.

@dragon788 과 @micheljung , 나는 내 문제를 해결했습니다.

실제로 실제 문제는 내 Dockerfile에서 VOLUME 선언한 다음 해당 볼륨에 있는 파일의 소유권과 권한을 수정했다는 것입니다. 이러한 변경 사항은 손실됩니다. VOLUME 선언을 Dockerfile의 끝으로 이동(또는 선택 사항이므로 제거)하면 내 문제가 해결됩니다. 권한이 정확합니다.

그래서 실수는 다음과 같습니다.

FROM blabla
RUN do stuff
VOLUME /vol
RUN useradd foo && chown -R foo /vol
USER foo
CMD ["blabla.sh"]

위의 예제 Dockerfile에서 chown 는 빌드 중에 손실됩니다. 왜냐하면 빌드 전에 VOLUME 를 선언했기 때문입니다. 컨테이너를 실행할 때 dockerd는 VOLUME 선언 이전에 /vol 의 내용을 명명된 볼륨 내에서 복사합니다(루트 권한 사용). 따라서 실행중인 프로세스는 권한을 수정하거나 변경할 수 없으므로 blabla.sh 스크립트에서 chown을 강제 실행해도 작동하지 않습니다.

파일을 다음과 같이 변경합니다.

FROM blabla
RUN do stuff
RUN useradd foo && chown -R foo /vol
USER foo
VOLUME /vol
CMD ["blabla.sh"]

문제가 해결되었습니다.

@jcberthon docker-compose.yml의 호스트 시스템과 볼륨 /vol을 어떻게 바인딩하는지 공유해 주시겠습니까?

저는 Fedora에서 Docker로 작업 중이며(SELinux 활성화됨) 위에서 언급한 방법 중 어느 것도 저에게 효과가 없었습니다. 이상적으로는 사용자(루트 없음) 컨텍스트에서 내 컨테이너에서 응용 프로그램을 실행하고 싶지만 이 볼륨 문제는 이를 차단합니다.

나를 위해 작동하는 유일한 해결 방법은 내 응용 프로그램 사용자를 제거하고 모든 것을 루트 사용자로 실행/소유하는 것입니다.

안녕하세요 @renanwilliam 및 @egee-irl

나는 여러 OS에서 위에서 언급한 솔루션을 사용하고 있습니다. SELinux가 적용된 Fedora 26 및 CentOS 7, AppArmor가 활성화된 Ubuntu 16.04, 17.10 및 Raspbian 9(amd64 및 armhf 플랫폼 혼합).

그래서 내가 말했듯이, 나는 이제 내 Dockerfile의 끝에서 VOLUME ... 선언을 옮겼지만, 당신은 그것을 모두 제거할 수 있습니다. 그것은 필요하지 않습니다. 내가 일반적으로 하는 일은 Dockerfile에서 사용자를 생성할 때 사용자 ID를 수정하는 것입니다(예: useradd -u 8002 -o foo ). 그런 다음 호스트에서 해당 UID를 재사용하여 폴더에 적절한 권한을 부여할 수 있습니다.

따라서 다음 단계는 호스트에서 /vol 디렉토리의 "펜던트"를 만드는 것입니다. /opt/mycontainer1/vol 라고 가정해 보겠습니다.

$ sudo mkdir -p /opt/mycontainer1/vol
$ sudo chown -R 8002 /opt/mycontainer1/vol
$ sudo chmod 0750 /opt/mycontainer1/vol

그런 다음 사용자 foo로 컨테이너를 실행할 때 /opt/mycontainer1/vol 디렉토리에 쓸 수 있습니다. 다음과 같은 것:

$ sudo -u docker-adm docker run --name mycontainer1 -v /opt/mycontainer1/vol:/vol mycontainer1-img

SELinux 기반 호스트에서 Docker가 폴더에 적절하게 태그를 지정할 수 있도록 볼륨에 :z :Z 옵션을 추가할 수 있습니다. z 와 Z 의 차이점은 소문자 z 가 볼륨에 태그를 지정하여 잠재적으로 이 호스트의 모든 컨테이너가 SELinux에서 해당 디렉토리에 액세스하도록 허용할 수 있다는 것입니다(그러나 분명히 다른 컨테이너에 마운트하는 경우에만) 반면 대문자 Z 는 해당 컨테이너만 디렉터리에 액세스할 수 있도록 태그를 지정합니다. 따라서 SELinux가 있는 Fedora에서 다음을 시도할 수 있습니다.

$ sudo -u docker-adm docker run --name mycontainer1 -v /opt/mycontainer1/vol:/vol:Z mycontainer1-img

업데이트 : https://github.com/jcberthon/unifi-docker에서 내 저장소를 확인할 수 있습니다. 저는 이 방법을 사용하고 있으며 호스트를 구성하고 컨테이너를 실행하는 방법을 설명하고 있습니다. 이것이 귀하의 문제를 해결하는 데 도움이 되기를 바랍니다.

Btw, 답변이 오래 지연된 @renanwilliam 에 대해 사과드립니다. 이번 연말은 시간이 별로 없어서...

그래서, 참을성이 없는 사람을 위한 짧은 이야기:

RUN mkdir /volume_data
RUN chown postgres:postgres /volume_data

볼륨 디렉토리를 미리 생성하고 chown 해결하면 볼륨이 기존 디렉토리의 권한을 보존하기 때문입니다.

이것은 명확하지 않기 때문에 좋지 않은 해결 방법입니다(Dockerfile에서 chown을 수행한 다음 마운트 중에 해당 소유권을 상속함). docker-compose 및 docker CLI에서 소유자 및 그룹 제어를 노출하는 것은 유닉스 스타일 명령에 대한 최소한의 놀라움이 될 것입니다.

@villasv

작은 팁: 2개의 RUN ... 를 하나로 병합합니다. 이렇게 하면 추가 레이어 생성을 방지할 수 있으며 모범 사례입니다. 따라서 2줄은 다음과 같아야 합니다.

RUN mkdir /volume_data && chown postgres:postgres /volume_data

그러나 (위의 주석에서 언급했듯이) VOLUME ... 사용하여 볼륨을 선언하기 전에(또는 실제로 볼륨을 선언하지 않고) 위의 RUN ... 명령을 수행해야 한다는 점에 주의하십시오. 볼륨을 선언한 후 소유권 변경을 (내가 한 것처럼) 수행하면 해당 변경 사항이 기록되지 않고 손실됩니다.

@colbygk 정말 편리하겠지만 Linux는 그렇지 않습니다. Docker는 Linux 마운트 네임스페이스를 사용하여 다른 단일 디렉토리 계층 구조( / 및 하위 폴더)를 생성하지만 AFAIK에는 현재 Linux 마운트 네임스페이스에서 재정의하는 사용자/그룹 매핑 또는 권한이 없습니다. 컨테이너 내부의 "마운트"(바인드 마운트 볼륨 포함)는 호스트의 파일 시스템에 있으며(물론 다른 Docker 볼륨 플러그인을 사용하지 않는 한) 이 파일 시스템은 모든 작업을 수행하는 Linux VFS 계층을 존중합니다. 파일 권한 확인. 컨테이너가 컨테이너 내에서 파일에 액세스하는 것을 방해할 수 있는 일부 MAC(예: SELinux, AppArmor 등)이 호스트에 있을 수도 있습니다. 실제로 chroot 하면 chroot 내에서 마운트 폴더를 바인딩할 수 있으므로 유사한 문제가 발생할 수 있으며 chroot 환경 내에서 실행 중인 프로세스가 파일에 액세스하는 데 잘못된 유효 UID/GID를 가질 수 있다는 문제도 있습니다. 바인드 마운트.

컨테이너에는 간단한 Linux(실제로는 Unix도 포함) 규칙이 적용됩니다. 비결은 오늘날 Linux 네임스페이스의 가능성과 한계를 보고 이해하는 것이며, 이 문제와 같은 문제를 해결하는 방법이 점점 더 명확해지고 있습니다. 나는 고전적인 Unix 명령을 사용하여 완전히 해결했습니다.

@jcberthon 사려 깊은 답변에 감사드립니다:

나는 이것이 당신이 제안한 대로 플러그인 계층으로 푸시되어야 하는 문제여야 하며 따라서 Docker와 함께 제공되는 일반 볼륨 핸들러 플러그인의 일부가 될 수 있다고 주장합니다. 컨테이너가 파생된 이미지에 정의된 본질적으로 정적 관계를 준수하도록 외부 리소스(특정 컨테이너 외부)를 강제로 적용하는 것은 저와 같은 클라우드/컨테이너를 매우 해제하는 것 같습니다.

"유닉스"의 다른 유사한 영역에서 발생하는 이 정확한 종류의 uid/gid 매핑의 다른 예가 있습니다.

• http://man7.org/linux/man-pages/man5/nfsidmap.5.html
• http://wiki.lustre.org/UID/GID_Mapping
• https://docs.oracle.com/cd/E19120-01/open.solaris/820-2429/mapusergroupidentities/index.html
• https://github.com/zfsonlinux/zfs/issues/4177

내가 틀렸다면 저를 수정하십시오. https://github.com/zfsonlinux/zfs/issues/4177 은 Linux의 ZFS와 관련된 문제로 "LXC/LXD의 리더"가 UID/GID 정보를 올바로 제공하지 않아 UID/GID 정보를 우리가 여기서 논의하고 있는 거의 _정확한_ 방식으로 컨테이너. https://github.com/zfsonlinux/zfs/issues/4177을 자세히 살펴보면 zfs 볼륨 유형이 실제로 이미 네임스페이스 간의 이 uid/gid 매핑을 지원할 수 있지만 이를 위한 컨트롤을 노출하지 않는 것으로 보입니다.

Docker를 사용하는 대부분의 사람들은 dev/CI용이므로 php/nginx(runner) 또는 gradle/python(builder)과 같은 "일반" 이미지를 사용하므로 좋은 솔루션은 다음과 같습니다.

1. 이미지를 재정의하기 위해 Dockerfile을 생성/편집할 필요가 없습니다.
2. docker-compose yml 파일에서 간단한 구문 사용

볼륨(X:X:OPTION_READ_WRITE)의 쓰기 권한은 쉽게 결정할 수 있으니 마찬가지로 소유자를 추가하면 어떨까요?

SOURCE:TARGET:RW:OWNER

같은 문제가 있습니다. 아마도 가장 좋은 방법이 있을 것입니다. 제 방법은 _not_입니다.

version: '3.5'
services:
    something:
        image: someimage
        user: '1000'
        expose:
            - 8080
        volumes:
            - dev:/app

volumes:
    dev:

이로 인해 EACCES: permission denied, access '/app' 합니다.

어떻게 해야 할까요? 즉, 새 볼륨을 정의하고 루트가 아닌 사용자로 액세스할 수 있습니까?

안녕하세요 @Redsandro

someimage Docker 이미지에서 /app 대한 UID를 1000으로 설정하는 것이 좋습니다. 또는 이를 제어할 수 없는 경우 이미지 작성자가 의도한 UID 또는 GID를 작성 파일에서 user: ... 에 사용해야 합니다.

물론 이미지 작성자가 UID 0을 사용하고 서비스를 루트로 실행하고 싶지 않다면(그리고 권한이 없는 사용자로 실행할 수 있음) Docker 이미지 작성자에게 문제를 제기하십시오.

@Redsandro Docker 및 --userns-remap 에서 해결 방법을 확인하십시오.

이것은 docker가 관리할 수 있는 것이 아니므로 https://hub.docker.com/r/hasnat/volumes-provisioner를 사용하여 관련 컨테이너가 시작되기 직전에 볼륨을 프로비저닝하기 위해 다른 컨테이너를 생성할 수 있습니다.

version: '2'
services:
  volumes-provisioner:
    image: hasnat/volumes-provisioner
    environment:
      PROVISION_DIRECTORIES: "65534:65534:0755:/var/data/prometheus/data"
    volumes:
      - "/var/data:/var/data"

  prometheus:
    image: prom/prometheus:v2.3.2
    ports:
      - "9090:9090"
    depends_on:
      - volumes-provisioner
    volumes:
      - "/var/data/prometheus/data:/prometheus/data"

Docker가 이것을 수정하지 않는 이유를 이해하지 못합니다. 개발 목적으로 해킹할 수 있다는 데 동의하지만 프로덕션에서는 절대 안됩니다!

IMHO podman은 (권한이 없는) 사용자로 실행할 수 있으며( 여기 참조) 아마도 이 문제를 해결할 것입니다. 누군가는 또한 compose 솔루션 에

[podman]은 많은 부분에서 Docker와 호환되기 때문에 일부 사람들에게 도움이 될 수 있습니다.

전적으로 동의합니다. 불행히도 podman은 Mac에서 작동하지 않습니다.

전적으로 동의합니다. 불행히도 podman은 Mac에서 작동하지 않습니다.

저는 더 이상 OS/X 사용자가 아니지만 _experimental_ podman dmg가 있다는 것을 방금 보았습니다.

이미 podman programmatic 또는 podman-compose 에 액세스할 수 있기 때문에 가까운 미래에 유사한 생태계가 개발될 수 있다고 생각합니다.

공유 클러스터에 대한 sudo 권한이 없는 사용자가 실수로 docker-compose를 통해 루트가 소유한 일부 폴더를 만든 다음 해당 폴더 자체를 삭제할 수 없는 경우 특히 문제가 됩니다.

나는 또한이 문제에 부딪쳤다. jpetazzo의 게시물에 안내된 대로 docker에서 docker를 사용하려고 합니다.

docker-compose 파일에서 이 컨테이너를 시작하고 호스트 시스템의 도커 소켓을 도커 그룹 아래의 컨테이너 시스템에 탑재할 수 있기를 원합니다. 이는 루트가 아닌 다른 사용자를 사용하여 컨테이너 내부에서 도커를 실행할 수 있도록 하기 위한 것입니다.

현재 바인드 마운트 파일의 소유권 및 권한을 지정할 수 없기 때문에 이것은 달성할 수 없습니다.

여기에 내 두 센트를 넣으십시오.

docker-compose "네이티브" 솔루션의 경우 대부분의 사람들이 이미 이미지 라이브러리에 알파인을 가지고 있기 때문에 이렇게 했습니다.

volumes:
  media:
services:
  mediainit:
    image: alpine
    entrypoint: /bin/sh -c "chown -v nobody:nogroup /mnt/media && chmod -v 777 /mnt/media"
    container_name: mediainit
    restart: "no"
    volumes: 
      - "media:/mnt/media"

물론 가장 안전한 방법은 아니지만 컨테이너에 대한 권한이 부여된 컨테이너만 이를 볼 수 있으므로 큰 문제는 아니지만 커널이 지원하는 경우 쉽게 user:user를 chown하거나 setacl 공상을 수행할 수 있습니다

편집: 적어도 내 테스트에서 chmod 전에 폴더를 먼저 chown해야 하는 것 같습니다

볼륨 소유권은 docker-compose가 제어하지 않으므로 이 논의는 moby 프로젝트 repo에서 이루어져야 합니다.

해결 방법을 찾는 사람들을 위한 몇 가지 참고 사항:
Docker 볼륨은 컨테이너에서 처음 사용할 때 컨테이너에서 상속된 초기 콘텐츠와 권한을 얻습니다. 즉, 다음과 같이 이미지를 구성할 수 있습니다.

#Dockerfile
FROM alpine
RUN addgroup -S nicolas && adduser -S nicolas -G nicolas
RUN mkdir /foo && chown nicolas:nicolas /foo  
# empty, but owned by `nicolas`. Could also have some initial content
VOLUME /foo  
USER nicolas

이러한 이미지는 명시적 볼륨(임의의 ID로 의도적으로 생성됨) 없이 실행되거나 아직 존재하지 않는 명명된 볼륨과 함께 실행될 때 볼륨에 권한을 "전파"합니다.

➜  docker run --rm -it -v some_new_volume:/foo myimage
/ $ ls -al /foo
total 8
drwxr-xr-x    2 nicolas  nicolas       4096 Oct 18 08:30 .
drwxr-xr-x    1 root     root          4096 Oct 18 08:30 ..

작성 파일에 선언된 볼륨을 사용할 때도 동일하게 적용됩니다.

#docker-compose.yml
version: "3"
services:
  web:
    image: myimage
    command: ls -al /foo
    volumes:
      - db-data:/foo
volumes:
    db-data:

➜  docker-compose up
Creating volume "toto_db-data" with default driver
Creating toto_web_1 ... done
Attaching to toto_web_1
web_1  | total 8
web_1  | drwxr-xr-x    2 nicolas  nicolas       4096 Oct 18 08:30 .
web_1  | drwxr-xr-x    1 root     root          4096 Oct 18 08:37 ..
toto_web_1 exited with code 0

다른 컨테이너에서 이미 사용한 볼륨을 다시 연결하면 작동하지 않습니다. 볼륨 소유권을 변경하거나 생성 시 이를 제어하는 ​​것은 엔진이나 특정 옵션이 있는 볼륨 드라이버에 의해 구현되어야 합니다. 그렇지 않으면 제안된 대로 몇 가지 chown 트릭에 의존해야 합니다 ^.

도움이 되었기를 바랍니다.
작성은 볼륨 생성에 대한 제어 권한이 없지만 노출된 엔진 API이므로 이 문제를 닫습니다.