나는 이것에 대해 조사하고 있었다

사용법: 도커 빌드 [옵션] 경로 | URL | -

그래서 당신이 실행하면

도커 빌드 -t my/thing my-dockerfile

tar 파일이 너무 짧다고 불평합니다.

'PATH' 옵션이 문서화되지 않은 것 같으므로 일부 레거시 의미가 있을 수 있습니까?

그래서 - PATH가 파일이고 Tarfile이 아닌지 감지하는지 궁금합니다.

개인적으로 테스트에 사용하는 Dockerfile 세트가 있으며, 하나의 디렉토리에 모두 포함하고 전체 컨텍스트도 갖고 싶습니다.

해당 PATH는 특정 Dockerfile이 아닌 디렉토리를 참조합니다.

오, 그런 다음 서버로 보내기 위해 해당 디렉토리를 Tars로 만듭니다. 멋지군요!

isafile을 감지할 수 있도록 해당 디렉토리를 tar로 만든 다음 해당 tarball의 Dockerfile을 지정된 파일로 바꿉니다.

또는 -f를 같은 방식으로 사용 - Dockerfile 정의가 페이로드와 별도로 존재하도록 허용

이제 테스트가 어떻게 작동하는지 알아보기 위해 시도해 보고 나에게 맞는지 확인하십시오.

아무 것도 tar하지 않습니다 - PATH는 Dockerfile 가 있다고 가정하는 디렉토리입니다.

그것이 그 PATH로 하는 전부는 아닙니다 - 코드를 읽으면, '컨텍스트'는 디렉토리의 무게를 측정하여 서버로 보내집니다.

(그래, 그래서 나는 여전히 go를 모른다. 그리고 나는 지난 몇 분 동안만 코드를 읽었다.

맞습니다. 따라서 ADD를 통해 참조되는 모든 비원격 파일도 동일한 디렉토리에 있어야 합니다. 그렇지 않으면 데몬이 해당 파일에 액세스할 수 없습니다.

아, 나는 당신이 말하는 것을 봅니다 - 예 - 그것이 내가 원하는 것입니다 - -f를 사용하여 dockerfile을 지정한 다음 별도의 디렉토리 PATH를 지정하는 방법입니다.

그래서 나는 가질 수 있었다:

docker build -t my/thing fooproj
docker build -t my/thing -f debug-dockerfile fooproj

2108(Dockerfiles에 include 지시문 추가) 흥미로운 주름 추가

포함이 지정된 dockerfile 또는 PATH에 상대적이어야 합니다. 아직 중요하지 않지만.

재미있는:

docker build -t my/thing fooproj
docker build -t my/thing -f ../../debug-dockerfile fooproj
docker build -t my/thing -f /opt/someproject/dockerfiles/debug-dockerfile fooproj

추가 보너스로 - 아직 CmdBuild 테스트가 없으므로 먼저 무엇을 배울지 추측해 보세요. :)

@SvenDowideit 이 작업을 하고 있습니까? 오늘 해킹할까 생각중이었는데

천천히 코드에 익숙해지고 가십시오. 이제 단위 테스트를 작성하는 것이 너무 재미있습니다. 테스트 커밋을 사용하여 도움을 받을 수 있습니다.

내가 할 것이다 :)

이 기능도 보고 싶습니다. 우리는 3개의 다른 모드에서 실행할 수 있는 시스템을 가지고 있으며 각 모드에 대해 1개의 3개의 다른 컨테이너를 배포하고 싶습니다. 이는 CMD만 다른 3개의 거의 동일한 도커 파일을 의미합니다. 그러나 경로는 디렉토리일 뿐이고 디렉토리는 ADD 명령의 컨텍스트이기 때문에 지금은 이 작업을 수행할 수 없습니다.

그래서: 나에게서 +1!

이것은 #1618과 동일한 최종 목표를 가질 수 있는 것 같습니다(비록 다른 접근 방식이 있음에도 불구하고). 여기에 설명된 대로 여러 Dockerfile 및 포함 시스템과 비교하여 여러 이미지를 생성하는 여러 TAG 명령이 있는 단일 Dockerfile을 사용하는 것이 좋습니다. 생각?

Dockerfile을 파이프할 수 있는 것처럼 경로도 지정할 수 있어야 합니다. #1618이 무엇인지 알고 싶지만 이것이 더 많은 가능성을 제공한다고 생각합니다.

이것은 내가있는 곳입니다 : https://github.com/peterbraden/docker/compare/2112-specify-dockerfile?expand=1

문서에 Dockerfile이 포함된 디렉토리가 빌드 컨텍스트라고 명확하게 명시되어 있지 않다는 사실 때문에 문제가 생겼습니다. 빌드 컨텍스트가 현재 작업 디렉토리라는 잘못된 가정을 했으므로 대신 Docerfile에 대한 경로를 전달하면 현재 디렉토리에 있는 파일 중 현재 작업 디렉토리에서 추가하려고 시도한 파일이 "해당 파일 또는 디렉토리 없음" 오류와 함께 폭격되었습니다.

동일한 오류가 발생합니다. 모든 아이디어

도커 빌드 도커 파일

컨텍스트 업로드 중

2013/12/11 21:52:32 오류: 빌드 오류: Tarball이 너무 짧습니다.

@bscott 대신 docker build . 를) 시도하십시오. 빌드는 파일이 아닌 디렉토리를 사용하며 이것이 "빌드 컨텍스트"입니다. :)

작업 Thx!, 다른 Docker 파일 중에서 선택하고 싶습니다.

나에게서 +1.

내 소스에서 여러 이미지를 만들어야 합니다. 각 이미지는 동일한 컨텍스트를 구축해야 하는 별도의 관심사입니다. 단일 Dockerfile을 오염시키는 것(#1618에서 제안한 대로)은 엉뚱한 일입니다. 내 소스에 3개의 개별 <image-name>.docker 파일을 보관하는 것이 훨씬 깨끗할 것입니다.

나는 이런 것이 구현되는 것을 보고 싶습니다.

이것은 처음에 보이는 것보다 구현하기가 더 어렵습니다. ./Dockerfile 가 꽤 많이 들어간 것 같습니다. 초기 조사 후에 최소한 다음 파일이 포함됩니다.

api/client.go
archive/archive.go
buildfile.go
server.go

client 용도 archive 타르 build context 하고 그것을 보내는 server 후 사용하는 archive 풉니에 build context 바이트를 buildfile .

가장 쉬운 구현은 client 및 archive 를 변경하여 이 옵션을 통해 지정된 파일로 tar의 ./Dockerfile 를 덮어쓰는 것 같습니다. 더 조사하겠습니다.

@thedeeno 정말 빨리 살펴보고 변경 사항을

나에게서 +1!

나는 # 1618과 # 2112를 모두 따라 왔으며 이것이 가장 우아한 솔루션입니다.

내 개발에서 이 기능이 매우 편리한 한 가지 특별한 사용 사례가 있습니다... "웹" 및 "작업자" 역할이 모두 있는 응용 프로그램에서 작업할 때. 이 상황에 대해 "Dockerfile-web"과 "Dockerfile-worker"라는 두 개의 도커 파일을 만들고 싶습니다. 그런 다음 둘 다 빌드하고 태그를 지정하고 내 이미지 리포지토리로 푸시할 수 있습니다. 그런 다음 로드 밸런서와 여러 작업자 뒤에서 여러 웹 프런트 엔드 인스턴스를 실행하여 대기열에 푸시되는 작업을 처리합니다.

#2745의 대안으로 +1.

+1

Dockerfile 가 하드코딩되어 있고 빌드 컨텍스트가 강제로 Dockerfile의 디렉토리가 되며 명령줄 플래그로도 재정의할 수 없다는 사실에 놀랐습니다. 이는 개발, 테스트 및 배포 도구로서의 Docker의 유용성과 유연성을 심각하게 제한합니다.

+1
나는 그 변화에 감사 할 것입니다

+1
정말 필요합니다.

5033은 이 기능을 허용해야 합니다. cc/@crosbymichael

@shykes 이 변화에 대해 어떻게 생각하세요? 나는 당신이 동의했거나 같은 문제를 해결하기 위한 더 나은 해결책을 알고 있다고 생각하지 않습니다.

나는 주저한다.

한편으로 나는 사람들이 자신의 빌드를 사용자 정의하는 능력을 제한하고 싶지 않습니다.

반면에 _run -v /host:/container_ 및 _expose 80:80_과 같은 일이 일어날까 걱정됩니다. 다시 말해, 자신이 무엇을 하고 있는지 알고 있는 1%는 멋진 사용자 정의를 추가할 수 있고 나머지 99%는 자신의 발에 총을 쏠 수 있습니다.

예를 들어 일반 볼륨 대신 호스트 탑재 볼륨으로 시작하는 새로운 Docker 사용자가 많이 있습니다. 그리고 너무 많은 사람들이 정당한 이유 없이 호스트당 한 번 이상 실행할 수 없는 이미지를 게시했기 때문에 _expose 80:80_ 구문을 모두 사용하지 않아야 했습니다.

그래서 제 질문은: _docker build로 반복적으로 빌드할 수 없는 많은 소스 리포지토리를 가질 위험이 있습니까?

@shykes 이 Dockerfile 제한 때문에 _because_ 설명하는 문제가 발생했습니다. 다음은 몇 가지 사용 사례입니다.

1. 아티팩트(이 경우 JAR 파일)를 생성하는 Docker 기반 빌드 환경이 있습니다. 빌드 환경은 실행 환경(다른 종속성, 더 큰 이미지 등)과 다르므로 빌드 환경을 런타임으로 상속하고 싶지 않습니다. Dockerfile 빌드를 갖는 것이 가장 합리적입니다. JAR 주변에서 런타임 환경을 실행합니다.따라서 빌드 환경을 빌드 및 실행하고 JAR을 생성하는 별도의 Dockerfile.build 파일이 있습니다.하지만 Dockerfile을 지정할 수 없기 때문에 scripts/build docker build < Dockerfile.build 를 수행한 다음 호스트 볼륨 w/ docker run -v ... 를 마운트하여 빌드를 실행하는 scripts/build 파일입니다. 대신 docker build -t foobar/builder -f Dockerfile.build , docker run foobar/builder , docker build -t foobar/runtime , docker run foobar/runtime 하고 두 Dockerfile에서 모두 ADD 명령을 사용할 수 있기를 바랍니다.
2. ONBUILD 명령어를 사용하면 FROM 명령어에 루트 Dockerfile이 있지만 여전히 프로젝트의 루트를 그들의 빌드 컨텍스트. 이는 예를 들어 다양한 환경에 대한 구성 매개변수를 가져오는 데 유용합니다. 루트 Dockerfile은 여전히 ​​유용한 컨테이너를 생성하지만 나머지는 우리가 필요로 하는 다른 변형을 생성합니다.

그래서 내가 정말로 원하는 것은 "Dockerfile 위치/이름"에서 "빌드 컨텍스트"의 개념을 분리할 수 있는 것입니다. 물론 그렇게 할 수 있는 잠재적인 방법은 많이 있지만 나에게는 비교적 간단한 방법처럼 보입니다.

@cap10morgan 혹시 귀하의 예 1이나 알려줄 수 있습니까? 그래서 나는 우리가 같은 것에 대해 이야기하고 있는지 확인하고 놀 수 있습니다.

@shykes https://github.com/shykes 이것이 바로 이식성의 꿈이 아닙니까?
이미지 인덱스는 무엇을 위한 것입니까? 빌드 환경이 필요한 이유
휴대용으로도?

일부 빌드 프로세스에는 바닐라로 가능한 것보다 더 많은 것이 필요합니다.
도커파일. 또한 컨텍스트당 하나의 Dockerfile을 적용합니다(이는
이 요청은 수정을 목표로 함)이 매우 제한적입니다.

이것은 실제로 우리 팀에 영향을 미칩니다. 우리의 설정에서 우리는 여러
동일한 "컨텍스트"의 이미지. --file 옵션을 추가하면
우리가 정말로 하고 싶은 것 - foo.docker 와 bar.docker
우리의 저장소 루트에. 대신 복사할 bash 스크립트를 작성하게 됩니다.
컨텍스트를 설정하고 이름을 바꾸기 위해 임시 위치에 수많은 파일
명명된 도커 파일을 Dockerfile 마법처럼 docker build 넣을 수 있습니다.
일하다.

나에게 이러한 고리는 정당한 이유가 있습니다. 우리 팀의 누군가가 원하는 경우
이미지를 빌드하려면 사용자 지정 스크립트를 실행하여 작업을 완료해야 합니다.
이 제한을 고수함으로써 피할 수 있다고 생각하는 정확한 것.

2014년 4월 7일 월요일 오후 4시 23분에 Solomon Hykes [email protected]이 다음과 같이 작성했습니다.

@cap10morgan https://github.com/cap10morgan 지적할 수 있는 기회
나는 당신의 예 1, 또는 그것을 근사하는 무엇입니까? 그래서 나는 놀 수 있다
우리가 같은 것에 대해 이야기하고 있는지 확인하십시오.

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

@shykes 이것이 '고정되지 않은' 것처럼

내 사용 사례는 테스트에 프로덕션 이미지와 다른 요구 사항이 있는 도커로 빌드하려는 앱이 있다는 것입니다. 나는 이것이 꽤 일반적이라고 생각합니다.

이 문제와 .dockerignore 문제(https://github.com/dotcloud/docker/pull/3452)(내 전체 .git 디렉토리를 빌드 컨텍스트에 복사)는 도커를 사용해 볼 때 처음 부딪히는 다소 중요한 고충입니다. 지난 며칠 동안 우리 프로젝트에 대한 정보가 없었고 나에게는 별 생각이 없어 보이지만 이러한 문제에 대한 반발이 있는 것 같습니다.

이것도 필요하다는 점에서 +1 - 여러 마이크로 서비스가 개발 중인 단일 코드 기반이 있습니다. 여러 이미지를 생성할 수 있기를 원합니다. 예를 들어 하나의 이미지에는 services/base/* 및 services/fooservice/* 가 포함되어 있습니다. services/base/* 및 services/barservices/* 및 staticfiles/*를 포함하는 다른 이미지.
Docker가 해당 폴더를 컨텍스트로 처리하고 폴더 구조에서 상위에 있는 항목을 추가할 수 없기 때문에 Dockerfile을 서비스 폴더 안에 배치할 수 없습니다. 두 개의 Dockerfile은 이름이 같으므로 루트에 둘 수 없습니다.
우리가 가진 유일한 솔루션은 Dockerfile을 서비스 폴더에 배치한 다음 선택한 Dockerfile을 구문 분석하는 사용자 지정 스크립트를 작성하고 추가할 경로(모두 프로젝트 루트에 대해 지정됨)를 결정한 다음 새 폴더에 복사하는 것입니다. 임시 폴더에서 선택한 Dockerfile을 새 폴더의 루트에 복사하고 마지막으로 "docker build tempfolder"를 실행합니다. 그게 정말 필요한가요?
Dockerfile이 어디에 있고 컨텍스트가 어디에 있는지 별도로 "도커 빌드"라고 말할 수 있다면 훨씬 간단했을 것입니다.

이 문제가 발생하면 .. 어떤 종류의 수정 사항을 보고 싶습니다.

+1, 이 제한 사항을 코딩하는 것은 큰 고통입니다.

빌드 컨텍스트와 별도로 Dockerfile 경로를 지정하는 -f 플래그의 경우 +1

Docker는 훌륭한 도구이지만 컨텍스트와 특정 Dockerfile의 긴밀한 결합은 확실히 Docker 팀을 약간 오염시킵니다. 디렉토리 구조가 항상 '컨테이너/하위 시스템' 구조를 정확히 반영하는 것은 아닙니다.

고치기 얼마나 힘들까요? 그리고 이에 대한 몇 가지 PR이 있었지만 무시되었습니다.

관련된 간단한 추가 사항은 컨텍스트에 추가하고 싶지 않은 항목에 대한 무시 파일을 갖는 것입니다. 예, .git ...

이로 인해 실제로 지금은 Docker를 건너뛰고 Vagrant + Ansible로 돌아갈 수 있습니다. 멋진.

@davber .dockerignore는 -> #6579에 있습니다.

그러나 네, 기여 관리는 지금 약간 고통스럽고 지금까지 docker에서 보기 드문 낙담한 것 중 하나입니다. 나는 그들이 단지 조금 희망적으로 압도되었다고 생각합니다.

Docker 팀, 어떻게 사람들이 이와 같은 내용을 검토하고 받을 수 있습니까? 이것이 실제로 실제로 나쁜 이유와 프로젝트에서 이 문제를 피하는 방법에 대한 명확한 생각이 있다면 듣고 싶지만 설명할 수 있는 간단한 문제와 해결해야 할 간단한 문제처럼 보입니다.

/cc @shykes @creack @crosbymichael @vieux

-f 플래그의 경우 +1입니다. 또한 빌드 설정을 재정의하는 DOCKERFILE 환경 변수입니다.

@jakehow 네, 확실히 압도당하는 요소가 있습니다. 모든 메인테이너에 대해 적어도 1,000명의 사람들이 적극적으로 무언가를 요청하고 아직 완료되지 않은 이유에 대한 자세한 설명을 요구합니다. 우리는 정말 최선을 다하고 있으며 #docker 및 #docker-dev irc 채널을 방문하면 Firehose를 직접 목격할 수 있습니다.

그러나 이 경우 Dockerfile과 소스 디렉토리의 1-1 매핑을 유지하는 것이 더 나은 이유에 대한 명확한 답변이 있습니다. 다시 한 번 반복하겠습니다. 도커 빌드의 자체 설명 속성을 유지하려고 합니다. _대역 외의 다른 정보 없이_ 소스 코드 디렉토리를 가리키고 이 디렉토리에서 업스트림 개발자의 사양과 정확히 일치하는 이미지를 빌드할 수 있다는 사실은 매우 강력하고 Docker의 주요 차별화 요소입니다.

물론, 디렉토리 X와 Dockerfile Y를 즉석에서 동적으로 결합할 수 있다는 것은 약간 편리합니다. 그러나 그것은 어리석은 일, 즉 빌드의 자체 설명적인 특성을 깨뜨리는 일을 너무 쉽게 만듭니다. 그리고 그것은 엄청나게 가난한 트레이드오프처럼 보입니다. 따라서 이 기능을 구현하지 않기로 결정했습니다.

"1 소스 리포지토리, 여러 이미지"의 예에 관해서는 예, 필요하다는 데 동의합니다. 우리에게 필요한 것은 단일 소스 디렉토리가 여러 빌드 대상을 정의하기 위한 Docker 표준 방법입니다. 이는 다중 부분 Dockerfile을 사용하거나 _이 Dockerfile을 모호하지 않은 방식으로 나열하고 선택할 수 있도록 하는 잘 정의된 파일 이름 규칙이 있는 한 다중 Dockerfile로 수행할 수 있습니다.

누군가가 이것을 기여하고 싶다면 우리는 그것을 병합하고 싶습니다. 그리고 평소와 같이 처음 기여하는 사람들을 기꺼이 도울 것입니다. IRC에 와서 인사를 하면 시작하도록 하겠습니다.

@davber 나는 Vagrant가 프로젝트당 1개의 설명 파일에 대해 동일한 제한을 가지고 있다는 인상을 받았습니다(아마도 비슷한 이유로). Vagrant로 다시 전환하면 문제가 정확히 어떻게 해결됩니까?

@gabrtv 다중 이미지를 다시 가져오시겠습니까? 잠정적인 제안은 다음과 같습니다.

$ ls | grep Dockerfile
Dockerfile
db.Dockerfile
frontend-prod.Dockerfile
frontend-dev.Dockerfile
$ docker build -t shykes/myapp .
Successfully built shykes/myapp/db
Successfully built shykes/myapp/frontend-dev
Successfully built shykes/myapp/frontend-prod
Successfully built shykes/myapp
$ docker build -t shykes/myapp2 --only frontend-dev .
Successfully built shykes/myapp2/frontend-dev

그 제안은 우리에게 잘 작동할 것이며 다른 사람들을 위해 다른 문제도 해결하는 것을 볼 수 있습니다.

@shykes 나는 Dockerfile 형식의 복잡성을 증가시키는 것이 하나의 Dockerfile을 유지하기 위한 가치 있는 절충안이라고 생각하지 않습니다.

예를 들어 makefiles - 프로젝트에 'Makefile'이 없는 것보다 더 일반적이지만 make를 사용하면 '-f'로 다른 makefile을 지정할 수도 있습니다.

또한 소스 폴더와 이미지 간의 1:1 매핑은 사용자가 생각하는 것보다 덜 유용하다고 생각합니다. 최소, 따라서 더 작은 이미지.

"그래서 내 질문은: docker build로 반복적으로 빌드할 수 없는 많은 소스 리포지토리를 가질 위험이 있지 않습니까?"

그러나 이것이 이미 사실이라고 생각합니다. 일부 프로젝트 요구 사항은 단일 빌드 방법이 실용적이지 않다는 것을 의미하며 Dockerfile 구문은 많은 구성 가능성을 허용하지 않습니다. ...).

나는 또한 --only 제안을 특히 좋아하지 않습니다. 사람들이 빌드할 때 /want/ 모든 것이 아니라 특정 컨텍스트를 빌드하는 것이 기본이라고 생각합니다. docker 빌드를 실행할 때 /only/ Dockerfile 가 실행되기를 원합니다. 그러나 나는 또한 구축할 수 있는 또 다른 이미지를 가질 수 있는 능력을 원합니다.

내 이해에 따르면 여기서 문제는 다음과 같은 사실에 있습니다.
Dockerfile 파이핑(cat Dockerfile | docker build -) 작업을 느슨하게 합니다.
ADD 및 CP용 디렉토리.

도커 빌드용 플래그를 추가하여 문제를 해결할 수 있습니다.
소스 폴더 내용이 있는 위치를 지정하시겠습니까?

cat Dockerfile | docker build --cwd=~/my_docker_data_files -

이 제안에서 --cwd 플래그는 ADD 및 CP에 대한 기본 폴더를 지정합니다.
명령.

2014-06-29 19:42 GMT+10:00 Peter Braden [email protected] :

당신은 "그래서 내 질문은: 우리가 많은 소스를 가질 위험을 감수하지 말라는 것입니다.
docker build로 반복적으로 구축할 수 없는 저장소"

그러나 이것이 이미 사실이라고 생각합니다. 일부 프로젝트 요구 사항은
단일 빌드 방법은 실용적이지 않으며 Dockerfile 구문은
많은 구성 가능성을 허용합니다(설계상으로
변경하는 것...).

나는 또한 --only 제안을 특히 좋아하지 않습니다. 내가 생각하는 기본
사람들이 구축할 때 /원하는/은 특정 컨텍스트가 구축되기 위한 것입니다.
전부는 아닙니다 - 도커 빌드를 실행할 때 /only/ Dockerfile이
실행됩니다. 하지만 나는 또 다른 이미지를 가질 수 있는 능력을 원합니다.
세워짐.

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

@llonchj는 실제로 https://github.com/dotcloud/docker/pull/5715를 해결하고 이미 마스터에 병합되었습니다.

@shykes는 확실히 다른 다중 이미지 PR에 열려 있지만 #5715를 보고 이 특정 PR이 더 이상 관련이 있는지 궁금합니다.

@peterbraden 의 원래 의견에 따라 ...

파일을 추가하고 여러 dockerfile을 가질 수 있도록 [command redacted]를 지정할 수 있으면 좋을 것입니다.

@cap10morgan 당...

그래서 내가 정말로 원하는 것은 "Dockerfile 위치/이름"에서 "빌드 컨텍스트"의 개념을 분리할 수 있는 것입니다.

바로 #5715가 하는 일 아닌가요? 내가 이해한 대로:

$ cd myapp
$ ls Dockerfile
Dockerfile
$ docker build -t gabrtv/myimage
Successfully built gabrtv/myimage
$ ls subfolder/Dockerfile
Dockerfile
$ tar -C subfolder -c . | docker build -t gabrtv/myotherimage -
Successfully built gabrtv/myotherimage

나는 이것이 repo 루트에서 다중 이미지 빌드를 해결하지 못한다는 것을 알고 있지만(나도 동의할 것입니다), 이 특정 PR/구현이 #5715로 이제 중단될 수 있는지 궁금합니다.

@gabrtv #5715는 항상 작동하는 단일 명령을 갖는 @shykes 기준에 맞지 않는 것 같습니다. tar -C subfolder -c . | docker build -t gabrtv/myotherimage - 는 나에게 매우 명확하지 않습니다.

또한 repo 레이아웃과 관련하여 개발자에게 성가신(부담스럽지 않은 경우) 제약을 부과합니다. 고칠 수는 없지만 "아, 전체 저장소를 재구성해야 합니다"는 상사가 Docker로 전환하도록 설득하는 데 도움이 되지 않습니다.

저는 개인적으로 @shykes 의 가장 최근 제안을 아주 좋아합니다. 잠재적으로 여러 개의 .dockerfile(단지 .docker가 아닌 이유가 무엇입니까?) 파일이 기본적으로 모두 빌드됩니다. 이를 통해 어떤 일이 있어도 하나의 명령으로 쉽게 시작하고 실행할 수 있으며 나중에 최적화할 수 있습니다.

구현에 따라 모든 이미지에 대해 빌드 컨텍스트를 한 번만 업로드할 수 있으므로 여러 이미지를 빌드하는 비용을 줄일 수 있습니다. .dockerignore가 없기 때문에 빌드 컨텍스트가 수백 메가바이트이고 컨텍스트가 업로드될 때까지 꽤 기다려야 하므로 이것이 좋을 것입니다.

@rattrayalex 는 저를 믿으세요. 저는 "항상 작동할 단일 명령을 갖는 것"이라는 목표에 동의합니다. 코드를 작성하고 PR을 제출하게 될 좋은 기회가 있습니다. :눈짓:

제 요점은 프로젝트 조직의 관점에서 Allow specifying of a dockerfile as a path, not piping in 라는 제목의 기발한 문제가 아니라 다른 곳에서 논의해야 한다는 것입니다.

1. 여기서 논의의 대부분은 https://github.com/dotcloud/docker/issues/2112#issuecomment -47448314의 @shykes 새로운 제안과 관련이 없습니다.
2. 원래 기본 문제(Dockerfile에서 빌드 컨텍스트 분리)는 #5715로 해결되지만 모든 사람이 좋아하는 것은 아닙니다.

@llonchj 인용...

내 이해에 따르면 여기의 문제는 Dockerfile(cat Dockerfile | docker build -)을 파이핑할 때 ADD 및 CP에 대한 작업 디렉토리를 느슨하게 한다는 사실에 있습니다.

다시 말해서, docker build -t <image> -f <path-to-dockerfile> 에 대해 괜찮다면 @shykes 제안을 위한 PR을 함께 넣을 수 있을 때까지 기능적으로 동등한 해결 방법으로 tar -C <path-to-context> -c . | docker build -t <image> - 를 사용할 수 있습니다.

나는 이것을 닫고 다른 곳에서 새로운 토론을 시작할 것을 제안합니다(메일링 리스트? 새로운 이슈?).

오늘 이 문제에 관심을 가져주신 모든 분들께 감사드립니다.

@shykes 추론

@gabrtv 여기 있는 거의 모든 논의가 특히 이 문제와 관련이 있다고 생각하며 마침내 여기에서 논의되는 것을 보게 되어 기쁩니다. 문제의 제목과 일부 '발견' 게시물은 약간 관련이 없을 수 있으므로 새로운 문제 또는 이 문제를 참조하는 깨끗한 시작의 PR이 좋을 것입니다.

@shykes 의견의 제안은 나에게 솔루션처럼 들립니다. 참조를 위해 볼 수 있거나 볼 수 있는 어딘가에서 이에 대한 이전 작업이 수행되었습니까?

"Dockerfile.frontend-prod"가 더 좋지 않아 모든 Dockerfile이
디렉토리에서 자연스럽게 함께 정렬됩니까?

죄송합니다만, 그건 어리석은 일입니다. 내 저장소가 100개의 서비스를 빌드한다면 루트에 100개의 Dockerfile을 갖고 싶지 않습니다. (예시: dotCloud PAAS repo.)

100개 섹션이 있는 거대한 단일 Dockerfile도 원하지 않습니다.

100개의 Dockerfile이 필요하고 별도의 디렉토리에 저장하고 싶습니다.

(아니요, 거의 모든 서비스가 각 서비스 디렉토리의 _외부_에 있는 공통 코드와 라이브러리를 사용하기 때문에 각 서비스를 자체 디렉토리에 구축할 수 없습니다.)

다시 말하지만, Dockerfile에 대한 경로를 지정하는 추가 플래그가 있는 이유(기본값은 Dockerfile )가 왜 그렇게 큰 문제인지 이해가 되지 않습니다.

또한 현재 제안( <imagename>.Dockerfile )은 자동화된 빌드의 현재 디자인과 전혀 매핑되지 않습니다. 내 빌드 시스템 중 하나의 리포지토리가 손상되면 공격자가 내 모든 리포지토리에 과부하가 걸릴 수 있습니다...?

@jpetazzo 가장 합리적인 사람들처럼 나는 의견 불일치는 환영하지만 바보라고 불리는 것은 싫어합니다. 동료의 지성을 모욕하지 않고 자신의 주장을 제시하기 위해 노력하십시오. 감사 해요.

_다시 말하지만, Dockerfile에 대한 경로를 지정하기 위해 추가 플래그를 갖는 것이 왜 그렇게 큰 문제인지 이해가 되지 않습니다.

위에서 구체적인 주장을 했습니다. 자유롭게 읽고 반론을 제시하십시오.

Re: 난잡함. @gabrtv 는 IRC에 대해 동일한 우려를 갖고 있습니다. 약간의 토론 후에 우리는 이 대안을 생각해 냈습니다.

$ ls Dockerfile Dockerfiles/*
Dockerfile
Dockerfiles/frontend-prod
Dockerfiles/frontend-dev

같은 생각이지만 루트 저장소에 있는 개별 파일이 적습니다.

또한 현재 제안(.Dockerfile)은 자동화된 빌드의 현재 디자인과 전혀 매핑되지 않습니다. 내 빌드 시스템 중 하나의 리포지토리가 손상되면 공격자가 내 모든 리포지토리에 과부하가 걸릴 수 있습니다...?

자, 이제 이름이 어떻게 됩니까? 일반 Dockerfile과 함께 "abc"라는 리포지토리가 있는 경우 "abc"라는 이름으로 생성된 이미지에 대해 의미가 있습니다. "Dockerfile.abc" 및 "Dockerfile.zzz"가 포함된 "xyz" 리포지토리가 있는 경우 빌드 이름을 "xyz-abc" 및 "xyz-zzz"로 지정하는 것이 좋습니다.

나는 당신과 비슷한 상황에 있습니다 (공통 부분이있는 자체 하위 폴더에 많은 서비스가 있음). 빌드 시간에 Dockerfile을 사용하도록 설정하는 명시적인 옵션은 내 생각을 더 쉽게 만들지 만 다음도 볼 수 있습니다. 내가 원하는 것을 얻을 수 있도록 "Dockerfile.*" 제안을 이미 출시된 "tar 파일을 컨텍스트로" 결합하는 방법 - 각 서비스의 루트 dockerfiles는 빌드 이미지(컴파일러 및 기타 포함)를 생성하고 실행되면 이미 컴파일된 실행 파일과 런타임 종속성만 있는 이미지를 설명하는 프로덕션 Dockerfile(서비스 폴더 자체에서 가져옴)이 포함된 컨텍스트 tar를 출력합니다.

사실 내 빌드 환경이 모든 서비스에 대해 거의 동일하고 런타임에 매개변수를 전달하여 생성하려는 서비스 릴리스 컨텍스트 tar를 알릴 수 있기 때문에 이제 단일 루트 Dockerfile로 이것을 작성하고 있습니다.

@shykes 글쎄, 우리가 Dockerfile/* 을 가질 수 있다면 한 단계 더 나아가 "docker build"가 현재 디렉토리의 모든 하위 폴더에서 "Dockerfile.*"이라는 파일을 재귀적으로 검색하도록 하는 것이 어떻습니까? 현재 디렉토리의 컨텍스트에서 모두 실행하시겠습니까? 그리고 우리가 if에 있는 동안 "-f"와 같이 그 중 하나를 구축할 수 있는 옵션을 제공합니까? :)

... 바보라고 불리는 것을 싫어합니다

나는 "바보"가 불쾌하게 느껴질 수 있다는 것을 몰랐습니다. 나는 단지 "서투른"을 의미했으며, 따라서 단어를 오용한 것에 대해 사과드립니다.

귀하의 구체적인 주장은 "사람들이 Dockerfile을 임의의 장소에 배치하고 꼭 필요한 경우가 아닐 때 -f 체계적으로 사용하는 것을 원하지 않습니다"였다고 생각합니다. 맞나요? 이 경우 저장소 상단에 하나의 Dockerfile을 지정하고 다른 Dockerfile을 나열하는 것이 합리적입니다. 해당 파일이 없으면 빌더는 작동을 거부(또는 경고 발행)할 수 있으며, 하나의 Dockerfile만 나열하는 경우 빌더도 경고를 발행할 수 있습니다. -v 및 -p 와 병행하는 것은 적절하지 않다고 생각합니다.

@aigarius 그렇게 하면 각 하위 Dockerfile을 자식 이미지에 매핑하는 방법이 덜 명확할 것입니다. ./Dockerfile.* 및 ./Dockerfiles/* 의 장점은 결과 이미지의 이름을 지정하는 데 사용할 수 있는 단일 네임스페이스에 매핑된다는 것입니다. 반대로 ./foo/Dockerfile.db 와 ./bar/Dockerfile.db 가 있고 docker build -t shykes/myapp . 가 있는 경우 shykes/myapp/db 무엇입니까?

어떤 것이 shykes/myapp/db라고 부를까요?

어느 것도 아니다. 이러한 시나리오에서는 Dockerfile의 전체 경로를 이름으로 인코딩하므로 "shykes/myapp/bar/db" 및 "shykes/myapp/foo/db"가 됩니다. 이것은 불편할 정도로 Java 네임스페이스에 가까워지지만 그것이 좋은지 나쁜지 결정하는 것은 다른 사람들에게 맡길 것입니다.

@shykes : Vagrant와 관련하여 저와 다른 몇몇 사람들은 Docker의 일부 겹치는 기능에 Vagrant를 사용합니다. 따라서 저는 현재 다중 머신 빌드(Vagrant에서 다중 머신 정의와 함께 수행)가 Dockerfile을 사용할 때 더 어색해지지 않는다는 확신이 필요합니다. 문제는 "컨텍스트"가 Vagrant에서 훨씬 더 유연하다는 것입니다. 공유 디렉토리를 통해 모든 위치에서 컨텍스트를 즉석에서 가져올 수 있고 언어도 마찬가지이므로 하나의 서비스(또는 기계)를 구축하려는 경우 나는 환경 변수를 설정하고 그것을 '유행/프로비저닝'할 수 있습니다. 나는 매일 그 방법을 사용하여 내 시스템에서 몇 가지 서비스를 생성하거나 프로비저닝합니다. 그리고 성장하는 Vagrantfile에 너무 짜증이 나면 개별 서비스나 측면을 설명하는 하위 Vagrantfile을 쉽게 '로드'할 수 있습니다.

여러 Dockerfile을 처리하기 위한 구체적인 제안과 관련하여 예, 개별 서비스에 대한 논리를 나눌 수 있습니다. 엄청난. 그러나 나는 종종 하나의 서비스를 별도로 구축하기를 원하거나 구축해야 하기 때문에 여전히 하나의 특정 Dockerfile을 지정해야 할 필요가 있습니다...

따라서 여기서 내 문제는 두 가지입니다.

1. 모든 서비스에 대해 거대한 지저분한 파일을 얻지 않음
2. 해당 파일/파일 클러스터에서 하나의 특정 서비스를 구축할 수 있음

다시 말하지만, Docker는 천재적인 아이디어이자 도구입니다. 그래서 저는 저와 같은 사람들이 특정 종류의 기능이나 사용 사례를 위해 Vagrant를 포기하기를 바랍니다.

위에서 철저하게 다룬 것을 반복한다면 미안하지만 '-f' 옵션을 지원하는 것보다 어떤 솔루션이 더 나은지 알 수 없습니다. 즉, 컨텍스트 루트에 있는 Dockerfile에 대한 뿌리 깊은 종속성으로 인한 모듈로 구현 문제로 인해 어떠한 단점도 보이지 않습니다.

'-f' 옵션을 사용하면 위의 Dockerfiles/ 접근 방식과 같이 원하는 대로 하위 디렉터리와 하위 Dockerfile을 확실히 구조화할 수 있습니다. 예, 정확한 동작을 모방하기 위해 간단한 한 줄 배셔가 필요합니다...

공유와 유연성 사이에 긴장이 있는 것 같습니다.

공유가 가장 중요한 기능이라면 예, 표준 dockerfile
맞는 말이다.

공유가 가장 중요한 기능이라고 생각하지 않습니다. 공유가 이루어집니다
이미지를 통해.

또한 명시적으로 공유할 수 없는 프로젝트에 도커를 사용합니다. 에
이러한 경우 유연성은 우리에게 훨씬 더 가치가 있습니다. 에서 많이 들린다.
스레드 any는 이 동일한 위치에 있습니다.

목적이 지정된 -f 옵션은 우리에게 필요한 유연성을 제공합니다. 한편,
빌드 컨텍스트에 대한 절대 경로를 지정할 수도 있습니다.
일하다.
2014년 7월 3일 오후 6시 "David Bergman" [email protected]이 다음과 같이 썼습니다.

위에서 철저하게 다룬 것을 반복한다면 미안하지만 나는 보지 못한다.
어떤 솔루션이 '-f' 옵션을 지원하는 것보다 낫다. 즉, 모듈로
에 대한 뿌리 깊은 종속성으로 인한 구현 문제
컨텍스트 루트에 있는 Dockerfile, 나는 어떤 단점도 보지 못한다.
그것.

'-f' 옵션을 사용하면 하위 디렉토리를 확실히 구조화할 수 있습니다.
및 Dockerfiles/와 같이 원하는 하위 Dockerfiles/
위에 접근합니다. 예, 그러면 간단한 한 줄 배셔가 필요합니다.
정확한 행동을 모방 ...

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

-f 는 최소한의 "놀라움"으로 가장 많은 유연성을 제공한다는 데 동의했습니다(개인적으로 이러한 플래그가 있다고 가정하고 이 스레드에 오기 전에 시도했습니다).
-c 디렉토리나 tar 중 하나를 추가하여 컨텍스트를 제공하는 것도 훌륭한 추가 기능인 것 같습니다. 이렇게 하면 대규모 빌드 프로세스에서 상수 cd 가 제거됩니다. 회사에서.

또한 docker build -f foo/bar/Dockerfile -c foo/ 지침이 포함된 README는 나에게 불쾌감을 주는 것처럼 들리지 않습니다.
또한 docker build 가 Dockerfile s를 쉽게 검색할 수 있다는 데 동의했습니다. 이런 식으로 리포지토리는 다음과 같이 구성됩니다.

-- README
-- foo/
---- Dockerfile
---- etc
-- bar/
---- Dockerfile
---- etc
---- subbar/
------ Dockerfile
-- context/
---- etc

가능한 모든 이름 충돌( repo/bar/subbar )을 피하고 금액을 추론하기 쉽고 많은 개발 컨텍스트에서 의미가 있어야 합니다. 그것은 모두 쉽게 사용할 수 있도록 할 docker build 많은 컨텍스트를 구축 할 것, 그리고 docker build -f 불필요한 생략 할 수있는, Dockerfile 에서 가장 컨텍스트.

-f 가 Docker가 포함된 디렉토리가 아닌 aa 파일인 경우 개발자가 docker build 가 실행될 때 빌드되지 않은 dockerfile을 가질 수 있도록 그것도 작동해야 합니다.

이것이 손실되지 않도록 어제 @shykes 와의 IRC 토론에서 그는 이것을 구현하는 다른 아이디어를 가지고 있었습니다.

• 생성할 각 이미지에 대해 "INCLUDE foo/bar/Dockerfile AS bar-foo"와 같은 새로운 형식의 몇 줄만 포함하는 저장소의 루트에 마스터 Dockerfile이 있습니다.
• 별도의 이미지가 필요한 각 하위 프로젝트(예: foo 하위 프로젝트의 bar 모듈)는 foo/bar/Dockerfile에 일반 Dockerfile을 유지 관리합니다. 해당 Dockerfile의 경로(ADD 및 COPY용)는 여전히 리포지토리의 루트(마스터 Dockerfile이 있는 위치)인 컨텍스트 루트에 상대적입니다.
• "docker build -t mycorp/myapp ."에 대한 일반 호출 루트 Dockerfile에 등록된 모든 이미지를 빌드하고 이 예에서 "mycorp/myapp/bar-foo"와 같은 이름을 할당합니다.
• "docker build"에 대한 추가 명령줄 옵션은 "docker build -t mycorp/myapp --only bar-foo,baz-db"와 같이 선언된 이미지 중 일부만 빌드하기 위해 도입되어야 합니다.

사람들이 여전히 해결 방법을 찾고 있는 경우를 대비하여:

#!/bin/bash
ln -s Dockerfile-dev Dockerfile
docker build -t image/name-dev:latest .
rm Dockerfile

@샤이크스 핑? 특정 설계 솔루션에 대한 핵심 개발자 승인이 있는 경우 누군가가 이를 구현하고 끌어오기 요청을 할 가능성이 훨씬 더 높습니다.

-f 솔루션에 +1, 각 리포지토리가 이론상 자체 서비스를 배포해야 한다는 데 동의합니다. 어떤 사람들은 그 솔루션을 사치스럽게 여기지 않습니다. 내 특정 문제는 여러 요리 책이 있는 요리사 저장소가 있고 많은 서비스를 구축할 수 있어야 한다는 것입니다. 하지만 위의 디렉토리를 추가할 수 있어야 합니다. 따라서 컨텍스트를 루트에 유지하고 하위 디렉토리의 도커 파일을 가리키는 것이 최적입니다.

"-f"는 이미 주어진 이유로 구현되지 않을 것입니다.

빌드가 호스트 간에 정확히 동일하게 작동해야 하며 호스트가 특정 방식으로 설정하는 데 의존하는 것(즉, 임의의 위치에 Dockerfile이 있고 다른 위치에 컨텍스트)이 있으면 이 계약이 깨집니다.

나는 #7115가 아마도 이것에 대한 적절한 해결책이라고 생각합니다.

#7204 도 있는데, 이것은 이것에 대한 사용 사례의 많은 부분에도 적합하다고 생각합니다.

dockerfile에 구문을 추가하는 것과 관련된 두 가지 제안된 솔루션이 모두 마음에 들지 않습니다. 어느 쪽도 간단해 보이지 않습니다. #7115는 예를 들어 내 프로젝트 중 하나에서 '테스트' 이미지를 생성하고 '프로덕트' 이미지. #7204는 다른 문제를 해결하는 지나치게 복잡한 솔루션처럼 보입니다. -f 는 빌드에 _configurability_를 허용하지만 두 솔루션 모두 _sub_builds_를 처리합니다.

"빌드가 호스트 간에 정확히 동일하게 작동하는 것이 필수적입니다"에 대한 설명이 필요합니다. 이것이 왜 그렇게 중요한 원칙인지 모르겠습니다.

있는 그대로, 이 전체 문제에 대한 해결 방법으로 도커 환경을 생성하기 위해 make 를 사용하고 있습니다. 이는 이미 호스트 간 실행 명령을 위반하는 것처럼 보입니다.

나에게 -f 는 실용적인 솔루션처럼 보이지만 수용할 수 없다면 dockerfile을 완전한 프로그래밍 구문으로 바꾸는 것과 관련이 없는 솔루션을 생각할 수 있습니다.

빌드가 호스트 간에 정확히 동일하게 작동하는 것이 필수적입니다.

저도 이것이 왜 중요한지 더 듣고 싶습니다. 우리 팀은 현재
빌드 프로세스를 스크립팅하도록 강요 - 피하려는 정확한 것.

레지스트리에서 이미지를 다운로드하면 제대로 작동합니다. 그럴 필요 없어
그것을 구축. 호스트 간 반복성을 달성하는 것이 아닌가요? 빌드를 하는 이유
또한 호스트 간 반복 가능해야 합니까?

2014년 7월 28일 월요일 오전 10시 43분, Peter Braden [email protected]
썼다:

나는 구문을 추가하는 것과 관련된 2가지 제안된 솔루션을 모두 싫어합니다.
도커 파일. 어느 쪽도 간단해 보이지 않습니다. #7115
https://github.com/docker/docker/issues/7115 여전히 그렇지 않은 것 같습니다.
여러 유형의 이미지를 생성하려는 유스 케이스를 해결할 것입니다.
예를 들어 내 프로젝트 중 하나에서 수행하는 것처럼 단일 리포지토리에서
'테스트' 이미지와 '프로덕트' 이미지를 생성합니다. #7204
https://github.com/docker/docker/pull/7204
다른 문제를 해결하는 지나치게 복잡한 솔루션 -f 허용
_configurability_는 빌드에 대한 반면 이러한 솔루션은 모두
_서브_빌드_.

"빌드가 작동하는 것이 필수적입니다"에 대한 설명을 원합니다.
호스트에서 호스트로 정확히 동일합니다." 이것이 왜 그러한 키인지 모르겠습니다.
원칙.

그대로, 나는 도커 환경을 생성하기 위해 make를 사용하고 있습니다.
이 전체 문제에 대한 해결 방법은 이미 귀하의
host-to-host run-the-same 명령.

나에게 -f는 실용적인 솔루션처럼 보이지만 수용할 수 없다면
그렇다면 아마도 우리는 회전을 포함하지 않는 솔루션을 생각할 수 있습니다
dockerfile을 완전한 프로그래밍 구문으로 변환합니다.

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

내가 이해하는 한 핵심 아이디어는 git repo를 가져올 수 있고 Dockerfile이 있는 경우 "docker build -t mytag"를 실행할 수 있다는 것입니다. 그 안에 완전한 예상 빌드를 얻으십시오. 여기서 핵심은 사람들이 오해하거나 알지 못할 수 있는 사용자 정의 빌드 지침이 없다는 것입니다.
절충안이 될 수 있는 것은 기본적으로 모든 이미지가 사전 정의된 하위 태그로 빌드된 단일 컨텍스트에서 여러 Docker 이미지를 정의한 다음 가능한 많은 이미지 중 하나만 빌드하는 옵션을 가질 수 있는 방법입니다.
이렇게 하면 공통 빌드 구문이 유지되는 동시에 다음 두 가지가 모두 허용됩니다. 1) 하나의 컨텍스트에서 많은 다른 이미지를 생성합니다. 2) "고급" 옵션으로 그 중 하나만 생성하도록 선택합니다.
제안된 구문은 위의 내 의견에 설명되어 있습니다 - https://github.com/docker/docker/issues/2112#issuecomment -48015917

@algarius 감사합니다. 이 시점에서 _INCLUDE_ 구문에 대한 새로운 설계 제안을 열어야 한다고 생각합니다. 디자인 제안의 예는 #6802 또는 #6805를 참조하십시오.

프로세스는 다음과 같습니다.

• 디자인 제안 제출
• 디자인 제안 논의
• 디자인 제안을 승인합니다
• 디자인 제안에 대한 PR 보내기

솔직히 말해서, 빌드는 이제 실제로 반복할 수 없습니다.

내 Dockerfile에 RUN apt-get update && apt-get install build-essentials ruby python whatever 가 있으면 이미
내가 이미지를 구축하는 시점에 리포지토리에서 "최신"인 것이 무엇이든 상관없습니다. 만약에
일주일 후에 이미지를 빌드하면 다른 버전의 이미지를 얻을 수 있습니다.
내가 가진 것들에 대한 의존성.

@codeaholics 그러나 버전을 페깅하지 않은 것은 당신에게

아마 공정한 댓글

@codeaholics 빌드의 반복성이 완벽하지 않다는 것이 맞습니다. 비록 버전 고정과 같은 제어 옵션이 있고 더 많은 것을 제공해야 합니다. 그러나 적어도 빌드에는 항상 동일한 _진입점_이 있습니다. 이는 우리가 향후 더 나은 반복성을 도입할 수 있음을 의미합니다. 그러나 빌드가 Docker 자체의 업스트림에 있는 타사 도구에 종속되면 되돌릴 수 없습니다. 빌드의 반복성은 기본적으로 0이며 Docker의 향후 개선으로 이를 수정할 수 없습니다.

반복성뿐만이 아닙니다. 빌드가 _docker build_에서 검색할 수 없는 특정 인수 집합에 의존하는 경우 사용자 지정 도구는 빌드할 수 있는 세계에서 유일한 빌드 도구입니다. 네이티브, 검색 가능한 _docker 빌드_.

#7115의 @peterbraden 에서 여러 PUBLISH 호출 기능을 추가하면 이제 여러 이미지를 생성할 수 있습니다. 그런 다음 빌드할 하위 이미지를 선택하여 구성 가능성을 추가할 수 있습니다. 핵심은 구성 가능성이 _Docker가 검색할 수 있는 하위 이미지 세트 내에서 발생한다는 것입니다. 그렇게 하면 검색 가능성을 유지할 수 있습니다.

@shykes > 빌드가 Docker의 업스트림에 있는 타사 도구에 종속되면
자체 ... 빌드의 반복성은 기본적으로 0입니다.

나는 동의한다. 대부분의 Dockerfile은 apt 및 apt 저장소에 의존한다고 생각합니다.
끊임없이 변화하고 있습니다. 오늘날의 빌드는 빌드와 동일하지 않습니다.
어제. 구축된 이미지는 유일한 금본위제입니다.

반복성이 제한의 주요 원인이 아닌 경우 CI 플러그인
지원은 꽤 약한 대안처럼 보입니다. 빌드 도구는 다음을 수행하도록 설계되었습니다.
독특한 사용 사례를 지원합니다. 그 이상을 수행하지 않는 플러그인
configure docker build cmd는 꽤 쓸모가 없어 보입니다. 내 빌드 도구는
이미 스크립팅 환경입니다. 더 나쁜 것은 모든 잠재력을 삽질하는 것입니다.
Dockerfile에 대한 사용 사례 초과 근무는 아키텍처를 설계하는 데 나쁜 방법인 것 같습니다.
그것. Dockerfile은 다음을 통해 단순히 새 이미지를 생성하는 데 집중해야 합니다.
기본 이미지에 레이어 추가 다른 작업은 아웃 오브 밴드로 보입니다.

나는 지금까지 도커를 사랑한다. 멋진 일들! 이 특정 문제는 그냥 발생합니다
통증 포인트가 될 수 있습니다.

2014년 7월 28일 월요일 오후 12시 25분, Solomon Hykes [email protected]
썼다:

@peterbraden https://github.com/peterbraden in #7115
https://github.com/docker/docker/issues/7115 , 기능을 추가하면
여러 PUBLISH 호출의 경우 이제 여러 이미지를 생성할 수 있습니다. 그럼 당신은
빌드할 하위 이미지를 선택하여 구성 가능성을 추가할 수 있습니다.
핵심은 구성 가능성이 다음 세트 내에서 발생한다는 것입니다.
Docker_가 검색할 수 있는 하위 이미지. 그렇게 하면 검색 가능성을 유지할 수 있습니다.

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

@thedeeno Dockerfile 의 목표는 소스 코드 저장소를 Docker가 실행할 수 있는 것으로 변환하는 방법을 지정하는 것입니다.

"_a_ Dockerfile의 목표는 소스 코드 저장소를 Docker가 실행할 수 있는 것으로 변환하는 방법을 지정하는 것입니다."

여러 repo->image 매핑을 갖는 방법이 실제로 필요하다는 데 동의할 수 있다고 생각합니다. 있는 그대로, 우리 중 많은 사람들이 이것을 하기 위해 쉘 스크립트와 메이크파일을 남용하고 있습니다. 내 경험상 Makefile이라는 사용자 지정을 많이 본 적이 없습니다. 구성과 기본값은 강력한 힘입니다. 이 때문에 사람들이 관습을 남용하는 것이 현실적인 시나리오라고 확신할 수 없습니다.

제안하는 대안으로 Dockerfile 구문에 키워드를 추가하면 Dockerfile 생성이 더 복잡해집니다. 나는 그 구문을 가능한 한 간단하게 유지하는 것에 찬성합니다. PUBLISH et al은 나머지 Dockerfile 구문에 비해 세련되지 않은 것 같습니다.

기존 도구 규칙을 따르는 아이디어도 있습니다. 언급한 바와 같이 -f는 사람들이 작동하는지도 모른 채 시도하는 일반적인 패턴입니다. UI는 직관적이어야 하며 사람은 _get_ -f 플래그를 지정해야 합니다. Grokking 새로운 Dockerfile 구문은 거의 직관적이지 않습니다.

@peterbraden @shykes -f가 더 간단하고 직관적이라는 데 동의합니다. 처음에 이 문제를 발견한 이유는 Docker가 이미 이 기능을 갖고 있을 것으로 _예상_했고 애플리케이션 테스트를 시작한 첫날(기본적으로 작동하지 않을 때) 검색했기 때문입니다.

이것은 소프트웨어를 테스트하지 않거나 여러 환경에서 소프트웨어를 실행하지 않는 상황이 아닌 한 특별한 경우가 아닙니다. 지난 10년 동안 내가 접한 모든 리포지토리에는 다양한 컨텍스트에서 실행할 수 있어야 한다는 요구 사항이 있습니다. 이 스레드의 많은 사람들이 같은 문제를 가지고 있다고 생각합니다. 규칙을 갖는 것이 애플리케이션의 기본 컨텍스트에 분명히 가치가 있다는 점에 모두 동의합니다(제 생각에는).

나는 #7115(빠르게)를 읽고 그것이 우리를 위해 이 문제를 어떻게 해결하는지 이해하지 못합니다. 아마도 이것은 PR에 대한 문서의 문제일 것입니다. 유사한 플래그는 올바르게 설명하고 사용하는 데 약간의 노력이 필요합니다.

그 INCLUDE 아이디어로 새로운 제안을 만들었습니다 - https://github.com/docker/docker/issues/7277

부수적으로 - 투박한 "RUN apt-get install -y ...." 대신 더 효율적인 "APT" 명령에 대해 생각하는 것이 가치가 있을 수 있습니다(그런 다음 YUM, EMERGE, PACMAN 등).

아 그리고 많은 사람들이 어쨌든 "-f" 옵션을 실제로 시도한다는 점을 고려하면 이 옵션을 사용하려고 할 때마다 새 솔루션을 설명하는 문서의 페이지로 안내하는 멋진 오류 메시지가 표시되는 것이 좋습니다.

나는 정말로 우리 모두가 방에 있는 코끼리를 무시하고 있다고 생각합니다.

@shykes 는 "아웃오브밴드(out-of-band) 정보 없이 소스 코드 디렉토리를 가리킬 수 있다는 사실과 업스트림 개발자의 사양에 정확히 일치하는 이미지를 빌드할 수 있다는 사실은 매우 강력하고 Docker의 주요 차별화 요소입니다."

나는 이것이 "디렉토리에 docker build . 를 입력하면 절대적으로 항상 옳은 일을 해야 합니다"라고 말하는 것과 동일하다고 확신합니다 docker build . 할 일, 틀렸어"

이 호에 가입한 다른 사람들의 동기에 대해 말할 수는 없지만 이 호에 대한 제 자신의 동기는 정확히 docker build . 에 명백한 행동이 없는 경우입니다. 디버그 버전을 원했습니까 아니면 릴리스 버전을 원했습니까? Postgres 베이크인을 원했습니까, 아니면 별도의 앱과 포스트그레스 이미지를 내보내야 합니까? 테스트 데이터 또는 프로덕션 데이터를 로드하고 싶었습니까? 테스트를 실행하고 싶었습니까?

물론, 나는 사람들이 빌드를 얻기 위해 이러한 질문에 답할 필요가 없는 세상에 살고 싶습니다. 하지만 나는 그 세계에 살고 있지 않다. 물론 이러한 질문에 대한 몇 가지 답변을 임의로 선택하고 docker build . 대한 동작을 정의할 수 있습니다. 그러나 문제의 사실은 사용자가 docker build . 입력할 때 임의의 것을 구축하는 것은 "올바른 일을 하는 것"이 ​​아니라는 것입니다.

마땅히 구축해야 할 것이 명확하지 않은 프로젝트가 있는 것이 현실입니다. -f 지원과 같이 docker 내부에서 해결하거나 다른 곳에서 가져온 대상 목록 또는 다양한 다른 제안에서 사용자가 선택하도록 하는 방법이 많이 있습니다. 그러나 그들은 모두 설계상 docker build . 이 깨지는 속성을 가지고 있습니다. 여기에는 근본적인 임피던스 불일치가 있습니다. 그냥 벗어날 수 있는 방법을 제안할 수 없습니다.

모든 프로젝트가 docker build . 대해 합리적인 것을 선택할 수 있다는 생각은 환상입니다. 합리적인 일을 할 수 없는 프로젝트가 수적으로 존재합니다. 이 시점에서 유일한 질문은 Docker가 해당 프로젝트의 다중 빌드 제품 특성을 직접 지원할 것인지 아니면 make 또는 쉘 스크립트와 같은 기존 빌드 도구로 대체할 것인지입니다. 이것은 현재 일어나고 있습니다 . 예를 들어 더 큰 Docker 기반 분산 프로젝트 중 하나인 Discourse는 이 문제를 해결하기 위해 부분적으로 자체 빌드 시스템을 사용합니다.

@drewcrawford 보시다시피 , 그것이 바로 문제입니다. "도커 빌드." _the_ 이미지를 빌드해야 합니다. 하나뿐인 진정한 이미지. 다른 환경에 대한 유일한 이미지의 동작을 조정하려면 docker 실행 매개변수를 변경해야 합니다.
이러한 맥락에서 당신은 릴리스 버전을 원할 것입니다. 앱만 있고 다른 것은 없습니다. "postgres 이미지"와 같은 다른 모든 것은 런타임에 앱에 연결되는 다른 것입니다. 동일한 릴리스 이미지를 가져오고 기본이 아닌 명령으로 실행하여 테스트를 실행할 수 있습니다.
이상적으로는 다중 이미지 지원을 사용하면 "릴리스", "디버그" 및 "테스트 포함" 빌드 중에서 선택할 필요조차 없습니다.
Docker를 오래된 사고 방식으로 구부리려고 하면 시간이 많이 걸릴 것입니다. 드라이버로 나사를 망치로 치지 마십시오.

@algarius 제 생각에 문제는 이 생각이 실제 응용 프로그램에 적용되지 않는다는 것이며, 여기에서 패러다임 전환이 진정으로 있어야 하는 경우 아무도 설명하지 않는다는 것입니다.

여러 이미지를 허용하는 것은 대부분의 실제 네트워크 액세스 응용 프로그램에 필요한 요구 사항을 지원하는 가장 간단하고 직관적인 방법입니다(다른 종속성이 있는 여러 환경). 이것을 해결하기 위해 문법을 더 복잡하게 만드는 것이 바람직합니까? 결국에는 소프트웨어의 최종 사용자에게 거의 설명이 필요하지 않은 여러 Dockerfile과 같은 간단한 방식으로 쉽게 표현할 수 있는 서로 다른 종속성을 가진 > 1개의 환경이 있다는 사실을 다시 엔지니어링하고 난독화하는 것입니다.

@drewcrawford 는 Docker 지원과 함께 배포되는 현재 실제 세계에서 널리 사용되는 애플리케이션에서 이것이 어떻게 처리되는지에 대한 구체적인 예를 제공했습니다. 어떻게 해야 합니까?

@aigarius "도커 방식"을 이해하지 못하는 것은 아닙니다. 그냥 잘못된 것 같아요.

예를 들어 테스트에는 다른 빌드(신에게 정직한 _recompile_)가 필요할 수 있습니다. 왜냐하면 프로덕션에 너무 느린 특정 로깅 코드는 조건부로 컴파일해야 하기 때문입니다.

이것이 make 시스템을 위한 작업처럼 들린다면, 당신 말이 옳습니다. 사실 저와 같은 사람들은 실제 빌드 시스템을 사용하여 도커 빌드를 스크립팅하는 방법을 찾습니다.

여기서 문제는 Dockerfile이 빌드에 선호되는 사용자 인터페이스가 될 수 없으며 예를 들어 make 보다 훨씬 덜 강력하다는 것입니다. 그것은 makelike 파워로 구축을 위한 선호 사용자 인터페이스이거나 실제 사용자 인터페이스로 make 등이 있는 저수준 도구일 수 있습니다. 그러나 "실제" 빌드 시스템은 임의로 복잡하지 않습니다. 사람들이 기능을 사용하기 때문에 복잡하고 단순화된 도커 빌드가 아무리 많아도 이를 변경할 수 없습니다. 일어날 일은 docker가 make 호출하는 새로운 cc 가 되는 것뿐입니다.

@shykes @drewcrawford @aigarius 이 스레드의 앞부분에서 설명한 @shykes 와 동일한 방식으로 간단한 -f 옵션에 대한 제안을 작성했습니다. #7284

@drewcrawford 당신이 옳습니다. 빌드에 선호되는 사용자 인터페이스가 되려면 docker build 가 최소한 예를 들어 강력해야 합니다. make . 2가지 방법이 있습니다.

• 1) Maven, scons, rake, 그리고 물론 좋은 오래된 쉘 스크립트와 같이 make의 모든 변형의 모든 기능과 거기에 있는 모든 대안을 다시 구현하려고 시도할 수 있습니다.

또는

• 2) 우리는 이러한 빌드 도구 자체가 실행 가능한 프로그램이라는 것을 인식할 수 있습니다. 즉, 런타임 종속성이 있고 자체적으로 빌드 종속성으로 빌드되었습니다. 그리고 우리는 당신이 가장 좋아하는 빌드 도구를 _실제로 사용_할 수 있는 방법을 제공할 수 있습니다. 따라서 실제로 make를 빌드하고 실행할 수 있기 때문에 make를 다시 구현할 필요가 없습니다.

make 하면 어떤 맛의 메이크를 말씀하시는 건가요? 어떤 버전? 정확히 어떤 svn 체크아웃에서 구축되었습니까? 어떤 빌드 옵션을 사용합니까? 어떤 libc에 연결되어 있습니까? 귀하가 언급한 cc 대한 동일한 질문입니다. 아마도 그것은 중요하지 않을 것입니다. 아마도 make 의 임의 버전에 관계없이 앱이 정확히 동일하게 나타날 것입니다. 하지만 다시 말하지만, 어쩌면 중요할 수도 있습니다. 내가 당신과 똑같은 빌드를 얻을 수 있는 유일한 방법은 당신이 사용한 것과 똑같은 Make와 Cc 빌드를 사용하는 것뿐입니다. 그리고 오늘날 그렇게 하는 쉬운 방법은 없습니다. 하지만 그것이 제가 하고 싶은 일입니다.

저는 docker build 를 빌드 도구라고 생각하지 않습니다. 정확히는 메타 빌드 도구에 가깝습니다. 빌드 환경을 안정적으로 재구성할 수 있는 알려진 시작점입니다. 이것이 #7115의 동기입니다.

@shykes make, Maven, rake 등의 _모든_ 기능을 실제로 복제할 필요는 없다고 생각합니다. 결국 이러한 도구는 서로의 모든 기능을 복제하지 않고 어떻게든 잘 어울립니다.

그러나 Dockerfile이 현재보다 더 표현력이 풍부한 언어가 되어야 합니다(Docker가 이미지 빌드에 선호되는 사용자 인터페이스인 경우).

이번 호에 실린 제안은 사실 그 선을 따라 다소 겸손한 움직임입니다. "make의 _targets_에 상응하는 것이 필요합니다."라고 말하고 있습니다. "어떤 버전의 make"에 대한 질문은 실제로 그림에 포함되지 않습니다. "대상"의 개념은 Maven, rake 및 기타 모든 진지한 빌드 시스템을 만드는 데 일반적입니다. 구문은 다르지만 기능 자체가 보편적이라는 사실은 이것이 사람들이 물건을 만들 때 자주 하는 일이라는 단서가 되어야 합니다.

그들이 빌드하는 것이 C 프로그램, Docker 이미지 또는 그 사이의 무엇이든 상관없이 여전히 일부 대상을 빌드하고 있습니다. 빌드 타겟에 대한 아이디어는 매우 기본적이어서 빌드 시스템 구현, 프로그래밍 언어, 운영 체제에 걸쳐 있습니다. 우리는 여기에서 모호한 GNU Make 특정 기능을 복제하는 것에 대해 이야기하는 것이 아니라 가능한 가장 광범위한 동의를 얻는 것에 대해 이야기하고 있습니다.

여기에 "메타 빌드 도구"라는 개념을 소개하려고 하지만 그런 것은 없습니다. docker가 make 빌드를 오케스트레이션할 수 있는 것처럼 make도 docker 빌드를 오케스트레이션할 수 있으며 실제로 make는 현재 바로 그런 방식으로 사용되고 있습니다. Docker에 빌드 대상을 지정할 수 있는 방법이 없기 때문입니다. 그러나 어쨌든 어느 시스템도 본질적으로 다른 것보다 더 많거나 적은 메타가 아니며 모두 대상을 빌드하는 빌드 시스템일 뿐이지만 Docker의 경우에는 하나만 허용됩니다. 이것이 문제입니다.

#7115와 같은 제안은 흥미롭지만 내가 놓치고 있는 것이 없다면 목표를 효과적으로 대체할 수 없습니다. 대상은 무엇을 구축해야 하는지 알려줍니다. #7115는 여전히 한 가지만 구축할 수 있는 보다 유연한 DSL을 제공합니다. 그게 뭔가요, 하지만 여기에서 요구하는 것은 아닙니다.

docker build -t my_project_builder .
# Builds the builder container
docker run my_project_builder my_target | docker build -t my_project/my_target -< Dockerfile_MyTarget
# target is built, tarballed, and sent to stdout, then piped into a new docker build as the context and custom Dockerfile name

@drewcrawford 확인을 위해 docker가 Make target과 동등한 것을 허용하면 1) 빌드할 대상을 지정할 수 있습니다. make clean; make foo , 2) 기본적으로 _all_ 타겟을 구축하고 3) 타겟을 열거하는 방법이 있습니다... 그게 당신에게 만족스러울까요?

만족스럽습니다... 모든 대상을 기본값으로 설정하는 대신 개발자가 선택한 대상을 기본값으로 설정하는 것을 선호하지만 둘 중 하나를 수락하겠습니다.

괜찮아.

@shykes @drewcrawford :+1:

일어날 일은 docker가 사람들이 make로 호출하는 새로운 cc가 되는 것뿐입니다.

이번 호에 실린 제안은 실제로 그 선을 따라 다소 겸손한 움직임입니다. 그것은 "우리는 make의 목표에 상응하는 것이 필요합니다"라고 말하고 있습니다. "어떤 버전의 make"에 대한 질문은 실제로 그림에 포함되지 않습니다. "대상"의 개념은 Maven, rake 및 기타 모든 진지한 빌드 시스템을 만드는 데 일반적입니다. 구문은 다르지만 기능 자체가 보편적이라는 사실은 이것이 사람들이 물건을 만들 때 자주 하는 일이라는 단서가 되어야 합니다.

@drewcrawford :+1: +1,000,000

제가 계속 겪고 있는 상황은 다음과 같습니다.

내 저장소에서 두 개의 Docker 컨테이너를 만들고 싶습니다. 아마도 하나는 서버이고 하나는 데이터베이스입니다. 또는 하나는 서버이고 다른 하나는 API 호출을 통해 서버에 대해 자동화된 테스트를 실행하는 클라이언트일 수 있습니다.

어쨌든 이 두 컨테이너에 대해 추가해야 하는 파일이 저장소에 있습니다. 있는 그대로 bash 스크립트에서 별도의 Dockerfile을 한 번에 하나씩 복사하고 빌드를 수행한 다음 Dockerfile을 교체하거나 삭제하지 않고는 이 작업을 수행할 수 없습니다.

다음 중 하나가 필요합니다.

1. -f 명령은 Dockerfile로 사용할 파일을 지정합니다.
2. Dockerfile의 하위 경로가 아닌 파일을 추가하는 기능.

1번은 금지라고 반복해서 말했고 2번은 기술적으로 훨씬 더 어렵다고 가정합니다. 이를 수행하는 "적절한" 방법은 무엇입니까?

@ShawnMilo

@shykes 마지막 의견은 이것이 더 이상 예전만큼 불쾌하지 않다는 것을 나타내는 것 같았지만 기존 제안이 적절할 것인지 또는 적절하지 않은 경우 변경해야 할 것이 무엇인지에 대해서는 여전히 불분명하다고 생각합니다.

@jakehow 업데이트 감사합니다. 따라서 문제에 대한 공식적인 수정은 아직 멀었습니다. 그동안 "좋은 방법"이 있습니까? 내가 가진 가장 좋은 아이디어는 파일을 한 번에 하나씩 repo 루트의 "Dockerfile"에 복사하고 이미지를 빌드하는 bash 스크립트입니다. 작동하지만 더럽게 느껴집니다.

@ShawnMilo 예, 대부분의 사람들이 빌드 도구(make, rake 등)를 사용하거나 이를 수행하기 위해 오래된 bash 스크립팅을 사용하고 있다고 생각합니다.

위에 누군가는 이것을 다루는 빌더 이미지가 있는 스니펫을 보여주었습니다.

이 문제를 해결하는 방법은 다음과 같습니다. v2 및 v3라고 가정해 보겠습니다. 플랫폼의 다른 버전에 대한 이미지를 빌드해야 합니다. 그래서 저는 Dockerfile.v2와 Dockerfile.v3을 가지고 있습니다. 빌드를 만들고 싶을 때 먼저 ln -s ./Dockerfile.v3 ./Dockerfile 한 다음 docker build . 실제로 스크립트가 있고 ./build v3 또는 ./build v2

현재 지정된 Dockerfile 을 ./Dockerfile 연결하는 스크립트를 사용하고 있지만 이것은 좋은 기능이 될 것입니다.

이 문제를 해결하기 위해 PR #7995를 만들었습니다. 이 (긴 :-)) 스레드에서 논의된 솔루션 중 일부는 사람들이 사용하기에 매우 고통스러워 보입니다. (저에게) Docker의 가장 큰 판매 포인트 중 하나는 사용하기가 얼마나 쉬운지 사람들에게 이런 종류의 고리를 건너뛰도록 요청하는 것이 꽤 쉬운 질문처럼 느껴지는 것이 옳지 않다고 느끼는 것입니다.

이제 내가 누락된 것이 있을 수 있지만 "Dockerfile"이라는 이름을 지정해야 하는 기술적 이유가 있습니까? PR을 만드는 동안 PR을 찾을 수 없었고 변경이 얼마나 쉬운지 즐겁게 놀랐습니다.

@duglin 당신은 내 모든 지원이 있습니다.

이것이 현재 프로젝트에 -f 옵션이 없는 문제를 해결하기 위해 하는 일입니다.

# build.sh
...
mv specialDockerfile Dockerfile
docker build -t $(PROJECT) .

-f 를 추가할 때 이것을 +1이라고 생각하십시오.

현재는 kikito 같은 것도 관리하고 있습니다. 동일한 컨텍스트에서 다른 이미지를 빌드하기 위해 몇 가지 셸 스크립트를 작성했지만 이미 제안된 대로 CLI 인수에서 도커 파일을 지정하는 방법을 보고 싶습니다. 이 요청에 대해 +1입니다.

+1000

나는 오늘 docker를 사용하여 golang 프로젝트 크로스 플랫폼을 구축하려고 할 때 이것을 발견했습니다. 이것은 작동합니다( boot2docker 참조). 하지만 도커 빌드 프로세스의 내부와 외부를 함께 연결하려면 Makefile이 필요합니다(예: docker cp 도커 내부에서 내 빌드 디렉토리로 아티팩트).

그러나 repo 루트의 .git 폴더가 없기 때문에 내 repo의 하위 디렉토리에서 이것을 사용하려고 하면 GOPATH 가 손상됩니다. ADD repo 루트를 만든 다음 내 하위 디렉터리에 빌드해야 하지만 docker에서는 허용하지 않습니다.

이 긴 스레드를 읽은 후 빌드를 재현할 수 없다는 우려를 보았습니다. 이를 완화할 수 있는 한 가지 방법은 -f 옵션이 빌드 컨텍스트 내에서 또는 아래쪽을 가리키도록 허용하는 것입니다. 이렇게 하면 하위 디렉토리에 여러 Dockerfile을 갖고 repo 루트에서 빌드할 수 있습니다. 또한 이것을 repo 경계 내로 제한할 수 있습니다. 예를 들어 .git/.hg/.foo와 같은 수준 및 그 이하이지만 repo 외부는 아닙니다.

여기 내가 생각하는 것이 있습니다

FROM scratch
BUILD myname1 path/to/dockerfile/in/context
BUILD myname2 path/to/dockerfile2/in/context

docker build -t myimage .

이렇게 하면 3개의 이미지가 생성됩니다.

1. 예를 들어 실제로 아무 것도 포함하지 않는 "myimage"라는 기본 이미지
2. myimage-myname1이라는 이미지
3. myimage-myname2라는 이미지

BUILD 키워드는 Dockerfile에 대한 이름과 경로를 사용합니다. 이 Dockerfile은 원래 컨텍스트 내에 있어야 합니다.
각 빌드 명령은 기본 빌드에서 전체 컨텍스트에 액세스할 수 있습니다.
Dockerfile이 포함된 dir-tree로 컨텍스트를 제한하는 것이 좋습니다.

-1

이 특별한 경우에 dockerfeed 와 같이 컨텍스트 피더를 docker build - 사용할 수 있습니다.

@itsafire 요점은 이러한 유형의 기능을 Docker에 가져와 이것이 프로젝트를 빌드하는 데 지원되는 방법이 될 수 있도록 하는 것입니다. 사람들이 자동화된 빌드와 함께 작동하는 것을 좋아할 것이라고 확신합니다.

나는 여기서 길을 잃었다. 이 추가된 기능에 대한 몇 가지 pull 요청이 있습니다. 맞나요? 그리고 그렇게 하기 어려워 보이지는 않습니다... @maxnordlund가 언급한 규칙을 적용할 수도 있습니다. 경로를 컨텍스트/루트에 상대적으로 제한하는 것입니다. 그러면 최소한 boot2docket 등과 함께 보다 원활하게 작동하고 "휴대용"으로 만들 수 있습니다.

이것은 지금까지 Docker에서 가장 짜증나는 격차이며 점점 더 많은 도구가 Docker를 기능의 일부로 사용하기 시작함에 따라 '-f' 플래그에 대한 기능을 신속하게 추가하여 이러한 도구가 준비되도록 하는 것이 중요합니다. 너무 최종적이 되기 전에... 관련: 이러한 관련 "메타" 도구는 종종 Dockerfile당 _하나의_ 이미지를 가정하기 때문에 다중 이미지 Dockerfile을 갖는 것으로는 잘리지 않습니다! 또한 '-'를 사용하면 이러한 도구로 잘리지 않으며 우리 모두가 알고 있듯이 기능이 심각하게 제한됩니다.

권한이 있는 누군가가 이 수정 사항이 아직 병합되지 않은 이유 또는 적어도 이 매우 부족한 기능이 여전히 존재하지 않는 이유를 설명할 수 있습니까?

트와일라잇 존처럼 느껴지기 시작합니다.

Docker 팀이 Docker를 사용하는 방식/Docker가 사용되기를 원하는 방식과 커뮤니티의 많은 부분이 Docker를 사용하는 방식에 불일치가 있는 것 같습니다. 틀 렸으면 고쳐줘.

도커 팀은 데비안 프로젝트의 리포지토리와 크게 다르지 않은 소프트웨어 리포지토리를 구축하려고 합니다. 사람들이 좋아하는 소프트웨어를 얻고 쉽게 실행할 수 있는 곳. 소프트웨어의 빌드 프로세스는 반복 가능하고 명확해야 합니다.

다른 사람들은 이미 많은 빌드 도구, CI 시스템 등으로 매우 복잡할 수 있는 기존의 사내 소프트웨어 배포를 자동화하기를 원합니다. 그들에게 Docker는 인프라에 맞아야 하는 또 다른 도구일 뿐입니다. 그리고 Docker를 사용하는 방법에 있어 좀 더 유연성이 필요합니다.

Docker(예: .deb)가 양 당사자의 요구를 충족할 수 있다고 생각하지만 타협이 이루어져야 합니다.

기본적인 문제는 다음과 같습니다. 이 끝은 어디입니까? Dockerfile에 대한 튜링 완전성? 아마 그렇지 않을 것입니다. 특별한 경우를 해결하려면 항상 더 많은 유연성이 필요합니다. 일부 아이디어는 Dockerfile 언어를 입력하고 다른 아이디어는 입력하지 않습니다. 도커는 빌드에서 stdin을 통해 컨텍스트를 먹을 수 있으므로 누락된 기능은 전처리기를 통해 구현할 수 있습니다.

@itsafire 마지막으로 확인한 결과 docker는 Dockerfile 를 먹을 수 있지만 컨텍스트는 먹을 수 없습니다. 실제로 그런 식으로 Dockerfile을 제공하면 컨텍스트가 무시됩니다. 그들이 당신이 제안한 것에 대한 지원을 추가했다면 이것은 닫힌 문제가 될 것입니다.

한동안 보지 않았지만 기본 요청은 다음과 같습니다. 빌드 중에 Dockerfile 및 context 모두 제공하는 명시적인 방법을 제공하십시오. 솔직히 이게 8개월이 지난 지금도 열려 있다는 사실에 충격을 받았습니다.

@thedeeno 이것은 실제로 가능합니다.
cat mystuff.tar.gz | docker build -

@ cpuguy83 하지만 해당 명령으로 명시적 Dockerfile을 제공할 수 없습니다. 오른쪽?

@thedeeno 예, 원하는 컨텍스트로 원하는 Dockerfile을 tar업합니다.

@cpuguy83 @thedeeno 아니요, 작동하지 않습니다. 일반적으로 Dockerfile에서 얻는 "cwd" 범위에 파일이 없기 때문에 파일을 추가할 수 없기 때문입니다.

편집: 이 진술은 잘못되었습니다. @cpuguy83 의 예를 잘못 이해했습니다.

@ShawnMilo 그렇습니다. tar의 모든 것은 컨텍스트 내에 있습니다.

@cpuguy83 죄송합니다, 제 실수입니다. 전체 tarball이 아니라 Dockerfile에 파이핑하는 것으로 급하게 읽었습니다.

@cpuguy83 좋아요 ! 나는 당신이 제안한 것처럼 작동한다면 닫기 투표합니다.

부수적인 질문, 내 사용자 지정 솔루션 타임스탬프는 무게를 측정할 때 캐시를 파열시켰습니다. 그게 아직도 문제야? 동일한 폴더를 여러 번 tar하면 빌드 시 캐시가 사용됩니까?

앞으로도 힘써주세요!

전체 컨텍스트를 파이핑하는 것은 위에서 이야기한 내용을 전혀 완화하지 않습니다.

우리가 원하고 필요한 것은 다양한 Dockerfile과 함께 _same_ 컨텍스트를 사용하는 방법입니다. 앞서 언급한 "로깅으로 빌드" 및 "로깅 없이 빌드"와 같은 개별 이미지입니다. 이것이 필요한 다른 많은 사용 사례가 있습니다.

디렉토리를 tar-balling하는 것이 이 문제에 어떻게 도움이 되는지 알지 못합니다. 예, 특별한 디렉토리를 만들고 거기에 특정 Dockerfile을 복사한 다음 전체 컨텍스트 디렉토리를 복사하거나 새 Dockerfile을 tar하고 추가한 다음 gzip으로 압축할 수 있습니다. 그러나 docker를 실행하기 전에 올바른 Dockerfile을 제자리에 배치하는 전처리기 스크립트를 사용하는 현재 채택해야 하는 [매우 끔찍한] 해결 방법보다 어떻게 쉽습니까?

그리고 이것은 위에서 언급한 것처럼 Docker 생태계에 도움이 되지 않습니다.

내가 뭔가를 놓쳤나요?

다시 말하지만, 간단한 '-f' 옵션입니다. 제발. 제발, 이쁘게 해주세요. 컨텍스트의 상대 경로가 되도록 합니다. 괜찮습니다.

@davber 당신이 정말로 원하는 것은 Docker가 tarballing 컨텍스트와 Dockerfile을 처리하는 것입니다.
그리고 나는 이것에 완전히 반대하지 않습니다. 중첩 빌드가 이에 대한 더 나은 솔루션이 될 수 있다고 생각합니다.

@cpuguy83 : 예, 그래서 Docker가 저를 위해 그것을 처리하기를

중첩 빌드는 이 스레드를 시작한 우리가 직면한 문제를 해결하지 않고 계속 진행합니다.

즉, 우리는 여전히 동일한 루트 컨텍스트를 사용하기를 원합니다.

예, 파일을 복사할 수 있습니다. 예, 'Dockerfile'이라는 정확한 Dockerfile과 컨텍스트의 이상한 결합을 피하기 위해 이 작업을 수행합니다. 그러나 그것은 이상적이지 않으며 파일이 실제로 원본 파일과 동일한지 확인하기 위해 rsync를 설정하는 것은 이상합니다.

@cpuguy83 : 중첩된 빌드가 징징거리는 사람 "에게 어떻게 도움이 되는지 설명할 수 있습니까? :-)

@davber
이에 대한 나의 견해는 다음과 같다.

FROM scratch
BUILD myname1 path/to/dockerfile
BUILD myname2 path/to/another/dockerfile

이:

docker build -t myimage .

"myimage", "myimage-myname1", "myimage-myname2"라는 3개의 이미지가 생성됩니다.
각 내부 빌드는 전체 빌드 컨텍스트에 절대 경로로 액세스할 수 있습니다. 상대 경로는 Dockerfile에 상대적입니다.
그리고 "myimage"는 BUILD 명령을 넘어 자체적인 것을 가질 수도 있습니다.

앞서 언급했듯이 더 큰(그리고 훌륭한!) Docker 생태계의 많은 새로운 도구는 각 Dockerfile이 정확히 하나의 Docker 이미지와 연결되어 있다고 가정합니다. 다양한 "무화과"와 같은 오케스트레이터 도구가 있습니다. 그리고 Docker에 대한 특정 지원을 제공하는 많은 신규 및 기존 클라우드 솔루션에도 이러한 일대일 가정이 있습니다. 물론 '-f' 옵션으로 생성된 세계에서는 컨텍스트(예: tar 볼)뿐만 아니라 잠재적으로 별도의 Dockerfile도 가져와야 합니다. 그러나 이러한 각 업로드는 여전히 정확히 하나의 Docker 이미지에 해당합니다.

Dockerfile을 컨텍스트 루트에서 잠재적으로 분리하는 경로를 사용하는 경우 이러한 도구가 이 시나리오에서 시작되기를 바랍니다.

Each deployment/use of a Docker image is done with an upload of either:

   1. a Dockerfile solely, when no contextual operations are needed
   2. a context tar ball only, containing the context with a top-level Dockerfile
   3. both a context tar ball and a separate Dockerfile

컨텍스트의 최상위 수준에서 'Dockerfile'의 강력한 결합을 오래 유지할수록 생태학에 더 깊이 뿌리 내릴 것입니다. 즉, Docker 세계가 일반적으로 훌륭하기 때문에 빠르게 움직이므로 지금 행동해야 합니다.

솔직히 말해서, Dockerfile과 이미지 사이에 동형을 갖는다는 것은 합리적이고 개념적으로 매력적인 가정입니다. 전자는 엄격하게 컨텍스트 디렉토리(tared up...)와 Dockerfile의 제품 공간이 될 것이며 기본값은 (null, file) Dockerfile만 제공되는 경우 및 (context, context/'Dockerfile') 컨텍스트만 제공되는 경우.

그리고 로컬 배포의 경우에도 최소한 로컬 오케스트레이션에 Fig를 사용하고 싶다고 가정해 보겠습니다. 어떻게 하시겠습니까? 이러한 다중 빌드 Dockerfile에서 이미지를 미리 만든 다음 그림의 해당 이미지를 참조해야 합니다. 최적이 아닙니다.

Dockerfile과 이미지 간의 동형

이 가정은 이 스레드의 사람들이 Dockerfiles를 사용하는 방식에서 이미 깨졌습니다. 즉, 도커 빌드를 실행하기 전에 스크립팅을 사용하여 Dockerfile을 수동으로 교체합니다. 그들은 또한 그들만의 오케스트레이션을 가지고 있을 것입니다. 이 기능 요청은 도커 환경을 변경하는 것이 아니라 특정 용도로 도커가 작동하도록 하는 것입니다.

@hanikesn : 두 개의 댓글:

1. 빌드하기 전에 Dockerfiles를 제자리에 복사해야 해서 그 가정이 깨지는 이유는 무엇입니까? 여전히 하나의 Dockerfile <-> 하나의 이미지가 될까요?
2. 내가 주장하는 것은 이 환경에서 너무 큰 변경 없이 기존 및 성장하는 Docker 환경과 _작업_하기 위해 우리가 여기에서 제공하는 솔루션이 무엇이든 원한다는 것입니다. 그리고 나는 동형론이 언급된 _유지_에 의해 그렇게 한다고 생각합니다.

여기에서 다른 제안은 잠재적으로 하위 Dockerfile을 호출하는 하나의 다중 이미지 Dockerfile을 갖는 것입니다. 현재 Docker를 사용하는 대부분의 도구(그림 등)에서는 작동하지 않습니다.

@davber

중첩 빌드는 이 스레드를 시작한 우리가 직면한 문제를 해결하지 않고 계속 진행합니다.

앞에서 이미 지적한 이 솔루션을 제안합니다.

$ docker-pre-processor [ --options ... ] . | docker build -

반면 --options 는 (여기) 현재 디렉토리의 컨텍스트가 변경되어 docker에 전달되는 규칙입니다. 이것은 컨텍스트를 포함하는 임시 tar 아카이브를 생성하여 즉석에서 수행되어야 합니다. 그렇게 하면 소스 컨텍스트가 그대로 유지될 수 있습니다. Dockerfile 구문보다 전처리기를 변경하는 것이 더 쉽습니다.

@itsafire

오늘날 Dockerfiles를 기대하는 도구는 어떻습니까? 그들은 Amazon, Google 등을 사용하여 점점 더 풍부해지고 있습니다. 그리고 Fig 및 유사한 오케스트레이션 프레임워크.

그런 다음 표준화된 '도커 전처리기' 도구와 이러한 도구의 사용을 해당 프레임워크, 공급자 및 도구에 적용해야 합니다.

최소한 이 스레드를 트리거하는 옵션을 '도커'로 적절하게 지원하는 것이 훨씬 쉬울 것입니다.

@itsafire 이 문제를 해결한 모든 사람은 이미 이 목표를 달성하기 위해 일종의 전처리기 또는 도커 빌드 주변 래퍼를 사용하고 있습니다.

이 상황을 둘러싼 단편화는 @docker 팀의 명시된 목표인 '반복성'과 충돌합니다. 이 토론과 다른 토론은 이 문제를 해결하는 것입니다.

1년 이상 및 130개 이상의 댓글과 대부분의 사용자에게 영향을 미치는 간단한 문제에 대해 계산하고 있습니다. 좋은 일을 계속하십시오, 도커!

+1

도구는 사람들이 자신의 방식을 따르도록 도와야 하지만 "올바른" 방식을 강요해서는 안 됩니다. 나를 이 토론으로 이끌었던 간단한 사례:

`-- project
     |-- deploy
     |    |-- .dockerignore
     |    |-- Dockerfile
     |    ...
     `-- src

내 방법은 프로젝트 루트를 깨끗하게 유지하는 것입니다. 그러나 ADD ../src 및 -f deploy/Dockerfile 는 작동하지 않습니다. 지금은 프로젝트 루트에 Dockerfile 및 .dockerignore 가 있지만 저에게는 고통스럽습니다.

필자는 .dockerignore 파일이 ADD 의해 무시되는 문제가 발생했기 때문에 필요한 파일이 있는 폴더를 준비하고 표준 명령줄 docker build -t my/image . 을 실행하는 스크립트를 작성했습니다 ADD ...

+1 단일 저장소에 여러 Dockerfile을 가질 수 있기를 원합니다. 내 사용 사례: 하나의 이미지는 프로덕션 사용 및 배포용이고 다른 이미지는 동일한 백엔드 도구 및 데이터베이스 연결을 사용하도록 설계된 보고 인스턴스이지만 프론트엔드, 웹, 시스템 서비스 또는 프로세스 감독이 필요하지 않습니다...

이것에 대해 +1. 다른 서버에 대해 동일한 폴더의 다른 이미지에 파일을 추가해야 합니다.

+1 지금까지는 Docker를 즐기고 있지만 팀이 설정한 방식 때문에 한 리포지토리에서 좋은 코드 덩어리를 공유하는 다양한 배포 가능 항목을 구축하는 방법이 정말 필요합니다. 배포/릴리스 주기가 불필요하게 서로 연결되어 있기 때문에 uberdocker 컨테이너에 모두 구축하는 것을 특별히 좋아하지 않습니다. 이 문제를 해결하는 가장 좋은 방법은 무엇입니까?

@jfgreen : 원하는 곳에 여러 개의 Dockerfile을 놓고 원하는 대로 이름을 지정합니다. 그런 다음 "./Dockerfile"로 repo 루트에 한 번에 하나씩 복사하고 "docker build"를 실행한 다음 삭제하는 bash 스크립트가 있습니다. 그것이 내가 여러 프로젝트에서 하는 일이며 완벽하게 작동합니다. 모든 Dockerfile인 데이터베이스, 기본, 테스트 등과 같은 이름의 파일이 포함된 "dockerfiles" 폴더가 있습니다.

@ShawnMilo 감사합니다. 매우 합리적인 해결 방법인 것 같습니다.

+1

+1

-f +1 . 플래그가 생략되면 도커가 _올바른 일을 하는 정상적인 기본값이 있습니다. 어떤 이유에서든 _올바른 일_에 대한 매우 구체적인 보기가 사용자를 위한 _잘못된 일_인 경우 -f 있습니다. make 와 같은 도구에 대한 위의 비교는 합리적이라고 생각합니다. make 도 원래 1976년에 작성된 매우 독단적인 유틸리티이므로 기능 세트를 안정화하는 데 상당한 시간이 소요되었습니다. man make 에서 매우 간단한 시놉시스에서 언급되는 유일한 플래그는... -f 입니다.

       make [ -f makefile ] [ options ] ... [ targets ] ...

독단적인 ux 중심 유틸리티에는 문제가 없지만 -f 와 같은 일부 기능은 실제 사용자가 살고 있는 실제 세계에 대한 실용적인 고개를 끄덕입니다. 도구는 여러분의 삶을 힘들게 하는 것이 아니라 더 쉽게 만들어 주어야 합니다. -f 없이 도구를 해결하기 위해 Makefile 또는 쉘 스크립트를 작성해야 한다면 도구의 실패입니다. 시간을 내어 댓글을 달고 +1에 도달한 사용자 수를 보면 이 기능은 처음 제안된 지 1년이 지난 후에도 상당한 유용성을 가지고 있습니다.

+1

+1(또는 권장 해결 방법이 포함된 공식 블로그 게시물)

+1

+1

@crosbymichael #9707이 병합되어 지금 닫을 수 있다고 생각합니다.

승리.

이 새로운 기능을 사용해보고 싶다면 다음 위치에서 마스터용 바이너리를 다운로드할 수 있습니다.

master.dockerproject.com

@duglin 감사

:박수:

바이너리에 대해 @crosbymichael 에게 감사드립니다! :+1:

잘했어 얘들아! :박수:

docker build -f Dockerfile.dev . 입니까? 편집: 네