우리가 이것을 위해 간다면, 나는 다음을 갖는 대신에 RUNP 옵션을 선호합니다.
-privileged 모드에서 실행되는 모든 컨테이너.

2013년 9월 18일 수요일 오후 1:07 Benjamin Podszun
알림@github.com작성 :

현재로서는 권한 있는 작업을 외부에서 실행할 방법이 없는 것 같습니다.
도커 실행 - 권한이 있습니다.

즉, Dockerfile에서 동일한 작업을 수행할 수 없습니다. 나의 최근
문제: 컨테이너 내부에서 fuse(encfs용)를 실행하고 싶습니다. 설치 중
퓨즈는 이미 해킹 및 추악한 해결 방법으로 엉망입니다([1] 및 [2] 참조).
권한 있는 빌드 단계 없이는 mknod가 실패/지원되지 않기 때문입니다.

현재 유일한 해결 방법은 다음을 사용하여 수동으로 설치하는 것입니다.
-privileged를 실행하고 새로운 '퓨즈 기본 이미지'를 생성합니다. 그 의미는 내가
공식 기본 이미지에서 마무리까지 전체 컨테이너를 설명할 수 없습니다.
단일 Dockerfile에서.

따라서 다음 중 하나를 추가하는 것이 좋습니다.

• 도커 빌드 - 권한
  이것은 run-privileged와 동일한 작업을 수행해야 합니다. 즉, 모든
  모자 제한

또는

• Dockerfile의 RUNP 명령
  이것은 .. 잘 .. 실행되어야 하지만 _P_rivileges와 함께

소스를 찾아봤는데 가도 소용없고 못찾겠다
불행히도 개념 증명을 첨부하기에 적절한 진입점입니다. :(

1: https://github.com/rogaha/docker-desktop/blob/master/Dockerfile#L40
2: #514(댓글) https://github.com/dotcloud/docker/issues/514#issuecomment -22101217

—
이 이메일에 직접 답장하거나 Gi tHubhttps://github.com/dotcloud/docker/issues/1916에서 확인하세요.
.

빅터 뷰
http://vvieux.com

사실, 우리는 둘 다 해야 할 수도 있습니다. 즉, RUNP +는 "-privileged"를 요구합니다.
깃발.

"-privileged"를 요구하지 않고 RUNP에만 의존한다면,
빌드를 할 때 "이 빌드가 안전한가요?"라는 질문을 해야 합니다.
"-privileged"에만 의존하면 정보를 놓치게 됩니다(
Dockerfile) "이 작업에는 확장된 권한이 필요합니다".

두 가지를 병행하는 것이 가장 안전한 방법이라고 생각합니다.

2013년 9월 18일 수요일 오전 4:07 Benjamin Podszun
알림@github.com작성 :

현재로서는 권한 있는 작업을 외부에서 실행할 방법이 없는 것 같습니다.
도커 실행 - 권한이 있습니다.

즉, Dockerfile에서 동일한 작업을 수행할 수 없습니다. 나의 최근
문제: 컨테이너 내부에서 fuse(encfs용)를 실행하고 싶습니다. 설치 중
퓨즈는 이미 해킹 및 추악한 해결 방법으로 엉망입니다([1] 및 [2] 참조).
권한 있는 빌드 단계 없이는 mknod가 실패/지원되지 않기 때문입니다.

현재 유일한 해결 방법은 다음을 사용하여 수동으로 설치하는 것입니다.
-privileged를 실행하고 새로운 '퓨즈 기본 이미지'를 생성합니다. 그 의미는 내가
공식 기본 이미지에서 마무리까지 전체 컨테이너를 설명할 수 없습니다.
단일 Dockerfile에서.

따라서 다음 중 하나를 추가하는 것이 좋습니다.

• 도커 빌드 - 권한
  이것은 run-privileged와 동일한 작업을 수행해야 합니다. 즉, 모든
  모자 제한

또는

• Dockerfile의 RUNP 명령
  이것은 .. 잘 .. 실행되어야 하지만 _P_rivileges와 함께

소스를 찾아봤는데 가도 소용없고 못찾겠다
불행히도 개념 증명을 첨부하기에 적절한 진입점입니다. :(

1: https://github.com/rogaha/docker-desktop/blob/master/Dockerfile#L40
2: #514(댓글) https://github.com/dotcloud/docker/issues/514#issuecomment -22101217

—
이 이메일에 직접 답장하거나 Gi tHubhttps://github.com/dotcloud/docker/issues/1916에서 확인하세요.
.

@jpetazzo https://twitter.com/jpetazzo
최신 블로그 게시물: http://blog.docker.io/2013/09/docker-joyent-openvpn-bliss/

합리적으로 들리네요. 나에게 이 기능(장치 노드를 생성할 수 있음)은 Docker에서 배포를 생성하는 기능을 만들거나 끊습니다. 내가 도울 수 있다면 (대부분 테스트, 나는 소스를 보려고했지만 지금까지는 실패했습니다. 빌드 파일에서 사용 가능한 명령은 리플렉션을 통해 찾은 것 같습니다. config.privileged를 true로 설정하는 runp 명령을 추가했지만 지금까지는 빌드 및 테스트할 수 없음 -> 멈춤) 기꺼이 시간을 투자하겠습니다.

RUNP + build -privileged 제안합니다.

_@ shykes , @crosbymichael_의 주의를

... 그리고 우리는 그것을 구현할 사람을 찾아야 할 것입니다. 물론 ☺
그것이 당신이 시도하고 싶은 것입니까(물론 핵심 팀의 적절한 지침과 피드백과 함께)?

마지막 부분이 나를 대상으로 한 경우: 물론입니다. 나는 이미 go 코드를 엉망으로 만들고 있습니다.

몇 가지 질문에 대해 핑(ping)할 몇 가지 지침/누군가가 있으면 확실히 시도해 볼 것입니다.

나는 RUNP에 팔리지 않거나 권한이 없습니다.

일반적으로 동일한 입력에 대해 가능한 다른 빌드를 소개하는 것은 좋아하지 않습니다. 이것이 빌드에 인수 또는 환경 변수를 전달할 수 없는 이유입니다.

특히 나는 a) 매우 크고 b) 명확하게 지정되거나 정의되지 않은 기능 집합을 지정하기 때문에 "특권"에 대한 종속성을 모든 곳에서 도입하는 것을 좋아하지 않습니다. 표준 도커 실행 환경이 충분하지 않을 때 시스템 관리자가 전부 아니면 전무(all-or-nothing) 방식으로 보안을 우회하는 거친 메커니즘으로서는 괜찮습니다. bind-mounts 및 사용자 정의 lxc-conf와 같은 방식으로 유사합니다.

—
@solomonstre
@getdocker

2013년 9월 20일 금요일 오후 3:18 Benjamin Podszun
[email protected] 은 다음과 같이 썼습니다.

마지막 부분이 나를 대상으로 한 경우: 물론입니다. 나는 이미 go 코드를 엉망으로 만들고 있습니다.

몇 가지 질문에 대해 핑(ping)할 몇 가지 지침/누군가가 있으면 확실히 시도해 볼 것입니다.

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/dotcloud/docker/issues/1916#issuecomment -24844868

예를 들어 퓨즈를 실행하는 도커 이미지를 구축하는 것이 가능해야 한다는 데 동의하십니까?
이를 위해서는 mknod가 필요합니다.

내가 보기에는 이러한 빌드가 매개변수에 따라 다를 수 있는 방법이 없습니다. 빌드는 작동하거나(현재보다 제한이 적음) 실패합니다(현재 상태). 동일한 빌드 파일의 다른 '버전'에 대한 위험이 거의 또는 전혀 없습니다.

지금이 문제가 발생했습니다. 필요한 이미지를 빌드하려면 Dockerfile을 build 하는 대신 일련의 run -privileged 단계 + commit 단계를 수행해야 합니다. 이상적으로는 Dockerfile에서 이미지 빌드 단계를 표현하는 것이 좋을 것입니다.

mknod 작업과도 관련이 있습니까?
권한 모드가 필요한 작업을 정확히 설명할 수 있다면
귀하의 경우 매우 도움이 될 것입니다!
감사 해요,

안녕하세요 @jpetazzo , 메일링 리스트에서 제가 직면한 문제는 다음과 같습니다. https://groups.google.com/forum/#!topic/docker -user/1pFhqlfbqQI

컨테이너 내부에서 내가 만든( aufs 및 저널링에 대한 문제를 해결하기 위해 생성된) mount a fs를 시도하고 있습니다. 내가 실행하는 특정 명령은 mount -o loop=/dev/loop0 /db/disk-image /home/db2inst1 . 여기서 /db/disk-image 는 dd if=/dev/zero of=disk-image count=409600 되었고 home/db2inst1 는 db2를 시작하려는 곳입니다.

내가 올바르게 이해했다면 설치 과정에서 AUFS가 아닌 디렉토리가 필요하거나 O_DIRECT 를 지원하는 디렉토리가 필요합니다. 이 경우 Docker 0.7은 AUFS 대신 ext4(및 블록 수준 스냅샷)를 사용하므로 문제를 해결해야 합니다.

이것도 +1.

메모리 설정 및 커널 구성 변경이 필요한 패키지(예: Vertica DB, WebSphere MQ) 설치는 권한 모드에서만 수행할 수 있습니다.

"권한 있음"으로 실행/빌드할 때 문제를 분리해 보겠습니다. 빌드 중에만 필요할 수 있습니다. docker run 또는 둘 모두를 통해 실행하는 동안에만 필요할 수 있습니다.

필요한 경우 빌드에서 단계(또는 그 이상)에 대해 더 많은 권한이 필요한 작업을 수행할 수 있어야 합니다. 프로젝트에 이것이 필요했고 Dockerfile의 절반을 빌드를 호출하고 권한 있는 모드에서 계속 빌드하는 셸 스크립트로 변환해야 했으므로 "권한 있는" 빌드가 있으면 유용할 것입니다.

그러나 sysctl을 사용하여 일부 설정을 변경할 수 있도록 기본적으로 권한 모드로 끝까지 내려가서는 안됩니다. 이는 이미지 구성을 통해 또는 docker run 전달할 명령줄 인수를 통해 수행해야 합니다.

오른쪽. @orikremer , Vertica DB와 WebSphere MQ가 변경하려고 했던 매개변수에 대한 세부 정보가 있습니까?

/sys 또는 /proc에 있는 항목인 경우 가장 좋은 솔루션은 권한 있는 모드로 전환하는 대신(변경 사항이 유지되지 않기 때문에) 대신 거기에 일부 모형을 배치하는 것입니다.

장기적으로 모의 파일 시스템은 변경 사항을 캡처하고 Dockerfile 지시문으로 변환하여 런타임에 "이 컨테이너에는 이러한 조정이 필요합니다"라고 지시할 수 있습니다.

@jpetazzo 이미지를 만든 지 며칠이 지났습니다. AFAIR Vertica는 메모리가 충분하지 않고 둘 다 최대 열린 파일을 변경하려고 한다고 불평했습니다.
Dockerfile을 사용하여 이미지를 다시 만들고 다시 보고하겠습니다.

관련된 문제 #2080에 주목하십시오.

@jpetazzo가 -privileged 없이 이미지

• limits.conf의 nice: Vertica는 "dbadmin - nice 0"을 /etc/security/limits.conf에 추가합니다. 권한이 없는 컨테이너에서 실행할 때 해당 사용자로 전환하려고 하면 "세션을 열 수 없습니다" 오류가 발생합니다. 권한 있는 컨테이너에서 사용자 전환은 오류 없이 작동합니다.
• 최대 열린 파일: 컨테이너에 필요한 최대 값이 호스트에 설정된 것보다 높기 때문에 호스트에서 /etc/init/docker.conf를 변경하고 "limit nofile"을 설정한 다음 컨테이너에서 ulimit -n을 설정해야 했습니다. 그것이 올바른 접근 방식입니까?

해당 사용자로 전환하려고 할 때

스위치는 어떻게 발생합니까? -privileged 가 사용자 전환에 어떻게 도움이 되는지 이해가 되지 않습니다. 나는 아마도 여기에 뭔가를 놓치고있을 것입니다 :-)

최대 열린 파일

내가 올바르게 이해한다면 수직 설치 프로그램은 열린 파일의 최대 수를 매우 높은 수로 설정하려고 시도하며 Docker가 -privileged 플래그로 그렇게 높은 수로 시작되거나 _또는_ 작동하는 경우에만 작동합니다. 오른쪽?

사용자 전환 - su dbadmin 는 해당 오류와 함께 실패합니다.
나는 다음과 같이 재현할 수 있었다:

• 새 이미지(centos-6.4-x86_64)를 가져오고 권한이 없는 상태로 실행
• 사용자 추가 테스트 사용자
• /etc/security/limits.conf 편집, "testuser - nice 0" 추가
• su testuser 시도 --> "세션을 열 수 없음"과 함께 실패해야 합니다.
  -권한이 있는 컨테이너에서는 su testuser 가 제대로 작동합니다.

최대 열린 파일 - 맞습니다. 설치 프로그램이 호스트보다 높은 숫자로 설정하려고 합니다. 호스트 설정을 늘리거나 -privileged를 시작해야만 이 작업이 수행됩니다.

방금 다음 Dockerfile로 시도했습니다.

FROM ubuntu
RUN useradd testuser
RUN echo testuser - nice 0 > /etc/security/limits.conf
CMD su testuser

그리고 그것은 잘 작동합니다. 사용중인 이미지의 정확한 이름은 무엇입니까?
( centos-6.4-x86_64 시도했는데 못 뽑는 것 같아요!)

@lukewpatterson 컨테이너 내부에서 루프 파일 시스템이 어떻게 작동하는지 공유할 수 있습니까?

@jpetazzo 이 도커 파일 실행

FROM backjlack/centos-6.4-x86_64
RUN useradd testuser
RUN echo 'testuser - nice 0' >> /etc/security/limits.conf
RUN su testuser
RUN echo 'test' > ~/test.txt

실패:

ori<strong i="10">@ubuntu</strong>:~/su_test$ sudo docker build .
Uploading context 10240 bytes
Step 1 : FROM backjlack/centos-6.4-x86_64
 ---> b1343935b9e5
Step 2 : RUN useradd testuser
 ---> Running in b41d9aa2be1b
 ---> 2ff05b54e806
Step 3 : RUN echo 'testuser - nice 0' >> /etc/security/limits.conf
 ---> Running in e83291fafc66
 ---> 03b85baf140a
Step 4 : RUN su testuser
 ---> Running in c289f6e5f3f4
could not open session
Error build: The command [/bin/sh -c su testuser] returned a non-zero code: 1
The command [/bin/sh -c su testuser] returned a non-zero code: 1
ori<strong i="11">@ubuntu</strong>:~/su_test$

I는 (추가하여 PAM 모듈 디버깅 온 debug 받는 pam_limits.so 라인 /etc/pam.d/system-auth 설치) syslog 하려고 su 다시, /var/log/secure 에서 찾은 내용은 다음과 같습니다.

Oct 7 14:12:23 8be1e7bc5590 su: pam_limits(su:session): '/etc/security/limits.conf'에서 설정 읽기
Oct 7 14:12:23 8be1e7bc5590 su: pam_limits(su:session): process_limit: 처리 중 - 사용자에게 좋은 0
Oct 7 14:12:23 8be1e7bc5590 su: pam_limits(su:session): '/etc/security/limits.d/90-nproc.conf'에서 설정 읽기
Oct 7 14:12:23 8be1e7bc5590 su: pam_limits(su:session): process_limit: DEFAULT에 대한 soft nproc 1024 처리 중
Oct 7 14:12:23 8be1e7bc5590 su: pam_limits(su:session): 'nice'에 대한 제한을 설정할 수 없음: 작업이 허용되지 않음

그런 다음 strace su 프로세스를

setrlimit(RLIMIT_NICE, {rlim_cur=20, rlim_max=20}) = -1 EPERM (Operation not permitted)

이것은 차례로 pam_limits 모듈이 실패를 보고하도록 합니다. 이것은 su 가 계속되는 것을 방지합니다.
흥미롭게도 Ubuntu에서는 기본적으로 su 에 대해 pam_limits 가 활성화되어 있지 않습니다. 활성화하더라도 setrlimit 호출은 실패하지만 su 는 계속되고 어쨌든 작동합니다.
감사 코드와 관련이 있을 수 있습니다. 잘 모르겠습니다.

이제 setrlimit 실패하는 이유는 무엇입니까? 컨테이너에 sys_resource 기능이 없기 때문에 모든 종류의 제한을 높이는 데 필요합니다.

나는 그 limits.conf 지시문을 주석 처리할 것이라고 생각합니다.
(그런데 limits.conf 직접 항목을 추가하는 것은 좋지 않습니다. limits.d 의 별도 파일로 이동해야 합니다.)

참고: Docker의 열린 파일 수 제한을 이미 늘렸으므로 최대 우선 순위 제한도 높일 수 있습니다. 그것도 작동해야합니다!

이게 도움이 되길 바란다.

해당 Dockerfile에는 다음 줄이 있습니다.

RUN su testuser

이것과 함께 갈 명령이 없습니다 (그리고 후속 RUN 명령에 결과 쉘을 적용하지 않음). 따라서 쉘을 열려고 시도하는 데 실제로 실패하고 그렇게하는 것이 의미가있는 대화 형이 아닌 경우 놀라지 않을 것입니다. ( docker build 는 대화식 프로세스가 아니기 때문에). 지금은 확인할 시간이 없지만 su 에 전달되는 실제 명령으로 시도해 볼 가치가 있습니다.

@jpetazzo 자세한 설명 감사합니다. Docker의 최대 우선 순위를 높이고 도움이되는지 확인하겠습니다.

(그런데 limits.conf에 직접 추가하는 것은 좋지 않습니다. limits.d에 있는 별도의 파일로 이동해야 한다고 생각합니다.)

동의합니다. 하지만 이것이 Vertica 설치 프로그램 코드이므로 이를 해결하려고 합니다.

@tianon 대화형 셸(/bin/bash)에서 실행해도 마찬가지입니다.

죄송합니다. 여전히 시도해 볼 가치가 있다고 생각합니다.

Dockerfile에서 그다지 의미가 없는 줄에 대한 요점은 여전히 ​​적용됩니다. 아마도 다음과 같은 것을 더 원했을 것입니다(한계 문제를 파악한 후).

RUN su testuser -c 'echo test > ~/test.txt'

@tianon 네 말이 맞아, 별로 말이 안 돼. 그것은 단지 su 자체가 실패한다는 것을 보여주기 위한 것이었습니다.

원래 논의로 돌아가려면: 보안 관점에서 (그리고 유용합니다!) 빌드 프로세스에서 setfcap 및 mknod 기능을 허용하는 것이 좋습니다(그리고 아마도 다음과 같이 일반 컨테이너 실행에서). 잘). 누구든지 그로 인해 발생할 수있는 문제가 있습니까?

@jpetazzo 정반대! 그것은 내가 겪고 있는 많은 문제를 해결할 것입니다. 실제 기계처럼 작동하거나 보이는 Docker 컨테이너를 실행하려는 사람들에게 이것이 필요하다고 생각합니다.

좋아요! 괜찮으시다면 #2191, "모든 컨테이너에서 mknod 및 setfcap 기능 활성화"를 위해 이 문제를 종료하겠습니다 :-)

우리는 그러한 시나리오에 대해 알고 있습니까?

2013년 10월 13일 일요일 오후 12시 22분에 unclejack [email protected]에 다음과 같이 작성했습니다.

2191 https://github.com/dotcloud/docker/issues/2191 해결되지 않습니다

docker 빌드 권한이 필요한 모든 시나리오에 대한 문제입니다.

—
이 이메일에 직접 답장하거나 Gi tHubhttps://github.com/dotcloud/docker/issues/1916#issuecomment -26224788에서 확인하세요.
.

@jpetazzo https://twitter.com/jpetazzo
최신 블로그 게시물:
http://jpetazzo.github.io/2013/10/06/policy-rc-d-do-not-start-services-automatically/

@jpetazzo Dockerfile을 사용하여 운영 체제 이미지를 빌드하려는 경우에 필요합니다.

수정하다가 실수로 댓글을 지웠습니다.

Dockerfile에서 모든 작업을 수행하지 않고 이것이 어떻게 보이는지 살펴보십시오.

from ubuntu:12.04
run apt-get update
[... a few more run commands]
add build.sh /root/build.sh

빌드.sh

docker build -t mybuild .
docker run -i -t -privileged -cidfile mybuild.cid mybuild /root/build.sh
buildcid=`cat mybuild.cid`
rm mybuild.cid
docker commit $buildcid mybuild-final

이것은 내가 Dockerfile 또는 docker build -privileged 에 runp 가 없는 문제를 해결하도록 강제하므로 Dockerfile을 쓸모없게 만들고 Dockerfile과 유사한 기능을 복제하는 도구를 작성해야 합니다.

분명히 Dockerfile은 runp 또는 docker build -privileged 와 함께 훨씬 더 유용합니다.
실행 예:

from ubuntu:12.04
run apt-get update
[... a few more run commands]
add build.sh /root/build.sh
runp /root/build.sh

docker build -privileged 예:

from ubuntu:12.04
run apt-get update
[... a few more run commands]
add build.sh /root/build.sh
run /root/build.sh

@unclejack : 죄송합니다. 제 질문이 정확하지 않았습니다!
내가 의미한 것은 "정확히 (mknod 및 setfcap 위에) 어떤 권한이 필요합니까?"였습니다.

@jpetazzo 말하기 어렵습니다. 필요한 것이 무엇인지 알아내기 위해 어떻게든 감사해야 할 것입니다. 루프백 마운트 블록 장치 및 기타 몇 가지를 사용하여 파일 시스템 마운트.

이미지 빌드와 관련하여 최소한 세 가지 개별 요구 사항이 있습니다. docker build 동안 필요한 권한, 도커로 컨테이너를 실행할 때 필요한 권한 및 빌드, 실행 또는 둘 다(예: sysctls 및 기타) 동안 프로세스에 대한 런타임 요구 사항 .

docker build -privileged (또는 실제로 필요한 명령에 대해서만 -privileged 모드를 사용하려면 runp )가 유용할 것이라고 생각합니다.

아, 마운트는 확실히 큰 것입니다. 이것은 매우 유효한 사용 사례이며 우리는 _아마도_ 일반적인 경우에 이를 허용하고 싶지 않습니다. 문제를 다시 열겠습니다.

@jpetazzo RE: PAM 모듈(Vertica도 설치 중입니다) lxc.cap.drop에서 sys_resource를 가져온 후 docker를 다시 컴파일하도록 제안하시겠습니까?

이러한 제한 중 일부는 docker.conf 파일을 통해 설정할 수 있습니까?

Docker 자체가 제한된 기능 집합에서 실행될 수 있으므로 Docker가 해당 컨테이너에 위임하는 데 이러한 권한을 사용할 수 없을 수 있다는 점을 고려해야 합니다. 이는 중첩된 Docker 시나리오에서 #2080 토지를 발행해야 하는 경우에 특히 해당됩니다. 이는 권한이 없는 중첩된 Docker를 허용할 수 있습니다.

이것은 'runp' 또는 '-priviledged'와 같은 솔루션이 모든 Docker 환경에서 성공을 보장하지 않을 수 있다는 점을 제외하고는 아무 것도 변경하지 않습니다. 그러한 명령을 추가하고 문서화할 때 이를 고려해야 합니다.

@ramarnat @jpetazzo Vertica 설치 및 좋은 수준 문제에 대한 루프를 닫으려면,
docker.conf에서 멋진 제한을 설정하려고 시도했지만 작동하지 않아 bash 권한을 실행하고 수동으로 설치해야 했습니다.

@orikremer @jpetazzo lxc_template.go에서 sys_resource를 제거하고 docker를 다시 컴파일하여 설치를 실행할 수 있었습니다. 풀 리퀘스트를 공개할 수는 있지만 lxc 설정에서 이를 제거하는 것이 보안에 미치는 영향에 대해 다른 사람들의 의견을 기다립니다.

@ramarnat : 시나리오에 따라 어떤 사람들은 sys_resource를 제거하는 것이 괜찮다고 생각할 것입니다. 다른 사람들에게는 문제가 될 것입니다.

기본 제한을 더 높은 것으로 늘릴 가능성이 있습니다(파일 설명자는 Elastic Search에서도 문제입니다). 이것은 "최소한 Docker 런타임이 1,000,000개의 파일 설명자를 처리할 수 있어야 한다"고 주장하는 것과 같습니다. Docker가 시작될 때 제한을 올릴 수 없는 경우 경고를 발행하고 계속 진행합니다(메모리/스왑 컨트롤러 그룹에 대해 수행하는 것처럼).

이것은 마운트/루프 시나리오를 수정하지 않지만(저는 여전히 이 시나리오에서 잠을 자고 있습니다).

@jpetazzo는 lxc_template.go 의 하드 코딩된 값을 재정의하는 방법을 제공할 수 있습니다. -lxc_conf 명령줄이 있는 시나리오에는 이미 무언가가 있지만 이러한 lxc config 지시자의 .drop 특성에는 작동하지 않습니다. 시도했습니다!

글쎄요, 그것은 가능성이 있지만 다른 컨테이너화 시스템 간에 미래의 호환성을 깨는 좋은 방법이기도 합니다 :-) 더 나은 것을 찾을 수 없는지 살펴보겠습니다.

비특권 모드에서 /dev/loop*를 화이트리스트에 추가할 수 있습니까? 문제는 다른 컨테이너의 루프 마운트 파일 또는 호스트의 파일에 액세스할 수 있다는 것입니다.

@solomonstre
@도커

2013년 10월 17일 목요일 오후 6:09 Jérôme Petazzoni
[email protected] 은 다음과 같이 썼습니다.

글쎄요, 그것은 가능성이 있지만 다른 컨테이너화 시스템 간에 미래의 호환성을 깨는 좋은 방법이기도 합니다 :-) 더 나은 것을 찾을 수 없는지 살펴보겠습니다.

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/dotcloud/docker/issues/1916#issuecomment -26565782

@jpetazzo 그건 사실이지만 허용되는 경우 기본

@solomonstre 요점은 docker build 가 특권 모드에서 빌드되도록 허용하는 방법이 있어야 한다는 것입니다. /dev/loop*에 대한 액세스를 허용해도 내 특정 사용 사례에는 도움이 되지 않습니다.

@solomonstre : /dev/loop을 화이트리스트에 추가하는 것은 IMHO, 큰 문제가 아닙니다. DM 분기를 사용하면 모든 것에 대한 읽기/쓰기 액세스 권한을 부여할 수 있기 때문입니다(DM 분기의 기본 동작은 루프 장치를 사용하여 저장하는 것이기 때문입니다) 수영장).

일부 빌드에는 루프 장치, 마운트 및 기타 사항이 필요하다는 것을 이해합니다. 옵션을 검토해 보겠습니다.

1. docker build -privileged
   편리하지만 "일반 빌드"와 "특권 빌드" 사이의 경계를 그립니다. 권한 있는 빌더가 필요한 매우 유용한 이미지가 있는 경우 공개 빌더에서 빌드하기가 어려울 것입니다. 예를 들어 누군가가 빌드를 자동화하는 서비스를 시작하면 권한 있는 빌드를 제공하지 않을 것입니다(또는 추가 보호 장치를 사용해야 함).
2. 빌더에서 약간의 권한 완화
   이것은 (적어도) cap_sysadmin을 활성화하고(이는 편집증을 약간 떨게 만듭니다), 각 빌더에게 하나 또는 두 개의 루프 장치를 제공할 수 있음을 의미합니다. 이렇게 하면 병렬로 실행되는 빌더의 총 수가 제한됩니다. 그러나 빌드는 빠르고 더 중요하게는 활성 프로세스가 있어야 하기 때문에 큰 문제는 아닙니다. IE에서 병렬로 실행 중인 빌드가 50개 있는 경우, kickass I/O 하위 시스템이 있는 시스템이 없으면 해당 빌드가 많이 진행되지 않습니다.
3. 다른 가상화/격리 계층 내에서 빌드를 래핑합니다.
   Docker 내에서 직접 빌드를 실행하는 대신 QEMU-in -Docker 또는 UML-in-Docker와 같은 것을 실행하십시오. 이것은 추가 작업이 필요하지 않기 때문에 Docker 개발자 관점에서 볼 때 멋진 솔루션입니다. 이것은 또 다른 복잡성 계층을 처리해야 하기 때문에 DOcker 사용자 관점에서 볼 때 좋지 않은 솔루션입니다.

올바른 솔루션이 docker build -privileged`를 허용하는 것과 동시에 옵션 3을 투명하게 구현할 수 있는 후크에 대해 생각하는 것이 맞는지 궁금합니다. 내가 "도커 빌드 공급자"라고 가정해 보겠습니다. 누군가가 권한 있는 빌드를 요청하면 샌드박스 환경 내에서 빌드 프로세스를 실행할 수 있는 무언가를 삽입하기만 하면 됩니다.

여러분은 어떻게 생각하세요?

@backjlack , 일단 구축된 컨테이너를 어떻게 사용하는지 여쭤봐도 될까요? 뭐
정확히 "도커 실행"하면 발생합니다. 응용 프로그램은 무엇입니까? 단지
이에 대한 사용 사례를 이해하려고 합니다.

2013년 10월 18일 금요일 오전 9시 59분, Jérôme Petazzoni
알림@github.com작성 :

@solomonstre https://github.com/solomonstre : /dev/loop을 화이트리스트에 추가하는 것은,
IMHO는 DM 분기를 사용하면 읽기/쓰기가 가능하기 때문에 절대 금물입니다.
모든 것에 대한 액세스(DM 분기의 기본 동작은
풀을 저장하기 위한 루프 장치).

일부 빌드에는 루프 장치, 마운트 및 기타
것들. 옵션을 검토해 보겠습니다.

1. docker build -privileged 편리하지만 다음 사이에 선을 그립니다.
   "일반 빌드" 및 "특권 빌드". 만약 당신이 매우
   권한 있는 빌더가 필요한 유용한 이미지,
   공공 건축업자에 그것을 구축하십시오. 예를 들어 누군가가 자동화 서비스를 시작하는 경우
   빌드, 그들은 아마도 특권 빌드를 제공하지 않을 것입니다 (또는 그들은
   추가 보호 장치를 사용하기 위해).
2. 빌더에서 약간의 권한 완화 이것은 (적어도)
   cap_sysadmin 활성화(이것은 편집증을 약간 떨게 만듭니다), 그리고 아마도
   각 빌더에게 하나 또는 두 개의 루프 장치를 제공합니다. 이것은 총계를 제한할 것입니다
   병렬로 실행되는 빌더의 수 하지만 이후로 큰 문제는 아니다
   빌드는 빠르고 더 중요하게는 활성 프로세스여야 합니다.
   기계가 없는 한 병렬로 실행 중인 빌드가 50개 있는 경우 IE
   kickass I/O 하위 시스템을 사용하면 해당 빌드가 많이 진행되지 않습니다.
3. 다른 가상화/격리 계층 내에서 빌드를 래핑합니다.
   Docker 내에서 직접 빌드를 실행하는 대신 다음과 같이 실행하십시오.
   QEMU-in -Docker 또는 UML-in-Docker. 이것은 Docker의 멋진 솔루션입니다.
   추가 작업이 필요하지 않기 때문에 개발자 관점; 이것은 가난한 사람이다
   DOcker 사용자 관점의 솔루션
   복잡성의 또 다른 계층.

docker build-privileged`를 허용하는 것이 올바른 솔루션인지 궁금합니다.
동시에 투명하게 허용하는 후크에 대해 생각하십시오.
옵션 3의 구현. 내가 "도커 빌드 공급자"라고 가정합니다.
누군가 권한이 있는 빌드를 요청하면 삽입하기만 하면 됩니다.
샌드박스 내에서 빌드 프로세스를 실행할 어딘가
환경(QEMU 및 UML은 명백한 후보이지만 다른 것들은 작동할 수 있습니다.
도; 그것들은 단지 편리한 예일 뿐입니다).

여러분은 어떻게 생각하세요?

—
이 이메일에 직접 답장하거나 Gi tHubhttps://github.com/dotcloud/docker/issues/1916#issuecomment -26612009에서 확인하세요.
.

+1 - 퓨즈를 설치하는 mknode 기능(S3 버킷 탑재용) 또는 Dockerfiles에서 권한 있는 실행을 실행하는 기능을 보고 싶습니다. 최고의 솔루션이 무엇인지 아직 확실하지 않습니다.

+1. 이 문제에 대한 업데이트가 있습니까?

+1
2013년 11월 17일 오후 11시 31분에 "yukw777" [email protected]에서 다음과 같이 썼습니다.

+1. 이 문제에 대한 업데이트가 있습니까?

—
이 이메일에 직접 답장하거나 Gi tHubhttps://github.com/dotcloud/docker/issues/1916#issuecomment -28676216에서 확인하세요.
.

또한 Java를 설치하려고 할 때 퓨즈 문제가 발생했으며 솔루션에 관심이 있습니다. https://gist.github.com/henrik-muehe/6155333에서 제안한 해결 방법을 시도했지만 Raspberry Pi의 도커에서는 작동하지 않습니다.

@jpetazzo : -privileged 플래그를 구현하는 동시에 장기적인 솔루션을 모색하는 전반적인 전략이 마음에 듭니다. 이를 위해 이 기능을 구현하기 위한 풀 리퀘스트를 제출했습니다. 현재로서는 이 스레드의 앞부분에서 설명한 것처럼 "RUNP" 명령을 구현하지 않습니다.

(사람들이 여기에서 해결 방법을 찾을 수 있으므로 "교차 게시"하겠습니다.)

실제로 장치 파일을 사용하지 않는 경우(하지만 fuse 패키지의 경우와 같이 post-inst 스크립트의 일부일 뿐입니다) 다음을 수행할 수 있습니다.

fakeroot apt-get ...

또는:

dpkg-divert --local --rename --add /sbin/mknod && ln -s /bin/true /sbin/mknod`

나는 그것이 좋은 의도라고 확신하지만 첫 번째 의견/내 보고서에는 이미 두 가지 해결 방법이 포함되어 있습니다.
공평하게, 당신은 목록에 새로운 것을 추가했지만 문제는 '퓨즈를 설치할 수 없습니다'가 아니며 첫 번째 게시물을 읽는 것은 무슨 일이 있어도 패키지만 설치해야 하는 사람들에게 도움이 될 것입니다.

진짜 문제는 'mknod를 호출해야 합니다'(또는 더 일반적으로: 지금까지 실패한 권한 있는 작업이 필요함)입니다.

@jpetazzo 이렇게 하면 해결할 수 있죠? https://lwn.net/Articles/564977/ - 그때까지는 장치 액세스를 격리하는 것이 _또 다른 복잡성 계층이고 어딘가에서 관리되어야 하기 때문에 3)을 선택합니다.

루프 마운팅이나 퓨즈가 필수 기능이라는 것도 팔지 않습니다. 사용자 공간에 있는 파일 시스템을 마운트하기 위해 사용 공간에 있는 컨테이너에 루트 권한을 부여하는 것은 미친 짓입니다.

파일 시스템 이미지나 fuse fs를 마운트해야 하는 경우 컨테이너 외부에 마운트하고 볼륨/바인드 마운트로 사용할 수 있습니다. docker 자체에서 원격 파일 시스템을 지원하고 관리하는 것은 좋은 기능일 수 있지만. 아마도 dockerfile MOUNT/마운트 포인트.

@discordianfish 3)은 거의 솔루션이 아닙니다.

#2979가 이 문제에 도움이 될까요?

나도 이것에 대한 해결책을 기다리고 있지만 mknod 때문이 아닙니다. 우리는 /etc/security/limits.d/를 사용하여 사용자에 대한 제한을 설정하는 rpm으로 centos 컨테이너를 실행하고 있으며 현재 다음으로 구성된 sledgehammer 해결 방법을 사용하고 있습니다.

RUN /bin/sed --in-place -e "s/^\s\?session.*pam_limits.so.*/\#\0/g" /etc/pam.d/*

내 Dockerfile의 맨 위에 있습니다. (저희는 프로토타이핑 중이니 걱정하지 마세요 :) )

안녕하세요 @jpetazzo 귀하가 제안한 두 가지 옵션을 모두 시도했습니다. 다음을 사용하여 "oracle_xe" 이미지를 만들려고 합니다.

sudo docker build-privileged -t oracle_xe 내 Dockerfile에서 이 2개의 명령을 실행하고 싶습니다.

RUN 마운트 -o 다시 마운트, 크기=3G /dev/shm
실행 마운트 -a

그러나 그것은 작동하지 않습니다. 사용한 구문이 잘못된지 여부를 모르겠습니다. 내가 얻는 오류는 다음과 같습니다.
플래그가 제공되었지만 정의되지 않음: -privileged

나는 또한 RUNP를 사용하기 위해 두 번째 선택을 시도했지만 작동하지 않았습니다. 이미지를 빌드할 때 해당 단계를 건너뜁니다.

알 수 없는 명령 실행을 건너뜁니다. 제가 빌드하려는 Dockerfile을 보내드릴 수 있습니다. 이 문제를 해결하도록 도와주세요.

감사 해요.

나는 RUNP나 "build --privileged"가 구현되지 않았다고 생각합니다.
가능하면 주저하지 말고 Dockerfile을 공유하십시오. 유용할 수 있으므로
"가장 덜 나쁜" 해결 방법을 제공할 수 있습니다 :-)

2014년 4월 9일 수요일 오전 7시 44분에 Manoj7 [email protected]에서 다음과 같이 썼습니다.

안녕하세요 jpetazzo 귀하가 제안한 두 가지 옵션을 모두 시도했습니다. 구축하려고 합니다
이미지 "oracle_xe"를 사용하여

sudo docker build - 내 Dockerfile에 있는 권한 있는 -t oracle_xe
이 2개의 명령을 실행하고 싶습니다

RUN 마운트 -o 다시 마운트, 크기=3G /dev/shm
실행 마운트 -a

하지만 작동하지 않습니다. 내가 사용한 구문이 다음과 같은지 모르겠습니다.
잘못된. 나는 또한 RUNP를 사용하기 위해 두 번째 선택을 시도했지만 그것도 되지 않았다
작업, 이미지를 만들 때 해당 단계를 건너뜁니다.
알 수 없는 명령 실행을 건너뜁니다. 나는 당신에게 내가 인 Dockerfile을 보낼 수 있습니다
구축하려고 합니다. 이 문제를 해결하도록 도와주세요.

감사 해요.

이 이메일에 직접 답장하거나 Gi tHubhttps://github.com/dotcloud/docker/issues/1916#issuecomment -39972199에서 확인하세요.
.

@jpetazzo https://twitter.com/jpetazzo
최신 블로그 게시물:
http://jpetazzo.github.io/2014/03/23/lxc-attach-nsinit-nsenter-docker-0-9/

안녕하세요 @jpetazzo , 내

@jpetazzo

oracle_xe 이미지를 빌드하는 데 사용한 Dockerfile

* 부터

유지 보수 * * * * * * *

추가 oracle-xe-11.2.0-1.0.x86_64.rpm.zip /appl/oracle/xe/oracle-xe-11.2.0-1.0.x86_64.rpm.zip
RUN 마운트 -o 다시 마운트, 크기=3G /dev/shm
실행 마운트 -a
RUN cd /appl/oracle/xe && oracle-xe-11.2.0-1.0.x86_64.rpm.zip 압축 풀기
실행 cd /appl/oracle/xe/Disk1 && rpm -Uvh oracle-xe-11.2.0-1.0.x86_64.rpm
실행 cd /appl/oracle/xe && rm oracle-xe-11.2.0-1.0.x86_64.rpm.zip
ENV ORACLE_HOME /u01/app/oracle/product/11.2.0/xe
ENV ORACLE_SID XE

내가 시도한 첫 번째 일은

sudo docker build -privileged -t oracle_xe .

이것은 작동하지 않았으며 RunP를 사용하려고했습니다.
실행 마운트 -o 다시 마운트, 크기=3G /dev/shm
실행 마운트 -a
이것도 작동하지 않아 이 두 단계를 건너뛰었습니다.

@gatoravi : 불행히도 /etc/hosts 마운트 해제는 쉽게 작동하지 않습니다. 왜 그렇게 해야 합니까? (매우 타당한 이유가 있을 수 있다는 것을 이해하지만 최선의 해결 방법을 제공하기 위해 그 이유를 듣고 싶습니다...)

@Bhagat7 : 맞아! 질문: 런타임 _및_ 설치 시 더 큰 /dev/shm이 필요합니까, 아니면 런타임에만 필요합니까? 빌드 시간에 있다면 어떤 단계가 실패하고 어떻게 됩니까?

@jpetazzo 내 도구의 빌드 프로세스의 일부로 /etc/hosts에 새 주소와 IP 주소를 추가하고 싶습니다.
echo $IP $HOST >> /etc/hosts.conf와 같은 것.

docker run --privileged 를 사용한 다음 sudo umount \etc\hosts 를 수행하면 이 작업을 잘 수행할 수 있지만 docker commit 를 사용하여 커밋할 수 없는 것 같으므로 umount 를 반복해야 합니다. 컨테이너를 실행할 때마다 수동으로

\etc\hosts 쓰기 가능하게 만들고 영구적으로 만들고 싶습니다. docker commit 또는 Dockerfile을 사용하여 수행할 방법을 찾지 못하는 것 같습니다.

@jpetazzo

나는이 문제가 있었다

bash-4.1#/etc/init.d/oracle-xe 구성
Oracle Application Express [8080]에 사용할 HTTP 포트를 지정합니다.

데이터베이스 리스너 [1521]에 사용할 포트를 지정하십시오: 1521

데이터베이스 계정에 사용할 암호를 지정합니다. 동일하니 참고하세요
암호는 SYS 및 SYSTEM에 사용됩니다. Oracle은 다음을 사용할 것을 권장합니다.
각 데이터베이스 계정에 대해 다른 암호. 이것은 후에 할 수 있습니다
초기 구성:
비밀번호 확인:

부팅 시 Oracle Database 11g Express Edition을 시작하시겠습니까(y/n) [y]:y

Oracle Net Listener 시작 중...완료
데이터베이스 구성 중...완료
Oracle Database 11g Express Edition 인스턴스 시작 중...완료
설치가 성공적으로 완료되었습니다.
bash-4.1#cd /u01/app/oracle/product/11.2.0/xe/bin
base-4.1#sqlplus
사용자 이름 입력: 시스템
비밀번호 입력: * **
하지만 나는이 오류가 발생
ORA-01034: Oracle을 사용할 수 없습니다.
ORA-27101: 공유 메모리 영역이 존재하지 않습니다
Linux-x86_64 오류: 2: 해당 파일 또는 디렉터리가 없습니다.
프로세스 ID: 0
세션 ID: 0 일련 번호: 0
df -h 반환된 컨테이너 내부
사용된 파일 시스템 크기 가용 사용량(%)이 마운트되었습니다.
tmpfs 64M 0 64M 0% /dev/shm

그래서 tmpfs의 크기를 3G로 늘렸을 때 이 오류가 발생하지 않았습니다. 다음과 같이 컨테이너를 실행하여 해결했습니다.
sudo docker run -privileged -i -t oracle_xe /bin/bash. 컨테이너 내부에서 2개의 마운트 명령을 실행했습니다. 하지만 그런 식으로 하고 싶지 않고 대신 Dockerfile에 넣고 빌드하고 싶습니다.

@gatoravi : 알겠습니다. 다음 두 가지 질문이 더 있습니다. 빌드 중에 /etc/hosts에 추가 호스트가 필요합니까, 아니면 실행 중에만 필요합니까? 그리고 왜 필요합니까?

@Bhagat7 : 죄송합니다, 아직 이에 대한 우아한 솔루션이 없습니다 :-(두 개의 Dockerfile이 있는 것이 좋습니다.

• 모든 단계를 수행하는 첫 번째 단계(더 큰 /dev/shm이 필요한 단계 제외), 컨테이너가 권한 모드에서 실행 중인지 확인하는 CMD 정의, 더 큰 /dev/shm 마운트, 특수 실행 명령;
• 추가 단계를 수행하기 위한 두 번째 Dockerfile(런타임에 /dev/shm도 필요하지 않는 한, 지금은 권한 있는 것이 필요함).

@jpetazzo 우리는 사용자에게 편집 가능한 /etc/hosts/가 있는 이미지(/container)를 제공하여 해당 파일을 수정하는 코드를 빌드할 수 있도록 하고 싶습니다. :) 호스트를 추가해야 하는 이유에 관해서는 솔직히 확신할 수 없지만 특정 호스트 이름이 IP 주소를 가리키도록 돕기 위해 설치의 일부로 수행합니다.

@Bhagat7 다음 조합을 사용하여 도커 0.9 컨테이너에서 Oracle XE를 실행할 수 있었습니다.

1. https://github.com/wnameless/docker-oracle-xe-11g
   그리고
2. 호스트에 ...

sysctl -w kernel.msgmni=4096
sysctl -w kernel.msgmax=65536
sysctl -w kernel.msgmnb=65536
sysctl -w fs.file-max=6815744
echo "fs.file-max = 7000000" > /etc/sysctl.d/30-docker.conf
service procps start

@mikewaters 답변 해주셔서 감사합니다. Ubuntu 위에 Oracle XE를 구축했다고 생각합니다. 하지만 Centos에서 빌드하려고 합니다.

@jpetazzo 제안

안녕하세요 여러분,

나는 /dev/shm 에 써야 하는 google-chrome을 사용하고 있습니다. /etc/fstab 특정 구성을 추가하려고 했지만 mout -a 를 실행하여 빌드에 수정 사항을 적용할 수 없습니다. 물론 기본 chmod 또는 chown 시도했지만 빌드에서도 할 수 없습니다.

--privileged 모드로 로그인할 때 내 명령을 사용하면 모든 것이 정상입니다. 그러나 다른 사람들이 설명했듯이 빌드 시 이 작업을 수행해야 합니다.

어떠한 제안?

감사합니다.

@tomav "/dev/shm" 권한 문제는 실제로 #5126이며 #5131에서 수정되었으며 이미 마스터에 병합되었습니다(다음 릴리스에 있을 예정).

@tianon님 감사합니다.

오늘 저는 이런 생각을 했습니다. 저는 데이터 볼륨을 관리하는 컨테이너를 원합니다. 쉽지만 vps에 있기 때문에 해당 볼륨을 암호화하고 싶지만 평소와 같이 다른 컨테이너에 명확하게 제공합니다. 요점은 가상 디스크에 명확한 데이터가 없고 키를 삭제하여 빠르게 파괴할 수 있다는 것입니다.

나는 컨테이너를 넣을 cryptfs를 만드는 방법에 대해 이 기사에서 아름답게 문서화된 몇 가지 단계를 따랐습니다. https://launchbylunch.com/posts/2014/Jan/13/encrypting-docker-on-digitalocean/

참고로 저는 그렇게 하려고 하지 _아니지만 실제로는 cryptfs가 탑재된 컨테이너가 있습니다.
따라서 암호화된 파일 시스템은 도커를 통해 빌드하는 동안 생성, 마운트, 포맷되어야 합니다.

실패:

• 루프 장치를 찾으려고 할 때 :

+ losetup -f
losetup: Could not find any loop device. Maybe this kernel does not know
       about the loop device? (If so, recompile or `modprobe loop'.)

• 이상하게도 똑같은 dockerfile _때때로_ 루프 장치를 찾는 데 성공하면 다음을 수행합니다.

+ losetup -f
+ LOOP_DEVICE=/dev/loop1
+ losetup /dev/loop1 /cryptfs/disk
+ cryptsetup luksFormat --batch-mode --key-file=/etc/cryptfs/random /dev/loop1
setpriority -18 failed: Permission denied
/dev/mapper/control: mknod failed: Operation not permitted
Failure to communicate with kernel device-mapper driver.
Cannot initialize device-mapper. Is dm_mod kernel module loaded?

아직 방법이 없나요? (디스크 마운트/포맷 단계를 run 로 이동하는 것 외에)

+1 "도커의 도커" 환경에 특히 유용합니다.

이에 대해 +1하면 iptables가 권한 없는 모드에서 작동하지 않아 방화벽 규칙을 설정하려는 모든 작업이 실패하게 됩니다.

@PerilousApricot : 그러나 RUN 에 iptables 규칙을 설정할 수 있더라도 이미지는 파일 시스템의 상태만 보유하므로 즉시 손실됩니다. 실행 중인 프로세스, 네트워크 경로, iptables 규칙 등에 대해 알지 못합니다.

컨테이너에는 특정 포트만 있기 때문에 괜찮습니다.
전달됨, 방화벽은 신경쓰지 않고 대부분
설치 프로그램은 전혀 성공할 수 없습니다.

앤드류 멜로

@PerilousApricot 알겠습니다 ! 이 경우 iptables 을 /bin/true 에 심볼릭 링크하는 것은 어떻습니까? 설치 프로그램도 만족해야 합니다. (또는 설치 프로그램을 속이는 유사한 트릭?)

나는 그것을 시도했지만 설치 프로그램은 또한 다음의 출력을 구문 분석해야 합니다.
iptables, 그래서 그렇게 쉽지는 않습니다 :)

알겠습니다. 이것이 해킹이 되고 있다는 것을 알고 있지만 -- 대신 가짜 iptables 를 넣는 것은 어떻습니까? 어떤 더미 출력이 생성됩니까?

나는 그것이 좋지 않다는 것을 완전히 이해합니다. 하지만 진지하게, 그런 종류의 설치 프로그램은 처음부터 고쳐져야 합니다 :)

docker 사용 사례의 docker는 저를 여기로 데려온 것입니다. 글쎄, lxc의 도커, 구체적으로 말하면 우리 개발 환경이 lxc를 사용하고 개발자가 lxc에서 이미지를 빌드할 수 있기를 바랍니다.

docker의 docker에서도 이것을 원합니다. 애플리케이션을 실행하기 전에 가져와야 하는 이미지가 있는데, 이는 다소 큽니다. 자주 가져오거나 커밋할 필요 없이 docker build 일부로 가져와서 캐시하는 것이 좋습니다. 잡아당긴 용기.

이 기능은 필수 IMHO이며 RUNP 와 build-privileged 이 좋습니다.

내가 직면한 실제/프로덕션 시나리오는 중간 컨테이너에서 Puppet 프로비저닝으로 구축된 Docker 이미지입니다. 상승된 기능이 필요한 특정 서비스에서는 ENTRYPOINT 또는 CMD 컨테이너를 -privileged 에서 실행해야 하는 빌드에 실패하여 puppet 스크립트를 다시 적용합니다.

이렇게 하면 컨테이너 내에서 실제 서비스의 시작 시간이 지연됩니다. 적절한 상태를 보장하기 위해 꼭두각시 구성을 빌드한 다음 적용해야 하고(시간이 많이 소요됨) 실행 중인 컨테이너가 실제 -privileged 에서 실행될 필요가 _없습니다.

위의 내용이 의미가 있기를 바랍니다.

@jpetazzo centos6 위에 웹 서버를 구축하려고 합니다. dockerfile을 통해 iptable 규칙을 구성하는 데 문제가 있습니다. @PerilousApricot 의 문제와 유사합니다.

btw: 나는 가짜 iptables와 같은 해킹을 구현하는 것이 아닙니다.

@pmoust : 상승된 권한이 필요한 빌드 작업에 대한 세부 정보가 있습니까? 나는 아마도 이 문제를 피하는 것이 좋습니다. 그리고 이것이 당신에게 만족스럽지 않을 수도 있다는 것을 완전히 알고 있습니다. 그러나 그럼에도 불구하고 어떤 종류의 설치 프로그램/빌더가 이러한 권한을 요구할 수 있는지 이해하게 되어 기쁩니다...

@passion4aix :

@jpetazzo Bitrock 설치 프로그램이 한 예입니다. /tmp를 tmpfs로 마운트해야 합니다. http://answers.bitrock.com/questions/3092/running-installer-inside-docker를 살펴보고 싶을 수도 있습니다.

@jpetazzo 또는 기본적으로 모든

또한 TokuMX는 'transparent_hugepage' 커널 옵션을 비활성화해야 하기 때문에 Docker 컨테이너에서 TokuMX를 실행하려고 할 때 비슷한 문제가 발생했습니다.

이 문제에 진전이 있습니까? 이미 1년이 넘었고 댓글을 보면 대부분의 사람들이 Dockerfile에서 권한 있는 작업을 실행하는 데 사용하고 있습니다.

개인적으로 나는 '--privileged' 솔루션으로 빌드를 선택하지 않을 것입니다. 전체 설치를 권한 있는 상태로 실행하는 대신 일부 작업만 권한 있는 사용자로 실행할 수 있으므로 RUNP 솔루션이 더 좋습니다. 이렇게 하면 최소한 언제 RUNP를 사용할지 생각하고 필요할 때만 사용해야 합니다.

나에게 질문은 더 이상 이 옵션을 추가해야 하는 경우가 아니라 완료될 때만 하는 것 같습니다. 그렇다면 언제 이 기능을 기대할 수 있습니까?

@diversit 그들은 결합되어야 할 것입니다. 따라서 명령줄에서 --privileged 를 사용하면 RUNP 를 사용할 수 있습니다. 그렇지 않으면 DockerHub를 포함하여 신뢰할 수 없는 코드 빌드를 수행하는 사람들에게 보안 악몽이 될 것입니다.

그러나 Dockerfile 구문 외부에서 수동으로 이 작업을 수행할 수도 있습니다. 빌드 프로세스는 Dockerfile을 읽고, 여기에서 컨테이너를 만들고, 이미지에 다시 커밋합니다.

@deas : VOLUME /tmp 하면 해결할 수 있을 것 같습니다.

@PerilousApricot : 좀 더 자세히

@diversit : 그 특정한 경우에, 나는 기계의 관리자가 빌드하기 전에 투명한 거대한 페이지를 비활성화해야 한다고 생각합니다. 빌더가 그렇게 하도록 허용되면 전역적으로(맞습니까?) 해당 기능이 필요할 수 있는 다른 컨테이너를 손상시킬 수 있기 때문입니다. 무슨 말인지 알겠어? 컨테이너 X를 빌드하는 것이 컨테이너 Y를 실행하는 것을 중단하면 나쁠 것입니다...

모두: Dockerfile이 작동하지 않을 때 매우 실망스럽고 이 --privileged / RUNP 플래그

@jpetazzo 많은/대부분의

또한 "권한 있는 빌드가 필요한 Dockerfile이 있는 경우 X, Y, Z 기능을 잃게 됩니다"라고 말하는 것이 공정한 트레이드오프라고 생각합니다.

Oracle x는 공유 메모리 공간이 충분하지 않으면 실행되지 않습니다. 모든 계정은 enuf 공간이 있는 remountimg tmpfs가 Oracle x를 기쁘게 시작하고 구성을 완료하도록 합니다. 마운트 크기를 늘려서 극복한다는 소문)

빌드 중
RUN 마운트 해제 tmpfs
실패
umount: /proc/kcore: umount하려면 수퍼유저여야 합니다.

나에게 RUNP를 주거나 죽음을 .... 또는 .... 다르게 할 수 있는 것을 보여주세요 :)

내 예는 유효하지 않습니다. @jpefazzo는 여전히 서 있습니다 :) 내 Oracle 설정이 문제를 일으키고 tmpfs 크기를 조정할 필요가 없는 것 같습니다... 최소한 초기 설치를 위해서는.

CentOS 7.0에서 run --privileged 경우에만 해결되는 iptables 문제가 발생했습니다. https://github.com/docker/docker/issues/3416

권한 있는 건물에 대한 지원이 없으면 문제를 해결하는 다른 방법을 모르겠습니다.

Step 24 : RUN iptables -I INPUT -p tcp --dport 80 -j ACCEPT
 ---> Running in 74ebc19b6935
iptables v1.4.21: can't initialize iptables table `filter': Permission denied (you must be root)
Perhaps iptables or your kernel needs to be upgraded.

@buley #8299에 security-opts 를 추가하면 --privileged 없이도 가능하다고 믿습니다.

@jpetazzo VOLUME /tmp 를 사용하여 Bitrock 설치 프로그램의 문제를 해결하는 방법을 모르겠습니다. 빌드에서는 작동할 수 있지만 /tmp 는 해당 이미지를 기반으로 하는 모든 컨테이너에 대한 AUFS 계층화를 우회하게 됩니다. 결국 AUFS에서 근본 원인을 수정해야 할 것 같습니다.

내 사용 사례는 다음과 같습니다. 도커 컨테이너 내부에 chroot 환경을 구축하고 싶습니다. 문제는 debootstrap 가 chroot에 proc을 마운트할 수 없기 때문에 실행할 수 없다는 것입니다.
W: Failure trying to run: chroot /var/chroot mount -t proc proc /proc
mount: permission denied
컨테이너를 run --privileged 하면 (물론) 작동합니다...
Dockerfile에서 chroot를 부트스트랩 해제하고 싶습니다(훨씬 더 깨끗함). RUNP 또는 빌드 --privileged를 기다리지 않고 작동하게 할 수 있는 방법이 있습니까?

정말 감사합니다!

--privileged 또는 탑재의 경우 +1입니다. glusterfs 구축 자동화의 필요성

이것은 Bitnami Tomcat 설치 프로그램에서 이미지를 빌드하려는 나의 노력에 영향을 미치고 있습니다. 설치 프로세스의 99%는 문제 없이 실행되지만 처음으로 tomcat을 시작하려고 하면 catalina-daemon.out에서 다음 출력과 함께 실패합니다.

set_caps: 기능을 설정하지 못했습니다.
커널이 기능을 지원하는지 확인
사용자 'tomcat'에 대해 set_caps(CAPS)가 실패했습니다.
반환 값이 4인 서비스 종료

"--cap-add ALL"로 생성한 컨테이너에서 Tomcat 설치 프로그램을 수동으로 성공적으로 실행할 수 있습니다. 'docker run' 다음 'docker commit'을 사용하여 수동으로 생성할 수 있는 이미지를 생성하기 위해 'docker build'를 사용할 수 없다는 것이 이상하게 보입니다. 빌드 과정에서 사용되는 컨테이너는 '도커 실행'을 사용하여 생성할 수 있는 컨테이너와 같은 모든 기능을 가지고 있어야 합니다.

@gilbertpilz 그들은 빌드 이식성과 보안을 보장하기 위해 매우 명시적으로 그렇게 할 수 없습니다.

@cpuguy83 - 말이 안 됩니다. 다음과 같이 하면 손으로 원하는 이미지를 만들 수 있습니다.

도커 실행 --cap-add ALL .... /bin/bash
bitnami-tomcatstack-7.0.56-0-linux-x64-installer.run ...
출구
도커 커밋 ....

내가 여기서 수동으로 하고 있는 것과 동일한 작업을 수행하기 위해 "도커 빌드"를 사용하는 기능만 요구하고 있습니다. 이미지를 한 가지 방법으로 만들 수 있지만 다른 방법으로는 만들 수 없는 경우 "이동성 및 보안"이 어떻게 "보장되는지"를 알 수 없습니다.

좋아, 호스트의 /etc/passwd를 빌더에 마운트하고 우연히 그것을 나에게 보내는 Dockerfile을 제공하겠습니다.

이 물건은 위험할 수 있습니다.
또한 --privileged(및 --cap-add ALL)는 컨테이너의 사용자에게 호스트의 모든 권한을 부여합니다.

이러한 것들을 허용하면 DockerHub 전체가 손상될 수 있습니다.

@cpuguy83 -

그러나 당신은 왕국의 열쇠를 흉내내지 않고 신뢰하지 않는 누군가에게 sudo를 주지 않을 것입니다.
빌드는 가능한 한 안전하게 신뢰할 수 없는 코드를 실행할 수 있어야 합니다.

빌드에서 추가 기능을 활성화하기 위해 CLI 플래그를 도입하면 빌드의 이식성이 깨져 아직 추가되지 않았습니다.

즉, 설치 프로그램 자체가 액세스할 수 없어야 하는 항목을 요청하는 오류가 거의 확실합니다.

정확히. 권한이 필요한 도커 빌드를 실행할 수 있는 능력을 신뢰하지 않는 사람들에게 주어서는 안 되지만, 도커는 당신이 _do_ 신뢰하는 사람들이 그렇게 하는 것을 막지 않아야 합니다. 이것은 정책 결정이며 도구가 나를 위해 정책 결정을 내리는 것을 정말 싫어합니다. 좋은 도구를 사용하면 내가 내린 정책 결정을 명확하고 놀라운 방식으로 실행할 수 있습니다.

당신은 더 큰 그림을 보고 있지 않습니다.

이 생태계에는 당신의 서버와 내 서버보다 더 많은 것이 있습니다. 예를 들어 DockerHub는 항상 신뢰할 수 없는 코드를 빌드하고 있습니다.

그런 다음 DockerHub는 빌드에 대한 기능을 추가할 수 있도록 _안_해서는 안 됩니다. 내 도커 빌드를 DockerHub로 푸시할 수 없다는 의미라면 괜찮습니다.

@cpuguy83 @tianon @jpetazzo -- FUD가 시작될 때, 나는 말할 수밖에 없습니다:

이러한 것들을 허용하면 DockerHub 전체가 손상될 수 있습니다.

헐?
이 기능 구현 == TEOTWAWKI ?

물론 DockerHub는 요청된 --privileged 플래그와 함께 docker build 를 실행하지 않습니다.
너무 많이 생각하지 않아도 구현하는 두 가지 분명한 방법이 있습니다.

• 당신은 또한 시작하면 플래그는 작동 docker -d 과 같은 몇 가지 새로운 플래그 : --i-want-a-broken-security-model
• 코드 경로를 활성화하는 컴파일 타임 플래그를 생성합니다.

전반적으로 구현에 대한 엔지니어링 기반 이유에 대한 이를 갈기의 비율이 여기에서 정말 높은 것 같습니다.

@tamsky 그리고 빌드가 한 곳에서는 작동하지만 다른 곳에서는 작동하지 않는 상황이 있습니다.
나는 어떤 경우를 논하는 것이 아니라 있는 그대로의 이유를 설명하고 있습니다.

그러나 또한... 대부분의 것들은 어떤 종류의 특권 액세스도 필요하지 않으며 특권 액세스가 필요한 것들은 일반적으로 설치가 작동하는 데 _실제로_ 필요하지 않습니다. 이로 인해 설치에 실패하면 해당 설치 프로그램이 손상됩니다(예: 인용된 tomcat 문제의 경우).
이러한 기능을 활성화하면 사람들이 당면한 실제 문제를 실제로 해결하는 대신 특권 모드로 실행하도록 권장합니다.

@cpuguy83

그리고 빌드가 한 곳에서는 작동하지만 다른 곳에서는 작동하지 않는 상황이 있습니다.

잠시 동안 우리가 _policy_가 다르고 일부 빌드는 한 곳에서 작동하지만 다른 곳에서는 작동하지 않는 세계로 마법처럼 이동했다고 상상해 보세요...

이게 왜 큰일이야?
정확히 누가 신경쓰나요?

Docker Inc는 "모든 빌드는 모든 곳에서 작동해야 함"이라는 가장 낮은 공통 분모의 진언/요구 사항이 실제로 실제 고객의 요구를 무시할 수 있다고 생각했습니까?

현재 정책은 고객이 "도커에서 X를 빌드"하기 위한 엔지니어링 비용을 외부화하는 것입니다.

docker에서 이 기능을 제공하는 대신 "어떤 종류의 권한 액세스가 필요하지 않은"(그러나 실제로는) 전 세계의 모든 타사 프로젝트를 먼저 업데이트하거나 도커 빌드 사례를 처리하기 위해 원숭이 패치를 적용해야 합니다.

결국 Docker가 여러 플랫폼에서 실행될 경우 'docker 빌드'는 모든 시스템에서 동일하게 작동하지 않습니다. 즉, Windows 컨테이너, Solaris 컨테이너 또는 ARM Linux 컨테이너의 빌드는 x86-64 Linux에서와 동일하지 않습니다. 이들에 대한 보안 컨텍스트도 플랫폼에 따라 다를 것입니다.

즉, @cpuguy83 , Dockerfile이 보편적으로 유지될 것이라고 항상 가정할 수는 없습니다. 그러나 나는 우리가 그들 사이에 얼마나 많은 차이가 있는지 최소화해야 한다는 데 동의합니다. 이 기능을 원하는 사용자를 위한 고려 사항은 위험하기는 하지만 궁극적으로 다중 아키텍처/다중 플랫폼 지원과 관련하여 발생해야 하는 대화에 포함할 가치가 있습니다.

예를 들어 로드된 앱 갑옷 프로필 때문에 빌드가 모든 곳에서 작동하지 않습니다.
또한 이미지로 구운 사전 캐시된 도커 컨테이너의 경우 어떻게 하시겠습니까?

2014년 18월 11일 2시 53분에 tamsky [email protected]이 다음과 같이 썼습니다.

@cpuguy83

그리고 빌드가 한 곳에서는 작동하지만 다른 곳에서는 작동하지 않는 상황이 있습니다.

정책이 다르고 일부 빌드는 한 곳에서 작동하지만 다른 곳에서는 작동하지 않는 세계로 마법처럼 이동했다고 잠시 상상해 보세요...

이게 왜 큰일이야?
정확히 누가 신경쓰나요?

Docker Inc는 "모든 빌드는 모든 곳에서 작동해야 함"이라는 가장 낮은 공통 분모의 진언/요구 사항이 실제로 실제 고객의 요구를 무시할 수 있다고 생각했습니까?

현재 정책은 고객이 "도커에서 X를 빌드"하기 위한 엔지니어링 비용을 외부화하는 것입니다.

docker에서 이 기능을 제공하는 대신 "어떤 종류의 권한 액세스가 필요하지 않은"(그러나 실제로는) 전 세계의 모든 타사 프로젝트를 먼저 업데이트하거나 도커 빌드 사례를 처리하기 위해 원숭이 패치를 적용해야 합니다.

—
이 이메일에 직접 회신하거나 GitHub에서 확인하세요.

이 상황에서 "깨진" 것은 "설치 프로그램"이 아니라 Tomcat 7입니다. 저는 Tomcat을 Apache 및 MySQL과 통합하는 Bitnami의 Tomcat 스택을 사용하고 있습니다. Docker는 소스, 구성, 통합, 테스트 및 패키징 서비스의 공급망 끝에 있습니다. Tomcat을 "수정"하도록 요구하면 이 공급망을 이용할 수 없습니다. Tomcat을 "수정"하는 것보다 손으로 원하는 이미지를 빌드하는 것이 훨씬 쉽습니다("--privileged"로 컨테이너 시작, 설치 프로그램 실행, 컨테이너 스냅샷 등).

+1
요리사 역할은 모두 ufw를 사용하여 포트를 여는 것과 관련이 있기 때문에 docker로 포팅할 수 없습니다.
빌드에 --privileged를 추가하면 이 문제가 해결됩니다.

+1. 내 Dockerfiles의 단계로 debootstrap을 가질 수 없습니다.

+1. 내 Dockerfiles의 단계로 debootstrap을 가질 수 없습니다.

Dockerfile/build를 통해 chroot를 빌드하는 것이 자연스러운 것처럼 보였지만 @fbrusch가 언급한 것과 동일한 문제가 발생했습니다.

FROM ubuntu:utopic
ENV HOME /root
RUN sudo apt-get update
RUN sudo apt-get install -y eatmydata
RUN for i in /usr/bin/apt*; do sudo ln -s /usr/bin/eatmydata $(basename $i); done
RUN sudo apt-get install -y debootstrap qemu-user-static binfmt-support
RUN sudo debootstrap --foreign --arch arm64 trusty ubuntu-arm64-chroot
RUN ls ubuntu-arm64-chroot
RUN sudo cp /usr/bin/qemu-aarch64-static ubuntu-arm64-chroot/usr/bin
RUN sudo cp /etc/resolv.conf ubuntu-arm64-chroot/etc
RUN sudo DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true LC_ALL=C LANGUAGE=C LANG=C chroot ubuntu-arm64-chroot /debootstrap/debootstrap --second-stage; sudo cat ubuntu-arm64-chroot/debootstrap/debootstrap.log

실패:

Step 11 : RUN sudo DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true LC_ALL=C LANGUAGE=C LANG=C chroot ubuntu-arm64-chroot /debootstrap/debootstrap --second-stage; sudo cat ubuntu-arm64-chroot/debootstrap/debootstrap.log
 ---> Running in 2654257e860a
I: Keyring file not available at /usr/share/keyrings/ubuntu-archive-keyring.gpg; switching to https mirror https://mirrors.kernel.org/debian
W: Failure trying to run:  mount -t proc proc /proc
W: See //debootstrap/debootstrap.log for details
gpgv: Signature made Thu May  8 14:20:33 2014 UTC using DSA key ID 437D05B5
gpgv: Good signature from "Ubuntu Archive Automatic Signing Key <[email protected]>"
gpgv: Signature made Thu May  8 14:20:33 2014 UTC using RSA key ID C0B21F32
gpgv: Good signature from "Ubuntu Archive Automatic Signing Key (2012) <[email protected]>"
mount: block device proc is write-protected, mounting read-only
mount: cannot mount block device proc read-only
 ---> de534a4e5458
Removing intermediate container 2654257e860a
Successfully built de534a4e5458

RUNP 대신 --insecure 빌드 플래그를 사용하는 것은 어떻습니까?
모든 RUN 명령에 대해 후속 컨테이너는 --add-cap=all 로 실행됩니다. 특권 대신 다른 일도 수행하기 때문에 특권 대신 ...
그러나 실제로 이것은 플래그를 수정하지 않고도 필요할 경우 전체 privileged 설정을 구현하도록 변경할 수 있습니다.

@cpuguy83
RUN 명령에 권한을 부여하거나 RUNP 명령을 활성화하는 도커 빌드에 전달된 플래그를 사용해야 하는 것에 신경 쓰지 않습니다. Dockerfile을 보고 그 안의 명령이나 무엇인가를 통해 권한 있는 액세스가 필요하고 런타임에 10단계로 이동하여 오류가 발생하는 대신 시작할 때 Dockerfile 권한이 필요한 명령이 포함되어 있습니다.

이 스레드로 나를 데려온 사용 사례는 바인드 마운트이며, 컨테이너 내에서 수행할 수 있기를 원합니다. 지금은 권한 모드에서 컨테이너를 실행하는 경우에만 수행할 수 있습니다. 시작할 때 명령을 함께 연결하거나 실행하려는 프로세스 전에 시스템 설정을 완료하기 위해 실행되는 초기화 스크립트를 갖도록 합니다.

Dockerfile에 다음을 포함할 수 있으면 좋을 것입니다.

RUN mount --bind /dir1 /dir2

내 사용 사례에 대해 더 자세히 설명할 것이므로 이는 광범위한 권한 부여 명령 요청이 아닙니다. 저의 특별한 경우는 응용 프로그램 영역의 마운트 디렉토리를 연결된 데이터 볼륨에 바인딩하고 싶습니다.

예

/usr/local/application/data -> /mnt/data 
/mnt/data -> HOST:/var/datasets/dataset1

이것은 응용 프로그램 영역에 직접 볼륨 마운트를 수행하여 해결할 수도 있지만 공통 위치에 제공하고 응용 프로그램 컨테이너가 특정 매핑을 수행하도록 하는 방법을 찾고 있습니다. 이것은 또한 symlinks로 해결할 수 있지만 일부 응용 프로그램은 대상/데이터 폴더로 symlink를 잘 사용하지 않습니다. 그리고 응용 프로그램이 데이터 디렉토리 위치 구성을 지원하는 경우 볼륨 마운트 영역을 가리키도록 수행할 수도 있습니다. 내 사용 사례 응용 프로그램은 데이터 디렉토리 위치 구성을 지원하지 않으며 현실은 데이터와 응용 프로그램 공간을 적절하게 분리하기 위해 일부 바인드 마운트 또는 심볼릭 링크를 수행해야 하는 응용 프로그램이 항상 있다는 것입니다.

A -> B -> C를 수행할 수 있는 이 기능을 통해 데이터 컨테이너를 일반 상태로 유지하고 --volumes-from 를 애플리케이션 및 데이터 컨테이너와 함께 사용할 수 있는 다양한 조합에서 유연성을 제공합니다.

--volumes-from 컨테이너 체인을 사용하여 이를 달성할 수도 있습니다.

GenericDataContainer -> ApplicationDataContainer -> ApplicationContainer

이것이 정답일 수 있지만 애플리케이션 컨테이너가 바인드 마운트를 실행할 수 있다면 애플리케이션 데이터를 위한 또 다른 컨테이너를 만들 필요가 없습니다.

오늘은 컨테이너를 권한 모드로 실행한 다음 마운트 바인드를 실행하여 이를 달성할 수 있지만 아래에서 볼 수 있듯이 해당 마운트 바인드를 지속할 수 있는 방법이 없으며 컨테이너를 시작할 때마다 재설정해야 합니다. . 커밋 시 심볼릭 링크가 유지됩니다.

내 특정 사용 사례에 대한 대답은 3체인 컨테이너 접근 방식 또는 초기화 스크립트를 사용하는 것일 수 있지만 Dockerfile에서 컨테이너 내(또는 기타 권한 있는 명령)를 바인딩할 수 있는 기능이 있으면 좋을 것입니다. 연결 데이터 컨테이너로 해결할 수 없는 호스트 대 컨테이너 매핑을 포함하지 않는 설명할 수 있는 바인드 마운트에 대한 다른 사용 사례가 있을 수 있습니다.

이것이 바인드 마운트 특정 문제와 관련이 있는지 확실하지 않지만 도커 커밋을 수행할 때 권한 있는 명령의 결과가 지속되면 도커 이미지 빌드와 도커 이미지 실행을 분리할 수 있습니다. 도커 빌드를 수행하는 영역을 제어할 수 있으며 최종 사용자는 권한 없는 모드에서 실행할 수 있는 커밋된 컨테이너만 가져옵니다. 이것은 현재 바인드 마운트 및 커밋을 실행할 때 원인이 아닙니다. 이것은 /proc/mounts 작동 방식과 더 관련이 있을 수 있습니다.

다음은 간단한 예입니다.

[root@ip-10-0-3-202 ~]# docker run --privileged -i -t --name test_priv centos:centos6 /bin/bash
[root<strong i="17">@d1d037cb170c</strong> /]# cat /proc/mounts 
rootfs / rootfs rw 0 0
/dev/mapper/docker-202:1-25352538-d1d037cb170c12dab94ebd01c56807210cf2aec50bef52c944f89225c8346827 / ext4 rw,seclabel,relatime,discard,stripe=16,data=ordered 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev tmpfs rw,seclabel,nosuid,mode=755 0 0
shm /dev/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
devpts /dev/pts devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
sysfs /sys sysfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
/dev/xvda1 /etc/resolv.conf xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hostname xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hosts xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
tmpfs /run/secrets tmpfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
devpts /dev/console devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0

바인드 마운트 예제를 만들고 symlink 예제도 만듭니다.

[root<strong i="6">@d1d037cb170c</strong> /]# mkdir /var/data1
[root<strong i="7">@d1d037cb170c</strong> /]# mkdir /var/data2
[root<strong i="8">@d1d037cb170c</strong> /]# mount --bind /var/data1 /var/data2
[root<strong i="9">@d1d037cb170c</strong> /]# ln -s /var/data1 /var/data3

Show 파일은 3개의 디렉토리 모두에서 볼 수 있습니다.

[root<strong i="13">@d1d037cb170c</strong> /]# touch /var/data1/test
[root<strong i="14">@d1d037cb170c</strong> /]# ls /var/data1
test
[root<strong i="15">@d1d037cb170c</strong> /]# ls /var/data2
test
[root<strong i="16">@d1d037cb170c</strong> /]# ls /var/data3
test

/proc/mounts 업데이트됨

[root<strong i="21">@d1d037cb170c</strong> /]# cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/mapper/docker-202:1-25352538-d1d037cb170c12dab94ebd01c56807210cf2aec50bef52c944f89225c8346827 / ext4 rw,seclabel,relatime,discard,stripe=16,data=ordered 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev tmpfs rw,seclabel,nosuid,mode=755 0 0
shm /dev/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
devpts /dev/pts devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
sysfs /sys sysfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
/dev/xvda1 /etc/resolv.conf xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hostname xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hosts xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
tmpfs /run/secrets tmpfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
devpts /dev/console devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
/dev/mapper/docker-202:1-25352538-d1d037cb170c12dab94ebd01c56807210cf2aec50bef52c944f89225c8346827 /var/data2 ext4 rw,seclabel,relatime,discard,stripe=16,data=ordered 0 0

중지하는 컨테이너를 종료한 다음 다시 시작하십시오.

[root<strong i="25">@d1d037cb170c</strong> /]# exit
[root@ip-10-0-3-202 ~]# docker start -a -i test_priv
test_priv

/proc/mounts 에 바인드 마운트가 없습니다.

[root<strong i="7">@d1d037cb170c</strong> /]# cat /proc/mounts 
rootfs / rootfs rw 0 0
/dev/mapper/docker-202:1-25352538-d1d037cb170c12dab94ebd01c56807210cf2aec50bef52c944f89225c8346827 / ext4 rw,seclabel,relatime,discard,stripe=16,data=ordered 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev tmpfs rw,seclabel,nosuid,mode=755 0 0
shm /dev/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
devpts /dev/pts devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
sysfs /sys sysfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
/dev/xvda1 /etc/resolv.conf xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hostname xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hosts xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
tmpfs /run/secrets tmpfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
devpts /dev/console devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0

Symlink는 살아남았지만 바인드 마운트는 아닙니다.

[root<strong i="11">@d1d037cb170c</strong> /]# ls /var/data1
test
[root<strong i="12">@d1d037cb170c</strong> /]# ls /var/data2
[root<strong i="13">@d1d037cb170c</strong> /]# ls /var/data3
test
[root<strong i="14">@d1d037cb170c</strong> /]#

바인드 마운트 재설정

[root<strong i="18">@d1d037cb170c</strong> /]# mount --bind /var/data1 /var/data2

컨테이너를 종료하는 대신 ctrl+p ctrl+q 로 분리한 다음 컨테이너를 커밋합니다.

컨테이너를 새 이미지로 커밋하고 비개인 모드의 이미지에서 새 컨테이너 시작

[root@ip-10-0-3-202 ~]# docker commit test_priv test_priv
74305f12076a8a6a78f492fd5f5110b251a1d361e63dda2b167848f59e3799e2
[root@ip-10-0-3-202 ~]# docker run -i -t --name test_nonpriv test_priv /bin/bash

/proc/mounts
바인드 마운트가 누락되었습니다. 무엇이 추가 /proc/[sys,sysrq-trigger,irq,bus,kcore] 마운트를 트리거했는지 확실하지 않습니다.

[root<strong i="5">@ba1ba4083763</strong> /]# cat /proc/mounts 
rootfs / rootfs rw 0 0
/dev/mapper/docker-202:1-25352538-ba1ba40837632c3900e4986b78d234aefbe678a5ad7e675dbab7d91a9a68469e / ext4 rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",relatime,discard,stripe=16,data=ordered 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev tmpfs rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",nosuid,mode=755 0 0
shm /dev/shm tmpfs rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",nosuid,nodev,noexec,relatime,size=65536k 0 0
devpts /dev/pts devpts rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
sysfs /sys sysfs ro,seclabel,nosuid,nodev,noexec,relatime 0 0
/dev/xvda1 /etc/resolv.conf xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hostname xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hosts xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
tmpfs /run/secrets tmpfs rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",nosuid,nodev,noexec,relatime 0 0
devpts /dev/console devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
proc /proc/sys proc ro,nosuid,nodev,noexec,relatime 0 0
proc /proc/sysrq-trigger proc ro,nosuid,nodev,noexec,relatime 0 0
proc /proc/irq proc ro,nosuid,nodev,noexec,relatime 0 0
proc /proc/bus proc ro,nosuid,nodev,noexec,relatime 0 0
tmpfs /proc/kcore tmpfs rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",nosuid,mode=755 0 0

심볼릭 링크가 살아 남았습니다.

[root<strong i="9">@ba1ba4083763</strong> /]# ls /var/data1
test
[root<strong i="10">@ba1ba4083763</strong> /]# ls /var/data2
[root<strong i="11">@ba1ba4083763</strong> /]# ls /var/data3
test
[root<strong i="12">@ba1ba4083763</strong> /]# exit

내가 현재 사용하고, 내 빌드 단계에서 고정 표시기 이미지를 실행하려고 dind을 . 그렇다면 현재 빌드에서 도커 이미지를 실행할 수 있는 방법이 없습니까?

여러분, 이것을 원한다면 '/usr/bin/unshare -f -m -u -i -n -p -U -r -- /path/to/binary'를 시도하십시오. 이렇게 하면 사용자 네임스페이스가 있는 빌드 내부에 컨테이너가 생성됩니다. 필요에 따라 공유 해제 옵션을 조정할 수 있습니다. 나는 실제로 이것을 사용하여 '/sbin/capsh'를 실행하여 내 프로세스의 기능을 세부적으로 설정합니다.

이것이 권한 있는 빌드에 대한 모든 사용자 사례를 해결할 것이라고 말할 수는 없지만 일부 사용자에게는 도움이 될 것입니다.

나는 이것이 Docker 자체의 일부가 되어야 하고 사용자 네임스페이스의 통합이 진행 중인 것으로 보인다는 데 동의합니다.

@saulshanabrook 정확히가 아니라 빌드에서 도커 이미지를 실행할 수 없습니다. 하루 빨리 이것이 가능하기를 바랍니다. 나는 이것에 대해 약간의 조사를 했고 VFS 저장소를 사용하는 한 빌드 내에서 '도커 풀'을 수행할 수 있다는 것을 발견했습니다. 편리하게는 '도커 저장'도 작동합니다.

도커 이미지를 실행하려는 사람에게는 실제 솔루션이 아니지만 '공유 해제' 및 '캡시'가 작동하므로 권한이 없는 컨테이너에서 컨테이너와 같은 런타임을 수행할 수 있습니다(예: 빌드 중 ). 틀림없이 '도커 실행'을 생략하고 이 단계를 수동으로 수행하고 이미지를 도커에 다시 커밋할 수 있습니다. 오늘은 대부분의 작업을 수행할 수 있습니다. 비록 모든 것을 활로 묶지는 않더라도 말입니다. 물론 결국에는 이러한 기능이 Docker 자체에 들어가야 합니다.

RUNP를 통한 도커 풀의 경우 +1

docker build 권한 있는 실행이 불가능하면 셸 및 docker 커밋을 사용하여 수동으로 빌드를 승격하여 Dockerfile을 무의미하게 만듭니다. 도커 빌드에 권한 있는 플래그를 추가하는 것이 빌드와 권한 있는 빌드 사이에 선을 그을 것이라고 생각하지 않습니다. 그 라인은 플래그가 실행에 추가되었을 때 이미 그려졌고 지원되어야 합니다.

+1 이것은 주어진 시점에서 재현 가능한 도커 컨테이너를 만듭니다(도커 파일만 가지고 다닐 필요가 있음)

+1 이와 같은 문제를 해결하기 위해 내 가능한 기본 역할을 완전히 분해해야 합니다. 도커 채택으로 기존의 많은 가능한 코드를 사용할 수 있기를 정말로 바랐지만 이미 크기에 대한 사용자 지정 역할을 생성했을 뿐만 아니라 이제 이와 같은 문제를 해결해야 합니다.

@lsjommer 어떤 문제를 해결해야 하나요? --privileged는 컨테이너를 실행하는 완전히 안전하지 않은 방법이며 컨테이너의 사용자에게 호스트에 대한 전체 루트 액세스 권한을 부여합니다.

이것을 구현하지 말자는 것이 아니라 우리가 이야기하는 내용에 대해 실제로 알아보도록 합시다.

또한 누군가가 원하는 경우 구현하기가 상대적으로 쉬울 것입니다 ...

@cpuguy83 이것은 모든 라이브러리를 설치하기 위해 도커 컨테이너에 채택하려고 하는 우리의 표준 "베어메탈" 기본 역할이며, 공유 메모리를 처리하지만 컨테이너 빌드에서 귀찮게 할 필요조차 없습니다. 컨테이너 호스트에서만 실행해야 합니까?
http://pastebin.com/P3QQxjNQ

Docker가 리소스 공유를 처리하는 방법을 완전히 이해하지 못한다는 것을 인정합니다.

@ljsommer 따라서 shm을 설정하는 것은 완전히 다른 짐승이며 RUN 명령 간에(또는 실제로 docker run ) 지속되지 않습니다.

@cpuguy83 예, 컨테이너 호스트 자체에 대한 기준선으로 이동할 수 있는 문제라고 생각한 것을 쳤다는 점에서 이것이 대부분 제 잘못이라고 생각합니다.
시간을 내어 답변해 주셔서 감사 드리며 불만을 제기하기 전에 자신을 적절하게 교육하지 못한 것에 대해 사과드립니다.
;)

빌드 프로세스 중 실행/권한에 대한 아이디어가 있습니까?
지정된 IP 주소에 대한 도커 액세스를 제한하기 위해 IP 테이블을 설정하는 것이 좋습니다.

나는 또한 RUNP 및/또는 "docker build --privileged"를 원합니다.

FROM ubuntu:latest
MAINTAINER xyz

RUN apt-get -qq update
RUN apt-get -yq install iptables

RUN iptables -t nat -I OUTPUT -p tcp --dport 443 -j DNAT --to-destination 127.0.0.1:8080 && iptables-save > /etc/iptables.rules

이 Dockerfile은 다음 오류로 인해 작동하지 않지만 "docker run --privileged"로 수행하면 작동합니다...

getsockopt failed strangely: Operation not permitted

@malcm , @ RUNP 같은 것이 있더라도 iptables 규칙이 파일 시스템에 유지되지 않기 때문에 이 시나리오에서는 작동하지 않습니다.

설명하겠습니다: RUN x 하면 Docker는 x 를 실행한 다음 파일 시스템의 스냅샷을 만듭니다. 파일 시스템 외부의 항목(실행 중인 프로세스, 라우팅 테이블, iptables 규칙, sysctl 설정...)은 Docker 이미지에 저장되지 않습니다.

사용자 정의 iptables 규칙을 원하는 경우 한 가지 방법은 다음과 같습니다.

• --name myapp 컨테이너 시작
• docker run --net container:myapp --privileged iptablesimage iptables -t nat ... 와 같이 iptables 규칙을 설정하기 위해 다른 컨테이너, 권한 있는 원샷 시작

말이 돼?

@jpetazzo : 답변 감사합니다. 제 경우에는 아래와 같이 iptables 규칙이 파일 시스템의 데이터로 유지되도록 두 번째 명령을 넣었습니다. 이렇게 하면 --privileged 옵션으로 컨테이너를 시작한 후 iptables 규칙을 로드할 수 있습니다.

RUN do-something-with-iptables && iptables-save > /etc/iptables.rules

RUNP 또는 "build --privileged"가 없으면 다음과 같이 작성해야 합니다.

ADD iptables.rules /etc/

예, 이것으로 충분할 수 있지만 내 저장소의 Dockerfile 옆에 iptables.rules를 추가해야 합니다.

그래서 나는 RUNP를 원한다(또는 부드럽게 갖고 싶다). :)

@jpetazzo @strib
iptables 문제, 마운트 및 기타 권한 있는 작업 외에도 해결해야 할 빌드 시나리오가 하나 있다고 생각합니다.

VM 배포 및 베어메탈 설치를 위한 어플라이언스를 배송합니다. 그러나 테스트를 위해 컨테이너 환경을 사용합니다. 차례로 우리는 이러한 어플라이언스 내부에서 컨테이너를 실행합니다. 따라서 테스트 컨테이너는 docker-in-docker를 기반으로 해야 합니다. 이제 테스트 이미지에 미리 로드해야 하는 서비스 이미지가 있다고 상상해 보십시오(테스트 시간에 서비스 이미지가 레지스트리에서 다운로드되지 않도록). 지금 당장은 d-in-d를 기본으로 사용하는 Dockerfile을 빌드하는 동안 권한 모드에서 d-in-d 컨테이너를 실행할 수 없기 때문에 그렇게 할 수 없습니다. docker daemon will not start, "docker pull " 또는 "도커 로드"가 작동하지 않습니다.

RHEL7 호스트에서 실행할 때 현재 사용자가 루트인 경우 su 가 실패하는 문제가 있었습니다. 이상하게도 현재 사용자가 다른 사용자라면 su 가 제대로 작동했습니다. 그럼에도 불구하고 해결 방법은 실행 명령 플래그 --add-cap=SYS_RESOURCE . 그러나 이 문제로 인해 빌드 단계에서는 이 작업을 수행할 수 없었습니다.

docker run 및 docker commit 하여 Dockerfiles 주위에 +1 스크립팅하는 것은 우스꽝스럽습니다. 이 기능을 포함시키십시오.

이 기능의 필요성에 +1. 컨테이너에 부여할 수 있는 기능을 제한하는 구성 파일에서 전역 "보안 수준"을 구성할 수 있다고 생각합니다. 안전한 기본값(오늘날과 같이)이 있어야 하며 시스템 관리자가 이를 변경할 수 있어 컨테이너가 더 많은 권한으로 실행될 수 있습니다. 이러한 RUNP 명령이 포함된 dockerfiles는 이러한 전역 제한이 있는 시스템에서 "이 Dockerfile에는 다음 기능이 필요합니다.... 빌드하려면"과 같은 메시지와 함께 실행되지 않을 수 있습니다.

나는 이것이 보안과 유용성 사이의 균형을 허용한다고 생각합니다.

내부에 이름이 없는 evli 전용 db로 이미지를 빌드하는 동안에도 이 문제가 발생합니다.
db는 docker에서 허용하지 않는 막대한 양의 메모리를 할당하려고 합니다.

현재 해결 방법은 --privileged 단계 실행 및 별도의 커밋 단계가 있는 2단계 빌드입니다.

다른 방법으로 메모리 할당을 허용하도록 도커를 구성할 수 있습니다. db가 소유하고 있기 때문에 실제로 무엇을 하고 싶은지 알아내기가 조금 어렵습니다.

+1
이 기능을 위해.
역사적 및 사용 사례의 경우 이 속임수를 참조하십시오.
https://github.com/docker/docker/issues/12138#issuecomment -90536998
속임수를 지적해 주셔서 감사합니다 @cpuguy83

나도이 문제가 있습니다. 도커 빌드 중에 cifs 공유에 연결하려는 시도는 특권 플래그가 제공되지 않는 한 허용되지 않습니다.

이제 이것을 구현하는 pull 요청이 있습니다. 거기에서 진행 상황을 확인할 수 있습니다. https://github.com/docker/docker/issues/12261

어떤 것이 특권 모드를 필요로 한다면 그것은 어떤 식으로든 호스트를 수정하고 있을 수 있습니다. 즉, 이러한 수정은 이미지를 사용하려는 다른 호스트에서 실행되어야 하기 때문에 이미지를 이식할 수 없음을 의미합니다.

#13171이 병합되면 자신의 빌더 롤링을 간단하게 만들고 --privileged를 허용하므로 이것을 닫아야 한다고 생각합니다.
내장된 docker build 가 이것을 허용해서는 안 된다고 생각합니다.

그래서 @cpuguy83 , 내가 올바르게 이해한다면 이 문제를 지원하는 방법은 docker build 를 완전히 다시 구현하는 것이지만 추가 매개 변수가 있습니까?

다른 패치가 적용되면 추가 기능을 채우기 위해 내 고유 버전의 docker build (아마도 docker pbuild ?)를 조합해야 합니까?

이 문제에 진전이 있습니까? 위에서 언급한 PR을 확인했는데 모두 실패했습니다.
BUILD --privileged/--granted 옵션을 더 세분화하고 이미지 빌더/소유자에게만 제한된 호스트 리소스의 특정 그룹에 대한 액세스 권한을 부여할 수 있습니까?

Dockerfile에서 RUN docker pull 를 수행할 수 있는 모든 솔루션에 대해 +1입니다.

사용 사례: 이미지 변환 및 문서 작성을 위한 여러 도구가 필요하지만 충돌하는 라이브러리로 인해 이러한 모든 도구를 단일 이미지에 설치할 수 없습니다. 그렇기 때문에 이러한 도구 중 일부를 별도의 이미지로 분리하고 모든 도구를 단일 이미지, 즉 이미지의 이미지로 배포하고 싶습니다. 이것이 내 Dockerfile에서 RUN docker pull 를 수행하려는 이유입니다.

@cpuguy83 이 문제가 만족스럽게 해결된 것 같지 않습니다. 나는 절대적으로, 100% 빌드하는 동안 /proc/sys/kernel/core_pattern 쓰는 것과 같은 지루한 일을 할 수 있어야 합니다.

현재 세계에서는 run 해결 방법을 통해 이 권한 있는 작업을 수행하고 어쨌든 해당 이미지를 허브로 푸시할 수 있습니다. 또한, 내가 _ever_ 생산한 어떤 Dockerfile 도 엄격하게 재현할 수 없습니다. 지속적으로 변경되는 공개 저장소에서 가져오기 때문입니다. 나는 그것을 몰랐다

1. 내 이미지의 공개 소비가 우선 순위였습니다.
2. 그들은 재현 가능해야 할 필요가 있었습니다.

사람들은 빌드에서 privileged 를 얻기 위해 형편없는 해결 방법을 _진행_합니다. 사용자가 있는 곳으로 이동하여 핵심 빌드 도구에서 이를 허용해야 한다고 생각합니다. 필요한 경우 무서운 메시지를 추가하십시오.

cc @thaJeztah , 이 입장에 공감하는 것 같습니다

이 기능을 활성화하기 위해 PR을 만들었지만 거부되었습니다.
어떤 형태로든 건축업자에게 이런 일이 일어나는 것을 보지 못했습니다.

마지막 통화를 한 것 같습니다. 그러면 PR 스레드 자체에서 동요하겠습니다.

이것은 RPM이 --privileged에서 실행하지 않고 실패하는 binmft_misc 등록 시도이므로 CentOS에서 이전 JDK 1.6 패키지를 설치하는 데 필요합니다.

Dockerbuild는 이를 사용하여 컨테이너를 빌드하기 위한 비 상태입니다.

복제하려면

Centos5.11에서
실행 yum 설치 -y jre-1.6.0_29-fcs

선택적 플래그로 빌드의 권한 있는 명령 부분이 있어야 합니다. 우리 응용 프로그램 중 하나를 POC로 도커에 이식하려고 하는데 적용되지 않고 빌드가 실패하는 IPtables 설정이 있기 때문에 구성 요소 중 하나에 대해 실패합니다. 필요한 변경을 수동으로 수행하고 커밋할 수 있지만 docker 빌드의 재미는 무엇입니까? 이는 빌드의 일부일 뿐이며 이미 기본 릴리스의 일부이므로 쉽게 이식할 수 있습니다.

Docker는 권한 있는 옵션이 설정된 중간 컨테이너를 쉽게 실행할 수 있어야 합니다.

@shubhamrajvanshi 우리는 데몬에서 (그리고 클라이언트로) "빌더"를 옮기는 과정에 있습니다. 이것은 빌드 프로세스에 대한 더 많은 사용자 정의를 위한 문을 열어야 합니다(사용자 정의 빌더 구현 가능 포함). "특권이 있는" 빌드를 허용하는 것이 고려될 수 있지만 이는 리팩토링 후에 내릴 수 있는 결정입니다. (https://github.com/docker/docker/blob/master/ROADMAP.md#122-builder 참조)

@shubhamrajvanshi 정당한 이유로 빌드에서 iptables를 변경할 수 없으며 설정이 고정되지 않습니다.

빌드에서 의미가 있는 --privileged로 할 수 있는 일은 거의 없습니다.

@thaJeztah 도움이 될 것
@cpuguy83 이미지에 iptables-persistent 패키지를 사용해도

이렇게 하면 규칙이 디스크에 저장되지만 불행히도 여전히 다시 로드해야 합니다.

_USER POLL_

_이 토론에 변경 사항이 있을 때 알림을 받는 가장 좋은 방법은 오른쪽 상단의 구독 버튼을 클릭하는 것입니다._

아래에 나열된 사람들은 무작위 +1로 귀하의 의미 있는 토론에 감사했습니다.

@karelstriegel

CoreOS의 Docker와 함께 nVidia의 CUDA 드라이버를 사용할 수 있도록 하려면 이것도 정말 원합니다. 그들이 제공하는 설치 프로그램은 커널 소스에 대해 커널 모듈을 빌드한 다음 modprobe를 사용하여 설치합니다. 빌드할 --privileged 옵션 없이 작동하게 하는 방법을 알 수 없습니다.

기본적으로 빌드 시 항상 권한 모드를 지원하지 않는 이유는 무엇입니까?

+1
centos7용 Dockerfile에서 mysql 명령을 사용하고 싶습니다.
물론 entrypoint.sh를 사용할 수도 있지만 빌드와 실행 모두에 -privileged를 사용할 수 있다면 더 유용합니다.

MySQL 명령을 실행하기 위해 --privileged가 필요하지 않습니다.

이 문제는 일어나지 않을 것(또는 일어나야 할 것)이 아닌 것 같으므로 닫아야 합니다.
빌드에서 권한을 허용한다는 것은 빌더가 호스트에서 항목을 변경할 수 있도록 허용하여 이미지가 해당 호스트(또는 유사한 수정이 있는 호스트)에서만 작동하도록 만드는 것을 의미합니다.

빌드에서 권한을 허용한다는 것은 빌더가 호스트에서 항목을 변경할 수 있도록 허용하여 이미지가 해당 호스트(또는 유사한 수정이 있는 호스트)에서만 작동하도록 만드는 것을 의미합니다.

이것은 chroot 사용자 사례에 적용됩니까?

이런 것 없이 dpkg-depcheck -d ./configure 하는 방법을 알아내려고 합니다.

빌드하는 동안(또는 --priviledged 없이 실행) 아래와 같은 오류가 발생합니다. 필요한 권한을 파악하거나 활성화하는 방법을 모르겠습니다.

dpkg-depcheck -d ./configure
strace: test_ptrace_setoptions_followfork: PTRACE_TRACEME doesn't work: Permission denied
strace: test_ptrace_setoptions_followfork: unexpected exit status 1
Running strace failed (command line:
strace -e trace=open,execve -f -q -o /tmp/depchJNii2o ./configure
devel<strong i="8">@98013910108c</strong>:~/src/cairo-1.14.2$ 

약 3년 동안 162개의 댓글이 달렸으니 충분히 관심을 가질만하다고 생각합니다. 인용된 대부분의 경우에 특권 모드가 필요하지 않다는 의견은 사실이며, 제 경우에도 마찬가지입니다. 그러나 로컬, 임시, 탐색 및/또는 편의 빌드에 유용할 수 있는 것을 금지하는 데 사용해서는 안 됩니다. 소들이 조화를 이룰 때까지 경고를 게시하고, 명령줄 경고를 인쇄하고, 사용을 욕하고 비난하지만 사람들에게 유연성을 제공하십시오. 이식성이 항상 모든 사람의 주요 관심사는 아닙니다.

_USER POLL_

_업데이트 알림을 받는 가장 좋은 방법은 이 페이지의 _구독_ 버튼을 사용하는 것입니다._

문제에 대해 "+1" 또는 "나도 있습니다" 댓글을 사용하지 마십시오. 우리는 자동으로
스레드를 짧게 유지하려면 해당 주석을 수집하십시오.

아래 나열된 사람들이 +1 댓글을 남겨 이 문제에 찬성했습니다.

@robeferre

+1

도커 컨테이너 내부에 NFS 볼륨을 마운트해야 하는데, 지금까지는 "--privileged=true" 플래그 없이는 NFS 공유를 생성할 수 없었습니다. 제 생각에 가장 좋은 경우는 권한 있는 명령을 사용하여 이미지를 빌드하는 것입니다. 이것이 어떻게 가능한지?

+1

Step 19 : RUN lxc-create -t ubuntu.sf -n percise -- -r precise -a i386 -b root
 ---> Running in 4c51b7cf0058
lxc_container: lxccontainer.c: create_run_template: 893 error unsharing mounts
lxc_container: lxccontainer.c: create_run_template: 1084 container creation template for percise failed
lxc_container: lxc_create.c: main: 274 Error creating container percise
The command '/bin/sh -c lxc-create -t ubuntu.sf -n percise -- -r precise -a i386 -b root' returned a non-zero code: 1

빌드하는 동안 docker의 gentoo 시스템에 gobject-introspection을 설치하려고 하지만 다음 오류와 함께 실패합니다.

• ISE:_do_ptrace: ptrace(PTRACE_TRACEME, ..., 0x000000000000000, 0x0000000000000000): 작업이 허용되지 않음

컨테이너에 수동으로 설치하려고 해도 동일한 결과가 나오지만 권한 모드(docker run --privileged)로 시작된 컨테이너에서 시도하면 잘 작동합니다.

glibc를 설치하려고 할 때도 같은 문제가 발생합니다.

따라서 빌드 중에 권한 있는 명령을 실행하는 방법도 필요합니다.

도커 버전 1.10.1을 사용 중이고 glibc 문제가 1.9에서 나타나지 않습니다.

버전 1.10에서는 네트워킹을 사용할 수 없기 때문에 32비트 컨테이너를 빌드할 수 없습니다.
--privileged 또는 --security-opt seccomp:unconfined for BUILD -는 정말 필요합니다.
또는 Dockerfile의 해당 지시문

나에게서 큰 +1

빌드하는 동안 '마운트' 명령을 사용할 수 없다는 것이 저에게는 진짜 문제입니다.
빌드하는 동안 호스트 디렉토리를 컨테이너에 마운트할 수 없다는 한계를 극복하려고 했으므로 호스트에 NFS 서버를 설정하고 NFS 공유 마운트를 시도했지만 비특권 모드 때문에 불가능하다는 것을 알아냈습니다.

내 사용 사례에서는 빌드 컨텍스트에 복사하지 않고 이미지에 몇 가지 항목을 설치하고 설치하기 전에 추가해야 합니다.

선택의 여지가 없는 것처럼 느껴집니다.

thaJeztah는 3월 10일에 이 문제를 언급했습니다.
1.10.2로 업그레이드한 후 LTTng 동작의 회귀 #20818 종료됨

아니오, 닫히지 않았습니다. 우리는 1.11.0-0~wily를 사용하고 있으며 32비트 컨테이너에서는 1.10.0 이후로 새 작업이 작동하지 않지만 1.9.x는 잘 작동했습니다.
-privileged만 컨테이너를 시작하는 데 도움이 될 수 있습니다. 그러나 우리는 새로운 것을 만들 수 없습니다

나는 사람들이 이 스레드에서만 2.5년 동안 구걸했고 사람들이 이 기능을 구현하기 위해 PR을 제출했음을 감안할 때 많은 사람들이 분명히 필요로 하는 것이 구현되지 않았다는 사실에 놀랐습니다.

@ctindel 에 동의 rkt로 마이그레이션하는 이유 중 하나입니다.

@ctindel 우리가 구현하거나 지원할 준비가 되지 않은 것입니다. 구현 자체는 다소 간단합니다(심지어 논의할 수 있도록 직접 구현했습니다). 그건 문제가 아닙니다.

--privileged 는 탱크이며 빌드 시 허용하는 것은 위험하며 이미지 이식성에 큰 영향을 미칩니다.

브라이언,

해결 방법이 있다면 저에게도 공유해 주십시오. 나는 것
에 감사하다.

감사 해요
슈밤 라즈반시
669-300-8346

2016년 5월 2일 월요일 오후 2시 30분에 Brian Goff [email protected] 은 다음과 같이 썼습니다.

@ctindel https://github.com/ctindel 아직 준비가 안 된 부분입니다.
구현하거나 지원합니다. 구현 자체는 다소 간단합니다(나는 심지어
우리가 논의할 수 있도록 직접 구현했습니다), 그것은 문제가 아닙니다.

--privileged는 탱크이며 빌드 시 이를 허용하는 것은 위험합니다.
이미지 이식성에 큰 영향을 미칩니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/docker/docker/issues/1916#issuecomment -216369957

휴대성에 미치는 영향을 이해하지 못합니다. 빌드 시 권한 있는 작업이 이식성에 어떤 영향을 줍니까? 제 말은, 권한이 있든 없든 다양한 방법으로 휴대용이 아닌 이미지를 만드는 것이 어렵지는 않지만 권한이 있는 작업으로 빌드된 이미지가 반드시 이식이 불가능한 방법이 있다는 것입니다.

나는 모든 컨테이너가 휴대용이어야 한다고 생각하지 않습니다. 일부 컨테이너는 커뮤니티와 공유하기 위해 생성되고 일부는 내부 애플리케이션 배포를 위해 생성될 수 있습니다.

특권 모드에서 실행해야 하는 앱의 이식성 문제는 앱 자체에 있습니다.

권한 모드는 코드 변경 없이 앱이 작동하도록 하는 최후의 수단입니다.

특권 모드 구축이 필요한 이미지 빌더는 그러한 컨테이너가 특권 모드에서 실행해야 할 수도 있다는 것을 이해하고 있다고 믿습니다.

특권 모드로 빌드하는 것은 이식성 문제를 일으킬 수 있으므로 권장하지 않는다는 점을 분명히 문서화해야 합니다.

Outlook Mo 담즙 에서

2016년 5월 2일 월요일 오후 2:53 -0700에 "Trevor Blackwell" < [email protected] [email protected] >에 다음과 같이 썼습니다.

휴대성에 미치는 영향을 이해하지 못합니다. 빌드 시 권한 있는 작업이 이식성에 어떤 영향을 줍니까? 제 말은, 권한이 있든 없든 다양한 방법으로 휴대용이 아닌 이미지를 만드는 것이 어렵지는 않지만 권한이 있는 작업으로 빌드된 이미지가 반드시 이식이 불가능한 방법이 있다는 것입니다.

이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하거나 Gi tHubhttps://github.com/docker/docker/issues/1916#issuecomment -216375159에서 확인하세요.

@tlbtlbtlb 특권 모드는 호스트에 대한 전체 액세스를 제공하기 때문입니다. 아마도 shmmax 또는 훨씬 더 나쁜 것과 같은 단순한 것을 설정했을 것입니다.
나는 이것이 사용 가능하다는 1일차에 이러한 일이 일어날 것임을 보장합니다.

@davidl-zend "휴대용"은 커뮤니티와 공유하는 것을 의미하지 않습니다. 한 기계에서 다른 기계로 이동하는 것을 의미합니다.

@cpuguy83 다른 사람들이 지적했듯이 이미지 이식성을 깨는 다른 많은 방법이 있습니다. 권한 있는 빌드 프로세스를 사용하지 않음으로써 수행하는 모든 작업은 Dockerfile에서 부분적으로 빌드한 다음 수동으로 컨테이너를 변경하고 커밋을 수행하거나 Dockerfile에서 부분적으로 빌드하고 완료하는 두 단계 프로세스를 갖도록 하는 것입니다. 컨테이너가 처음 실행될 때 권한이 부여된 설치는 짜증나는 일입니다. 즉, 시간이 많이 걸리는 작업을 수행하는 경우 첫 번째 부팅이 작동하는 데 몇 분이 걸릴 수 있기 때문입니다.

다양한 포럼에서 본 의견을 감안할 때 많은 사람들이 오늘날 존재하는 도커 제한 사항을 해결하기 위해 이미 정확히 이 작업을 수행하고 있다고 확신합니다.

이미지 이식성이 수십 가지 다른 방식으로 손상된 아키텍처가 있으면 이 특정 풍차에 대해 기울어지는 것이 무슨 의미가 있습니까?

분명히 더 이상 도커 허브나 travis-ci가 이미지를 빌드하도록 할 수 없지만 권한 모드로 빌드해야 하는 사람들은 어쨌든 이해할 것입니다.

@ctindel 이미지 이식성이 깨지는 몇 가지 예를 보고 싶습니다.

컨테이너를 처음 시작할 때 이런 종류의 일을 하는 것이 _정확히_ 올바른 방법입니다.
이미지에 있어서는 안 되는 런타임 구성입니다.

@cpuguy83 누군가가 Dockerfile에서 부분 빌드를 수행하고, 권한 모드에서 컨테이너를 회전하고, 더 많은 변경을 수행한 다음, 도커 커밋을 수행할 수 있다는 사실에 대해 논쟁하고 있습니까? 특권 모드에서 빌드하는 것과 어떻게 다릅니까? 그것이 오늘날 다른 사람들이 하고 있는 일이기 때문입니다.

나는 뻔뻔스럽게 말하려는 것이 아니라 사람들이 어색한 방식으로 일하고 있는 플랫폼의 심각한 한계라고 말하는 것뿐입니다.

예를 들어, 시스템에 특정 기능이 없으면 올바르게 설치할 수 없는 타사 데비안 패키지(및 아마도 RPM)가 있습니다. 데비안 패키지를 설치하는 것은 "런타임 설정"이 아니라 설치 과정의 이상한 부분입니다.

@ctindel 나는 이것에 대해 전혀 토론하지 않습니다. 차이점은 행동을 지원하는 것입니다. 차이가 없었다면 우리는 이 토론을 하지 않았을 것입니다.

저에게 저는 동의하는 성인이고 여러 노드에 걸쳐 packstack 이미지를 롤링할 수 있기를 원합니다. 현재 Dockerfile 폭탄으로 빌드하고 있으므로 도커 제한을 피하기 위해 속임수를 써야 합니다.

@ cpuguy83 사람들이 다른 방식으로 작업하고 있는 이 옵션을 제공하지 않음으로써 정확히 무엇을 얻을 수 있는지 (이 스레드의 다른 사람들도 생각합니다) 여전히 명확하지 않습니다. 어쨌든 커밋 옵션이 추가되는 순간 당신이 논쟁하는 것처럼 보이는 일종의 아키텍처 순수성(나는 그것에 대해 더 나은 단어가 없습니다)이 사라졌습니다. 그래서 그것이 권한 있는 빌드 또는 권한 있는 컨테이너의 도커 커밋을 통한 Dockerfile.

한 가지 방법은 사람들을 위한 끔찍한 PITA이고 Dockerfile을 사용하여 빌드하는 현재 메커니즘에 대한 한 가지 방법은 매우 훌륭합니다.

또한, 당신은 내 질문에 대답하지 않았습니다. 타사 데비안 패키지(또는 packstack)의 간단한 설치를 "런타임 구성"으로 간주하는 이유는 무엇입니까?

@ctindel 이식성. 어떤 일을 할 수 있다고 해서 지원되는 것은 아니며 build 에 포함하여 누구나 쉽게 할 수 있다는 것은 지원된다는 의미입니다.
우리는 호스트 간에 작동하지 않는 이미지 문제로 가득 차 _할_ 것입니다... 이는 기본적으로 Docker의 모든 이유를 무효화합니다.

패키지를 설치하기 위해 --privileged 가 필요한 경우 패키지로 해결해야 합니다. 설치에는 --privileged 가 필요하지 않습니다 ... 그리고 실제로 필요한 경우 설치 자체가 이식 가능하지 않다는 표시입니다(호스트에서 변경해야 함)... --privileged 없이 컨테이너에서 docker를 실행할 수 있음을 참조하십시오(실행 가능하며 --privileged 없이 문제 없이 원하는 모든 것을 설치할 수 있음).

그러나 도커 커밋을 통해 수행할 수 있다는 것은 지원된다는 의미입니다!

이해가 되지 않습니다. 지원되지 않는 이미지에 대해 누군가가 개인적으로 불만을 제기할까봐 걱정해서 이 제품의 한계를 해결하기 위해 수많은 사람들을 만들고 있습니까?

패키지를 설치하는 작업(여기서 구성에 대해 이야기하지도 않음)이 "런타임 구성" 작업인 이유에 대한 내 질문에 여전히 대답하지 않았습니다. "휴대성"이라는 말은 아무 의미가 없습니다.

도커에 대해 x86_64에 특정한 것이 있습니까? 특정 CPU 아키텍처용으로 빌드된 도커 이미지가 결국에는 없을까요? 또한 휴대가 불가능하지 않습니까? 내 말은 어떻게 든 항상 도커 이미지를 가져 와서 다른 수많은 변수에 관계없이 전 세계의 모든 도커 호스트에서 실행할 수 있다는이 전체 아이디어는 어쨌든 불가능한 것처럼 보이므로 푸시해야 할 필요성을 이해하지 못합니다. 사람들이 요구하는 이 특정 기능으로 돌아갑니다.

BTW, 여기에서 귀하의 답변과 지속적인 참여에 감사드립니다. 이슈 스레드가 무시되는 다른 많은 github 프로젝트!

docker run --privileged with docker commit 를 사용하여 이 문제를 해결하는 사람들에 대한 요점에 동의합니다. 지금까지 두 회사에 대해 그런 솔루션을 만들었습니다. 사람들은 그런 이미지를 만들 것이고 그것을 하는 것이 끔찍하고 끔찍한 일인 것처럼 행동하는 것은 의미가 없습니다.

지옥, --privileged 로 빌드된 컨테이너를 지원하는 것이 너무 두려우면 문서에 명확하게 명시하여 사람들이 자신의 위험을 감수하고 수행하고 있음을 완벽하게 인식하도록 하십시오. 나는 지금까지 어떤 부정적인 영향도 보지 못했지만. 그러나 다시 우리는 다른 배포판에서 컨테이너를 실행하려고 시도하지 않았습니다.

@PerilousApricot 실제로 packstack에 문제를 일으키는 원인은 무엇입니까? 특정 문제를 해결하거나 업스트림에서 문제를 해결하는 데 도움을 드리겠습니다. 하지만 호스트 서버에 대한 완전한 무제한 루트 액세스를 제공하는 --privileged 를 추가하는 것이 올바른 방법이라고 생각하지는 않습니다. 사람들이 특정 빌드 문제를 제기한 모든 경우는 일반적으로 수정할 수 있습니다. 대부분의 경우 실제로 빌드를 수행하기 위해 호스트 시스템에 대한 루트 액세스가 필요하지 않기 때문입니다.

@justincormack init 스크립트가 tmpfs 파일 시스템을 마운트해야 하는 자체 서비스를 시작하는 타사 패키지(즉, 변경할 수 없음)에 대한 솔루션은 무엇입니까? 내 말은 --privileged를 무시하더라도 빌드하는 동안 --cap-add 또는 --security-opt apparmor:unconfined를 수행할 방법이 없습니다.

@ctindel 설치 시 tmpfs를 마운트하지 않아야 합니다. 런타임 시 tmpfs가 필요한 경우 훌륭하지만 설치 시에는 정확하지 않습니다.

@cpuguy83 상업적인 제 3자로부터 온 것이기 때문에

이것이 이 전체 토론의 요점입니다. "잘못하는" 사람들의 지원 요청에 대한 철학적 우려 때문에 도커 사용을 훨씬 더 어렵게 만드는 임의의 제한을 부과하고 있습니다.

이는 운영 체제가 사람들이 프로세스 스케줄링 클래스를 변경하는 것을 허용해서는 안 된다고 말하는 것과 같습니다. 잘못하면 우선 순위가 역전될 수 있기 때문입니다. 또는 잘못 사용하면 엄지손가락을 칠 수 있기 때문에 아무도 망치를 만들어서는 안 됩니다.

여러 번 말했듯이 docker는 이미 commit 명령을 통해 이를 지원하므로 사용자에게 더 고통스러울 뿐입니다. 이 기능을 원하지 않는 사람은 사용하지 않을 것이고, 동의한 성인은 제한 사항을 이해하고 사용하고자 하는 경우 눈을 크게 뜨고 사용할 수 있습니다.

@ctindel 더군다나 50km 반경에 있는 모든 사람을 죽일 수 있기 때문에 이 핵폭탄을 처리할 수 없습니다.

설치하는 동안 tmpfs를 로드해야 하는 이 패키지의 특징은 무엇입니까? 설치는 말 그대로 일부 아카이브 형식에서 rootfs로 파일을 추출하는 것입니다.

무엇이든 변경할 수 있습니다.
빌드 시 권한 있는 권한을 활성화하는 것보다 설치 시 tmpfs를 마운트하지 않도록 업스트림으로 변경하는 것이 훨씬 간단하고 안전한 변경 사항입니다.

Docker는 워크로드 이식성에 관한 것입니다. 빌드에 대한 특권(또는 추가 권한, 보안 프로필 조정 등)을 활성화하면 이 문제가 근본적으로 중단되며 오늘날 우리가 받아들일 수 있는 사항이 아닙니다.

commit 및 build 는 매우 다른 두 가지이며 한 가지 방법으로 수행할 수 있다고 해서 다른 모든 방법으로도 수행할 수 있어야 한다는 의미는 아닙니다.

FROM python

ENV PACKSTACK_VERSION 7.0.1
RUN cd /opt && git clone https://github.com/openstack/packstack.git \
  && cd packstack \
  && git checkout $PACKSTACK_VERSION \
  && rm -rf .git \
  && python setup.py install

권한이 필요하지 않습니다.

번영의 교회.
언젠가는 "강제" 이식성이 이 프로젝트를 죽일 것입니다. 이미 실행 중입니다.
너무 많은 기능이 애매한 이식성 때문에 거부되고 있고, 그것 때문에 많은 진전이 이루어지지 않고 있습니다 .....
언젠가 누군가가 프로젝트를 포크하고 이식성을 선택 사항으로 만들 것입니다. 꿈 ... 꿈 .... 아멘.

두 가지 경우로 나누면 다음과 같습니다.

1. 성능을 위해 tmpfs를 마운트하는 것과 같이 권한이 있는 작업을 경솔하게 사용하는 설치 프로그램. 이러한 설치 프로그램은 쉽게 고칠 수 있습니다(그러나 가까운 시일 내에 해결되지 않을 수 있음).

이 경우 Docker가 제대로 작동하지 않는 설치 프로그램을 푸시백하는 것이 유효한 철학입니다. 대부분의 설치 프로그램에는 Dockerfile을 조금 더 길게 만드는 일종의 해결 방법이 있습니다.

1. GPU 드라이버용 커널 모듈 설치와 같이 기본적으로 권한 있는 작업에 의존하는 설치 프로그램. 이것들은 또한 근본적으로 휴대가 불가능합니다. 예를 들어, Mac용 docker-machine에서는 작동하지 않습니다.

이 경우 Docker 환경이 손상됩니다. 예를 들어 Mac에서는 docker-machine을 사용할 수 없습니다. 예를 들어 호환되는 대상 호스트 컴퓨터에서만 이미지를 빌드할 수 있습니다. 내 사용 사례는 호스트 OS(CoreOS)에 nVidia GPU 드라이버를 설치하는 것이어서 호스트 OS에 직접 설치하는 것을 권장하지 않았습니다.

그래서 어느 쪽이든 지원하지 않는 것의 미덕을 알아보기 위해 찾아온 것 같습니다. 내 생각을 바꾸게 만든 것은 먼저 내 코드를 Ubuntu 상자에 밀어 넣고 거기에서 빌드하는 것보다 docker-machine을 사용하여 랩톱에서 이미지를 빌드하는 편리함 때문이라고 생각합니다.

@tlbtlbtlb 무슨 "덕"을 말씀하시는지 이해가 되지 않습니다. 경박하지는 않지만 한 환경에서는 실행되지만 다른 환경에서는 실행되지 않는 수많은 도커 이미지가 있는 것을 고려하십시오. 예를 들어, linux->linux에서 mongodb 컨테이너로 호스트 볼륨을 마운트할 수 있습니다. mmapv1 스토리지 드라이버가 제대로 작동하기 때문입니다. 이 경우 mmap 항목이 제대로 작동하지 않습니다.

나는 이것이 건물과 관련하여 문제가 아니라는 것을 알고 있지만 도커 이미지가 "이식 가능"하고 "어디서나 실행할 수 있다"는 생각은 이 시점에서 완전히 넌센스입니다. 아무데도 달릴 수 없는 상황이라면 "어디서든 지을 수 있어야 한다"는 말이 무슨 미덕이겠습니까?

요점은 mongodb 이미지가 모든 곳에서 작동한다는 것입니다. 잘못된 런타임 구성을 제공하는 것은 다른 문제입니다.

Docker에는 이식 가능한 구성과 이식 불가능한 구성이 매우 구체적이고 장에서 분리되어 있습니다.

이것은 어떤가요 ?
내 nginx 구성 확인 패스에 컨테이너 내부에 내 실제 IP가 있어야 합니다.

이것은 내 Dockerfile입니다.

FROM ubuntu:14.04.4

RUN apt-get update
RUN apt-get install -y software-properties-common
RUN add-apt-repository ppa:nginx/stable
RUN apt-get update
RUN apt-get install -y nginx-full vim
RUN ifconfig lo:0 192.168.168.70 netmask 255.255.255.0 up
RUN ifconfig lo:1 192.168.168.57 netmask 255.255.255.0 up
RUN ifconfig lo:2 192.168.168.58 netmask 255.255.255.0 up

ADD . /etc/nginx

➜  nginx git:(ha-node-01) ✗ docker build -t nginx4test .
Sending build context to Docker daemon 976.4 kB
Step 1 : FROM ubuntu:14.04.4
 ---> 90d5884b1ee0
Step 2 : RUN apt-get update
 ---> Using cache
 ---> eea42cb6135d
Step 3 : RUN apt-get install -y software-properties-common
 ---> Using cache
 ---> 9db86ab17850
Step 4 : RUN add-apt-repository ppa:nginx/stable
 ---> Using cache
 ---> 5ed2266a93a9
Step 5 : RUN apt-get update
 ---> Using cache
 ---> 09fcfdc1fed3
Step 6 : RUN apt-get install -y nginx-full vim
 ---> Using cache
 ---> cc0c1662e009
Step 7 : RUN ifconfig lo:0 192.168.168.70 netmask 255.255.255.0 up
 ---> Running in 5d962ec4e35d
SIOCSIFADDR: Operation not permitted
SIOCSIFFLAGS: Operation not permitted
SIOCSIFNETMASK: Operation not permitted
SIOCSIFFLAGS: Operation not permitted
The command '/bin/sh -c ifconfig lo:0 192.168.168.70 netmask 255.255.255.0 up' returned a non-zero code: 255

권한 옵션으로 컨테이너를 실행하면 루프백 인터페이스에 IP를 설정할 수 있습니다. 그러나 추가할 스크립트가 하나 더 있습니다.

@cpuguy83 내 Dockderfile 에 RUN 하고 싶은 iptable 항목이 약 20줄 정도 있지만 --cap-add=NET_ADMIN 가 필요하기 때문에 할 수 없습니다. 이러한 명령은 컨테이너를 실행하는 사람과 컨테이너를 실행하는 컴퓨터(컨테이너가 내부 앱을 실행함)에 관계없이 발생해야 합니다. 위에서 논의한 내용을 기반으로 어디/어떻게 제안하시겠습니까?

@MatthewHerbst 불행히도 iptables 규칙은 이미지와 함께 지속되지 않거나 지속되지 않습니다.

@cpuguy83 저는 centos:6 이미지를 사용하고 있으며 run /sbin/service iptables save 을 실행하여 파일 시스템에 규칙을 유지할 수 있습니다. 나는 그것들이 iptables-persistent 패키지를 통해 Ubuntu와 다른 것들에서 유사한 기능이라고 생각합니다.

해당 파일에 대한 iptables 규칙을 생성하기만 하면 됩니다.
실제로 적용하십시오. 컨테이너가 실행되는 네트워크 상황은
매우 다르기 때문에 런타임에 규칙을 적용해야 합니다.
호스트가 생성하는 것이 더 나을 수 있음).

2016년 5월 16일 16:03에 "Matthew Herbst" 알림 @github.com이 작성했습니다.

@ cpuguy83 저는 CentOS를 사용
파일 시스템에 규칙을 유지합니다. 나는 그들이 비슷하다고 믿습니다.
iptables-persistent 패키지를 통한 Ubuntu 및 기타 기능.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.

@justincormack 왜 그 생각을 못했는지 모르겠어! 감사 해요!

docker service 사용할 때 권한이 필요한 명령을 어떻게 실행해야 합니까? 몇 대의 컴퓨터에 호스트 이름을 설정해야 하지만 불행히도 이를 위해서는 권한이 필요합니다.

@nostrebor 는 이 공개 문제와 매우 관련이 없습니다.
서비스를 1:1로 복사하는 대신 서비스에 어떤 옵션이 있어야 하는지 평가하고 있습니다. 특권 모드는 서비스에 대해 1.12에 없을 것입니다.

설치를 위해 무언가를 컴파일하는 도커 빌드를 시도하고 있지만 CVMFS 네트워크 파일 시스템에 존재하는 라이브러리에 대해 컴파일해야 합니다. 물론 --privileged를 실행하지 않고 CVMFS를 마운트할 수 없으므로 Dockerfile을 사용하여 전혀 할 수 없습니다.

@cpuguy83 @tlbtlbtlb 기본적으로 권한 있는 동작에 의존하는 '인스톨러'의 경우입니다. 그러나 그것은 내가 '사소한 사용'이라고 부르는 것이 아니라 네트워크 파일 시스템의 공유 라이브러리에 대한 액세스가 필요합니다. 그러나 이 경우 설치는 단순히 일부 아카이브에서 파일을 추출하는 것이 아닙니다.

네트워크 파일 시스템을 마운트하는 것이 이식성 문제라는 것을 이해하지 못합니다. (우리의 모든 대상 환경은 이 파일 시스템에 액세스할 수 있습니다. 네트워크 파일 시스템의 바이너리 코드에도 연결해야 하는 다른 코드를 빌드하기 때문에 필요합니다.)

다른 접근 방식을 시도해야 합니까? 호스트에 CVMFS를 마운트하고 해당 디렉토리를 컨테이너 등과 공유해야 합니까? 이 이미지를 만들기 위해 외부 빌드 시스템을 설정하고 싶지 않습니다. 이미지의 기반이 되는 이미지에는 이미 작업을 수행할 전체 빌드 시스템이 있습니다. CVMFS를 마운트할 수만 있으면 됩니다.

Dockerfile을 사용하여 이 작업을 수행하게 되어 기뻤지만 docker run --privileged 일부 스크립트를 사용하거나 docker 대신 다른 것을 사용해야 할 것 같습니다. 액세스 권한이 없는 _없는_ 컨테이너에 파일 시스템을 마운트하는 방법이 있습니까?

스크립트 내부에 권한 있는 명령을 배치/반향하여 해결 방법을 수행하고 CMD 명령을 사용하여 컨테이너 진입점에서 스크립트를 실행하므로 그런 이미지를 빌드한 후 권한 있는 모드에서 컨테이너를 실행할 수 있고 모든 것이 작동합니다.

@drstapletron , CERN cvmfs 문서 에 따르면 현재로서는 호스트에서 컨테이너로 cvmfs를 마운트하거나 권한 있는 컨테이너 내부에 cvmfs를 설치하는 두 가지 옵션이 있습니다.

초의 경우 여기에서 cmssw 녀석을 위한 도커 파일을 작성했습니다.
https://github.com/iahmad-khan/system-admin/blob/master/cvmfs-inside-docker.Dockerfile

따라서 이 파일을 사용하여 이미지를 빌드하고(또는 cmssw dockerhub에서 가져올 수 있음) P 모드에서 실행할 수 있으며 모든 것이 이미 컨테이너 내부에 있습니다( ls /cvmfs/*)

이 문제에 대한 피드백의 목록이 다소 길기 때문에 이것이 위에서 다루어졌는지 확실하지 않습니다. 나도 --privileged 빌드 명령을 갖고 싶습니다. 현재 사용 사례는 gentoo stage3에서 go ebuild를 빌드할 때 부딪힌 문제를 해결하는 것입니다. 컨테이너를 사용하지 않으면 gentoo 핸드북의 현재 지침으로 인해 'umount -l /mnt/gentoo/dev{/shm,pts,} && umount -l /mnt/gentoo/{ proc,sys}' systemd로 부팅된 시스템에서... 내 stage3 빌드를 도커 컨테이너로 이동하면 빌드에 ptrace 또는 go-1.7.1이 요구하는 다른 제한된 기능이 필요할 때까지 모든 것이 제대로 작동합니다. ebuild가 필요한 것 같습니다.

지금은 단순히 docker run 명령 내에서 빌드를 실행하고 커밋한 다음 계속 진행하지만 수동 단계를 피하기 위해 docker build 명령 자체 내에서 ptrace를 활성화하는 것이 좋습니다.

저도 이 기능을 원합니다. 빌드 환경을 만들고 싶지만 커널 모듈이 필요하고 빌드할 때 modprobe가 저와 협력하지 않습니다. 이에 대한 해결 방법이 있습니까?

구체적으로 특별히:

modprobe vcan && \
ip link add type vcan && \
ifconfig vcan0 up

완전히 합리적인 사용 사례처럼 보입니다.

@seltzy docker 누군가가 귀하의 사용 사례의 합리성을 인정할 때까지 숨을 참지 않는 것이 좋습니다.

아키텍처 및 기능 포함과 관련하여 매우 엄격하고 실용적이며 냉담하며 _자신의_ 로드맵에 맞지 않는 모든 사용 사례를 무시하는 경향이 있습니다.

우리 평범한 사람들은 이해할 필요가 있습니다. docker 팀은 자신의(비즈니스 고객 및 셀프 서비스 가능성이 있는) 요구 사항을 충족시키는 아키텍처 결정을 내립니다. 이러한 결정은 매우 힘들게 만들어진 우리(공개 최종 사용자)와 거의 겹치지 않습니다. 여기에 제출하는 문제 .

물론 그들은 이러한 방식으로 엔지니어링 리소스를 자유롭게 할당할 수 있습니다.
그러나 회사가 "사용자의 요구를 진지하게 받아들이는" 것으로 묘사된다면 상상을 불러일으키는 실적을 제공합니다.

@tamsky 수고 하셨습니다!

@tamsky 당신이 분명히 원하는 기능을 프로젝트에서 수락하지 않았기 때문에 왜 그렇게 생각하는지 이해할 수 있습니다.

이것은 어떤 종류의 비즈니스 결정과도 관련이 없습니다. 사실 빌드 시 --privileged 는 이식할 수 없는 이미지를 생성합니다.
빌드 환경에서 modprobe 와 같은 것은 도움이 되지 않으며 두 개의 빌드에서 완전히 다른 결과를 생성할 수도 있습니다.

나 자신은 빌드에 --privileged 를 구현했습니다. 이것은 엔지니어링 문제가 아니며 실제로 구현하는 것은 매우 간단합니다. 그것을 지원하는 것이 문제입니다.
고급 사용자의 경우 권한 있는 지원을 포함할 수 있는 기존 API를 사용하여 기존 코드를 재사용하는 경우에도 사용자 정의 빌더를 구현할 수 있습니다.

즉, 이 문제는 여전히 열려 있습니다. 사람들이 듣고 있기 때문입니다.

이해해 주셔서 감사합니다.

@cpuguy83 설명 감사합니다. 휴대성 문제인지 몰랐습니다. 이에 대한 나의 욕망은 오해에서 비롯된 것 같다.

특권 빌드를 갖고 싶은 유혹에 직면했을 때 취해야 할 일반적인 철학적 접근 방식은 무엇입니까?

@seltzy 귀하의 사용 사례가 이 기능의 필요성에 대한 합리적인 예가 아니라고 확신하지 마십시오.

@cpuguy83 아직 사용 사례에 대한 답변을 기다리고 있습니다. 우리 기관의 빌드 시스템은 내 컨테이너에 탑재 해야 하는 네트워크 파일 시스템을 통해 배포됩니다. 이를 위해서는 컨테이너가 권한 있는 모드에서 실행되어야 합니다. 소프트웨어 배포를 위해 네트워크 파일 시스템을 사용하기로 한 우리 기관의 결정은 입자 물리학에서 드문 일이 아닙니다. 빌드 시 --privileged 가 이식 불가능한 이미지를 생성한다고 주장하지만 이것은 제 사용 사례와 전혀 관련이 없습니다. 우리의 개발 모델은 네트워크 파일 시스템(정말?)의 사용으로 인해 잃어버릴 _수도 있는_ 모든 이식성을 이미 포기했습니다. 우리는 그것을 마운트하기 위해 개발 기계가 필요합니다.

@ cpuguy83 추신 당신은 사용자 정의 빌더를 언급했습니다. 이에 대한 정보는 어디에서 찾을 수 있습니까? 감사 해요!

컨테이너 이식성에 대한 이 모든 논의는 어쨌든 거대한 청어입니다. 1단계 이미지를 생성하고, 권한 모드에서 컨테이너를 실행하고, 해야 할 일을 모두 수행한 다음, 도커 커밋을 사용하여 해당 컨테이너에서 최종 이미지를 생성함으로써 이미 동일한 작업을 수행할 수 있습니다.

일단 도커 커밋 옵션을 추가하면 이미지 이식성에 대한 모든 개념이 사라졌습니다. 따라서 사람들에게 1단계 대신 3단계로 이 작업을 수행하도록 하는 것은 아무 것도 얻지 못하고 권한 있는 빌드 옵션을 실제로 사용할 수 있는 사람들을 짜증나게 할 뿐입니다.

@drstapletron 파일 시스템을 마운트하는 것이 반드시 이식성을 손상시킬 수 있는 것은 아닙니다(누군가가 이미지에 마운트될 것으로 예상하지 않는 한).
여기서 문제는 파일 시스템을 마운트할 수 있는 기능이 있다는 것 또한 다른 많은 나쁜 일을 할 수 있다는 것을 의미한다는 것입니다.

@ctindel 예, 생성한 컨테이너에서 원하는 모든 작업을 수행할 수 있습니다. 그러나 docker build 가 지원되는 이미지 빌드 방법이라는 사실은 이를 사용하여 빌드된 이미지가 이식성 _있는_ 것을 보장해야 함을 의미합니다.

휴대용 이미지는 청어가 아닙니다. 워크로드 이식성은 Docker의 주요 설계 목표입니다. 말 그대로 우리의 주요 지시.

@seltzy 대부분의 경우 상승된 권한이 어떤 식으로든 호스트를 수정하는 데 사용되기 때문에 추가 권한이 필요한 대부분의 항목은 런타임에 속합니다.
즉, 빌드 시 몇 가지 사항이 필요하다는 것을 확실히 이해할 수 있습니다(예: 위의 nfs 마운트).... 하지만 NFS의 경우에도 이미지를 수동으로 빌드하는 경우( docker build 아님), 컨테이너에 --privileged 또는 추가 기능을 전혀 제공하지 않고 대신 nfs 내보내기를 볼륨으로 마운트합니다.

@drstapletron mount 는 --privileged 더 제한된 기능 집합만 필요로 하지 않으며 대부분의 사람들이 하는 호스트에 대한 전체 루트 액세스 권한을 부여하기 때문에 전체 권한 모드보다 더 빨리 발생할 가능성이 훨씬 높습니다. 하지. (여전히 보안 문제가 있지만 더 관리하기 쉽습니다.)

그래서 나는 완전히 이식 가능하고 호스트를 수정하지 않는 사용 사례를 가지고 있습니다. 그것은 심지어 오픈 소스이며 여기에서 볼 수

기본적으로 휴대용 Docker 컨테이너에서 Mock을 실행하여 맞춤형 CentOS ISO 이미지를 빌드하고 싶습니다. Mock은 모르는 사람들을 위한 컨테이너화된 RPM 빌더입니다. 문제는 컨테이너를 사용하기 때문에 --privileged 또는 --cap-add 합니다. 이상적으로는 docker build 가 함수처럼 작동하여 몇 가지 인수를 취하고 최종 결과를 반환한다고 생각합니다. 하지만 이 플래그가 없으면 그렇게 할 수 없습니다.

여기도 마찬가지! 도커 내부에서 mock을 사용하는 것은 그 때문에 악몽입니다 :(

Sending build context to Docker daemon 9.728 kB
Step 1 : FROM centos
 ---> 980e0e4c79ec
Step 2 : MAINTAINER Gregory Boddin
 ---> Using cache
 ---> 93e709c87f25
Step 3 : RUN yum install -y spectool mock
 ---> Using cache
 ---> 7006ef8d0276
Step 4 : RUN useradd mock -g mock
 ---> Using cache
 ---> bfb931c56d89
Step 5 : ADD *.cfg /etc/mock/
 ---> Using cache
 ---> 15521d2822b1
Step 6 : RUN su mock -c"/usr/bin/mock -r edge-5-x86_64 --init"
 ---> Running in 542a742b6017
INFO: mock.py version 1.2.17 starting (python version = 2.7.5)...
Start: init plugins
INFO: selinux disabled
Finish: init plugins
Start: run
ERROR: Namespace unshare failed.

@cpuguy83 은 다음

사실 --privileged on build는 이식할 수 없는 이미지를 생성합니다.

광범위한 휴대성을 필요로 하지 않는 사람들을 위해 --privileged 를 허용하지 않는 이유는 무엇입니까?
공식 문서의 간단한 메모는 합리적인 절충안이 될 것입니다(예: _경고: build 명령에 --privilege 를 전달하면 이미지의 이식성이 떨어질 수 있습니다!_). 이것은 거의 모든 사람의 요구 사항을 해결할 것입니다. 어떤 사용자는 이식성이 필요하지 않고 어떤 사용자는 필요합니다. 경고는 모든 사람의 요구를 충족하기에 충분할 것입니다.

build --privileged 의 부족으로 인해 현재 사용 사례가 상당히 복잡해집니다.

--non-portable 라고 할 수 있습니다. 나는 아직 docker의 배포 부분을 사용하지 않았지만 격리 + 오버레이 파일 시스템 항목은 그것 없이는 정말 유용했습니다.

권한 있는 컨테이너를 설치해야 하는 독점 소프트웨어를 사용해야 합니다. 제가 할 수 있는 일은 없습니다. 3단계 빌드, 실행, 커밋 프로세스를 수행해야 하는 데 어려움을 겪고 있습니다.

컨테이너 이식성은 나와 내 비즈니스에 아무 의미가 없습니다. 사실 대부분의 비즈니스에는 아무 의미가 없습니다. 중요한 것은 유지 관리하는 소프트웨어를 줄이고 싶기 때문에 이 문제에서 사용성보다 이식성을 선택하는 것이 Docker에 해롭다고 생각합니다.

이에 대해 +1, setfacl을 사용하는 빌드 프로세스에서 빌드 중에 실패하고 컨테이너에서 서비스가 시작되지 않습니다. 최종 사용자로서 우리는 제한되어서는 안 된다고 생각합니다. 필요한 경우에만 --priviledge 옵션을 사용하고 기본값은 비활성화되어 있습니다.

이것에 대해 +1. 빌드 프로세스에서 /proc 및 /dev를 마운트해야 합니다. 이상적으로는 dockerfile의 일부로 마운트 단계를 가질 수 있어야 합니다.

@samsun387 빌드 프로세스에 이것이 필요한 이유는 무엇입니까?

@skshandilya setfacl은 이식성이 없으며

@robhaswell "권한 있는 컨테이너 필요"는 별로 도움이 되지 않습니다. 실제로 설치 시 무엇을 사용하고 있습니까?

+1. 모의 초기화는 이것을 필요로 합니다.
거의 전체 문제를 읽습니다. 왜 사람들이 3년 동안 "이게 왜 필요해"라고 계속 묻는지 이해가 가지 않습니다.

@Betriebsrat "X가 이것을 필요로 한다"는 것은 그다지 도움이 되지 않기 때문입니다.
"X"는 무엇을 하고 있습니까? 빌드 단계에서 "X"가 이것을 필요로 하는 이유는 무엇입니까?

예를 들어, /proc 및 /dev 를 마운트하는 기능이 있는 위의 경우는 실제로 빌드 단계에 적합한 위치가 아닌 것처럼 보이며 이미지가 호스트에 연결되는 것처럼 보입니다. 사례.

"privileged"도 탱크입니다. 그것은 절대적으로 모든 것을 열고, 모든 보안 기능을 비활성화하고, 일반적으로 읽기 전용 장소에 대한 쓰기 액세스를 제공합니다. 누군가는 아마도 매우 특정한 일을 할 수 있어야만 하는 곳입니다.

이러한 질문은 실제 사용 사례와 그러한 사례를 충족할 수 있는 방법을 얻을 수 있도록 하기 위한 것입니다.

그건 그렇고, 내가 "보안 기능"이라고 말할 때 두 가지를 의미합니다.

1. 해킹을 방지하기 위한 것들
2. 호스트 문제에서 애플리케이션 문제 격리(즉, 이미지 빌드는 이미지를 빌드된 호스트에 연결해서는 안 됨).

내 문제는 21051에 의해 해결된 것 같습니다. 지금은 외출 중입니다. :)

@shykes 는 2013년 11월 28일 @ https://github.com/docker/docker/pull/2839#issuecomment -29481246에 말했습니다::

죄송합니다. 현재 디자인은 '1 소스, 1 빌드'를 적용하는 것이므로 소스 디렉토리 이외의 docker 빌드에 대한 인수를 허용하지 않습니다.

일부 빌드는 권한 있는 작업이 필요하기 때문에 현재 수행할 수 없다는 사실을 이해합니다. 이를 적절하게 처리하려면 1) Dockerfile이 권한 있는 방식으로 빌드해야 할 필요성을 표현하도록 허용하고, 2) 도커가 빌드를 일시 중지하고 사용자에게 위험에 대해 적절하게 경고하도록 허용하는 권한 부여/트러스 시스템을 구현해야 할 수 있습니다. Dockerfile의 출처 및 신뢰성에 대한 정보를 노출한 다음 빌드를 허용하거나 거부하는 사용자의 결정을 수집합니다.

@ cpuguy83 , "1 소스, 1 빌드" 시행에서 디자인이 전혀 변경 되었습니까?
Docker 프로젝트가 해당 디자인을 변경하고 커뮤니티에서 요청한 이 기능을 허용할 의향이 있습니까?

위의 Shykes의 설명은 이 문제를 처리하기 위해 "우리가 해야 할 일"이 무엇인지 설명하는 것 같습니다. 동시에 사용된 언어("might")는 도커 프로젝트에 이 디자인 변경을 거부할 추가 이유를 제시할 수 있는 많은 공간을 제공하는 것으로 보입니다.

NEEDS_PRIVILEGED 선언을 추가하는 것은 의미가 있지만 빌드 일시 중지에 대한 이 모든 것이 있습니까? 오류로 실패하고 실제로 권한 있는 빌드를 허용하려는 경우 운영자가 --privileged 옵션을 전달하도록 하십시오.

@cpuguy83 문제는 빌드에서 특권 모드가 필요한 사람들은 일반적으로 사용 위험이 무엇인지 완벽하게 잘 알고 있는 고급 사용자라는 것입니다. 그리고 대부분은 이를 수락하고 필요한 단계에 대한 빌드의 일부로 docker commit 를 사용하여 이 문제를 해결합니다.

당신은 사람들이 빌드에서 특권 모드를 사용하는 것을 어떤 식으로든 막지 않고 그저 귀찮게 만들고 있을 뿐입니다.

당신의 목표가 그렇게 하는 것을 짜증나게 하는 것이라면, 몇 년 동안 계속 놔두는 대신 이 문제를 솔직하게 말하고 닫으십시오.

"성가시게 하기를 원하기 때문에 이 문제를 수정하지 않을 것입니다"라고 말하고 이 문제를 닫습니다.

/실

@cpuguy83 , 내 이해에서 Mock은 unshare(2) CLONE_NEWNS 플래그와 함께 unshare(2) 를 사용하며 chroot/container 환경을 만들 때 다른 것도 사용할 수 있습니다. 여기에는 CAP_SYS_ADMIN 이상이 필요합니다.

"X"는 무엇을 하고 있습니까? 빌드 단계에서 "X"가 이것을 필요로 하는 이유는 무엇입니까?

우리의 사용 사례에서는 모릅니다. 그것은 우리가 변경할 수 없는 일부 독점 쓰레기입니다. 문제는 우리 비즈니스가 "보안"(이 맥락에서)이나 이식성 또는 나열된 우려 사항에 대해 관심이 없다는 것입니다. 우리는 이 망할 쓰레기를 컨테이너에 넣고 가치 있는 일을 하고 싶을 뿐입니다.

@PonderingGrower가 말했듯이 어쨌든 우리는 그것을 할 것입니다. 그것은 우리가 그것을 하는 동안 얼마나 많은 시간을 낭비하느냐의 문제일 뿐입니다.

빌드에서 특권 모드가 필요한 사람들은 일반적으로 사용 위험이 무엇인지 완벽하게 알고 있는 고급 사용자입니다.

나는 그 가정에 강력하게 동의하지 않습니다. 전반적으로 --privileged 를 사용하는 사람들은 "누군가가 문제를 해결했다고 썼기 때문에" 맹목적으로 chmod -r 777 실행하는 동일한 범주의 사용자입니다.

우리의 사용 사례에서는 모릅니다. 그것은 우리가 변경할 수 없는 일부 독점 쓰레기입니다. 문제는 우리 비즈니스가 "보안"(이 맥락에서)이나 이식성 또는 나열된 우려 사항에 대해 관심이 없다는 것입니다.

여기서 "이 컨텍스트에서"는 호스트에서 "소유의 쓰레기" 루트 액세스 권한을 부여하는 것을 의미합니다.

@thaJeztah 나는

빌드하는 동안 dind를 사용하여 빌드하는 컨테이너 내부의 일부 컨테이너를 미리 구성하려면 이 기능이 필요합니다.

여기서 3년동안 무슨 얘기를 하는거야?

docker run 에는 --cap-add , --cap-drop 및 기타 옵션이 있습니다. 그래서 RUN 에서 명령 Dockerfile 동일한 옵션을 갖고 싶어. 따라서 Dockerfile 는 상위 시스템에 요청을 보내고 일부 권한을 추가/삭제하도록 요청합니다.

상위 시스템은 이러한 요청으로 원하는 작업을 수행할 수 있습니다. 쉘을 대화식으로 만들 수 있고 GUI 확인 대화 상자 등을 만들 수 있습니다. 이 문제에서 이러한 요청의 해결에 대해 논의하는 이유는 무엇입니까?

상당수의 도커 사용자는 빌드 명령에서 --cap-add 또는 --privileged 기능을 사용하여 실행 명령에 있는 것을 모방하기를 원합니다.

그렇기 때문에 유지 관리자가 이 특정 인스턴스에서 사용자가 원하는 것을 제공하는 데 관심이 없음에도 불구하고 이 티켓이 3년 동안 열려 있는 사람들과 함께 계속해서 차임벨이 울리는 것입니다.

@ctindel 이것은 확실히 이 문제의 문제입니다. docker build --cap-add 와 RUN --cap-add 사이에 간격이 있습니다.

어떤 사람들은 docker build --cap-add=caps_array 만으로 자식 시스템의 권한 요청을 해결하기를 원합니다. 그것은 무엇입니까? caps_array.include? requested_cap 입니다.

어떤 사람들은 pre_requested_caps.include? requested_cap 원합니다. 어떤 사람들은 원하는 stdout << requested_cap, stdin.gets == 'y' K2661에 사람들이 원하는 gui_confirm requested_cap . 어떤 사람들은 확실히 UAC_fullscreen_dialog requested_cap 원할 것입니다.

requested_cap 의 해결 방법은 사용자의 취향에 따라 다르며 이 질문은 절대 하지 않을 것이라고 생각합니다.

하지만 RUN --cap-add 는 사람의 취향과 아무 상관이 없습니다. 우리는 무엇을 기다리고 있습니까?

@andrew-aladev 귀하의 게시물이 말하는 내용을 정말 이해하지 못합니다. 요점은 사람들이 제어할 수 없는 타사 소프트웨어(RPM, DEB 등)가 있고 "도커 빌드" 시간에 이미지에 설치하기를 원하고 올바르게 설치하기 위해 추가 기능이 필요하다는 것입니다. 타사 RPM이므로 설치 단계에서 권한 증가 요구 사항을 해결할 방법이 없습니다.

그들은 이러한 향상된 기능으로 컨테이너를 실행하고 소프트웨어를 설치한 다음 해당 컨테이너에서 이미지를 생성하여 문제를 해결하고 있습니다. 그것은 고통스럽고 동일한 끝이 회로적으로 달성될 수 있기 때문에 빌드 시 cap-add를 금지할 기능적 이유가 없음을 분명히 보여줍니다.

@ctindel 제 영어

알아요. glibc를 이머지하려고 시도했는데 ptrace not permitted 받았습니다.

docker 자체적으로 기능이 증가/감소된 컨테이너를 실행할 수 있습니다. RUN 명령은 Dockerfile --cap-add , --cap-drop 등을 지원해야 합니다.

Dockerfile RUN --cap-add=SYS_PTRACE -- emerge -v1 glibc 가 있다고 상상해 봅시다. 어떻게 작동할까요?

1. 자식 머신은 부모에게 요청을 보내고 SYS_PTRACE 합니다.
2. 상위는 확장된 기능을 허용합니다.
3. 상위는 SYS_PTRACE가 허용된 새 컨테이너를 생성합니다.

이 문제에 대해 실제로 논쟁을 벌이는 사람은 아무도 없습니다. 사람들은 이러한 기능을 허용하는 방법 에 대해 논쟁하고 있습니다.

@thaJeztah가 말했다

전반적으로 --privileged를 사용하는 사람들은 chmod -r 777을 맹목적으로 실행하는 동일한 범주의 사용자입니다.

이 사람은 log :info, requested_cap; return privileged? 보다 더 유연한 유효성 검증 방법 을 원합니다.

@ctindel 당신이 말

NEEDS_PRIVILEGED 선언을 추가하는 것은 의미가 있지만 빌드 일시 중지에 대한 이 모든 것이 있습니까? 오류로 실패하고 실제로 권한 있는 빌드를 허용하려는 경우 운영자가 --privileged 옵션을 전달하도록 하십시오.

쉘을 대화식으로 만들고 싶습니다. stdout << requested_cap, stdin.gets == 'y' 원합니다. 이것은 필수 기능을 검증하는 또 다른 방법 입니다.

@cpuguy83이 말했다

누군가는 해킹을 방지하기 위해 매우 구체적인 일을 할 수 있어야 합니다.

이 남자는 docker build --cap-add=caps_array caps_array.include? requested_cap 원합니다. 이것은 필수 기능을 검증하는 또 다른 방법 입니다.

그래서 저는 RUN in Dockerfile 여전히 --cap-add , --cap-drop 등을 지원하지 않는 이유를 묻고 있습니다. 아무도 그것에 대해 논쟁하지 않습니다. 3년이 지났다!

@andrew-aladev 빌더가 메인 엔진에서 재작성/리팩터링/분리될 때까지 dockerfile 구문이 고정되어 있다는 것이 분명했기 때문에 아무도 그 구문에 대해 논쟁하지 않았다고 가정합니다. https://github.com/docker/docker/issues/29719#issuecomment -269342554

더 구체적으로 말하면 문제의 제목과 OP가 --privileged 빌드를 요청하고 있습니다.

이것은 Fonzie를 쿵쾅거리게 합니다. .

build 단계에서 strace 를 실행할 수 있으면 많은 도움이 됩니다.
현재 디버그에 필요한 모든 것을 run 단계로 이동하여 이 문제를 해결합니다. 이상적이지는 않습니다.

build 단계가 아닌 run 에서 작동하는 이유를 아는 사람이 있습니까? 즉, 역사적 이유.
많은 권한이나 구성 없이 작동하는 strace 대한 대안이 있습니까?

이에 대한 제안된 솔루션/해결 방법이 있습니다.
https://github.com/docker/docker/issues/6800#issuecomment -50494871 :

도커 빌드에 문제가 있는 경우 "빌더 컨테이너"를 사용할 수 있습니다.
docker run --cap-add [...] mybuilder | docker build -t myimage -

누군가(아마도 @tiborvass) 이에 대해 자세히 설명할 수 있습니까? 여기서 mybuilder 는 무엇입니까?
일부 ENTRYPOINT 가 포함된 이미지 이름 ? 또는 [...] 및 mybuilder 의 이미지 부분은 다음을 참조합니다.
쉘 스크립트에? 그리고 docker run 가 context.tar.gz를 docker build - 에 전달하도록 어떻게 설득합니까?
그것이 정말로 여기에서 일어나고 있는 일이라면. 미리 감사드립니다, Steffen

@sneumann mybuilder 는 이미지 이름이고 실제로 CMD 또는 ENTRYPOINT 있습니다. 이 해결 방법이 작동하는 계약은 mybuilder 가 컨테이너 내에서 컨텍스트를 tar 해야 하고 stdout으로 보내야 한다는 것입니다. 즉에 전달된다 docker build '의 표준 입력 쉘 관 덕분 | 하고 대한 컨텍스트 경로 때문에 컨텍스트로 간주 docker build -t myimage - 인 - .

코드를 보면 약간 이상합니다. build 명령에서 이 옵션을 사용할 수 있는 것 같습니다.

• run : 여기서 container 는 run 의미한다고 가정합니다. - https://github.com/docker/docker/blob/bb0a532fc21cb6b9390fb7e5eb0054bdc8045bbc/cli/command/container/opts.go #L485.
• build : https://github.com/docker/docker/blob/bb0a532fc21cb6b9390fb7e5eb0054bdc8045bbc/cli/command/image/build.go#L108.

더 단서가있는 사람이 왜 적용되지 않는지 알 수 있습니까?

@mbana --security-opt 는 "credentialspec"을 지원하는 기본 Windows 컨테이너용입니다. https://github.com/docker/docker/pull/23389

미래의 build 가 ptrace 활성화하도록 이것을 수정하고 지속되도록 할 수 있습니까?

여기에 관심이 있는 사람을 위해 다음과 같은 좋은 링크가 있습니다.

• http://www.projectatomic.io/docs/docker-building-images/ - 위에서 설명한 기술을 사용하여 이미지를 빌드하는 방법. 즉, 이미지에 run 를 build 합니다.
• https://blog.afoolishmanifesto.com/posts/how-to-enable-ptrace-in-docker-1.10/ - 기타

특정 권한이 부여된 작업을 요구하지 않도록 빌드를 변경할 수 있기 때문에 이 기능이 필요하지 않다는 다양한 사람들의 주장을 많이 보았지만 "도커의 도커" 경우에 대해 수행할 작업에 대한 제안은 없습니다. 빌드에서 docker 명령을 실행해야 하는 경우, 예를 들어 이 안에 포함하려는 일부 이미지를 풀다운하거나 하위 이미지를 빌드하려면 일종의 권한 없이 이 작업을 수행해야 합니다. 빌드 옵션?

지금은 docker run 및 docker commit 사용하여 이 문제를 해결하려고 하지만 docker build 가 이 사용 사례를 지원할 수 있다면 좋을 것입니다.

@scjody 당신이 원하는 것 같군요 #31257

@ cpuguy83 이 경우에 무슨 일이 일어나고 있는지 확실하지 않지만 병합되면 한 번

안녕하세요, 이 모자에 제 이름을 넣고 싶습니다. 아니면 누군가가 나를 가리킬 수 있는 내 문제(여기서는 docker noob)에 대한 다른 솔루션이 있습니까?

공식 centos/systemd 이미지를 기반으로 이미지를 빌드하고 Saltstack으로 프로비저닝하려고 합니다. 이것은 특권 모드 없이는 할 수 없는(AFAIK) systemd로 salt-minion 데몬을 시작(그리고 아마도 다시 시작)해야 합니다.

@onlyanegg 그런 상황에서 Saltstack은 빌더의 기능을 크게 대체한다고 생각합니다. 각 RUN 문은 새 컨테이너에서 실행되며 이 지점에서 이전 빌드 컨테이너가 중지되고 이미지/계층에 커밋됩니다.

컨테이너를 실행하고 결과를 커밋( docker commit )하여 빌드를 수행하는 것을 고려했습니까?

응답해 주셔서 감사합니다, @thaJeztah. RUN 지시문이 무엇인지 몰랐습니다. 나는 이 문제의 대부분을 읽었으므로 docker build -> docker run -> docker commit 해결 방법을 알고 있으며 이것이 결국 내가 할 일입니다. 내 이미지를 설명하는 단일 파일을 사용하는 것이 더 좋습니다. 더 깔끔해 보입니다. 아마도 나는 그 모든 단계를 패커 후처리기에 넣을 수 있고 그렇게 될 것입니다.

왜 이렇게 무시당하는 걸까요? 컨테이너, kubernetes, minikube, CI에서 docker 사용 및 개발 환경 통합 시대에 이 기능은 정말 중요합니다.

@onlyanegg 권한 모드 없이 RUN 명령은 특권 모드가 필요하기 때문에 작동하지 않습니다") 기꺼이 살펴보겠습니다!

@derberg 정확히! 컨테이너, CI, CD 시대에는 빌드 도구가 (보안적인 의미에서) 포함될 수 있는 것이 중요합니다. 권한 모드를 허용하면 Jenkins, Travis, Codeship 등과 같은 CI 도구를 사용하는 방식을 크게 변경해야 합니다. 동일한 질문: 권한 모드가 필요한 Dockerfile이 있는 경우 대안을 제안하기 위해 살펴보고 싶습니다.

감사합니다!

@jpetazzo는 내부에 도커가 있는 도커 이미지를 얻으려고 시도합니다.

FROM ubuntu:16.04

# Get dependencies for curl of the docker
RUN apt-get update && apt-get install -y \
    curl \
    sudo \
    bash \
    && rm -rf /var/lib/apt/lists/*

RUN curl -sSL https://get.docker.com/ | sh

이제 빌드하고 시작하십시오. 시작 후 service docker start 를 실행하여 도커 데몬을 시작합니다. 그런 다음 service docker status 서비스의 상태를 확인합니다.

• 권한 있는 플래그 상태는 정상이며 문제 없이 컨테이너를 시작할 수 있습니다.
• 플래그가 없으면 시작되지 않습니다

@jpetazzo ech, 방금 당신이 https://github.com/jpetazzo/dind의 제작자임을 알아차렸습니다 :) 그래서 당신은 도커 개념의 도커를 알고 있습니다 :)

어쨌든 실행하려면 특권 플래그가 필요하다는 것을 알고 있습니다. 이제 어떤 환경에서 작업하고 내부에 미리 구성된 일부 항목(예: 사전 설치된 구성 요소 또는 기타 요소가 있는 minikube)이 포함된 통합 개발 환경을 원하는 그룹을 상상할 수 있습니다.

그렇다면 docker build 에 NFS 또는 SMB 공유를 마운트하는 방법이 아직 있습니까?

@derberg 빌드 컨테이너가 --privileged 실행 중이더라도 해당 단계는 작동하지 않습니다. 도커 패키지(및 설치 스크립트)는 (예를 들어) Ubuntu 16.04에 커널 패키지를 설치합니다.
이것이 --privileged 가 docker build 대해 나쁜 생각인 이유입니다. 왜냐하면 _host_에서 변경할 수 있기 때문입니다.

docker는 _running_할 때 권한이 필요하지만 설치 자체에는 이것이 필요하지 않습니다. 예를 들어, 다음은 이미지에 도커를 설치하기 위해 실행하는 단계입니다.

docker build -t foo -<<'EOF'
FROM ubuntu:16.04

RUN apt-get update && apt-get install -y \
    apt-transport-https \
    ca-certificates \
    curl \
    software-properties-common \
    && rm -rf /var/lib/apt/lists/*

RUN curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
RUN add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu xenial stable"
RUN apt-get update && apt-get install -y docker-ce \
    && rm -rf /var/lib/apt/lists/*
EOF

그리고 당신은 그것을 잘 실행할 수 있습니다 (여기서 --privileged 를 사용하고 있지만 더 세분화된 권한이 가능합니다):

docker run -it --rm --privileged -v /var/lib/docker foo dockerd --debug

다음은 권한 모드에서 도커 이미지를 빌드해야 하는 사람들을 위해 이 문제를 우회하는 방법입니다. 모든 경우를 해결할 수는 없지만 일부 경우에는 도움이 될 수 있습니다.

이 방법에는 Dockerfile, docker-compse 파일 및 셸 스크립트가 필요합니다.

도커파일

이미지를 빌드하는 데 필요한 것과 동일합니다. 유일한 차이점은 권한 있는 작업을 수행해야 하는 위치에서 중지하고 포함하지 않는다는 것입니다. 스크립트로 docker-compose에서 실행해야 합니다. 예를 들어:

FROM ubuntu:16.04
RUN apt-get update && apt-get install <your packages>
# And more commands
......

## Below are the operations you intended to run in privileged mode when building the image, which does not work.
# More commands....
## But they now are moved to a separated shell script and it will be included in the image
COPY further-commands-to-run-in-privileged-mode.sh /

특권 모드에서 실행해야 하는 더 많은 명령은 이제 further-commands-to-run-in-privileged-mode.sh 있습니다. 이미지에 포함되어 있으며 나중에 docker composer에서 실행하여 빌드 프로세스를 완료합니다.

도커 작성 파일

작성 파일이 핵심입니다. 먼저 위의 Dockerfile에서 이미지를 빌드하고 권한 있는 모드 에서 해당 이미지의 컨테이너를 시작한 다음 권한 있는 작업을 수행할 수 있습니다. 예를 들어:

version: '3'

services:
  your_service:
    container_name: your_container
    # First build the image from the Dockerfile
    build:
      # Change this to where you keep above Dockerfile
      context: ../docker-build
    image: "your_image_name:your_image_tag"

    # Then start a container from the just built image in privileged mode to finish what's left
    entrypoint: /further-commands-to-run-in-privileged-mode.sh
    privileged: true

이미지 구축

아래 단계는 쉘 스크립트로 저장할 수도 있습니다.

# First build the image and container(in privileged mode)
docker-compose -f docker-compose.yml up

# Then commit the temporary build container to a new image, change the ENTRYPOINT to what you want
docker commit \
    -c 'ENTRYPOINT ["/bin/bash"]' \
    <build container name> \
    <final image name>:<final image tag>

# Remove the temporary build container
docker rm <build container name>

@thaJeztah 설치에 문제가 없습니다. 빌드 중에 도커 서비스를 시작하고 상자에서 꺼낸 이미지에서 사용할 수 있도록 일부 이미지를 가져오는 데 문제가 있습니다.

Dockerfile에 다음 스크립트를 추가하면 docker 서비스가 작동하지 않는 것을 볼 수 있습니다.

#!/bin/bash

service docker start

sleep 20

service docker status

docker pull busybox

@derberg 알겠습니다! _개인적으로_ dind 컨테이너에 이미지를 포함하려면 이미지를 다운로드하고(예: reg ) 컨테이너가 처음 시작될 때 이미지를 로드합니다. 왜요? 빌드하는 동안 이미지를 가져오면 _ dind 가 동일한 스토리지 드라이버로 시작된 경우에만 이미지가 작동하기 때문입니다. 즉, 이미지가 다른 컴퓨터에서 작동하거나 작동하지 않을 수 있습니다.

또한 이미지가 큰 경우(예: busybox 또는 alpine 이외의 다른 것) 정말 큰 DinD 이미지로 끝납니다...

나는 당신의 최종 사용 사례에 대해 더 알고 싶습니다. 왜냐하면 거대한 DinD 이미지를 굽는 것보다 더 효율적인 방법을 찾는 데 우리가 당신을 도울 수 있다고 확신하기 때문입니다 :-)

(그렇지 않으면 @kraml 이 제안한 솔루션이 오히려 우아합니다!)

https://github.com/moby/moby/blob/master/contrib/download-frozen-image-v2.sh 도 참조
bash+curl+tar만 사용하여 이미지를 다운로드합니다.
여기에서 사용합니다: https://github.com/moby/moby/blob/master/Dockerfile#L171

@jpetazzo 우리는 이미 빌드-런-커밋과 같은 해결 방법으로 실행하고 있지만, 내 관점에서는 여전히 해결 방법입니다. 사용 사례는 kubernetes 및 minikube 환경과 관련하여 매우 구체적이며 현재로서는 할 수 있는 것이 없습니다. 지금은 도커를 데몬으로 사용하여 도커에서 minikube를 시작할 수 있었고 virtualbox 또는 다른 vm 드라이버를 사용하면 작동하지 않으므로 dind 접근 방식에 의존합니다.

설치 프로그램이 sysctl 명령을 실행하려고 시도했지만 실패한 레거시 응용 프로그램(매우 일반적인 사용 사례)이 포함된 이미지를 빌드하려고 시도하는 중에 이 문제가 발생했습니다.

이 스레드로 돌아와 도커 빌드 명령에 일종의 권한 있는 기능을 추가하는 방법의 문제에 대해 4년 동안(!!!) 앞뒤로 검토한 결과 이 ​​상황에서 사용 가능한 옵션은 다음 중 하나입니다. sysctl 호출 또는 다단계 빌드 -> 실행 -> 커밋 파이프라인을 제거하기 위해 설치 프로그램을 수정하는 sed 명령의 불쾌한 무리. 나는 '빌드 -> 실행 -> 커밋'이 해결 방법으로 느껴진다는 @derberg의 말에 동의하고(총체적/해키 해결 방법) 내 사용 사례가 그렇게 독특하다고 생각하지 않습니다. 다른 스레드 확인 권한 부족으로 인해 실패한 docker build 명령으로 다양한 응용 프로그램 및 데이터베이스 설치와 관련된 문제를 보고하는 많은 사람들을 보았습니다.

이 시점에서 docker run 명령은 "--cap-add 및 --cap-drop을 사용하여 기능에 대한 세밀한 제어"와 함께 광범위한 '권한' 옵션을 지원합니다. 그래서 보안이나 기술적인 측면에서 반대하는 것은 말이 안 된다고 생각합니다. 권한 있는 실행 옵션이 '--cap-add' 및 '--cap-drop'과 함께 추가되면 보안에 민감한 엔지니어는 빌드에 필요한 특정 기능만 포함하도록 권한 있는 빌드를 제한하도록 선택할 수 있습니다.

안녕하세요 ,

나는 이미 같은 문제를 이전에 보고했습니다.

Docker를 패키징 도구로 사용하여 VM과 container에서 동일한 사용자 ID로 VM당 하나의 컨테이너를 실행하려는 사람들은 어떻습니까?

이와 관련된 보안 문제가 여전히 있습니까?

이 문제가 발생했습니다. 빌드 기능을 실제로 사용할 수 있습니다.

이 문제도 만났습니다.
슬레이브 도커 이미지를 빌드할 때 CI/CD 빌드/테스트 도구 체인을 설치하기 위해 docker build 에 대한 권한 있는 권한이 필요할 수 있는 CI/CD 슬레이브로 도커를 사용할 때 매우 유용합니다.
저는 이 기능을 몇 년 동안 기다리고 있으며 향후 지원될 수 있기를 진심으로 바랍니다.

--privileged for docker image와 관련하여 개발자들로부터 왜 그렇게 많은 반발이 있는지 정말 이해가 되지 않습니다.
사용자가 자신의 발에 총을 쏘고 싶다면 허용하지 않는 이유는 무엇입니까? 경고 메시지만 넣으면 끝입니다. 동일한 것을 달성하기 위한 해결 방법이 이미 있습니다. 실제로 필요한 사용자를 위해 더 쉽게 만들지 않겠습니까?
4~5년이 지났지만 아무런 진전이 없었습니다.
그냥 놀랍다...

오늘 현재 이 기능조차 아직 구현되지 않았습니다.
실행 --cap-add=SYS_PTRACE
많은 사용자의 요구에 맞는..

Gentoo Linux 호스트에서 이 Dockerfile을 빌드하는 방법을 제안해 주시겠습니까?

FROM gentoo/stage3-amd64
# Download and extract latest portage
RUN wget http://distfiles.gentoo.org/snapshots/portage-latest.tar.bz2 && \
    wget http://distfiles.gentoo.org/snapshots/portage-latest.tar.bz2.md5sum && \
    md5sum -c portage-latest.tar.bz2.md5sum 
RUN tar -xjvf portage-latest.tar.bz2 -C /usr
RUN emerge dev-lang/go

dev-lang/go를 이머징할 때 이 오류가 발생하기 때문입니다.

##### Building Go bootstrap tool.
cmd/dist
 * /var/tmp/portage/sys-apps/sandbox-2.12/work/sandbox-2.12/libsandbox/trace.c:_do_ptrace():75: failure (Operation not permitted):
 * ISE:_do_ptrace: ptrace(PTRACE_TRACEME, ..., 0x0000000000000000, 0x0000000000000000): Operation not permitted
/usr/lib64/libsandbox.so(+0xb692)[0x7fd10e265692]
/usr/lib64/libsandbox.so(+0xb778)[0x7fd10e265778]
/usr/lib64/libsandbox.so(+0x6259)[0x7fd10e260259]
/usr/lib64/libsandbox.so(+0x6478)[0x7fd10e260478]
/usr/lib64/libsandbox.so(+0x7611)[0x7fd10e261611]
/usr/lib64/libsandbox.so(execve+0x3f)[0x7fd10e2634ff]
bash[0x41d8ff]
bash[0x41f387]
bash[0x420138]
bash[0x4219ce]
/proc/330/cmdline: bash ./make.bash 

 * ERROR: dev-lang/go-1.9.2::gentoo failed (compile phase):
 *   build failed
 * 
 * Call stack:
 *     ebuild.sh, line 124:  Called src_compile
 *   environment, line 1034:  Called die
 * The specific snippet of code:
 *       ./make.bash || die "build failed"
 * 
 * If you need support, post the output of `emerge --info '=dev-lang/go-1.9.2::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=dev-lang/go-1.9.2::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/dev-lang/go-1.9.2/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/dev-lang/go-1.9.2/temp/environment'.
 * Working directory: '/var/tmp/portage/dev-lang/go-1.9.2/work/go/src'
 * S: '/var/tmp/portage/dev-lang/go-1.9.2/work/go'

--cap-add=SYS_ADMIN --device /dev/fuse 또는 --privileged 없이 어떻게 실행할 수 있습니까?

RUN apt-get -y install unionfs-fuse
RUN unionfs-fuse -o cow dir1=RW:dir2=RO dir3/

진입점에 별도의 bash 파일로 할 수 있지만 단일 Dockerfile이 필요합니다.

@amd-nick 빌드 중 RUN unionfs-fuse ... 라인에 대해 어떻게 예상하십니까? 그것이 작동하더라도 단일 RUN 동안에만 파일 시스템이 마운트되고 다음 단계에서 사라집니다.

@thaJeztah 설명하기 어렵습니다. 이 repo 를 수정하려고 합니다. 건물에서 이 줄을 건너뛸 수 있나요?

안녕하세요

무작위로 도커 빌드는 0부터 시작하는 호스트 이름을 선택하여 애플리케이션을 중단합니다. 그런 경우 DockerFile 내에서 "호스트 이름"을 실행하려고 시도했지만 동일한 문제에 직면했습니다.

또한 도커 빌드를 RUNP로 실행하거나 빌드 중에 호스트 이름을 선택하는 옵션을 갖고 싶습니다.

Kaniko로 이러한 종류의 이미지를 @maneamarius Mac 용 부두 노동자에의 Dockerfile로했다 그것을 당신이 Kaniko의 전화 한 번 성공적으로 구축 할 것 docker run 에 "빌드"명령 --cap-add=SYS_PTRACE . 그러나 결과 tarball을 로컬로 로드하는 데 약간의 문제가 있습니다. 오버레이를 사용할 수 없고 레이어 캐싱이 여전히 WIP이기 때문에 RAM 사용량이 약간 높습니다. 레지스트리에 푸시하면 문제가 해결될 수 있지만 아직 시도하지 않았습니다.

docker run --cap-add=SYS_PTRACE --rm -v $(pwd):/workspace gcr.io/kaniko-project/executor:latest --dockerfile=Dockerfile --context=/workspace --tarPath=/workspace/test.tar --destination=test  --single-snapshot

이 기능이 있으면 Puppet on Redhat/CentOS 기본 이미지를 통해 Docker 이미지를 빌드하는 데 큰 도움이 됩니다.

마지막으로 게시한 이후로 Kaniko 의 변경 사항을 확인 RUN 반복 저장 및 실행 작업이 없지만 alpine , ubuntu 및 인기 있는 베이스가 무엇이든).

내가의 @maneamarius을 구축 성공했습니다 곳은 상태에서의 젠투 이미지에 Golang 나온다 Dockerfile 의 Dockerfile 또는 자르고 그것을 어떤 식 으로든 (EDIT @maneamarius를 수정하지 않고이 프로젝트 / 데모를 '나는 이후했습니다 젠투 기본 이미지를 이 포스트 당시 latest 였던 버전으로 고정하기 위해 Dockerfile 를 수정해야 했습니다. 그렇지 않으면 여전히 수정되지 않은 상태입니다. ) :

https://github.com/nelsonjchen/kaniko-privileged-maneamarius-moby-1916

또한 --cap-add=SYS_PTRACE 를 사용하여 Kaniko를 사용하여 Dockerfile을 이미지로 빌드하고 Kaniko의 출력 tarball을 로드하고 생성된 이미지에서 go version 를 실행하도록 Azure Pipelines를 구성했습니다. 대화형 "생명 증명"이 재미있을 것이라고 생각했습니다. 여기에 있는 이전 의견 중 일부는 CI 시스템에 대해서도 우려했기 때문에 공개 CI 시스템도 작동하도록 구성해야 한다고 생각했습니다. BTW, Travis CI가 고려되었지만 빌드 출력이 너무 길어 종료되었고 Azure는 166k 라인의 출력에 완벽하게 만족합니다. Dockerfile이 약 70,000줄의 출력으로 빌드되었다면 Travis CI에서 성공했을 것입니다. Azure Pipeline 빌드 출력에 대한 링크는 README 상단에 있습니다.

빌다 루크 사용

이제 이 기능을 docker buildx build --allow security.insecure 로 사용할 수 있으므로 이 문제를 종료합니다.

https://github.com/docker/buildx/blob/master/README.md# --allowentitlement
https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/experimental.md#run ---securityinsecuresandbox

@AkihiroSuda buildx 를) 시도하기 위해 도커를 버전 19.03으로 업데이트했습니다. 언급 한 명령을 시도했을 때 오류가 발생했습니다.

$ docker buildx build --allow security.insecure -t sample-petclinic -f Dockerfile .
[+] Building 0.0s (0/0)                                                                                                                                                         
failed to solve: rpc error: code = Unknown desc = entitlement security.insecure is not allowed

Docker version :

Client: Docker Engine - Enterprise
 Version:           19.03.2
 API version:       1.40
 Go version:        go1.12.8
 Git commit:        c92ab06
 Built:             Tue Sep  3 15:57:09 2019
 OS/Arch:           linux/amd64
 Experimental:      true

Server: Docker Engine - Enterprise
 Engine:
  Version:          19.03.2
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.8
  Git commit:       c92ab06
  Built:            Tue Sep  3 15:55:37 2019
  OS/Arch:          linux/amd64
  Experimental:     true
 containerd:
  Version:          1.2.6
  GitCommit:        894b81a4b802e4eb2a91d1ce216b8817763c29fb
 runc:
  Version:          1.0.0-rc8
  GitCommit:        425e105d5a03fabd737a126ad93d62a9eeede87f
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

buildx 문서: For entitlements to be enabled, the buildkitd daemon also needs to allow them with --allow-insecure-entitlement

@AkihiroSuda 감사

다른 사용 사례를 추가하기 위해.
테스트 데이터베이스로 ibmdb2 컨테이너의 dockerfile 빌드를 수정하려고 합니다.
IBM은 허브에서 v10 이미지를 제거했습니다. 그러나 v11 DB 이미지는 --privileged로만 시작됩니다.
따라서 Dockerfile에서 데이터베이스를 설정하는 모든 코드는 이제 db2가 권한 없이 시작되지 않기 때문에 작동하지 않습니다. :(
docker run 및 docker commit을 사용하는 복잡한 해결 방법이 있는 것 같습니다.
생산적인 빌드 파이프라인에서 이것은 많은 추가 복잡성을 생성합니다.

내가 좋아하는 물어 봐야 https://github.com/maneamarius 에 https://github.com/moby/moby/issues/1916#issuecomment -361173550

이것을 지원하는 것이 왜 그렇게 큰 문제입니까? 빌드는 후드 아래에서 실행을 실행합니다.

이 특정 사용 사례에서 권한 있는 빌드 옵션은 일종의 "이전 버전 호환성"을 지원하며 웹 조사 후 이 문제를 겪은 사람이 나 혼자가 아니라는 것을 알고 있습니다.

@uvwild 이것이 귀하의 사용 사례에 도움이 되는지 확실하지 않지만 kaniko 로 빌드를 시도해 볼 수 있습니다. 이미지는 도커 데몬 없이 빌드되며 완료되고 kaniko를 사용하는 것은 컨테이너를 실행하는 것과 같습니다. 문제를 해결할 수 있는 --privileged 또는 --cap-add <capability which is needed> 사용할 수 있습니다.

나는 그것이 당신이 기대했던 완전한 솔루션이 아니라 당신의 빌드 파이프라인에 맞을 수 있는 더 쉬운 해결 방법이라는 것을 인정합니다.

편집: @alexey-vostrikov가 말했듯이 buildah 는 이미지를 빌드하는 데 --privileged 가 필요한 사용 사례에 더 적합한 솔루션이 될 수 있습니다.