남성
v1.23.2
다음 조건이 충족되어야 합니다.
귀하의 요구에 가장 적합한 자동화 도구를 찾는 것은 귀하에게 달려 있습니다. GitHub 워크플로 또는 GitLab CI와 같은 최신 CI/CD 시스템을 사용하는 것이 좋습니다. 우리(저자)가 GitLab CI를 사용하게 되면서 다음 예제는 이 특정 플랫폼에 맞게 조정되었지만 기본 원칙은 다른 곳에도 적용되어야 하며 예제는 충분히 단순하게 유지되므로 별도의 설명 없이도 따라갈 수 있을 것입니다. 이 특정 플랫폼에 대한 이전 경험. 확실하지 않은 경우 GitLab CI 키워드에 대한 포괄적인 개요를 보려면 gitlab-ci.yml 참조 페이지를 방문하세요.
gitlab-ci.yml:
# define a job for building the containers
build-container :
stage : container-build
# run parallel builds for the desired architectures
parallel :
matrix :
- ARCH : amd64
- ARCH : arm64
tags :
# run each build on a suitable, preconfigured runner (must match the target architecture)
- runner-${ARCH}
image :
name : gcr.io/kaniko-project/executor:debug
entrypoint : [""]
script :
# build the container image for the current arch using kaniko
- >-
/kaniko/executor --context "${CI_PROJECT_DIR}" --dockerfile
"${CI_PROJECT_DIR}/Dockerfile" # push the image to the GitLab container
registry, add the current arch as tag. --destination
"${CI_REGISTRY_IMAGE}:${ARCH}" gitlab-ci.yml:
# define a job for creating and pushing a merged manifest
merge-manifests :
stage : container-build
# all containers must be build before merging them
# alternatively the job may be configured to run in a later stage
needs :
- job : container-build
artifacts : false
tags :
# may run on any architecture supported by manifest-tool image
- runner-xyz
image :
name : mplatform/manifest-tool:alpine
entrypoint : [""]
script :
- >-
manifest-tool # authorize against your container registry
--username=${CI_REGISTRY_USER} --password=${CI_REGISTRY_PASSWORD} push
from-args # define the architectures you want to merge --platforms
linux/amd64,linux/arm64 # "ARCH" will be automatically replaced by
manifest-tool # with the appropriate arch from the platform definitions
--template ${CI_REGISTRY_IMAGE}:ARCH # The name of the final, combined
image which will be pushed to your registry --target ${CI_REGISTRY_IMAGE} 단순화를 위해 이전 예에서는 버전이 지정된 태그가 지정된 이미지(모든 빌드는 "최신"으로 태그가 지정됨)를 의도적으로 사용하지 않았습니다. 이는 많은 플랫폼 및 워크플로 관련 코드에 추가되는 것처럼 느껴지기 때문입니다.
그럼에도 불구하고 GitLab에서 (동적) 버전 관리를 처리하는 방법에 관심이 있는 분들을 위해 다음과 같은 간단한 요약을 제공합니다.
CI_COMMIT_TAG 변수를 사용하면 됩니다.needs 섹션을 적절하게 확장하는 것을 잊지 마세요). 기본 브랜치에서 실행될 때 태그를 latest 으로 설정합니다. 다른 브랜치에서 실행될 때는 커밋 해시에, 태그 파이프라인에서 실행될 때는 릴리스 태그에 저장됩니다.gitlab-ci.yml:
container-get-tag :
stage : pre-container-build-stage
tags :
- runner-xyz
image : busybox
script :
# All other branches are tagged with the currently built commit SHA hash
- |
# If pipeline runs on the default branch: Set tag to "latest"
if test "$CI_COMMIT_BRANCH" == "$CI_DEFAULT_BRANCH"; then
tag="latest"
# If pipeline is a tag pipeline, set tag to the git commit tag
elif test -n "$CI_COMMIT_TAG"; then
tag="$CI_COMMIT_TAG"
# Else set the tag to the git commit sha
else
tag="$CI_COMMIT_SHA"
fi
- echo "tag=$tag" > build.env
# parse tag to the build and merge jobs.
# See: https://docs.gitlab.com/ee/ci/variables/#pass-an-environment-variable-to-another-job
artifacts :
reports :
dotenv : build.env 유사한 도구는 다음과 같습니다.
이러한 도구는 모두 다양한 접근 방식으로 컨테이너 이미지를 구축합니다.
BuildKit(및 img )은 컨테이너 내에서 루트가 아닌 사용자로 수행할 수 있지만 중첩된 컨테이너를 생성하려면 seccomp 및 AppArmor를 비활성화해야 합니다. kaniko 실제로 중첩된 컨테이너를 생성하지 않으므로 seccomp 및 AppArmor를 비활성화할 필요가 없습니다. BuildKit은 QEMU를 활용하여 "크로스 빌딩" 멀티 아키텍처 컨테이너를 지원합니다.
orca-build runc 사용하여 Dockerfile에서 이미지를 빌드합니다. 이는 컨테이너 내부에서 실행할 수 없습니다(위의 img 와 비슷한 이유로). kaniko runc 사용하지 않으므로 커널 네임스페이스 기술을 사용할 필요가 없습니다. 그러나 orca-build Docker나 권한이 있는 데몬이 필요하지 않습니다. 따라서 빌드는 권한 없이 완전히 수행될 수 있습니다.
umoci 권한 없이 작동하며 추출되는 루트 파일 시스템에 대한 제한도 없습니다(파일 시스템이 충분히 복잡한 경우 추가 처리가 필요하지만). 그러나 Dockerfile 과 같은 빌드 도구는 없습니다( orca-build 와 같은 빌더를 빌드하는 데 사용할 수 있는 약간 낮은 수준의 도구입니다).
Buildah OCI 이미지 구축을 전문으로 합니다. Buildah의 명령은 Dockerfile에 있는 모든 명령을 복제합니다. 이를 통해 루트 권한이 필요하지 않으면서 Dockerfile을 사용하거나 사용하지 않고 이미지를 구축할 수 있습니다. Buildah의 궁극적인 목표는 이미지 빌드를 위한 하위 수준의 coreutils 인터페이스를 제공하는 것입니다. Dockerfile 없이 이미지를 유연하게 빌드할 수 있으므로 다른 스크립팅 언어를 빌드 프로세스에 통합할 수 있습니다. Buildah는 간단한 포크 실행 모델을 따르며 데몬으로 실행되지는 않지만 다른 도구에 판매될 수 있는 golang의 포괄적인 API를 기반으로 합니다.
FTL 과 Bazel 이미지 하위 집합에 대한 Docker 이미지를 가장 빠르게 생성하는 것을 목표로 합니다. 이는 kaniko가 제공하는 일반 Dockerfiles에 대한 지원과 함께 사용할 수 있는 특수한 경우의 "빠른 경로"로 생각할 수 있습니다.
kaniko-사용자 Google 그룹
kaniko에 기여하려면 DEVELOPMENT.md 및 CONTRIBUTING.md를 참조하세요.
스냅샷을 찍을 때 kaniko의 해싱 알고리즘은 파일이 변경되었는지 확인하기 위해 파일의 mtime 포함합니다(또는 --snapshot-mode=time 의 경우에만 사용). 불행하게도 파일이 변경되는 시점과 mtime 이 업데이트되는 시점 사이에는 지연이 있습니다. 이는 다음을 의미합니다.
--snapshot-mode=time )를 사용하면 kaniko가 RUN 명령으로 도입된 변경 사항을 완전히 놓칠 수 있습니다.--snapshot-mode=full )를 사용하면 RUN 명령이 파일을 수정 하지만 내용이 변경되지 않는 경우 kaniko가 레이어를 추가할지 여부는 이론적으로 비결정적입니다. 이는 여전히 올바른 내용에는 영향을 미치지 않지만 레이어 수에는 영향을 미칩니다.이러한 문제는 현재 이론적인 문제일 뿐입니다. 이 문제가 발생하는 경우 문제를 열어주세요.
--chown 지원 Kaniko는 현재 COPY --chown 및 ADD --chown Dockerfile 명령을 지원합니다. RUN --chown 지원하지 않습니다.
