당신은 그들을 체인 :)

예를 들어, 일반 postgres 클라이언트와 일반 python 앱 환경을 설정하는 Dockerfile이 하나 있는 경우 해당 빌드의 결과에 태그를 지정합니다(예: mygenericenv ). 그러면 후속 Dockerfile은 FROM mygenericenv .

예를 들어

## Dockerfile.genericwebapp might have FROM ubuntu
cat Dockerfile.genericwebapp | docker build -t genericwebapp -
## Dockerfile.genericpython-web would have FROM genericwebapp
cat Dockerfile.genericpython-web | docker build -t genericpython-web -
## and then this specific app i'm testing might have a docker file that containers FROM genericpython-web
docker build -t thisapp .

genericA --> specificA 와 같은 방법을 알 수 있지만 다음과 같은 작업을 수행할 수 있는 방법이 있습니까?

genericA --
            \
             ---> specificAB
            /
genericB --

?

공식적인 수단을 통하지 않았지만 일부 사람들은 운 좋게 이미지 계층 구조를 수동으로 수정하여 이를 달성했습니다(그러나 이렇게 하는 경우 모든 위험을 감수해야 하며 모든 조각을 유지하게 됩니다).

이것이 공식적으로 지원되지 않는 이유는 "우분투"를 사용하고 상단에 "centos"를 접목하고 싶다고 상상하기 때문입니다. 지원 악몽을 일으키는 정말 재미있는 갈등이 많이 있을 것이므로, 그런 일을 하고 싶다면 혼자 하세요.

알겠습니다. 이유를 알겠습니다. 구성 가능한 기능 블록을 찾고 있었지만 이것은 Docker 사용 사례가 아닐 수도 있습니다. 원시 컨테이너를 설정하는 데 사용하고 그 안에 소프트웨어를 구성하기 위해 상단에 가능한 또는 saltstack과 같은 것을 실행해야 하는 것 같습니다.

컨테이너 뒤에 있는 아이디어는 실제 구성의 가장 작은 단위가 컨테이너라는 것입니다. 즉, 컨테이너는 무엇과 결합될지 모르기 때문에 미리 생산할 수 있는 가장 작은 것이며, 다른 구성 요소와 어떻게 작동하고 상호 작용할지에 대한 강력한 보장을 가지고 있습니다.

따라서 컨테이너보다 작은 모든 단위(루비 또는 셸 스크립트, C++ 소스 트리, 자체 바이너리, 구성 파일 세트, 시스템 패키지 등)는 다음과 같이 동작하므로 안전하게 구성할 수 없습니다. 빌드 종속성, 런타임 종속성 및 컴포지션의 일부인 기타 구성 요소에 따라 매우 다릅니다.

그 현실은 무차별 대입으로 부분적으로 가려질 수 있습니다. 이러한 무차별 대입은 실용적이고 "충분히 좋은"(앱의 더 이식 가능한 빌드를 위해 모든 것을 자동 감지하는 거대한 Makefile) 또는 지나치게 거창할 수 있습니다("구성 요소 간의 모든 종속성 및 간섭의 가능한 모든 순열을 미리 모델링하고 높은 수준의 추상화로!")

Ansible, Chef 또는 기타 구성 관리에 의존하여 "구성 가능한 구성 요소"를 생성하는 경우 누수 추상화에 의존하는 것입니다. 이러한 구성 요소는 실제로 구성할 수 없습니다. 한 시스템에서 다음 시스템으로 백만 가지 방식으로 다르게 작동하는 빌드를 생성합니다. 결국 모든 추가 추상화는 당신에게 거의 이득이 되지 않을 것입니다.

제 조언은 1) 소스 코드, 2) 실행 가능한 컨테이너의 두 가지에 중점을 두는 것입니다. 이것들은 신뢰할 수있는 유일한 2 가지 구성 요소입니다.

2013년 12월 29일 일요일 오후 1시 46분, anentropic [email protected]
썼다:

알겠습니다. 이유를 알겠습니다. 구성 가능한 기능 블록을 찾고 있었지만 이것은 Docker 사용 사례가 아닐 수도 있습니다. 원시 컨테이너를 설정하는 데 사용하고 그 안에 소프트웨어를 구성하기 위해 상단에 가능한 또는 saltstack과 같은 것을 실행해야 하는 것 같습니다.

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

더 많은 관점을 제공해주셔서 감사합니다.

Dockerfiles의 일부를 재사용하기 위해 사용할 수 있는 유일한 도구는 복사하여 붙여넣기라는 말씀이신가요? '운영'보다 '개발'의 관점에서 보면 약간 잘못된 느낌이 듭니다.

이미지의 공개 색인을 갖는 것이 실수일 수도 있고, Chef 레시피와 모호하게 유사한 재사용 가능한 빌딩 블록을 공유할 수 있는 것처럼 보이지만 지금까지 내 경험에 따르면 다음과 같은 이유로 유용하지 않습니다.
) 대부분의 이미지에는 이미지가 수행하는 작업과 내부에 대한 정보가 없습니다.
b) 문서는 작업을 인덱스에 커밋하도록 권장합니다(나중에 가져올 수 있음). 비록 당신이 만든 것이 다른 사람들에게 유용하지 않을 수도 있지만, 거기에 있는 대부분의 내용은 아마도 공유할 가치가 없을 것입니다.

문서가 현재 Docker를 합리적인 방법으로 사용하도록 안내하지 않는 것 같습니다.

@anentropic Dockerfile을 사용 하여 이를 수행하는 올바른 방법은 여러 Dockerfile로 여러 이미지를 빌드하는 것입니다.
다음은 예입니다. Dockerfile 1은 Ubuntu 기본 이미지 위에 일반 이미지를 빌드하고, Dockerfile 2는 Dockerfile 1의 결과 이미지를 사용하여 데이터베이스 서버용 이미지를 빌드하고, Dockerfile 3은 데이터베이스 서버 이미지를 사용하여 특수 역할에 대해 구성합니다. .

docker build 는 실행하기 매우 쉬워야 하고 불필요한 복잡성이 추가되어서는 안 됩니다.

이미지의 공개 색인은 매우 유용합니다. Docker 이미지는 일반적으로 별도의 컨테이너에서 실행할 수 없는 하나의 서비스 또는 여러 서비스를 실행하기 위한 것입니다. 일반적으로 많은 노력 없이 이미지를 가져와서 실행하고 유용한 소프트웨어를 설치하고 실행할 수 있습니다.

이해했습니다 ... 위의 ASCII 아트로 요약 한 시나리오에서 Docker 방식은 다음과 같습니다.

• 독립 이미지 GenericA 및 GenericB 용 Dockerfile로 시작
• 이미지로 만들려면 SpecificAB 내가 복사의 내용을 붙여 것 GenericB 새로운 Dockerfile에 Dockerfile을 그와 함께 시작 : FROM GenericA

내가 보는 문제는 GenericB 대한 '레시피'(Chef 용어를 빌리기 위해)가 매우 복잡하고 많은 단계가 있는 경우 Dockerfile을 Github_에 게시하는 것 외에는 이 정보를 공유할 수 있는 방법이 없다는 것입니다. 다른 사람들이 관련 부분을 자신의 Dockerfile에 _복사 및 붙여넣기_할 수 있습니다.

공개 인덱스를 사용해 보셨습니까? 예를 들어, "postgres"를 검색했습니다... 다음과 같은 이미지의 유용성을 어떻게 판단(또는 구별)합니까:

• https://index.docker.io/u/ctulhuology/postgres/
• https://index.docker.io/u/alvin/postgres/
• https://index.docker.io/u/antihero/postgres/
• https://index.docker.io/u/dbraden/postgres/

?

내가 원하는 방식으로 Postgres 서버를 설정했는지 확인할 수 있는 유일한 방법이 특별한 기본 이미지에 아무 것도 숨겨져 있지 않은 상태에서 처음부터 직접 만드는 것일 때 이것이 제공하는 가치는 무엇입니까?

공개 색인에서 일부 '공식적으로 축복받은' 기본 이미지의 가치를 볼 수 있습니다. 가져올 준비가 된 나만의 사용자 지정 이미지에 대한 개인 색인을 보유하는 것의 가치를 알 수 있습니다.

그러나 여기 https://github 에서 거부된 '포함' 명령에 대한 제안과 같이 Dockerfile의 일련의 명령을 레시피로 공유할 수 있는 방법(복사 및 붙여넣기 제외)이 없는 것이 부끄러운 것 같습니다.

@anentropic 신뢰할 수 있는 이미지를 사용할 수 있으며 postgres Dockerfile을 찾아 이미지를 직접 빌드할 수도 있습니다.

이미지는 일반적으로 정확한 요구 사항에 맞도록 Dockerfile을 사용자 지정할 때 더 유용합니다. 그래서 더 많은 사용자가 동일한 소프트웨어에 대한 이미지를 레지스트리에 업로드했다는 사실을 알게 되었습니다.

postgres 이미지와 같은 기존의 특정 이미지는 특정 요구 사항을 충족하지 못할 수 있지만 기본 이미지도 있으며 사용자에게 유용한 것을 구축하는 데 바로 사용할 수 있습니다.

ubuntu , centos 및 stackbrew/* 일부 이미지는 필요한 것을 구축하는 데 사용할 수 있는 이미지입니다.

바로 사용할 수 있는 이미지의 예는 stackbrew/registry 입니다. 이 이미지를 사용하면 docker pull stackbrew/registry 및 docker run -p stackbrew/registry 실행이 완료되는 즉시 개인 Docker 레지스트리를 가지고 놀 수 있습니다.

Docker의 목표는 배포를 돕고 소프트웨어가 실행되는 환경을 준비하는 것입니다. 이는 빌드가 선형이고 초기 빌드 중에만 수행되지만 매번 똑같은 소프트웨어를 실행한다는 것을 의미합니다.

구성 관리 시스템을 사용하면 더 많은 작업을 수행하거나 다른 트릭을 사용할 수 있지만 "불변"하지 않으며 구성 관리 소프트웨어에서 포착하지 못하는 미묘한 차이가 있는 두 개의 호스트를 갖게 될 수 있습니다.

오래된 스레드를 necro하는 것을 싫어하지만 IMHO가 원본 포스터 문제를 해결하는 데 도움이 되고 다른 사람들이 여기에서 이 문제에 대한 유사한 솔루션을 찾는 데 도움이 될 수 있는 것을 제공하고 싶었습니다.

단순화를 위해 모두 동일한 기본 이미지 R 사용한다고 가정하겠습니다. A 서비스와 B 서비스가 있다고 상상해보십시오. 나는 그것들을 별도의 Docker 이미지와 동일한 Docker 이미지에 모두 원합니다.

A 서비스를 설치하는 스크립트를 작성하고 B 서비스를 설치하는 별도의 스크립트를 작성하십시오. 그런 다음 A 스크립트와 B 스크립트가 포함된 git repo가 ​​있습니다. 빌드될 3개의 Docker 이미지 모두에 대한 git repos를 만듭니다. 각각에는 사용될 설치 스크립트가 있는 git 하위 모듈이 포함되어 있습니다. 각 Dockerfile은 단순히 설치 스크립트를 ADD 한 다음 설치 스크립트를 RUN 하고 하나 또는 두 스크립트 모두에 대해 이 작업을 수행합니다. 이미지에서 스크립트를 제거하려면 스크립트를 실행한 후 고정하세요.

이렇게 하면 각 설치 스크립트의 사본 하나와 이를 사용하려는 도커 이미지가 있습니다. 이렇게 하면 불필요한 코드 복사를 방지하고 유지 관리 부담을 최소화할 수 있습니다. 노력의 유일한 중복은 하위 모듈에서 사용하는 커밋을 위로 옮기는 것입니다. 이는 대안보다 훨씬 우수하고 자동화될 수 있습니다.

작동 원리를 잘못 이해하고 있는 것 같아서 설명을 위해 답글을 답니다. 공식 셀레늄 도커 이미지와 함께 Ubuntu 11을 사용하고 싶습니다. 그들은 우분투 15를 사용합니다.

https://github.com/SeleniumHQ/docker-selenium/blob/master/Base/Dockerfile

이 작업을 수행하는 올바른 방법은 무엇입니까? 해당 저장소를 복제하고 모든 파일을 15가 아닌 Ubuntu 11로 편집하려면? 이것은 옳을 수 없습니다, 그렇죠? 이는 공식 이미지의 모든 측면에 대해 동의하지 않는 모든 사람이 코드를 복제하지 않고는 사용할 수 없음을 의미합니다. 제가 잘못 알고 있는 것 같은데요, 누가 설명 좀 해주실 수 있나요? Ubuntu 11에서 공식 셀레늄 이미지를 사용하는 올바른 방법은 무엇입니까?

@rjurney 네, 그렇게 하면 됩니다. 귀하의 예에서 전체 Dockerfile은 ubuntu:15.04 를 염두에 두고 개발되었습니다. ubuntu:11 에서 해당 패키지를 사용할 수

Docker는 기본 이미지와 이미지 간의 _differences_만 저장하기 때문에 기존 이미지의 기본 이미지를 "교체"하는 것도 작동하지 않습니다. 따라서 다른 기본 이미지를 사용하면 예측할 수 없는 결과가 발생합니다(예: "파일 X 제거", 여기서 "파일 X"는 원래 기본 이미지에 있지만 선택한 기본 이미지에는 없음). 또한 기본 이미지의 "위에" 빌드되는 이미지의 패키지/바이너리는 _that_ 버전용으로 빌드된 패키지이며, 이러한 바이너리는 다른 기본 이미지와 호환되지 않을 수 있습니다.

이는 공식 이미지의 모든 측면에 대해 동의하지 않는 모든 사람이 코드를 복제하지 않고는 사용할 수 없음을 의미합니다.

예. 공식 이미지는 해당 이미지의 유지 관리자(이 경우 Selenium의 유지 관리자)가 지원합니다. 해당 이미지에 변경이 필요하다고 생각되면 가장 좋은 방법은 해당 저장소에서 기능 요청을 여는 것입니다. 해당 기능 요청이 수락되지 않으면 고유한 버전을 빌드해야 합니다.

(또한 공식 ubuntu:11 이미지가 없음을 유의하십시오)

나머지 소프트웨어 세계에서 단일 상속은 다음과 같이 간주되지 않습니다.
필요한 의미를 합리적으로 표현하기에 적합합니다. 많은 코드로 이어집니다.
버그로 간주되는 중복. 이게 왜 이렇게 보여
도커에 허용됩니까? 한 번에 하나의 서비스를 구축하더라도
구성은 운영 체제 수준에서 필요합니다. 이기려는게 아니야
죽은 말이지만 이 한계는 약간 극단적인 것 같습니다. 더 나을지도
모범 사례로 표현되었습니까? 이러한 엄격함의 결과로
결정, 누군가는 구성 또는 다중 작업을 수행하는 도구를 만들 것입니다.
상속하고 단일 상속과 복제를 통해 표현합니다.
이것을 도커 외부에 적절하게 사용하면 도커 커뮤니티에 도움이 되지 않습니다.

2015년 12월 9일 수요일, Sebastiaan van Stijn <
[email protected]>은 다음과 같이 썼습니다.

@rjurney https://github.com/rjurney 예, 그것이 작동하는 방식입니다. ~에
귀하의 예에서 전체 Dockerfile은 ubuntu:15.04 를 염두에 두고 개발되었습니다.
ubuntu:11 에서 해당 패키지를 사용할 수
그들에? Dockerfile에서 수정해야 할 가능성이 있습니다.
다른 버전의 Ubuntu에서 작동하도록 합니다.

기존 이미지의 기본 이미지 "교체"도 작동하지 않습니다.
Docker는 기본 이미지와
영상. 따라서 다른 기본 이미지를 사용하면 예측할 수 없는 결과가 발생합니다.
결과(예: "파일 X 제거", 여기서 "파일 X"는 원래 베이스에 있음)
이미지이지만 선택한 기본 이미지에는 없음). 또한 패키지/바이너리
기본 이미지의 "위에" 빌드하는 이미지에서 빌드되는 패키지는
_that_ 버전의 경우 해당 바이너리가 다른 버전과 호환되지 않을 수 있습니다.
기본 이미지.

이것은 모든 측면에 대해 동의하지 않는 모든 사람을 의미합니다.
공식 이미지는 코드를 복제하지 않고는 사용할 수 없습니다.

예. 공식 이미지는 해당 이미지의 관리자가 지원합니다.
(이 경우 Selenium의 유지 관리자입니다). 변화를 생각한다면
이러한 이미지에 필요한 경우 가장 좋은 방법은 다음에서 기능 요청을 여는 것입니다.
그들의 저장소. 해당 기능 요청이 수락되지 않으면 다음을 수행해야 합니다.
아마도 자신의 버전을 빌드하십시오.

(또한 공식 ubuntu:11 이미지가 없음을 유의하십시오)

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

러셀 저니 twitter.com/rjurney russell. [email protected] relato.io

@rjurney 다중 상속은 결과, 코너 케이스 및 비호환성에 대해 생각하지 않고 추가하는 것뿐만 아니라 매우 복잡합니다.

12749는 이러한 기능을 추가하려는 가장 최근의 시도였습니다. 먼저 수행해야 할 다른 작업이 있기 때문에 결국 거부되었습니다.

이것을 상당히 개방할 수 있는 클라이언트 기반 빌드를 활성화하는 것을 포함하여 빌더에서 수행 중인 많은 작업이 있습니다.

단일 상속 Dockerfiles는 (광범위한) 대부분의 사용 사례에서 작동하므로 이를 향상시키기 위해 서두를 필요가 없습니다. 정확하고 의도적으로 수행해야 합니다.
그리고 위의 의견에 따르면 실제로 다중 상속이 필요하지 않으며 기존 코드를 복제하지 않고 Dockerfile이 실행되는 기본 이미지를 지정하는 방법일 뿐입니다.

그것은 내 필요를 충족시킬 것입니다. 네. 일부 속성을 수정할 수 있음
dockerfile 체인.

좋아, 당신이 이것의 꼭대기에 있다는 소식을 들으니 기쁩니다. 기다려 주셔서 감사합니다 :)

2015년 12월 9일 수요일 오전 9시 59분에 Brian Goff [email protected] 은 다음과 같이 썼습니다.

@rjurney https://github.com/rjurney 다중 상속도
매우 복잡하며 아무 생각 없이 추가하는 것이 아닙니다.
결과, 코너 케이스 및 비호환성을 위해.

12749 https://github.com/docker/docker/pull/12749 가 최신이었습니다.

이러한 기능을 추가하려는 시도 -- 결국 거부됨
먼저 해야 할 다른 작업.
활성화를 포함하여 빌더에서 수행 중인 많은 작업이 있습니다.
이것을 꽤 많이 열 수 있는 클라이언트 주도 빌드.

단일 상속 Dockerfile은 대부분의 사용 사례에서 작동합니다.
따라서 이것을 향상시키기 위해 서두를 필요가 없습니다. 올바르게 수행해야 하고
고의로.
그리고 위의 의견을 바탕으로 실제로 여러 번 필요하지 않다고 말하고 싶습니다.
상속, Dockerfile이 실행되는 기본 이미지를 지정하는 방법
기존 코드를 복제하지 않고 반대합니다.

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

러셀 저니 twitter.com/rjurney russell. [email protected] relato.io

@rjurney 정보는 어디서 얻

내가 보기에 docker에 필요한 것은 다중 상속의 개념이 아니라 포함 또는 외부 종속성의 개념입니다. 예를 들어 런타임에 컨테이너를 마운트할 수 있습니다. 진정으로 필요한 것은 이미지와 동등한 방법입니다. 따라서 예를 들어 Fedora 22를 기반으로 정의된 이미지가 있고 Oracle 이미지를 탑재하여 데이터베이스 기능을 추가할 수 있습니다.

이것은 컨테이너를 실행할 때 매우 성공적으로 수행할 수 있지만 이미지로 지정하는 구문이 없습니다. 따라서 런타임까지 docker가 이러한 종속성에 대해 알거나 어쨌든 관리할 수 있는 방법이 없습니다.

다중 상속 및 구성에 대해 언급했습니다.
컴포지션은 확실히 이를 수행하는 데 선호되는 방법입니다.

나는 당신이 말한 다른 모든 것에 동의하므로 +1.

2015년 12월 9일 수요일, Bill C Riemers [email protected]
썼다:

@rjurney https://github.com/rjurney 정보는 어디서 얻나요 ?
내가 아는 한 Java에는 다중 상속이 없었고 앞으로도 없을 것입니다.
많은 언어에서도 마찬가지라고 확신합니다. 많은 사람들이 여러 가지를 고려합니다.
상속이 거의 불가능할 수 있으므로 매우 유해합니다.
예측 가능한 코드 도커 컨테이너의 경우에도 마찬가지입니다.

내가 볼 때 docker에 필요한 것은 다중 개념이 아닙니다.
상속이지만 포함 또는 외부 종속성의 개념입니다. 예
런타임에 컨테이너를 탑재할 수 있습니다. 진정으로 필요한 것은
이미지와 동등합니다. 예를 들어
Fedora 22 기반으로 정의되었으며 추가할 Oracle 이미지를 마운트합니다.
데이터베이스 기능.

이것은 컨테이너를 실행할 때 매우 성공적으로 수행할 수 있지만
이미지로 지정하는 구문이 없습니다. 따라서 런타임까지
docker가 이러한 종속성에 대해 알거나 어쨌든 관리할 수 있는 방법
너.

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

러셀 저니 twitter.com/rjurney russell. [email protected] relato.io

이쯤되면 입 다물겠지만, 실수로 이 티켓 대신에 앞서 언급한 풀 리퀘스트에 이 욕설을 넣었습니다. 그래서 여기에 올립니다.

누군가 이것을 구축할 것입니다. INCLUDE를 추가하는 pull을 수락하지 않으면 이 기능이 지연되고 구체화됩니다. 이것은 여기에서 결정의 기초가 되어야 합니다. 이것은 도커 내부에 있어야 합니까 아니면 도커 외부에 있어야 합니까?

한 가지 예가 떠오릅니다. Apache Pig에서 팀은 루프에 대한 많은 요청에도 불구하고 루프를 포함하지 않기로 결정했습니다. Pig가 DAG 데이터 흐름에 적합해야 하고 그것이 전부이기 때문입니다. 대신, pig 스크립트를 스크립팅하기 위해 통합이 생성되었으므로 모든 JVM 언어에서 스크립트를 반복할 수 있습니다. 이것은 의식적인 결정이었고 대안을 추구했다는 점에 유의하십시오. 이것이 내가 생각하는 모델 프로세스입니다.

또 다른 돼지의 예가 떠오릅니다... 돼지 매크로. 그들은 존재하지 않았고 누군가(좋아, 나)가 그들의 대형 돼지 프로젝트가 얼마나 믿을 수 없을 정도로 추악하고 외부 도구에서 Pig를 생성하지 않고는 이 문제를 해결할 방법이 없다는 스레드를 시작하기 전까지 '돼지'였습니다. 탐탁지 않은. 많은 사람들이 소리쳤고 Pig 팀은 매크로를 추가했습니다. 매크로는 깨끗한 돼지를 가능하게 하고 커뮤니티는 혜택을 받았습니다.

나는 당신이 결정을 정면으로 다루고 그것에 대해 논의할 것을 제안합니다. 이것은 아직 여기에서 발생하지 않았으며, 검색 가능성을 위해 아마도 여기에 속할 것입니다. 이것은 존재할 것입니다. 도메인 특정 언어로 스크립트를 복제하는 것은 끔찍합니다. 국민이 요구할 것입니다. 이 기능은 Docker 내부에 있습니까 아니면 Docker 외부에 있습니까? 도커 외부에서 이 동작을 어떻게 용이하게 할 것인가?

죄송합니다. 메일링 목록에 많은 컨텍스트가 누락되어 있을 수 있지만 새로운 Docker 사용자로서... 기존 레시피에서 dockerfile을 구성할 수 있는 기능 없이 Docker로 많은 작업을 수행하는 것이 매우 주저합니다. 나는 돼지와 함께 이 길을 갔고, 거의 죽을 뻔했다. 많은 분들이 이렇게 느끼실 거라 생각합니다.

혹시라도 신경쓰시는 분이 계시다면...

Pig의 루프 및 매크로에 대한 반쯤 채택된 프레젠테이션: http://wiki.apache.org/pig/TuringCompletePig
돼지 매크로 JIRA: https://issues.apache.org/jira/browse/PIG-1793
Pig JIRA에 대한 API 인터페이스: https://issues.apache.org/jira/browse/PIG-1333
Apache Hive를 존중하기 위해 완전히 거부된 것... Pig에 SQL 추가: https://issues.apache.org/jira/browse/PIG-824

마지막으로 이 변경을 쉽게 할 수 있는 아이디어가 있었습니다... INCLUDE의 파일을 상속할 수 없다면 어떻게 될까요? 즉, 매우 단순하게 유지함으로써 반대를 피할 수 있습니다. 나중에 더 많은 것을 알게 되면 나머지를 처리하십시오. 예를 들어 사전 요구 사항 및 바이너리를 설치하고 Ubuntu에서 MySQL용 데몬을 설정하는 간단한 Dockerfile이 있을 수 있습니다. 필요한 경우 Ubuntu 및 MySQL 버전별로 버전을 지정할 수 있습니다. 개인적으로 나는 이러한 간단한 INCLUDE를 수행하는 유틸리티를 해킹하고 이를 사용하여 내 dockerfile을 이런 방식으로 구성할 것입니다. 내 코드를 주문하고 재사용할 때까지 기다릴 수 없습니다.

INCLUDE 아이디어에 대해 +1입니다. 상속을 금지하면 문제가 바뀔 뿐이라고 생각하지만 이제 상속받는 주류 이미지는 수정할 수 있지만 포함하는 다른 이미지는 수정할 수 없습니다. 기본적으로 기존 기본 이미지 항목을 손상시킬 수 있는 운영 체제 항목을 제공하지 않는다는 점에서 이미지를 "포함 가능"으로 지정할 수 있다면 의미가 있습니다. 이 플래그는 도커 빌드 프로세스에서 설정해야 하며 적절하게 플래그가 지정되지 않은 이미지가 포함되는 것을 방지합니다. 그리고 내 말은 그것을 직면하자는 것입니다. Dockerfiles를 가지고 놀고 있다면 아마도 처음으로 그의 컴퓨터를 보는 사람이 아닐 것이므로 docker의 최종 사용자가 어리석은 일을 하는 것을 방지하는 것이 합리적이지만 조금 더 있어야 합니다. 실제로 그런 이미지를 만드는 사람들을 위한 자유. 진심으로, 기본 이미지를 선택할 수 있고 내 앱을 프로비저닝하기 위해 기본 이미지에 원하는 모든 항목을 포함할 수 있다는 것은 정말 대단할 것입니다.

포함에 대해 +1. nginx와 ssh 이미지를 하나로 결합하면 됩니다. 왜 이것이 그렇게 어려워야 합니까?

이것이 필요하지 않다는 생각은 솔직히 말해서 혼란 스럽습니다.
솔직하지 못한. 생성된 경우 대부분의 사용자가 이를 사용합니다. "에 ssh 추가
우분투" 및 "우분투에 nginx 추가"는 모든 사람이 수행하는 매우 일반적인 작업입니다.
반복할 필요가 없습니다. docker HQ가 실제로 이것에 대해 말하는 것 같습니다.
"당연히 필요하지만 너무 추해질 것 같아서 우리가 가장합니다." 그것
이것에 대해 실제로 정직하고 공개할 수 있다면 더 좋을 것입니다.
내가 미쳤다면 죄송합니다.

2016년 1월 23일 토요일 오후 6시 22분에 Vazy [email protected]에서 다음과 같이 썼습니다.

포함에 대해 +1. nginx와 ssh 이미지를 하나로 결합하면 됩니다. 왜
이게 그렇게 어려워야 합니까?

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

러셀 저니 twitter.com/rjurney russell. [email protected] relato.io

@rjurney 빌드 스핀아웃을 기다리자 ; 이렇게 하면 이미지를 빌드하는 방법이 두 가지 이상 있기 때문입니다(따라서 이를 수행하는 사용자 정의 빌더가 나타날 수 있음). 도커 유지 관리자(도커에서 작동하거나 작동하지 않음)가 이에 대해 성가신 이유 중 하나는 유연성과 단순성을 추가하려는 곳에 복잡성이 추가되기 때문입니다. 빌더를 추출함으로써 우리는 (이미지 빌드와 이미지 실행 사이) 더 나은 문제 분리를 갖게 될 것이고 많은 사용 사례가 커스텀 빌더에서 더 자유롭게 구현될 것입니다.

여기서 다시, 당신은 이것을 프로젝트에서 밀어내고 있습니까? 커스텀 사운드... 아님
기본, 포함된 방법. 사실, Include는 다음과 같은 단순한 요구 사항입니다.
대부분의 모든 사람이 가지고 있습니다. 자신을 반복하는 것은 복잡성입니다. 상속만이
복잡성. 가장 간단한 방법으로 모든 사람이 필요로 하는 것을 포함합니다.
가능한.

2016년 1월 24일 일요일 Vincent Demeester [email protected]
썼다:

@rjurney https://github.com/rjurney 빌드 스핀아웃을 기다리자 ;
이렇게 하면 이미지를 빌드하는 방법이 두 가지 이상 있기 때문입니다(따라서
이를 수행하는 사용자 정의 빌더가 나타날 수 있음). 이유 중 하나는 도커
유지 관리자(Docker에서 작동하거나 작동하지 않음)는 이에 대해 까다롭습니다.
유연성을 추가하려는 경우 복잡성이 추가되고
간단. 빌더를 추출하면
(이미지 빌드와 실행 사이) 및 많은 사용 사례
커스텀 빌더에서 더 자유롭게 구현됩니다.

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

러셀 저니 twitter.com/rjurney russell. [email protected] relato.io

+1, 이미지를 결합하면 매우 유용합니다. (신이 금지한) C++ 사용 사례를 상상해 보십시오. 저는 boost를 사용하여 상상을 만들고, Qt를 사용하여 상상하고, 모두 동일한 컴파일러를 사용하는 등의 작업을 수행합니다. 이제 boost와 Qt를 모두 사용하여 앱을 빌드하고 싶다고 가정해 보겠습니다. 두 가지와 presto를 결합하기만 하면 개발 환경이 준비됩니다. 이것은 매우 유용할 것입니다.

개인적으로 이 문제는 다루지 않는 것이 너무 중요하다고 생각합니다. 즉, 구현 위치에 관계없이 문제와 범위가 무엇인지 잘 이해해야 합니다.

따라서 병합으로 인해 이러한 문제가 나타납니다.

1. 병합 충돌 처리.
2. 다른 기반 해결(Ubuntu 및 CentOS).

첫 번째 경우 간단한 대답은 하지 않는 것입니다. 나에게 그것은 복잡하고 잠재적으로 문제가 있는 것처럼 들리며 해결하려면 도구 모음이 필요하지만 여전히 너무 마술적일 수 있습니다. 따라서 이것이 추가되면 병합 충돌이 실패해야 합니다. 나중에 다시 볼 수 있을 것 같지만, 그게 가치보다 더 문제인 것 같습니다.

두 번째 경우에는 일부 기본 레이어를 공유하는 제약 조건을 추가할 수 있을 것 같습니다. 이제 문제는 몇 개로 충분하냐는 것입니다. 시작할 때 정답은 병합되는 두 개의 이미지가 동일한 FROM 이미지를 가져야 한다고 생각합니다. 여기에 더 많은 제약 조건이 필요할 수 있지만 이러한 경우가 단순히 허용하지 않음으로써 해결된 문제 1에 속하지 않을 것인지는 분명하지 않습니다.

여기에 내가 놓친 다른 문제가 있습니까?

병합 시도가 없어야한다고 생각합니다 ... 그런 일이 일어나는 것을 볼 수 없습니다

보다 현실적인 접근 방식은 템플릿 유형의 솔루션일 수 있습니다. 즉, Dockerfile _fragment_( FROM 절이 없고 명령 목록만 있음)를 실제 Dockerfile에 INCLUDE 허용하는 것입니다. 호환 가능한 기본 이미지 Dockerfile에 대해 조각을 공유, 재사용 및 포함할 수 있습니다.

http://docktitude.io

저는 Docker를 처음 접하고 겸손하게 배우고 있습니다. 하지만 Docker의 요점은 매우 작은 _재사용 가능한_ 응용 프로그램을 빌드하여 나중에 어떤 방식으로든 웹 응용 프로그램에서와 같이 큰 최종 응용 프로그램으로 결합하는 것이라고 생각했습니다. 그렇다면 INCLUDE 와 같은 IMHO 문은 필수입니다.

@jmcejuela 많은 경우 "재사용"은 특정 서비스 전용 이미지를 만들고 해당 이미지/컨테이너를 결합하여 애플리케이션을 구성하는 것입니다. 응용 프로그램의 개별 구성 요소는 재사용할 수 있지만(컨테이너의 구성만 다를 수 있음) 이러한 구성 요소를 결합하는 방법이 실제 응용 프로그램을 형성합니다.

@thaJeztah 이해합니다. 감사합니다.

하지만 이전에 게시한 사람들처럼 구체적으로 만들면 스칼라 애플리케이션을 실행하는 웹 앱을 빌드하고(image A ), nginx로 웹 서버를 만든 다음(image B ) ssh가 있습니다. (image C ) 및 추가 Python 응용 프로그램이 필요합니다(image D ). 각각에 대해 4개의 Dockerfile을 생성했다고 가정해 보겠습니다. 이들을 Docker와 결합하여 최종 웹 앱을 생성하려면 어떻게 해야 합니까(image E ?)

이 작업을 수행하는 간단한 방법이 필요합니다. 나는 다중 상속, 포함 여부, 작성 여부 등에 대한 철학 논쟁에 관심이 없습니다. 물론 이전에 제안된 대로 복사 및 붙여넣기를 하고 싶지는 않습니다.

시간 내주셔서 감사합니다. 나는 여전히 도커를 배우고 있다.

@jmcejuela _images_ 를 결합하지 않고 별도의 컨테이너로 실행하고 협력하여 응용 프로그램을 구성하도록 합니다. "스택"을 정의할 수 있는 Docker Compose를 사용하여 그렇게 할 수 있습니다. 예를 들어 https://github.com/docker/example-voting-app/blob/master/docker-compose.yml (및 README, https://github.com/docker/example-voting-app/ 블롭/마스터/README.md)

"ssh" 부분의 경우 실제로 사용하려는 용도에 따라 다릅니다. 전반적으로 컨테이너는 "불변"으로 간주되므로 컨테이너로 ssh하여 수정하지 않고 새 컨테이너를 실행하여 이전 컨테이너를 교체합니다. 컨테이너의 수명 주기를 넘어 지속되어야 하는 데이터는 새 컨테이너가 해당 파일을 사용할 수 있도록 볼륨에 저장됩니다.

@jmcejuela Docker 빌더는 STDIN에서 Dockerfile 내용을 허용하므로 "상대적으로" 쉽게 생성할 수 있습니까? 컨텍스트가 전달되어야 하는 경우 모든 것이 tarred되고 docker build 공급되어야 합니다. 내 경험에 따르면 이것은 구성을 얻는 가장 간단한 방법입니다.

나는 개발 (와 함께 연주) 위의 개념 떨어져 빌드 접근 방식을. nodejs 애플리케이션은 메모리에서 TAR 파일( Dockerfile 및 추가된 파일 포함)을 준비하고 STDOUT에 덤프합니다. STDOUT은 docker build 로 파이프됩니다. 구성 가능한 부품은 NPM 모듈로 버전 지정, 테스트 및 출시됩니다. crond - http://pastebin.com/UqJYvxUR에 대한 테스트 이미지를 보여주는 아주 짧은 예를 올렸습니다.

@thaJeztah 감사합니다. 결국 에는 공동 개발자가 전체 개발 스택을 보유하기 위해 실행할 수 있는 단일 파일이 필요합니다. 그런 다음 필요한 경우 prod에서도 실행할 수 있습니다. docker compose에 대해 더 자세히 살펴보겠습니다.

또한 INCLUDE 는 오래전에 제안되었습니다( https://github.com/docker/docker/issues/735 ).

@jmcejuela 사실 대부분의 도커 사용자는 ssh를 설치하고 사용하여 컨테이너를 설정하고 실행 중인 컨테이너의 문제를 해결합니다. 도커가 실제로 사용되는 방식입니다.

당신이 잘못하고있는 경우에만 docker exec 명령이 꽤 오랫동안 사용되어 왔으며 그 이후로 ssh가 필요하지 않았습니다 ...

@anentropic 종속성이 없는 단순 서비스를 배포하는 경우에만 해당됩니다. 예를 들어 기계 학습과 관련된 모든 서비스에 대해 복잡한 종속성 체인이 있는 경우 서비스를 배포하기 위해 코드를 복제하게 됩니다. 그리고 그렇게 해야 할 이유가 없습니다. 도커가 도메인 특정 언어라고 해서 프로그래밍 언어에 대한 많은 지식이 버려지고 오래된 교훈이 적용되지 않는다는 의미는 아닙니다. 온전함은 여전히 ​​중요합니다. 레시피를 복사하여 붙여넣는 것은 미친 짓입니다.

또한 모든 docker 사용자가 아닌 '단일 서비스' 세계관에 가입한 경우에만 유효합니다.

@anentropic Docker 로드맵 에 따르면 docker exec 통해 실행 중인 컨테이너 프로비저닝은 똑같이 잘못될 수 있습니다.

추신: rkt 엔진이 v1.0에 도달했습니다.

@rjurney , :100:

사랑받든 미워하든 다중 상속은 복잡한 특징이며 의심할 여지 없이 저항이 있을 것입니다. Include는 빌드 레시피의 Dockerfile을 해결하기 어려운 경로 문제가 있는 언어로 바꿉니다.

문제를 다르게 보면 어떨까요? " ADD / COPY " 파일을 다른 도커 이미지에서 빌드 중인 이미지로 선택할 수 있다면 어떨까요? 이렇게 하면 기능을 재사용하고 코드 중복을 피할 수 있습니다. 이미지에서 FROM 여러 번 사용하지 않고 명시적인 방식으로 바이너리를 복사하기 때문에 이것은 잘 정의된 방식으로 작동해야 하며 그렇지 않으면 실패입니다. 이것이 도커 이미지와 함께 작동하고 일부 새로운 검색 경로와 반대로 레지스트리를 솔루션으로 활용할 수 있다는 점을 감안할 때 이것이 합리적인 제안이 되기를 바랍니다. 추가 보너스는 동일한 코드를 여러 번 다시 실행할 필요가 없다는 것입니다. 또한 빌더에 대한 대규모 변경을 피할 수 있기를 바랍니다. 생각?

아마도 이것은 다른 곳에서 제안되었을 것입니다. 이 경우 링크가 좋을 것입니다.

안녕하세요,
어떤 솔루션을 선택하든 여러 독립 소스에서 이미지를 준비하는 것이 불가능하다는 사실에 매우 놀랐습니다.
런타임에 이 프로세스를 수행할 수 있으므로 이미지 준비를 건너뛰고 싶었습니다. 따라서 런타임에 이미지 세트가 배포되고 종속성이 수정될 때마다 이미지를 다시 만들 필요가 없습니다.
나는 대안을 찾았지만 아직 유효한 것을 찾지 못했습니다. 이것은 주요 사용 격차입니다.
ACI를 사용하여 매우 쉽게 수행할 수 있습니다.
감사 해요!

:+1: 이 문제에 대한 해결책을 원하고 적어도 논의되고 있는 것이 기쁩니다. 기본 이미지가 같아야 하는 경우에도 마찬가지입니다.

다른 이미지에서 복사하는 것이 다른 곳에서 제안된 것으로 나타났습니다. 이것이 문제입니다( https://github.com/docker/docker/issues/18596 ).

@jakirkham 감사

도커 다중 상속 기능의 경우 +1

편집하다:

또한 참조: https://github.com/docker/docker/issues/13026

제 생각에 당신이 겪고 있는 문제는 레시피를 작성할 수 없다는 것이 말이 되지 않는다는 것입니다. Docker compose는 애플리케이션에서 여러 컨테이너를 사용하는 데 적합합니다. Docker swarm은 여러 노드에서 동일한 작업을 수행하는 데 적합합니다. 그러나 많은 경우에 소스 코드 수준에서 다른 사람의 작업을 포함할 수 있는 방법이 없습니다. 한 번 상속하거나 다시 만들어야 하므로 제한적입니다.

2016년 3월 18일 금요일 오전 9시 1분, Alvin Chevolleaux < [email protected]

썼다:

@thaJeztah https://github.com/thaJeztah 의 답장은 매우
계몽. 나는 Docker를 처음 사용하고 왜 결합할 수 없는지 이해하지 못합니다.
여러 _이미지_를 함께 사용하지만 Docker Compose가
내가 찾고 있던 하나의 응용 프로그램으로 여러 _containers_ 결합
을위한.

내 문제는 내가 처음에 Docker를 이해했다고 생각했다는 것입니다.
하지만 지금은 그렇지 않다는 것을 알게 되었습니다. 돌아가서 좀 더 해봐야겠다
독서!

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

러셀 저니 twitter.com/rjurney russell. [email protected] relato.io

@rjurney 예, Docker Compose를 조금 더 debian:jessie 있지만 Centos 기반 설정을 원하므로 특정 이미지를 사용하려면 나머지 설정을 수락하거나 소스 Dockerfile을 복사하여 붙여넣어야 합니다. 내 자신의 이미지를 처음부터 롤링할 때 이미지를 믹스 앤 매치할 수 있는 중간 지점이 없는 것 같습니다.

편집하다:
명확히하기 위해 Ubuntu와 Centos 기반 이미지를 함께 혼합할 수 없는 이유를 이해하지만 일종의 계층 구조를 가질 수 없는 이유를 모르겠습니다. 그런 다음 전체 이미지를 다운로드하는 대신 한 이미지에서 다른 이미지로 변경 사항을 다운로드하면 됩니다.

INCLUDE 는 나에게도 매우 유용할 것입니다. 그것 없이는 복사-붙여넣기를 해야 합니다.

@RomanSaveljev 이해할 수 없습니다.

Docker 로드맵 에 따르면 docker exec 통해 실행 중인 컨테이너를 프로비저닝하는 것은 똑같이 잘못될 수 있습니다.

docker exec 가 더 이상 사용되지 않을 것이라고 말하지 않습니다. docker exec 는 항상 디버깅 도구였으며 Docker 컨테이너의 SSH도 마찬가지입니다.

나는 이것에 참여하는 것이 어리석은 것처럼 느껴지지만 도대체 ... 나는 이것을 다시 제안 할 것입니다 :

문제를 단순화하고 상속을 허용하지 않도록 INCLUDE를 구현하는 것으로 시작하지 않겠습니까? 즉, FROM이 없는 파일만 포함할 수 있습니다.

그렇게 하면 많은 사용 사례를 처리할 수 있으며 합리적인 운영 체제에서 작업하는 사람들이 INCLUDE 파일에 있을 것입니다. uname은 이유가 있습니다. 이것은 첫 번째 단계가 될 것이며 이 구현에 대한 피드백은 더 많은 것을 정의하는 데 도움이 될 것입니다.

쉽게 결정할 수 있을 것 같습니다. 그것은 많은 작업이 아닐 것입니다. 복잡하지 않을 것입니다. 오른쪽?

@rjurney 는 기본적으로 https://github.com/docker/docker/pull/12749 가 하는 일입니다.

@rjurney : 어리석게 생각하지 마십시오. INCLUDE가 초기 질문을 완전히 다루지는 않지만 올바른 방향으로 나아가는 단계입니다. 캡슐화 된 몇 가지 문제가 있습니다.

1. 여러 개의 독립적인 작업을 결합하는 방법은 무엇입니까?
2. 이러한 편집을 효율적으로 저장하는 방법은 무엇입니까?
3. 빌드 수준이 아닌 바이너리 수준에서 여러 작업을 결합하는 방법은 무엇입니까?

이 목록에 추가할 수 있는 항목이 더 있을 수 있습니다. INCLUDE 솔루션은 첫 번째 글머리 기호를 처리합니다. 일단 그것이 자리를 잡으면 바이너리 스토리지 효율성이 최종 사용자에게 투명하게 개선될 수 있는 표준 프레임워크가 마련됩니다. 그것이 제자리에 있으면 이미지 파일에 대해 동일한 조작을 직접 수행하는 도구에 대해 이야기하는 것이 좋습니다. 그러나 이 마지막 단계는 물론 매우 의심스럽습니다. 이미지 파일에서 직접 수행하는 즉시 이미지가 깨질 가능성이 매우 큽니다. 그러나 파워 유저(자신이 무엇을 하고 있는지 정확히 알고 있는 사람)만이 세 번째 옵션을 할 것이라고 가정한다면, 그것은 나에게 불합리한 추가처럼 보이지 않습니다... 결국.

이런 식으로 진정으로 구성 가능한 것을 원하는 사람들을 위해 Nix(NixOS, Linux 배포 및 패키지 관리 시스템)를 볼 수 있습니다. 일반적으로 소스에서 빌드하고 Linux에 대해 알고 있다고 생각했던 모든 것을 버리고 모든 소프트웨어를 다시 패키징하기만 하면 됩니다. 좋은 시스템이지만 사용하는 사람이 많지 않아 손이 많이 가는 시스템이지만 잘 활용되기를 진심으로 바랍니다.

다른 사람들이 말했듯이 Docker 구성 가능성은 서비스 수준에서 구성하는 것에 관한 것입니다.

:+1: 구성 가능한 모델에 대해 생각할 가치가 있는 defo - 동작을 dockerfile로 가져올 수 있다면 훌륭할 것입니다. 예를 들어 알파인 리눅스를 기반으로 하는 매우 다양한 빌드 컨테이너에 apache thrift를 포함하려는 유스 케이스가 있습니다.

복사하여 붙여넣는 것보다 절약형 설치를 포함할 수 있으면 좋을 것입니다. 하지만 쉘 스크립트로 쉽게 추출하고 추가하고 실행할 수 있을 것 같습니다.

그렇다면 ruby-2.3과 java-8 이미지를 모두 사용하려면 어떻게 해야 합니까? 그들은 기본으로 동일한 데비안 jessie 이미지를 사용합니다(도커 파일을 읽었습니다). 둘 다에 있는 명령을 실행하고 싶습니다. 그대로 Java Dockerfile을 Ruby Dockerfile에 복사/붙여넣기해야 했습니다. 앱에는 둘 다 필요합니다. 이 문제를 해결할 방법이 전혀 없습니다.

몇 가지 Dockerfile 명령을 붙여넣는 동안 제거할 기회를 잡았습니다. "기본" Dockerfile(명령을 붙여넣은)이 이미 해당 단계를 수행했기 때문에 해롭지는 않았지만 단순히 불필요했습니다. 따라서 "ruby" & "java" 이미지를 원하지 않았다는 주장을 볼 수 있습니다. 실제로 세 번째 "ruby+java 올인원" 이미지를 구축하고 있었습니다.

그러나 이 특별한 경우 두 이미지의 명령은 완전히 호환되는 것 같습니다. 단순히 연결하기만 하면 작동

그러나 이 기능을 원하는 나와 같은 모든 사람에게는 이것이 문제가 될 수 있는 상황을 많이 볼 수 있습니다. 따라서 동일한 도커 이미지에서 "nginx"를 실행한 다음 "ssh"를 실행하는 기능을 제공하는 것만이 문제가 아닙니다. 동일한 기능을 사용하면 "debian" 및 "centos"를 실행할 수도 있습니다. 실행 가능한 이미지. 그것이 도입되면 기본적으로 해제되어 많은 경고가 첨부 된 실험적 옵션 인 것처럼 보입니다.

따라서 이 기능에 대한 인터페이스가 무엇이든 간에 재사용 가능한 동작(명령 세트)을 올바르게 얻는 책임은 Dockerfile 개발자에게 있음을 매우 분명히 해야 합니다.

편집: 아, INCLUDE 토론을 놓쳤습니다.

문제를 단순화하고 상속을 허용하지 않도록 INCLUDE를 구현하는 것으로 시작하지 않겠습니까? 즉, FROM이 없는 파일만 포함할 수 있습니다.

그렇게 하면 많은 사용 사례를 처리할 수 있으며 합리적인 운영 체제에서 작업하는 사람들이 INCLUDE 파일에 있을 것입니다. uname은 이유가 있습니다. 이것은 첫 번째 단계가 될 것이며 이 구현에 대한 피드백은 더 많은 것을 정의하는 데 도움이 될 것입니다.

쉽게 결정할 수 있을 것 같습니다. 그것은 많은 작업이 아닐 것입니다. 복잡하지 않을 것입니다. 오른쪽?

:+1:

@rjurney 그게 기본적으로 #12749가 하는 일입니다

:+1: 완벽, 최종 형태로 무엇을 할 수 있을지 기대됩니다.

이 개념에도 매우 관심이 있습니다. "INCLUDE" 메커니즘은 매우 조잡한 솔루션이지만 솔직히 도커 파일 세트의 유지 관리 측면에서 꽤 큰 진전을 나타냅니다.

개인적으로 FROM 가 발생했을 때 _실패_ 하는 것을 원하지 않고 FROM _무시_ 하고 나머지 명령을 순서대로 적용하기를 원합니다.

FROM 지원 없이는 아직 이런 일이 발생하지 않았다는 것은 오픈 소스입니다.
장난.

2017년 1월 19일 목요일 오전 10:19, Ken Williams 알림 @github.com
썼다:

이 개념에도 매우 관심이 있습니다. "INCLUDE" 메커니즘은 매우
조잡한 솔루션이지만 솔직히 말하면
도커 파일 세트의 유지 관리 가능성.

개인적으로 FROM이 발생할 때 실패 하는 것을 원하지 않습니다.
FROM을 무시 하고 나머지 명령을 적용하기를 원합니다.
순서.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/docker/docker/issues/3378#issuecomment-273854850 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AACkpS8-EQ7r0BHid75rxeBDhOUDFRXlks5rT6kXgaJpZM4BWkJ9
.

--
러셀 저니 twitter.com/rjurney russell. [email protected] relato.io

여기 문제가 있습니다. 병합이 반드시 필요한 것은 아닙니다. 리베이스로 많은 문제를 해결할 수 있다고 생각합니다. 내 일반적인 사용 사례는

A(우분투) -> B(예: nginx)
A(우분투) -> C(예: 노드)

그리고 나는 결합 된 B & C 이미지를 원합니다. 일반적으로 그들은 서로 아무 관련이 없으므로 A와 C 사이의 모든 diff를 B에 리베이스하는 것으로 충분합니다. 즉

A -> B -> C'

해결하기가 더 쉬운 문제인 것 같습니다.

@cloutiertyler 일반적으로 Node.js 애플리케이션은 Nginx와 작동하기 위해 이 기능이 필요하지 않습니다(제 생각에는). Docker 방식은 두 개의 컨테이너가 될 것입니다. 하나는 Nginx용이고 다른 하나는 Node.js용입니다. 포트를 Nginx 컨테이너에만 노출하도록 노드 컨테이너를 구성하고 Nginx 컨테이너가 공용 포트(예: 80)를 수신하도록 합니다. Nginx가 Node와 동일한 컨테이너에 있어야 하는 이유가 있습니까?

샘플 Docker Compose 파일은 다음과 같습니다.

version: "2.1"

services:
  app: # Node.js application image
    build: .
  nginx: # Nginx container who can make request to app container
    image: nginx:1.10-alpine
    depends_on:
      - app
    ports:
      - "${PORT:-8080}:80" # public port, you may want PORT=80

@franklinyu 답변 감사합니다. 실제로 예제로 두 개의 임의 서비스를 사용했습니다. 내 일반적인 사용 사례는 일반 서비스(예: 우분투 기반 노드)와 내 사용자 정의 이미지(우분투 기반)로 시작하여 이들을 결합하려는 것입니다.

btw, 정확히 리베이스하지는 않지만 Dockerfiles에 대한 많은 사용 사례를 엽니다.
Dockerfile은 이제 다단계 빌드를 지원합니다. 예시:

FROM golang AS myapp
COPY . /myapp
RUN cd /myapp && go build

FROM scratch
COPY --from=myapp /myapp /usr/bin/myapp

당신은 당신이 원하는만큼 많은 단계를 가질 수 있습니다.
--from 매개변수는 기본적으로 컨텍스트를 지정된 빌드 대상 이름으로 전환합니다.
docker build -t myapp . 하면 myapp:latest 라는 결과 이미지가 마지막 단계에서 생성됩니다.
예를 들어 docker build --target=myapp 하여 특정 단계를 빌드할 수도 있습니다.

17.05(현재 RC1로 사용 가능)에는 몇 가지 다른 매우 멋진 Dockerfile 개선 사항이 있습니다. 시도해 보십시오!

이제 흥미롭습니다! 당신이 그렇게 할 수 있는지 몰랐어요. 내 일반적인 사용 사례를 해결하는지 확인하기 위해 시도해야 합니다.

이것은 훌륭한 기능이지만 사용해 본 후에도 가장 일반적인 문제가 해결되지는 않습니다. 오늘에서야 또 당했습니다.

컨테이너 내에서 빌드할 수 있도록 Docker가 설치된 Jenkins 이미지를 원합니다. 문제는 내 Dockerfile에서 둘 중 하나의 설치 프로세스를 복제하지 않고는 이 작업을 수행할 방법이 없다는 것입니다.

이것은 각 컨테이너가 하나의 서비스여야 하기 때문에 필요하지 않다는 점멸된 주장이 분명히 적용되지 않는 경우입니다. 내 "하나의 서비스"는 Docker와 Jenkins의 기능을 결합합니다.

문제는 내 Dockerfile에서 둘 중 하나의 설치 프로세스를 복제하지 않고는 이 작업을 수행할 방법이 없다는 것입니다.

따라서 두 개의 dockerfile을 하나로 부숴서 복사/붙여넣기를 할 필요가 없습니까?

복사/붙여넣기는 이 경우 분기와 동일합니다. 내가 하고 싶은 것은 Dockerfile을 분기하지 않도록 하여 나중에 변함없이 변경될 때 버그/보안 개선 또는 기타 변경 사항을 놓치지 않도록 하는 것입니다.

그냥 지나칠 수 없습니다. 긴 이미지 상속 체인(2보다 깊음)에 변경 사항을 배포하는 방법을 찾고 있습니다. 다단계는 문제를 명확히 하는 것 같지 않습니다. 지시문 블록만 포함할 수 있는 엔터티를 사용하여 기본 이미지 기능과 함께 모든 상속 이미지에 포함할 수 있다는 것은 합리적인 진화처럼 보입니다.

Docker 관점에서 이 작업을 수행하는 올바른 방법이 궁금하다면 잠시 시간을 내어 다음을 검토하세요.
https://github.com/floydhub/dockerfiles

여기에서 그는 Dockerfile의 전체 트리를 만듭니다. 트리 아래로 내려가면 트리의 위 레벨에서 각각 다른 종속성 조합을 찾을 수 있습니다. 그래서 만약 당신이 나무를 따라갔다면
-ubuntu->common-deps->python3->deepLearningBase->pyTorch
그리고 당신은 정말로 원했습니다

-ubuntu->common-deps->python3->deepLearningBase->pyTorch 
+
-ubuntu->common-deps->python3->deepLearningBase->TensorFlow 

두 가지 모두에 대해 deepLearningBase 아래에 노드(폴더)를 추가하기만 하면 됩니다.
-ubuntu->common-deps->python3->deepLearningBase->TensorFlow-pyTorch

이제 pyTorch와 TensorFlow dockerfile을 결합한 dockerfile을 만들어야 하지만
핵심은 해당 파일이 deepLearningBase 위에 몇 줄만 설치하면 매우 간단하다는 것입니다.

따라서 실제로 필요한 것은 웹 개발, 딥 러닝, 임베디드 소프트웨어 등과 같은 다양한 "세계"에 대해 이와 같은 여러 대규모 github 리포지토리에 대한 것입니다.

그런 다음 필요한 빌드로 트리를 따라가고 아직 아무도 만들지 않았다면 노드를 추가하고 2 또는 3개의 apt-get 라인을 결합하여 새 환경을 만드십시오.

그것은 "자신만의 모험을 선택하는" 스타일의 구성처럼 보입니다. INCLUDE는 훨씬 간단합니다. 젠장, nano 로 지정된 gcc 이미지를 구성하고 싶기 때문에 매번 apt-get에서 nano를 설치할 필요가 없습니다!

나는 그의 위 코멘트에서 @chambm 에 동의합니다. 대부분의 경우 이것이 가능하지 않아야 할 이유가 없습니다(충돌은 수동으로 관리되는 OS에서 발생하기 때문에 상당히 드물어야 함).

이것은 @cloutiertyler가 언급 한 것과 매우 유사한 사용 사례입니다. @franklinyu 의 솔루션 도 @cpuguy83이 언급 한 다단계 빌드도 적용되지 않습니다.

• A(debian:stretch-slim)
  
  
  
  • dockerfileAB -> B(python:slim-stretch)
  
  
  • dockerfileAC -> D ([빌드 단계] python-slim)
    
    
    
    
    
    • dockerfileDE -> E(ghdl/ext:vunit)
    
    
    
  
  
  • dockerfileAC -> C(ghdl/run:stretch-mcode)
  
  

어디:

• A에서 C로의 단계는 B에서 D로의 단계와 정확히 동일합니다(dockerfileAC).
• B의 개발팀은 C, D, E에 대해 아무것도 모릅니다.
• C의 개발팀은 B, D, E에 대해 아무것도 모릅니다.

D(및/또는 E)를 빌드하려는 사용자는 dockerfileAC에 대한 액세스 권한이 있어야 하지만 dockerfileAB에 대해 알 필요는 없습니다. 따라서 사용자는 한 종속성(C)을 다른 종속성(B)보다 더 잘 이해해야 합니다. 이상적으로는 팀 A와 B에 의존하고 D를 A + (diff(B,A) + diff(C,A)) (병합) 또는 A + diff(B,A) + diff(C,A) (리베이스)로 빌드하는 것이 가능해야 합니다.

GHDL은 웹 서비스가 아니고 VUnit은 웹 클라이언트가 아니므로 두 도구를 동일한 이미지/컨테이너(E)에 설치해야 합니다. 다단계 빌드는 유용하지 않습니다. 두 개의 FROM 레이블이 있는 (아마도 알려지지 않은) dockerfile을 빌드해야 하기 때문에 단일 포워드 체인이 아닙니다.

두 git 브랜치의 병합/리베이스와 유사한 사용 사례를 찾으면 충돌이 없는 경우도 있고 쉽게 해결할 수 있는 경우도 있고 공통 히스토리가 없기 때문에 병합할 수 없는 경우도 있습니다... 도구가 있나요? 이 기능을 제공하는 공식 또는 외부? 도구가 두 개의 이미지를 git 브랜치로 내보내고 실제로 병합에 git을 사용하는 경우 괜찮습니다.

@1138-4EB https://github.com/moby/buildkit 참조

놀랍게도 이것은 여전히 ​​문제이자 주제입니다. "INCLUDE someimage"가 얼마나 어려운지, 그런 다음 구문 분석할 때 베이스가 호환되는지 확인하고(FROM 체인에서) 그렇다면 해당 지점에서 나머지 해당 파일을 실행합니다(프로젝트에서 Dockerfile을 복사한 것처럼 그리고 그것을 내 것에 붙여넣었다)?

"사람들이 깨닫지 못하는 나쁜 일을 할 것이다"라는 변명은 이런 맥락에서 터무니없다. 이것은 이미 엄청나게 복잡하고 단순화하는 데 이것이 필요한 이유입니다.

@rainabba 전혀 도움이 되지 않는 댓글입니다.
완료되지 않은 데에는 기본적으로 두 가지 이유가 있습니다.

1. 그렇게 쉬운 일이 아니다
2. 아무도 그 일을 하기 위해 시간을 들이지 않았습니다.

실제로는 일반적으로 둘 다입니다.

1. 새로운 코더가 코드의 어디에 있는지 안다면 10분 만에 완료할 수 있는 구문 분석 및 문자열 교체 문제입니다. 모든 경우에 사용할 수 있다고 말하는 것은 아니지만 여기에서 계속해서 제안되는 제한된 경우(기지가 효과적으로 공통적인 경우)의 경우에는 매우 중요합니다.

2. 물론 그렇지 않습니다. 이 스레드는 수행할 수 없거나 수행해서는 안 되는 ~102가지 이유를 제공합니다. 그렇다면 왜 누구든지 상관없이 수행할 생각을 할까요?

다른 한편으로, 내 의견은 (여기에 있는 많은 다른 사람들과 마찬가지로) 방해하는 태도에 영향을 미치거나 적어도 상기시키는 역할을 할 필요가 있고 희망이 있음을 입증하는 역할을 합니다. "완전히 도움이 되지 않는" 경우 이 문제(기능 요청 무시)가 여전히 존재하고 기술적인 문제가 아닌 이유를 설명했습니다.

문자열을 파싱하는 것 보다 훨씬 더 중요합니다.
Docker와 Dockerfile은 수백만 명의 사람들이 사용합니다. API를 추가하는 것은 중요한 일입니다... 기본 구현이 "문자열 구문 분석"이 아니라는 점을 제외하면.

어쨌든 문제를 해결하기 위한 많은 제안이 있으며 이것은 매우 오래되고 닫힌 문제입니다.

Docker가 이 시나리오에 대한 깨끗한 솔루션을 찾지 못한다면 아마도 그것을 알아내는 도구로 대체될 것이라고 생각합니다.

동료 중 한 명이 다음 패턴을 사용하는 것을 발견했는데 이는 적절한 해결 방법일 수 있습니다.

ARG from
FROM $from
... rest of dockerfile

나는 그것을 직접 시도하지 않았으므로 캐싱과 함께 작동하는 방식 등과 같이 실제로 어떻게 작동하는지 잘 모르겠습니다.

실제로 이것은 매우 중요한 문제이며 제대로 해결되지 않았습니다. Docker만큼 큰 회사가 아직 이를 해결하지 못했다는 사실에 놀랐습니다.

단돈 2센트... 저는 현재 Docker에 대해 더 많이 배우고 있으며 INCLUDE와 같은 것이 매우 유용할 것이라고 생각합니다. 나는 위의 다중 상속 예제가 마음에 들었고 가능한 문제와 충돌에 대한 의견을 다루고 싶었습니다.

다중 상속은 지원하는 모든 언어에서 어렵지만 충돌이 발생하면 Docker 파일 작성자가 수행 중인 작업을 재고하고 다시 시작해야 합니다. Docker는 이미지를 빌드하기만 하고 빌드에 문제가 없음을 증명하려고 해서는 안 됩니다.

@cosminonea

INCLUDE와 같은 것이 매우 유용할 것이라고 생각합니다.

https://github.com/larytet/dockerfile-generator/ 에서 매크로에 대한 지원이 있습니다. "포함"도 지원할 수 있습니다.

그것은 요점을 놓치는 것입니다. 목표는 Dockerfile을 포함하지 않는 것입니다.
정의. 목표는 도커 이미지를 포함하는 것입니다. 이것은
그것은 내 머리 꼭대기에서 떨어져 있기 때문에 터무니없는 것처럼 보입니다.

페도라에서
우분투/우분투 포함
데비안/데비안 포함

합리적으로 나는 이것이 페도라의 이미지로 시작될 것으로 기대합니다.
그런 다음 /ubuntu 폴더 아래에 우분투용 이미지를 추가합니다. 그런 다음 추가
/debian 아래의 데비안 이미지.

이것은 물론 터무니없는 일입니다. 왜 내가 많은 운영 체제를 혼합하고 싶습니까?
시스템을 하나의 이미지로? 그러나 더 유용한 예는 다음과 같습니다.

페도라에서
플렉스/플렉스 포함
commericalremover /plex/add-on/commericalremover 포함

이제 이 경우에 더 의미가 있습니다. 이것들이 다른 이미지라면
작동하는 특정 구성 요소가 없습니다. 쉽게 만들 수 있습니다.
모듈식.

2018년 8월 8일 수요일 15:48 Arkady Miasnikov [email protected]
썼다:

나는 INCLUDE와 같은 것을 느낀다.
매크로를 지원합니다.
https://github.com/larytet/dockerfile-generator/ "포함"을 추가할 수 있습니다.
지원도.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/moby/moby/issues/3378#issuecomment-411529506 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/ADBcWAtBDEp_LXpW3HUkHd3Pw5IVAXvqks5uO0ChgaJpZM4BWkJ9
.

마지막 것은 이미 가능합니다. COPY --from 는 빌드 단계 또는 이미지를 모두 허용합니다. 예를 들면 다음과 같습니다.

FROM busybox

COPY --from=alpine:latest / /
COPY --from=docker:latest /usr/local/bin/docker /usr/local/bin/

편집하다; 또는 실제 예를 들면;

FROM fedora

COPY --from=ubuntu:latest / /ubuntu/
COPY --from=debian:latest / /debian/

정확히. 그렇기 때문에 "COPY
--from"은 원래 요청을 완료한 것으로 간주됩니다. 절대적으로
이 티켓에서 내가 더 이상 찾고 있던 것은 없습니다.

포함을 자동으로 리베이스하는 것과 같이 나중에 제기된 아이디어는 다음과 같습니다.
좋은 기능. 그러나 그들은 원래의 요구를 뛰어 넘습니다.

문안 인사,

청구서

2018년 8월 9일 목요일 12:55 Sebastiaan van Stijn 알림 @github.com
썼다:

마지막 것은 이미 가능합니다. COPY --from 둘 다 허용
예를 들어 빌드 단계 또는 이미지;

비지박스에서

복사 --from= 알파인:최신 //
복사 --from= 도커:최신 /usr/local/bin/docker /usr/local/bin/

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/moby/moby/issues/3378#issuecomment-411824851 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/ADBcWPE738cs9xf3ZHSOaUd1foI1XVIQks5uPGmYgaJpZM4BWkJ9
.

@thaJeztah 이를 위해 다단계 빌드를 사용하려면 여전히 각 이미지에서 복사할 파일을

물론 Docker 이미지를 병합하는 것은 쉬운 일이 아닙니다. 임의의 스크립트는 빌드 중에 실행할 수 있으므로 빌드 프로세스는 자동 충돌 감지의 일반적인 시도에 저항합니다. 정지 문제는 안녕이라고 말합니다! 당신이 할 수 있는 최선은 (빌드가 할 수 있는 일을 크게 제한하는 것 외에는) 정확한 의미를 정의하는 것입니다: 마지막 FROM / INCLUDE 이긴다(예: 같은 파일을 "쓰는" 경우) 또는 파일 시스템 수준 충돌 시 실패 또는 ....

다른 "기본" 이미지(stretch vs ubuntu vs alpine vs ...)에 대해 때때로 언급된 문제이지만 _is_ 간단합니다. 이미지 종속성의 DAG에는 단일 소스(현재 이미지)뿐만 아니라 단일 싱크도 있어야 합니다. ("계층 구조"에 있는 모든 이미지의 공유 "상위").

궁극적으로, 물론, 당신은 쓰레기 안에 쓰레기를 버리게 될 것입니다. 그것은 정말로 다른가요?

FWIW, 내 사용 사례는 다음과 같습니다.

1. PostgreSQL 데이터베이스 및 S3 객체 저장소로 Tomcat 웹 애플리케이션 실행.
   이것은 Docker Compose를 사용하여 해결할 수 있지만 단일 컨테이너가 더 좋을 수 있습니다.
2. 다국어 빌드는 Docker 컨테이너(예: Jenkins, Circle CI 등)에서 실행됩니다.
   가장 인기 있는 도구 체인에 대한 공식 이미지가 있지만 여기에서 논의된 문제에서 정확히 하나 이상의 실행을 처리할 수 있는 단일 컨테이너를 갖추는 것이 좋습니다.

@reitzig ,

• https://github.com/avirshup/DockerMake
• http://docteurklein.github.io/2015/01/11/docker-auto-builds-and-me/
• https://blog.dockbit.com/templating-your-dockerfile-like-a-boss-2a84a67d28e9
• https://github.com/larytet/dockerfile-generator/

@reitzig 이것은 유일한 옵션이 아닙니다. 올바른 옵션은 큰 문제를 피하기 위해 INCLUDE를 제한하는 것입니다. INCLUDE는 상속할 수 없습니다. 거기는. 단순한. 여전히 매우 유용합니다.

이 기능 요청은 인기가 있지만 Docker는 Beer에서와 같이 무료이지만 Freedom에서처럼 결코 무료는 아닙니다.

@rjurney 18.06 이후 빌드킷 지원을 포함하여 사용자는 빌더에 대한 자체 프론트엔드 파서를 제공할 수 있습니다. 많은 새로운 기능(초보자를 위한 비밀 지원)을 포함하는 공식(Docker Inc) 실험용 Dockerfile 파서가 이미 있습니다.

물론 사용자 지정 Dockerfile 프론트엔드에 고유한 "INCLUDE" 동작을 추가하거나 Dockerfile이 아닌 완전히 다른 작업을 수행할 수도 있습니다(buidpack에 대한 예가 있음).

커스텀 프론트엔드를 사용하려면 Docker가 처리할 수 있는 이미지를 가리키면 됩니다. Dockerfile(또는 무엇이든지)의 첫 번째 줄에 주석으로 이 작업을 수행합니다. syntax = myCustomFrontendImage

자세한 내용은 여기:
https://docs.docker.com/develop/develop-images/build_enhancements/#overriding -default-frontends

빌드킷이 활성화되면 Docker는 필요한 기능을 사용하여 원하는 모든 것을 빌드할 수 있습니다(Dockerfile 형식일 필요도 없음).

이 기능 요청은 인기가 있지만 Docker는 Beer에서와 같이 무료이지만 Freedom에서처럼 결코 무료는 아닙니다.

그 메모가 주제가 아닌 것처럼, 나는 당신이 틀렸다는 점에 주목해야한다고 생각합니다. Docker의 Apache 라이선스 덕분에 모든 사람은 여기에서 개발된 기능을 제공하는 Dockerfile에 대한 자체 인터프리터를 포크하고 개발할 수 있습니다. 주의를 기울이면 결과 이미지가 기존 Docker 런타임/도구와 호환됩니다.
물론 Docker 프로젝트의 유지 관리자도 마찬가지로 이러한 기능을 포크(원본?)에 병합하지 않을 자유가 있습니다.

@reitzig 그것은 실제로 자유 소프트웨어가 무엇인지 언급하지 않고 분명히 의미없는

나는 그것이 지금 Apache 라이센스인지 몰랐습니다. 발언에 대해 사과드리며
이것이 훌륭하다고 생각하십시오!

러셀 저니 @rjurney http://twitter.com/rjurney
러셀. [email protected] LI http://linkedin.com/in/russelljurney FB
http://facebook.com/jurney datasyndrome.com

2019년 1월 16일 수요일 오전 4시 17분에 Raphael R. [email protected]에서 다음과 같이 썼습니다.

이 기능 요청은 인기가 있지만 Docker는 Beer에서와 같이 무료이지만
모든 것은 자유에서와 같이 자유를 의미합니다.

그 메모가 주제가 아닌 것처럼, 나는 당신이
잘못된. Docker의 Apache 라이선스 덕분에 모든 사람이
제공하는 Dockerfiles에 대한 자체 인터프리터를 포크하고 개발하십시오.
여기에서 개발된 기능. 주의를 기울이면 결과 이미지가
기존 Docker 런타임/도구와 호환됩니다.
물론 Docker 프로젝트의 유지 관리자는 유사하게 무료입니다.
이러한 기능을 포크(원본?)에 병합합니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/moby/moby/issues/3378#issuecomment-454758482 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AACkpdj_YO76ge79bm4G8FBmhOdbjhO9ks5vDxhvgaJpZM4BWkJ9
.

죄송합니다, 잠을 잘 못 자서 실수를 했습니다. 내 의견이 서 있습니다.
비어에서처럼 무료는 Apache를 의미합니다. 자유에서와 같이 자유는 커뮤니티 통제를 의미합니다.
Apache 프로젝트 또는 다른 형태의 거버넌스.

러셀 저니 @rjurney http://twitter.com/rjurney
러셀. [email protected] LI http://linkedin.com/in/russelljurney FB
http://facebook.com/jurney datasyndrome.com

2019년 1월 16일 수요일 오후 12:32 Russell Jurney [email protected]
썼다:

나는 그것이 지금 Apache 라이센스인지 몰랐습니다. 발언에 대해 사과드리며
이것이 훌륭하다고 생각하십시오!

러셀 저니 @rjurney http://twitter.com/rjurney
러셀. [email protected] LI http://linkedin.com/in/russelljurney FB
http://facebook.com/jurney datasyndrome.com

2019년 1월 16일 수요일 오전 4:17 Raphael R. [email protected]
썼다:

이 기능 요청은 인기가 있지만 Docker는 Beer에서와 같이 무료이지만
모든 것은 자유에서와 같이 자유를 의미합니다.

그 메모가 주제가 아닌 것처럼, 나는 당신이
잘못된. Docker의 Apache 라이선스 덕분에 모든 사람이
제공하는 Dockerfiles에 대한 자체 인터프리터를 포크하고 개발하십시오.
여기에서 개발된 기능. 주의를 기울이면 결과 이미지가
기존 Docker 런타임/도구와 호환됩니다.
물론 Docker 프로젝트의 유지 관리자는 유사하게 다음을 수행할 수 있습니다.
이러한 기능을 포크(원본?)에 병합하지 마십시오.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/moby/moby/issues/3378#issuecomment-454758482 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AACkpdj_YO76ge79bm4G8FBmhOdbjhO9ks5vDxhvgaJpZM4BWkJ9
.

비어에서처럼 무료는 Apache를 의미합니다.

동의하지 않는다. 프리웨어는 독점 소프트웨어일 수 있습니다.

자유에서와 같이 자유는 커뮤니티 통제를 의미합니다.

커뮤니티 컨트롤이란? 재단에서 운영하는 프로젝트? 그렇다면 VS Code, Atom 편집기 및 Ubuntu를 비자유 소프트웨어로 간주하시겠습니까? 그렇다면 귀하의 정의는 FSF, EFF 및 기타 여러 조직에서 제안한 정의와 크게 다릅니다.

나는 Docker Inc가 이 문제에 대해 커뮤니티와 적극적으로 논의하지 않는다는 데 동의하지만 이것은 "Free as in Freedom"과 아무 관련이 없습니다.

죄송합니다. 이슈 트래커에서 이런 종류의 토론을 하지 맙시다.

Docker Inc가 이 문제에 대해 커뮤니티와 적극적으로 논의하지 않는다는 데 동의합니다.

docker build 를 통해 원하는 모든 빌드 형식을 지원할 수 있습니다. "공식" Dockerfile 형식은 이 옵션을 지원하지 않지만 docker build 이 옵션을 사용할 수 없다는 의미는 아닙니다.
docker build 와 함께 작동하는 사용자 정의 프론트엔드를 빌드하는 예제로 https://matt-rickard.com/building-a-new-dockerfile-frontend/ 를 확인하십시오.
이 프론트엔드는 Dockerfile 형식과 완전히 다른 작업을 수행할 수 있는 방법의 예이지만 반드시 필요한 것은 아닙니다. 기존 Dockerfile 형식을 사용하고 원하는 경우 고유한 기능을 추가할 수 있습니다.

공식 Dockerfile 형식에 무언가를 추가하는 한.... 제안은 언제나 환영 입니다. 형식은 .
그러나 모든 새로운 기능은 미래에 수행할 수 있는 작업을 제한하는 것을 포함하여 유지 관리에 대한 새로운 부담을 의미한다는 점을 명심하십시오.

여러 Dockerfile을 결합하는 많은 사용 사례가 실제로 Dockerfile의 새로운 기능으로 해결할 수 있다고 생각합니다. 특히 임의의 이미지에서 COPY --from 및 RUN --mount 을 사용할 수 있습니다.

이 가상의 INCLUDE가 @#$%를 제공할 필요 없이 단순한 세부 정보로 추가 컨테이너를 생성할 수 있다면 구성 가능한 컨테이너의 암시적이고 엉뚱한 판매 피치를 둘러싼 좌절감을 크게 줄일 수 있습니다. 저는 정말로 애플리케이션으로 돌아가 기능을 제공하고 싶습니다. 나쁜 분위기에 대해 미안하지만 나는 docker/container noob이고 다른 많은 포스터가 이미 표현한 것과 같은 혼란에 빠졌습니다.

만약 당신이 이것을 할 수 있다면:

              /--- python:3.8.3-alpine3.12 ---\
             /                                 \
alpine:3.12.0                                   custom image (with both python and rust)
             \                                 /
              \----- rust:1.44-alpine3.12 ----/

_두 이미지 모두 동일한 이미지의 자손이라는 점에 유의하십시오. 이것이 핵심입니다!_

다음과 같이 쉽게:

FROM alpine:3.12.0
INCLUDE rust:1.44-alpine3.12
INCLUDE python:3.8.3-alpine3.12

_"COPY --from image" 명령(다단계 빌드)을 사용할 때와 비교할 때 구현 세부 정보(복사할 파일/환경 변수)에 대해 생각할 필요가 없습니다._

이미지를 결합하려는 경우 현재 어떻게 보이는지

FROM alpine:3.12.0

# INCLUDE rust:1.44-alpine3.12
COPY --from=rust:1.44-alpine3.12 / /
ENV RUSTUP_HOME=/usr/local/rustup \
    CARGO_HOME=/usr/local/cargo \
    PATH=/usr/local/cargo/bin:$PATH \
    RUST_VERSION=1.44.1

# INCLUDE python:3.8.3-alpine3.12
COPY --from=python:3.8.3-alpine3.12 / /
ENV PATH /usr/local/bin:$PATH
ENV LANG C.UTF-8
ENV GPG_KEY E3FF2839C048B25C084DEBE9B26995E310250568
ENV PYTHON_VERSION 3.8.3
ENV PYTHON_PIP_VERSION 20.1.1
ENV PYTHON_GET_PIP_URL https://github.com/pypa/get-pip/raw/eff16c878c7fd6b688b9b4c4267695cf1a0bf01b/get-pip.py
ENV PYTHON_GET_PIP_SHA256 b3153ec0cf7b7bbf9556932aa37e4981c35dc2a2c501d70d91d2795aa532be79

_ENV 지침은 이 이미지의 Dockerfile에서 복사하여 붙여넣었습니다._

이것은 또한 훨씬 더 나은 컨테이너 재사용을 허용하고, 컴파일하거나 빌드하는 데 오랜 시간이 걸릴 수 있는 것들을 함께 던지는 것을 매우 쉽게 만듭니다!

이 접근 방식을 사용하면 프로그램을 플랫폼/기본 이미지 버전당 한 번만 컴파일하면 되며, 직접 구현하는 것보다 재사용하는 것이 더 쉽습니다. 좋은/범용 패키지 관리자가 없기 때문에 C++에서 "휠이 다시 구현된" 횟수를 생각해 보십시오. Docker에 대해 유사한 상황이 발생하기를 원하십니까?

@bergkvist , https://github.com/moby/moby/issues/3378#issuecomment -381449355 및 https://github.com/moby/moby/issues/3378#issuecomment -381641675를 참조 하세요 .

당신이 제안한 솔루션 중 어느 것도 다이어그램과 일치하지 않는다고 생각합니다. 대신 다음을 수행하고 있습니다.

              /--- python:3.8.3-alpine3.12 ---\
             /                                 \
alpine:3.12.0                                   \
             \                                   \
              \----- rust:1.44-alpine3.12 --------\ custom image 

그래서, 녹에 수정 된 모든 파일은 파이썬으로 덮어 씁니다. 서로를 복사하지 않고 결합하려면 병합이 필요합니다.

@eine 예, 충돌이 발생하면 파일을 덮어씁니다. 그건 사실이야. 따라서 대칭인 그림은 (관련) 파일이 겹치지 않는 특수한 경우입니다. 그림의 버전이 더 일반적입니다.

두 이미지가 동일한 정확한 이미지에서 상속되도록 하는 것에 대한 제 요점은 중요한 충돌 가능성이 희박할 수 있다는 것입니다.

패키지 관리자 파일과 관련된 충돌이 발생할 수 있다고 생각합니다. 두 이미지가 패키지 관리자를 사용하여 다른 것을 설치한 경우. 일종의 특별한 경우로 처리할 수 있는 것과 같은 다른 "공통 충돌"이 있는지 확실하지 않습니다.

두 파일을 병합하는 것은 간단하지 않습니다. 일반적인 경우에는 현명하게 쓰려고 하는 것보다 그냥 덮어쓰는 것이 더 나을 수도 있다고 생각합니다. 적어도 일이 작동하지 않을 때 디버그하는 것이 더 쉽습니다.

4일 전에 여기에 댓글을 달았기 때문에 Golang을 배우고 moby/buildkit 코드의 프론트엔드 코드를 살펴보기로 했습니다.

이제 위에서 논의한 INCLUDE 문을 허용하는 사용자 지정 프런트엔드를 만들었습니다.

#syntax=bergkvist/includeimage
FROM alpine:3.12.0
INCLUDE rust:1.44-alpine3.12
INCLUDE python:3.8.3-alpine3.12

사용자 정의 구문을 사용하려면 빌드할 때 DOCKER_BUILDKIT=1을 설정해야 합니다.

DOCKER_BUILDKIT=1 docker build -t myimage .

코드는 https://github.com/bergkvist/includeimage에서 사용할 수 있습니다.
Docker Hub의 이미지: https://hub.docker.com/r/bergkvist/includeimage