빌드킷

기타 소스코드

0.17.0

다운로드

빌드킷

BuildKit은 효율적이고 표현력이 풍부하며 반복 가능한 방식으로 소스 코드를 변환하여 아티팩트를 빌드하기 위한 툴킷입니다.

주요 기능:

자동 가비지 수집
확장 가능한 프런트엔드 형식
동시 종속성 해결
효율적인 명령어 캐싱
빌드 캐시 가져오기/내보내기
중첩된 빌드 작업 호출
분산형 작업자
다양한 출력 형식
플러그형 아키텍처
루트 권한 없이 실행

moby/moby#32925의 제안 읽기

소개 블로그 게시물 https://blog.mobyproject.org/introducing-buildkit-17e056cc5317

Docker Community Slack의 #buildkit 채널에 참여하세요

메모

RUN --mount=type=(bind|cache|tmpfs|secret|ssh) 와 같은 BuildKit 전용 Dockerfile 기능을 사용하기 위해 이 저장소를 방문하는 경우 Dockerfile 참조를 참조하세요.

메모

docker build Docker Engine 23.0부터 기본적으로 Buildx 및 BuildKit을 사용합니다. BuildKit의 모든 기능을 갖춘 독립형 버전을 사용하려는 경우가 아니면 이 문서를 읽을 필요가 없습니다.

사용처
빠른 시작

이미지/레지스트리
로컬 디렉토리
도커 타르볼
OCI 타르볼
컨테이너 이미지 저장소
buildctl 사용하여 Dockerfile 빌드
외부 프런트엔드를 사용하여 Dockerfile 빌드
리눅스 설정
윈도우 설치
macOS 설정
소스에서 빌드
LLB 탐구
Dockerfile 탐색
산출

은닉처

인라인(이미지와 캐시를 함께 푸시)
레지스트리(이미지와 캐시를 별도로 푸시)
로컬 디렉토리
GitHub Actions 캐시(실험적)
S3 캐시(실험적)
Azure Blob Storage 캐시(실험적)
쓰레기 수거
캐시 내보내기
일관된 해싱

메타데이터
시스템 소켓 활성화
BuildKit을 TCP 서비스로 노출

로드 밸런싱

BuildKit 컨테이너화

포드맨
Nerdctl
쿠버네티스
데몬리스

OpenTelemetry 지원
루트 권한 없이 BuildKit 실행
다중 플랫폼 이미지 구축

색상 출력 제어
로그 줄 수(tty 모드의 활성 단계용)
buildctl 구성

기여

사용처

BuildKit은 다음 프로젝트에서 사용됩니다.

모비 & 도커( DOCKER_BUILDKIT=1 docker build )
img
OpenFaaS 클라우드
컨테이너 빌드 인터페이스
Tekton Pipelines(이전의 Knative 빌드 템플릿)
Sanic 빌드 도구
바브
리오
김
파우치용기
도커 빌드X
옥테토 클라우드
지구의 어스파일
Gitpod
단검
환경
정거장
네임스페이스
유니크래프트
데브제로
dacc

빠른 시작

Kubernetes 배포에 대해서는 examples/kubernetes 참조하세요.

BuildKit은 buildkitd 데몬과 buildctl 클라이언트로 구성됩니다. buildctl 클라이언트는 Linux, macOS 및 Windows에서 사용할 수 있지만 buildkitd 데몬은 현재 Linux 및 *Windows에서만 사용할 수 있습니다.

BuildKit의 최신 바이너리는 Linux, macOS 및 Windows용 여기에서 사용할 수 있습니다.

리눅스 설정

buildkitd 데몬을 설치하려면 다음 구성 요소가 필요합니다.

런크 또는 크런
Containerd(containerd 작업자를 사용하려는 경우)

buildkitd 데몬 시작: 호스트에서 루트 사용자로 buildkitd 실행해야 합니다.

 $ sudo 빌드킷

루트가 아닌 사용자로 buildkitd 실행하려면 docs/rootless.md 참조하세요.

buildkitd 데몬은 OCI(runc)와 Containerd라는 두 가지 작업자 백엔드를 지원합니다.

기본적으로 OCI(runc) 작업자가 사용됩니다. --oci-worker=false --containerd-worker=true 설정하여 Containerd 작업자를 사용할 수 있습니다.

우리는 더 많은 백엔드를 추가할 준비가 되어 있습니다.

systemd 소켓 활성화를 사용하여 buildkitd 데몬을 시작하려면 buildkit systemd 단위 파일을 설치할 수 있습니다. Systemd 소켓 활성화를 참조하세요.

buildkitd 데몬은 기본적으로 /run/buildkit/buildkitd.sock 에서 gRPC API를 수신하지만 TCP 소켓을 사용할 수도 있습니다. BuildKit을 TCP 서비스로 노출을 참조하세요.

윈도우 설치

docs/windows.md 에서 지침과 참고 사항을 참조하세요.

macOS 설정

Homebrew 공식(비공식)은 macOS에서 사용할 수 있습니다.

 $ 브루 설치 빌드킷

Homebrew 공식에는 데몬( buildkitd )이 포함되어 있지 않습니다.

예를 들어 Lima는 Linux VM 내에서 데몬을 시작하는 데 사용될 수 있습니다.

 양조 설치 limalimactl 시작 템플릿://buildkitexport BUILDKIT_HOST="unix://$HOME/.lima/buildkit/sock/buildkitd.sock"

소스에서 빌드

소스에서 BuildKit을 빌드하려면 .github/CONTRIBUTING.md 참조하세요.

buildctl 참조는 이 문서를 참조하세요.

LLB 탐구

BuildKit 빌드는 빌드의 일부를 실행하는 프로세스에 대한 종속성 그래프를 정의하는 데 사용되는 LLB라는 이진 중간 형식을 기반으로 합니다. tl;dr: LLB는 Dockerfile에 대한 것이고 LLVM IR은 C에 대한 것입니다.

Protobuf 메시지로 마샬링됨
동시에 실행 가능
효율적으로 캐시 가능
공급업체 중립적(예: Dockerfile이 아닌 언어를 쉽게 구현할 수 있음)

형식 정의는 solver/pb/ops.proto 참조하고 LLB 애플리케이션 예제는 ./examples/README.md 참조하십시오.

현재 LLB에는 다음과 같은 고급 언어가 구현되었습니다.

Dockerfile(Dockerfile 탐색 참조)
빌드팩
모커파일
고커파일
bldr(패키지 파일)
HLB
어스파일(Earthly)
화물 부두(러스트)
아니야
mopy (파이썬)
envd (스타라크)
두툼한
베이스
kraft.yaml(유니크래프트)
r2d4/llb(JSON 게이트웨이)
(PR을 열어 자신의 언어를 추가하세요)

Dockerfile 탐색

프런트엔드는 BuildKit 내에서 실행되고 모든 빌드 정의를 LLB로 변환하는 구성 요소입니다. 모든 이미지를 프런트엔드로 사용할 수 있는 게이트웨이( gateway.v0 )라는 특수 프런트엔드가 있습니다.

개발 중에는 Dockerfile 프런트엔드( dockerfile.v0 )도 BuildKit 저장소의 일부입니다. 향후에는 이 기능이 제거될 예정이며 외부 이미지를 사용하여 Dockerfile을 빌드할 수 있습니다.

`buildctl` 사용하여 Dockerfile 빌드

 buildctl 빌드
     --frontend=dockerfile.v0
     --로컬 컨텍스트=.
     --local dockerfile=.# orbuildctl 빌드
     --frontend=dockerfile.v0
     --로컬 컨텍스트=.
     --로컬 도커파일=.
     --opt 대상=foo
     --opt 빌드 인수:foo=bar

--local 클라이언트의 로컬 소스 파일을 빌더에 노출합니다. context 및 dockerfile 은 Dockerfile 프런트엔드가 빌드 컨텍스트 및 Dockerfile 위치를 찾는 이름입니다.

Dockerfile의 파일 이름이 다른 경우 --opt filename=./Dockerfile-alternative 로 지정할 수 있습니다.

외부 프런트엔드를 사용하여 Dockerfile 빌드

Dockerfile 프런트엔드의 외부 버전은 https://hub.docker.com/r/docker/dockerfile-upstream 및 https://hub.docker.com/r/docker/dockerfile에 푸시되며 게이트웨이 프런트엔드와 함께 사용할 수 있습니다. . 외부 프런트엔드의 소스는 현재 ./frontend/dockerfile/cmd/dockerfile-frontend 에 있지만 향후 이 저장소에서 이동할 예정입니다(#163). 이 저장소의 마스터 브랜치에서 자동 빌드를 수행하려면 docker/dockerfile-upstream:master 또는 docker/dockerfile-upstream:master-labs 이미지를 사용할 수 있습니다.

 buildctl 빌드
     --프런트엔드 게이트웨이.v0
     --opt 소스=docker/dockerfile
     --로컬 컨텍스트=.
     --로컬 도커파일=.
buildctl 빌드
     --프런트엔드 게이트웨이.v0
     --opt 소스=docker/dockerfile
     --opt 컨텍스트=https://github.com/moby/moby.git
     --opt 빌드 인수:APT_MIRROR=cdn-fastly.deb.debian.org

산출

기본적으로 빌드 결과와 중간 캐시는 BuildKit 내부에만 유지됩니다. 결과를 검색하려면 출력을 지정해야 합니다.

이미지/레지스트리

 buildctl 빌드 ... --output type=image,name=docker.io/username/image,push=true

이미지를 여러 레지스트리로 내보내려면 다음 안내를 따르세요.

 buildctl 빌드 ... --output type=image,"name=docker.io/username/image,docker.io/username2/image2",push=true

이미지와 함께 포함된 캐시를 내보내고 레지스트리에 함께 푸시하려면 캐시를 가져오기 위해 registry 유형이 필요합니다. --export-cache type=inline 및 --import-cache type=registry,ref=... 를 지정해야 합니다. . 캐시를 로컬로 직접 내보내려면 --export-cache type=local 지정해야 합니다. 캐시 내보내기의 세부정보입니다.

 buildctl 빌드 ...
  --출력 유형=이미지, 이름=docker.io/username/image,push=true
   --export-cache 유형=인라인
   --import-cache 유형=registry,ref=docker.io/username/image

이미지 출력에서 지원되는 키:

name= : 이미지 이름을 지정합니다.
push=true : 이미지 생성 후 푸시
push-by-digest=true : 이름 없는 이미지 푸시
registry.insecure=true : 안전하지 않은 HTTP 레지스트리로 푸시
oci-mediatypes=true : Docker 대신 구성 JSON에서 OCI 미디어 유형을 사용합니다.
unpack=true : 생성 후 이미지 압축 풀기(containerd와 함께 사용)
dangling-name-prefix= : 익명 이미지에 사용되는 prefix@ 를 사용하여 이미지 이름을 지정합니다.
name-canonical=true : 추가 표준 이름 추가 name@
compression= : 새로 생성되고 캐시된 레이어에 대한 압축 유형을 선택합니다. gzip이 기본값입니다. estargz는 oci-mediatypes=true 와 함께 사용해야 합니다.
compression-level= : gzip, estarz(0-9) 및 zstd(0-22)의 압축 수준
rewrite-timestamp=true : 파일 타임스탬프를 SOURCE_DATE_EPOCH 값으로 다시 씁니다. SOURCE_DATE_EPOCH 값을 지정하는 방법은 docs/build-repro.md 참조하세요.
force-compression=true : 모든 레이어(이미 존재하는 레이어 포함)에 compression 옵션을 강제로 적용합니다.
store=true : 결과 이미지를 작업자(예: Containerd)의 이미지 저장소에 저장하고 이미지에 콘텐츠 저장소의 모든 Blob이 있는지 확인합니다(기본값 true ). 작업자에 이미지 저장소가 없으면 무시됩니다(예: OCI 작업자).
annotation.= : 해당 key 와 value 포함된 주석을 빌드된 이미지에 첨부합니다.

확장 구문을 사용하여 annotation-.= , annotation[].= 및 둘 다 annotation-[].= 결합 annotation-[].= 를 사용하면 주석을 첨부할 위치를 정확하게 구성할 수 있습니다.
연결할 개체를 지정하며 manifest (기본값), manifest-descriptor , index 및 index-descriptor 중 하나일 수 있습니다.
연결할 개체(기본적으로 all)를 지정하며 platform opt에 전달된 것과 동일한 키입니다. docs/multi-platform.md 참조하세요.
자세한 내용은 docs/annotations.md 참조하세요.

자격 증명이 필요한 경우 buildctl Docker 구성 파일 $DOCKER_CONFIG/config.json 읽기를 시도합니다. $DOCKER_CONFIG 의 기본값은 ~/.docker 입니다.

로컬 디렉토리

로컬 클라이언트는 파일을 클라이언트에 직접 복사합니다. 이는 컨테이너 이미지가 아닌 다른 것을 빌드하는 데 BuildKit을 사용하는 경우 유용합니다.

 buildctl build ... --output type=local,dest=path/to/output-dir

특정 파일을 내보내려면 스크래치 단계가 포함된 다단계 빌드를 사용하고 COPY --from 사용하여 필요한 파일을 해당 단계에 복사합니다.

 ...testresultCOPY --from=builder /usr/src/app/testresult.xml 로 처음부터 시작합니다.
...

 buildctl build ... --opt target=testresult --output type=local,dest=path/to/output-dir

다중 플랫폼 빌드를 사용하면 각 대상 플랫폼과 일치하는 하위 폴더가 대상 디렉터리에 생성됩니다.

 busybox AS buildARG TARGETOSARG TARGETARCHRUN mkdir /out && echo foo > /out/hello-$TARGETOS-$TARGETARCHFROM scrapCOPY --from=build /out /

 $ buildctl 빌드
   --프런트엔드 dockerfile.v0
   --opt 플랫폼=linux/amd64,linux/arm64
   --출력 유형=local,dest=./bin/release

$ 트리 ./bin
./큰 상자/
└── 출시
    ├── linux_amd64
    │ └── hello-linux-amd64
    └── linux_arm64
        └── hello-linux-arm64

platform-split=false 설정하여 모든 플랫폼의 파일을 동일한 디렉터리에 병합할 수 있습니다.

 $ buildctl 빌드
   --프런트엔드 dockerfile.v0
   --opt 플랫폼=linux/amd64,linux/arm64
   --output 유형=local,dest=./bin/release,platform-split=false

$ 트리 ./bin
./큰 상자/
└── 출시
    ├── hello-linux-amd64
    └── hello-linux-arm64

Tar 내보내기는 로컬 내보내기와 유사하지만 tarball을 통해 파일을 전송합니다.

 buildctl build ... --output 유형=tar,dest=out.tar
buildctl build ... --output 유형=tar > out.tar

도커 타르볼

 # 내보낸 tarball은 OCI specbuildctl build 와도 호환됩니다 ... --output type=docker,name=myimage | 도커 로드

OCI 타르볼

 buildctl build ... --output type=oci,dest=path/to/output.tar
buildctl build ... --output 유형=oci > 출력.tar

컨테이너 이미지 저장소

Containerd 작업자를 사용해야 합니다.

 buildctl 빌드 ... --output 유형=이미지, 이름=docker.io/username/image
ctr --namespace=buildkit 이미지 ls

Containerd 네임스페이스를 변경하려면 /etc/buildkit/buildkitd.toml 에서 worker.containerd.namespace 변경해야 합니다.

은닉처

로컬 빌드 캐시를 표시하려면( /var/lib/buildkit ):

 buildctl du -v

로컬 빌드 캐시를 정리하려면 다음 안내를 따르세요.

 buildctl 정리

쓰레기 수거

./docs/buildkitd.toml.md 참조하세요.

캐시 내보내기

BuildKit은 다음 캐시 내보내기를 지원합니다.

inline : 캐시를 이미지에 삽입하고 함께 레지스트리에 푸시합니다.
registry : 이미지와 캐시를 별도로 푸시합니다.
local : 로컬 디렉터리로 내보내기
gha : GitHub Actions 캐시로 내보내기

대부분의 경우 inline 캐시 내보내기를 사용하려고 합니다. 그러나 inline 캐시 내보내기는 min 캐시 모드만 지원합니다. max 캐시 모드를 활성화하려면 registry 캐시 내보내기를 사용하여 이미지와 캐시를 별도로 푸시하세요.

inline 및 registry 내보내기는 모두 캐시를 레지스트리에 저장합니다. 캐시를 가져오는 경우 캐시 형식을 지정할 필요가 없으므로 둘 다에 대해 type=registry 이면 충분합니다.

인라인(이미지와 캐시를 함께 푸시)

 buildctl 빌드 ...
   --출력 유형=이미지, 이름=docker.io/username/image,push=true
   --export-cache 유형=인라인
   --import-cache 유형=registry,ref=docker.io/username/image

--import-cache type=registry,ref=... 제공되지 않으면 인라인 캐시를 가져오지 않습니다.

인라인 캐시는 캐시 메타데이터를 이미지 구성에 포함합니다. 캐시 정보가 없는 이미지에 비해 이미지의 레이어는 그대로 유지됩니다.

Docker 통합 BuildKit( DOCKER_BUILDKIT=1 docker build ) 및 docker buildx inline 캐시 내보내기를 활성화하려면 --build-arg BUILDKIT_INLINE_CACHE=1 지정해야 합니다. 그러나 독립 실행 buildctl --opt build-arg:BUILDKIT_INLINE_CACHE=1 필요하지 않으며 build-arg는 단순히 무시됩니다.

레지스트리(이미지와 캐시를 별도로 푸시)

 buildctl 빌드 ...
   --output type=image,name=localhost:5000/myrepo:image,push=true
   --export-cache 유형=registry,ref=localhost:5000/myrepo:buildcache
   --import-cache 유형=registry,ref=localhost:5000/myrepo:buildcache

--export-cache 옵션:

type=registry
mode= : 내보낼 캐시 레이어 지정 (기본값: min )

min : 결과 이미지에 대한 레이어만 내보냅니다.
max : 모든 중간 단계의 모든 레이어를 내보냅니다.

ref= : 캐시를 저장하기 위한 저장소 참조를 지정합니다(예: docker.io/user/image:tag ).
image-manifest= : 캐시 매니페스트를 매니페스트 목록/인덱스가 아닌 OCI 호환 이미지 매니페스트로 내보낼지 여부(기본값: false , oci-mediatypes=true 와 함께 사용해야 함)
oci-mediatypes= : 내보낸 매니페스트에서 OCI 미디어 유형을 사용할지 여부(기본값: true , BuildKit v0.8 이후)
compression= : 새로 생성되고 캐시된 레이어에 대한 압축 유형을 선택합니다. gzip이 기본값입니다. estargz 및 zstd는 oci-mediatypes=true 와 함께 사용해야 합니다.
compression-level= : gzip, estarz(0-9) 및 zstd(0-22)에 대한 압축 수준을 선택합니다.
force-compression=true : 모든 레이어에 강제로 compression 옵션을 적용합니다.
ignore-error= : 캐시 내보내기가 실패한 경우 오류를 무시할지 여부를 지정합니다(기본값: false ).

--import-cache 옵션:

type=registry
ref= : 캐시를 검색할 저장소 참조를 지정합니다(예: docker.io/user/image:tag ).

로컬 디렉토리

 buildctl build ... --export-cache type=local,dest=path/to/output-dir
buildctl build ... --import-cache type=local,src=path/to/input-dir

디렉토리 레이아웃은 OCI Image Spec v1.0을 따릅니다.

--export-cache 옵션:

type=local
mode= : 내보낼 캐시 레이어 지정 (기본값: min )

min : 결과 이미지에 대한 레이어만 내보냅니다.
max : 모든 중간 단계의 모든 레이어를 내보냅니다.

dest= : 캐시 내보내기의 대상 디렉터리
tag= : 로컬 인덱스에 쓸 이미지의 사용자 정의 태그를 지정합니다 (기본값: latest )
image-manifest= : 캐시 매니페스트를 매니페스트 목록/인덱스가 아닌 OCI 호환 이미지 매니페스트로 내보낼지 여부(기본값: false , oci-mediatypes=true 와 함께 사용해야 함)
oci-mediatypes= : 내보낸 매니페스트에서 OCI 미디어 유형을 사용할지 여부(BuildKit v0.8 이후 기본값은 true )
compression= : 새로 생성되고 캐시된 레이어에 대한 압축 유형을 선택합니다. gzip이 기본값입니다. estargz 및 zstd는 oci-mediatypes=true 와 함께 사용해야 합니다.
compression-level= : gzip, estarz(0-9) 및 zstd(0-22)의 압축 수준
force-compression=true : 모든 레이어에 강제로 compression 옵션을 적용합니다.
ignore-error= : 캐시 내보내기가 실패한 경우 오류를 무시할지 여부를 지정합니다(기본값: false ).

--import-cache 옵션:

type=local
src= : 캐시 임포터의 소스 디렉터리
tag= : 로컬 인덱스에서 읽을 이미지의 사용자 정의 태그를 지정합니다. (기본값: latest )
digest=sha256: : 가져올 매니페스트 목록의 명시적 다이제스트를 지정합니다.

GitHub Actions 캐시(실험적)

 buildctl 빌드 ...
   --출력 유형=이미지, 이름=docker.io/username/image,push=true
   --export-cache 유형=gha
   --import-cache 유형=gha

GitHub Actions 캐시는 캐시 메타데이터와 레이어를 모두 GitHub의 캐시 서비스에 저장합니다. 이 캐시는 현재 저장소의 여러 캐시에서 공유되는 크기 제한이 10GB입니다. 이 제한을 초과하면 GitHub는 캐시를 저장하지만 총 크기가 10GB 미만이 될 때까지 캐시 제거를 시작합니다. 캐시를 너무 자주 재활용하면 전체적으로 런타임이 느려질 수 있습니다.

작업/캐시를 사용하는 것과 마찬가지로 캐시는 분기별로 범위가 지정되며 모든 분기에서 기본 및 대상 분기를 사용할 수 있습니다.

GitHub Actions Cache 서비스 API에 대해 인증하려면 다음 속성이 필요합니다.

url : 캐시 서버 URL (기본값 $ACTIONS_CACHE_URL )
token : 액세스 토큰 (기본값 $ACTIONS_RUNTIME_TOKEN )

이러한 유형의 캐시는 url 과 token 자동으로 설정되는 Docker Build Push Action과 함께 사용할 수 있습니다. 인라인 run 단계에서 이 백엔드를 사용하려면 워크플로에 crazy-max/ghaction-github-runtime을 포함하여 런타임을 노출해야 합니다.

--export-cache 옵션:

type=gha
mode= : 내보낼 캐시 레이어 지정 (기본값: min )

min : 결과 이미지에 대한 레이어만 내보냅니다.
max : 모든 중간 단계의 모든 레이어를 내보냅니다.

scope= : 캐시 객체가 속한 범위(기본 buildkit )
ignore-error= : 캐시 내보내기가 실패한 경우 오류를 무시할지 여부를 지정합니다(기본값: false ).
timeout= : 캐시 내보내기의 시간 초과 기간을 설정합니다(기본값: 10m ).

--import-cache 옵션:

type=gha
scope= : 캐시 객체가 속한 범위(기본 buildkit )
timeout= : 캐시 가져오기에 대한 시간 초과 기간을 설정합니다(기본값: 10m ).

S3 캐시(실험적)

 buildctl 빌드 ...
   --출력 유형=이미지, 이름=docker.io/username/image,push=true
   --export-cache 유형=s3,지역=eu-west-1,bucket=my_bucket,name=my_image
   --import-cache 유형=s3,지역=eu-west-1,bucket=my_bucket,name=my_image

다음 속성이 필요합니다.

bucket : AWS S3 버킷(기본값: $AWS_BUCKET )
region : AWS 지역 (기본값: $AWS_REGION )

저장 위치:

blob: s3://// , 기본값: s3:///blobs/
매니페스트: s3://// , 기본값: s3:///manifests/

S3 구성:

blobs_prefix : s3에서 Blob을 저장/읽기 위한 전역 접두사(기본값: blobs/ )
manifests_prefix : s3에서 매니페스트를 저장/읽기 위한 전역 접두사(기본값: manifests/ )
endpoint_url : 특정 S3 끝점을 지정합니다(기본값: 비어 있음).
use_path_style : true 로 설정하면 호스트 이름 대신 URL에 버킷 이름을 입력합니다. (기본값: false )

AWS 인증:

가장 간단한 방법은 IAM 인스턴스 프로필을 사용하는 것입니다. 다른 옵션은 다음과 같습니다:

AWS Go SDK에서 지원하는 환경 변수/구성 파일을 사용하는 모든 시스템. 클라이언트가 아닌 buildkit 데몬에 대해 구성을 사용할 수 있어야 합니다.
다음 속성을 사용합니다.

access_key_id : 액세스 키 ID
secret_access_key : 비밀 액세스 키
session_token : 세션 토큰

--export-cache 옵션:

type=s3
mode= : 내보낼 캐시 레이어 지정 (기본값: min )

min : 결과 이미지에 대한 레이어만 내보냅니다.
max : 모든 중간 단계의 모든 레이어를 내보냅니다.

prefix= : s3에 파일을 저장/읽기 위한 전역 접두사 설정(기본값: 비어 있음)
name= : 사용할 매니페스트 이름 지정(기본 buildkit )

여러 매니페스트 이름을 동시에 지정할 수 있으며 ; 로 구분됩니다. . 표준 사용 사례는 git sha1을 이름으로 사용하고 분기 이름을 중복으로 사용하고 2개의 import-cache 명령으로 둘 다 로드하는 것입니다.

ignore-error= : 캐시 내보내기가 실패한 경우 오류를 무시할지 여부를 지정합니다(기본값: false ).
touch_refresh=24h : 변경되지 않은 경우 다시 업로드되는 대신 Blob 파일은 touch_refresh 때마다 s3에서 "터치"됩니다. 기본값은 24시간입니다. 이로 인해 S3 버킷에 만료 정책을 설정하여 쓸모 없는 파일을 자동으로 정리할 수 있습니다. 매니페스트 파일은 체계적으로 다시 작성되므로 손댈 필요가 없습니다.
upload_parallelism=4 : 이 매개변수는 s3에 병렬로 업로드되는 레이어 수를 변경합니다. 각 개별 레이어는 AWS SDK에서 제공하는 업로드 관리자를 사용하여 5개의 스레드로 업로드됩니다.

--import-cache 옵션:

type=s3
prefix= : s3에 파일을 저장/읽기 위한 전역 접두사 설정(기본값: 비어 있음)
blobs_prefix= : s3에서 Blob을 저장/읽기 위한 전역 접두사 설정(기본값: blobs/ )
manifests_prefix= : s3에서 매니페스트를 저장/읽기 위한 전역 접두사 설정(기본값: manifests/ )
name= : 사용할 매니페스트의 이름(기본 buildkit )

Azure Blob Storage 캐시(실험적)

 buildctl 빌드 ...
   --출력 유형=이미지, 이름=docker.io/username/image,push=true
   --export-cache 유형=azblob,account_url=https://myaccount.blob.core.windows.net,name=my_image
   --import-cache 유형=azblob,account_url=https://myaccount.blob.core.windows.net,name=my_image

다음 속성이 필요합니다.

account_url : Azure Blob Storage 계정 URL(기본값: $BUILDKIT_AZURE_STORAGE_ACCOUNT_URL )

저장 위치:

blob: /// , 기본값: //blobs/
매니페스트: /// , 기본값: //manifests/

Azure Blob Storage 구성:

container : Azure Blob Storage 컨테이너 이름(기본값: buildkit-cache 또는 설정된 경우 $BUILDKIT_AZURE_STORAGE_CONTAINER )
blobs_prefix : Azure Blob Storage 컨테이너( )에서 Blob을 저장/읽기 위한 전역 접두사(기본값: blobs/ )
manifests_prefix : Azure Blob Storage 컨테이너( )에서 Blob을 저장/읽기 위한 전역 접두사(기본값: manifests/ )

Azure Blob Storage 인증:

Azure Blob Storage 인증에는 두 가지 옵션이 지원됩니다.

Go용 Azure SDK에서 지원하는 환경 변수를 사용하는 모든 시스템입니다. 클라이언트가 아닌 buildkit 데몬에 대해 구성을 사용할 수 있어야 합니다.
Azure Blob Storage 계정에 대한 기본 또는 보조 계정 키를 지정하기 위해 secret_access_key 특성을 사용하는 비밀 액세스 키. Azure Blob Storage 계정 키

메모

계정 이름이 계정 URL 호스트의 일부가 아닌 경우 account_name 속성(또는 $BUILDKIT_AZURE_STORAGE_ACCOUNT_NAME )을 사용하여 지정할 수도 있습니다.

--export-cache 옵션:

type=azblob
mode= : 내보낼 캐시 레이어 지정 (기본값: min )

min : 결과 이미지에 대한 레이어만 내보냅니다.
max : 모든 중간 단계의 모든 레이어를 내보냅니다.

prefix= : Azure Blob Storage 컨테이너( )에서 파일을 저장/읽기 위해 전역 접두사를 설정합니다(기본값: 비어 있음).
name= : 사용할 매니페스트의 이름을 지정합니다. (기본값: buildkit )

여러 매니페스트 이름을 동시에 지정할 수 있으며 ; 로 구분됩니다. . 표준 사용 사례는 git sha1을 이름으로 사용하고 분기 이름을 중복으로 사용하고 2개의 import-cache 명령으로 둘 다 로드하는 것입니다.

ignore-error= : 캐시 내보내기가 실패한 경우 오류를 무시할지 여부를 지정합니다(기본값: false ).

--import-cache 옵션:

type=azblob
prefix= : Azure Blob Storage 컨테이너( )에서 파일을 저장/읽기 위해 전역 접두사를 설정합니다(기본값: 비어 있음).
blobs_prefix= : Azure Blob Storage 컨테이너( )에서 Blob을 저장/읽기 위한 전역 접두사 설정(기본값: blobs/ )
manifests_prefix= : Azure Blob Storage 컨테이너( )에서 매니페스트를 저장/읽기 위한 전역 접두사 설정(기본값: manifests/ )
name= : 사용할 매니페스트의 이름(기본값: buildkit )

일관된 해싱

BuildKit 데몬 인스턴스가 여러 개 있지만 클러스터 전체에서 캐시를 공유하기 위해 레지스트리를 사용하지 않으려는 경우 일관된 해싱을 사용하는 클라이언트 측 로드 밸런싱을 고려하세요.

./examples/kubernetes/consistenthash 참조하세요.

메타데이터

이미지 다이제스트와 같은 빌드 메타데이터를 출력하려면 --metadata-file 플래그를 전달하세요. 메타데이터는 지정된 파일에 JSON 개체로 기록됩니다. 지정된 파일의 디렉터리가 이미 존재하고 쓰기 가능해야 합니다.

 buildctl 빌드 ... --metadata-file 메타데이터.json

 jq '.' 메타데이터.json

 { "containerimage.config.digest": "sha256:2937f66a9722f7f4a2df583de2f8cb97fc9196059a410e7f00072fc918930e66", "containerimage.descriptor": {"주석": { "config.digest": "sha256:2937f66a9 722f7f4a2df583de2f8cb97fc9196059a410e7f00072fc918930e66", "org.opencontainers.image.created": " 2022-02-08T21:28:03Z"},"다이제스트": "sha256:19ffeab6f8bc9293ac2c3fdf94ebe28396254c993aea0b5a542cfb02e0883fa3","mediaType": "application/vnd.oci.image.manifest.v1+json","size" : 506
  }, "containerimage.digest": "sha256:19ffeab6f8bc9293ac2c3fdf94ebe28396254c993aea0b5a542cfb02e0883fa3"}

시스템 소켓 활성화

Systemd 기반 시스템에서는 buildkitd --addr fd:// 사용하여 Systemd 소켓 활성화를 통해 데몬과 통신할 수 있습니다. ./examples/systemd 에서 BuildKit 및 Systemd와 함께 Systemd 소켓 활성화를 사용하는 예를 찾을 수 있습니다.

BuildKit을 TCP 서비스로 노출

buildkitd 데몬은 TCP 소켓에서 gRPC API를 수신할 수 있습니다.

데몬과 클라이언트(mTLS) 모두에 대해 TLS 인증서를 생성하는 것이 좋습니다. mTLS 없이 TCP를 활성화하는 것은 실행기 컨테이너(Dockerfile RUN 컨테이너라고도 함)가 BuildKit API도 호출할 수 있기 때문에 위험합니다.

 빌드킷
   --addr tcp://0.0.0.0:1234
   --tlscacert /path/to/ca.pem
   --tlscert /path/to/cert.pem
   --tlskey /path/to/key.pem

 buildctl
   --addr tcp://example.com:1234
   --tlscacert /path/to/ca.pem
   --tlscert /path/to/clientcert.pem
   --tlskey /path/to/clientkey.pem
   짓다 ...

로드 밸런싱

buildctl build 무작위로 로드 밸런싱된 buildkitd 데몬에 대해 호출될 수 있습니다.

클라이언트 측 로드 밸런싱을 위한 일관된 해싱도 참조하세요.

BuildKit 컨테이너화

BuildKit은 Docker 컨테이너 내에서 buildkitd 데몬을 실행하고 원격으로 액세스하여 사용할 수도 있습니다.

컨테이너 이미지를 moby/buildkit 으로 제공합니다.

moby/buildkit:latest : 최신 정규 릴리스에서 빌드됨
moby/buildkit:rootless : latest 과 동일하지만 권한이 없는 사용자로 실행됩니다. docs/rootless.md 참조하세요.
moby/buildkit:master : 마스터 브랜치에서 빌드됨
moby/buildkit:master-rootless : master와 동일하지만 권한이 없는 사용자로 실행됩니다. docs/rootless.md 참조하세요.

컨테이너에서 데몬을 실행하려면 다음 안내를 따르세요.

 docker run -d --name buildkitd --privileged moby/buildkit:latestexport BUILDKIT_HOST=docker-container://buildkitd
buildctl 빌드 --help

포드맨

Podman 컨테이너에서 실행 중인 BuildKit 데몬에 연결하려면 podman-container:// 대신 docker-container:// 사용하세요.

 podman run -d --name buildkitd --privileged moby/buildkit:latest
buildctl --addr=podman-container://buildkitd build --frontend dockerfile.v0 --local context=. --로컬 도커파일=. --출력 유형=oci | 포드맨 로드 foo

sudo 필요하지 않습니다.

Nerdctl

Nerdctl 컨테이너에서 실행 중인 BuildKit 데몬에 연결하려면 nerdctl-container:// docker-container:// 사용하세요.

 nerdctl run -d --name buildkitd --권한 있는 moby/buildkit:latest
buildctl --addr=nerdctl-container://buildkitd build --frontend dockerfile.v0 --local context=. --로컬 도커파일=. --출력 유형=oci | nerdctl 로드

sudo 필요하지 않습니다.

쿠버네티스

Kubernetes 배포에 대해서는 examples/kubernetes 참조하세요.

데몬리스

단일 컨테이너에서 클라이언트와 임시 데몬을 실행하려면("데몬 없는 모드"):

 도커 실행
     -그것
     --rm
     --특권
     -v /path/to/dir:/tmp/work
     --entrypoint buildctl-daemonless.sh
     모비/빌드킷:마스터
         짓다
         --프런트엔드 dockerfile.v0
         --로컬 컨텍스트=/tmp/work
         --local dockerfile=/tmp/work

또는

 도커 실행
     -그것
     --rm
     --security-opt seccomp=제한되지 않음
     --security-opt apparmor=제한되지 않음
     -e BUILDKITD_FLAGS=--oci-worker-no-process-sandbox
     -v /path/to/dir:/tmp/work
     --entrypoint buildctl-daemonless.sh
     moby/buildkit:마스터-루트리스
         짓다
         --프런트엔드
         dockerfile.v0
         --로컬 컨텍스트=/tmp/work
         --local dockerfile=/tmp/work

OpenTelemetry 지원

BuildKit은 buildkitd gRPC API 및 buildctl 명령에 대해 OpenTelemetry를 지원합니다. Jaeger에 대한 추적을 캡처하려면 JAEGER_TRACE 환경 변수를 컬렉션 주소로 설정하십시오.

 docker run -d -p6831:6831/udp -p16686:16686 jaegertracing/all-in-one:latestexport JAEGER_TRACE=0.0.0.0:6831# JAEGER_TRACE# 모든 buildctl 명령이 http:/로 추적되어야 함을 알 수 있도록 buildkitd 및 buildctl을 다시 시작합니다. /127.0.0.1:16686/

Windows에서 jaeger-all-in-one.exe 컨테이너 외부에서 Jaeger를 실행하는 경우 환경 변수 setx -m JAEGER_TRACE "0.0.0.0:6831" 설정하고 새 터미널에서 buildkitd 다시 시작하면 추적이 다음과 같이 됩니다. 자동으로 수집됩니다.

루트 권한 없이 BuildKit 실행

docs/rootless.md 를 참조하세요.

다중 플랫폼 이미지 구축

docs/multi-platform.md 를 참조하세요.

`buildctl` 구성

색상 출력 제어

buildctl 정보를 터미널에 출력하는 데 사용되는 색상 수정을 지원합니다. 환경 변수 BUILDKIT_COLORS run=green:warning=yellow:error=red:cancel=255,165,0 같이 설정하여 사용하려는 색상을 설정할 수 있습니다. NO_COLOR 무엇이든 설정하면 no-color.org에서 권장하는 대로 색상화된 출력이 비활성화됩니다.

구문 분석 오류가 보고되지만 무시됩니다. 그러면 필요한 경우 기본 색상 값이 사용됩니다.

미리 정의된 색상 목록입니다.

로그 줄 수(tty 모드의 활성 단계용)

BUILDKIT_TTY_LOG_LINES 숫자(기본값: 6)로 설정하여 tty 모드의 활성 단계에 표시되는 로그 줄 수를 변경할 수 있습니다.

기여

BuildKit에 기여하고 싶으신가요? 엄청난! CONTRIBUTING.md에서 이 프로젝트에 기여하는 방법에 대한 정보를 찾을 수 있습니다.

확장하다

추가 정보

버전 0.17.0
유형 기타 소스코드
업데이트 시간 2024-11-05
크기
언어 간체 중국어

빌드킷

빌드킷

사용처

빠른 시작

리눅스 설정

윈도우 설치

macOS 설정

소스에서 빌드

LLB 탐구

Dockerfile 탐색

buildctl 사용하여 Dockerfile 빌드

외부 프런트엔드를 사용하여 Dockerfile 빌드

산출

이미지/레지스트리

로컬 디렉토리

도커 타르볼

OCI 타르볼

컨테이너 이미지 저장소

은닉처

쓰레기 수거

캐시 내보내기

인라인(이미지와 캐시를 함께 푸시)

레지스트리(이미지와 캐시를 별도로 푸시)

로컬 디렉토리

GitHub Actions 캐시(실험적)

S3 캐시(실험적)

Azure Blob Storage 캐시(실험적)

일관된 해싱

메타데이터

시스템 소켓 활성화

BuildKit을 TCP 서비스로 노출

로드 밸런싱

BuildKit 컨테이너화

포드맨

Nerdctl

쿠버네티스

데몬리스

OpenTelemetry 지원

루트 권한 없이 BuildKit 실행

다중 플랫폼 이미지 구축

buildctl 구성

색상 출력 제어

로그 줄 수(tty 모드의 활성 단계용)

기여

`buildctl` 사용하여 Dockerfile 빌드

`buildctl` 구성