Docker Buildx Bake를 사용하여 복잡한 이미지 빌드 파이프라인을 만드는 방법
게시 됨: 2022-08-10 docker buildx
명령 그룹은 BuildKit을 사용하여 고급 이미지 빌드 기능을 노출합니다. 구운 빌드는 자동화된 빌드 파이프라인을 정의하는 데 사용할 수 있는 고급 기능입니다. 단일 빌드 작업에서 여러 이미지를 생성할 수 있습니다.
베이크된 워크플로는 이미지의 다양한 변형을 게시하거나 여러 연결된 프로젝트를 병렬로 구축하려는 경우에 유용합니다. 이 기사에서는 docker buildx bake
의 주요 기능과 이를 사용하여 복잡한 빌드를 간소화하는 방법에 대해 설명합니다.
시작하기
docker buildx bake
명령은 각각 컨테이너 이미지를 생성하는 여러 빌드 "대상"을 실행합니다. 성능을 최대화하기 위해 가능한 경우 대상이 병렬로 실행됩니다. 대상은 순차 파이프라인을 생성하기 위해 선행 작업을 직접 참조할 수도 있습니다.
빌드 대상은 기존 Docker Compose 파일을 비롯한 다양한 메커니즘을 사용하여 정의할 수 있습니다. Buildx는 파일에서 식별된 모든 이미지를 자동으로 빌드합니다.
JSON 또는 HCL 파일에 빌드 대상을 나열하면 더 많은 고급 기능이 노출됩니다. 이러한 지원 변수, 함수 및 값 보간을 통해 빌드를 사용자 지정할 수 있습니다.
buildx bake
명령은 다음 파일을 순서대로 찾습니다.
-
docker-compose.yml
-
docker-compose.yaml
-
docker-bake.json
-
docker-bake.override.json
-
docker-bake.hcl
-
docker-bake.override.hcl
-f
명령 플래그를 사용하여 다른 파일을 지정할 수 있습니다.
빌드 타겟
빌드 대상은 빌드와 관련된 모든 구성을 캡슐화합니다. 다음과 같은 세부 정보가 포함됩니다.
- 빌드할 Dockerfile의 경로
- Dockerfile 내에서 사용 가능한 콘텐츠 정의, 컨텍스트 경로 빌드
- 출력 이미지에 첨부할 태그 및 레이블
- 이미지를 생성하는 플랫폼.
지원되는 구성 필드의 전체 목록은 설명서에서 확인할 수 있습니다. 이전에는 이러한 설정을 docker buildx build
(또는 일반 docker build
)에 명령줄 플래그로 제공하여 매번 올바른 값을 기억해야 했습니다. buildx bake
를 사용하면 버전 제어 베이크 파일에서 동일한 값을 정의하여 안정적으로 사용할 수 있습니다.
다음은 단일 빌드 대상을 정의하는 docker-bake.hcl
명령의 간단한 예입니다.
target "default" { dockerfile = "app/Dockerfile" contexts = { app = "app/src" shared = "shared-components/src" } tags = ["my-app:latest", "docker.io/my-org/my-app:latest"] }
이 베이크 파일로 docker buildx bake
를 실행하면 작업 디렉터리에서 app/Dockerfile
Dockerfile이 로드됩니다. 빌드 컨텍스트로 app/src
및 shared-components/src
디렉토리에 액세스할 수 있습니다. 생성된 이미지에는 두 개의 태그가 할당됩니다.
default
대상은 docker buildx bake
를 실행할 때 자동으로 빌드됩니다. 요청 시 구축할 수 있는 명명된 대상을 정의할 수도 있습니다.
target "app" { // ... }
$ docker buildx bake app
여러 대상 사용
베이킹 파일 내에서 새 대상으로 정의하여 다른 이미지를 동시에 빌드할 수 있습니다.
group "default" { targets = ["app", "api"] } target "app" { dockerfile = "app/Dockerfile" contexts = { app = "app/src" shared = "shared-components/src" } tags = ["my-app:latest", "docker.io/my-org/my-app:latest"] } target "api" { dockerfile = "api/Dockerfile" contexts = { src = "api/src" } tags = ["my-api:latest", "docker.io/my-org/my-api:latest"] }
이러한 이미지는 그룹에 중첩되어 있으므로 동시에 빌드할 수 있습니다. api
및 app
이미지는 default
그룹이 자동으로 선택되므로 docker buildx bake
명령을 실행할 때마다 병렬로 빌드됩니다. 위의 명명된 대상 예와 유사하게 명명된 그룹을 사용할 수 있습니다.
대상 상속 빌드
빌드 대상은 구성을 재사용하기 위해 서로 상속할 수 있습니다. 이것이 유용할 수 있는 한 가지 시나리오는 다양한 환경에 맞게 사용자 정의해야 하는 이미지에 관한 것입니다. 개발용 이미지 변형에 추가 구성 파일을 추가할 수 있습니다. 다음은 이 모델을 보여주는 docker-bake.hcl
입니다.
group "default" { targets = ["backend", "backend-dev"] } target "backend" { dockerfile = "backend/Dockerfile" contexts = { src = "api/src" config = "api/config" } tags = ["backend:latest"] } target "backend-dev" { inherits = ["backend"] contexts = { config = "api/config-dev" } tags = ["backend:dev"] }
backend-dev
대상은 backend
대상의 모든 속성을 상속하지만 config
컨텍스트를 재정의하고 다른 태그를 적용합니다.

--print
플래그와 함께 bake
명령을 실행하여 병합된 파일 구조를 미리 볼 수 있습니다.
$ docker buildx bake --print ... "backend-dev": { "context": ".", "contexts": { "config": "api/config-dev", "src": "api/src" }, "dockerfile": "backend/Dockerfile", "tags": [ "backend:dev" ] } ...
이전 대상을 기본 이미지로 사용
때로는 빌드 대상이 이전 대상에서 만든 이미지를 자체 기반으로 사용하기를 원할 수 있습니다. 이것은 Dockerfile이 서로 의존하지만 함께 병합할 수 없는 경우 사용할 수 있는 다단계 빌드의 대안입니다. 아마도 서로 다른 프로젝트에 존재하기 때문일 수 있습니다.
group "default" { targets = ["org-base-image", "api"] } target "org-base-image" { dockerfile = "docker-base/Dockerfile" tags = ["org-base-image:latest"] } target "api" { dockerfile = "api/Dockerfile" contexts = { base = "target:org-base-image" } tags = ["api:latest"] }
이 예에서는 먼저 org-base-image
대상을 빌드합니다. 여기에는 조직의 컨테이너화된 워크로드에 공통적인 일부 유틸리티가 포함될 수 있습니다. 그런 다음 api
대상은 base
빌드 컨텍스트로 액세스할 수 있는 org-base-image
대상의 출력으로 빌드됩니다. API Dockerfile은 이제 기본 이미지 내부의 콘텐츠를 참조할 수 있습니다.
COPY --from=base /utilities/example /usr/bin/example-utility
이는 별도의 Dockerfile을 유지하면서 이미지 간에 종속성 링크를 생성할 수 있는 강력한 패턴입니다.
빌드 시 대상 속성 재정의
docker buildx bake
명령을 사용하면 빌드를 실행할 때 대상의 속성을 재정의할 수 있습니다.
$ docker buildx bake --set api.dockerfile="api/Dockerfile-dev"
이 예에서는 api
대상의 Dockerfile을 변경합니다. 변경할 대상을 식별할 때 *
와일드카드가 지원됩니다. *
자체적으로 모든 대상을 선택하는 반면 api*
는 api
로 시작하는 모든 대상을 수정합니다.
변수 설정
HCL 파일은 빌드 대상에서 참조할 수 있는 변수를 정의할 수 있습니다. variable
블록을 사용하여 설정하십시오.
variable "TAG" { default = "latest" } group "default" { targets = ["app"] } target "app" { dockerfile = "src/Dockerfile" tags = ["my-app:${TAG}"] }
이 구성으로 docker buildx bake
를 실행하면 app
대상에 my-app:latest
태그가 지정됩니다. 명령을 실행하기 전에 환경 변수를 설정하여 TAG
변수의 값을 변경할 수 있습니다.
$ TAG=v1 docker buildx bake
HCL 언어의 모든 변수 보간 및 비교 기능을 사용하여 빌드 대상을 재사용 가능하게 만들 수 있습니다. 값을 구문 분석하고 변환하는 데도 함수를 사용할 수 있습니다.
요약
구운 Buildx 빌드를 사용하면 이미지 빌드 구성을 파일에 정의된 "대상"으로 캡슐화할 수 있습니다. buildx bake
를 실행하면 참조된 모든 대상에 대한 이미지가 병렬로 빌드됩니다.
대상은 서로 상속되고 종속될 수 있습니다. 변수와 함수를 사용하여 매우 복잡하고 구성 가능한 빌드 파이프라인을 생성할 수도 있습니다.
docker buildx bake
명령은 모든 워크플로에서 필요하지 않은 고급 작업입니다. 프로젝트 간 종속성이 없는 간단한 이미지를 만들 때는 사용할 필요가 없습니다. docker compose build
를 사용하는 것은 docker-compose.yml
파일에 빌드 구성을 유지하는 대부분의 사용 사례에 대한 더 나은 대안입니다. 다양한 변수, 플랫폼, 빌드 컨텍스트 및 구성 재정의를 사용하여 동시에 많은 이미지를 빌드할 때 베이크된 빌드로 전환하는 것을 고려해야 합니다.