kaniko

KO | EN

gitlite — search

#javascript #python #hacktoberfest #react #ai #typescript #llm #go #golang #android #machine-learning #rust #deep-learning #linux

★ 15,779 Open GitHub ↗

Kubernetes에서 컨테이너 이미지 빌드하기

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

# 🧊 이 프로젝트는 보관(archived)되었으며 더 이상 개발 또는 유지보수되지 않습니다. 🧊
코드는 역사적 목적을 위해 계속 사용할 수 있습니다.
보관 시점의 README는 역사적 목적을 위해 아래에 변경되지 않은 상태로 유지됩니다.
-----
# kaniko - Build Images In Kubernetes
## 🚨참고: kaniko는 공식적으로 지원되는 Google 제품이 아닙니다🚨
[![Unit tests](https://github.com/GoogleContainerTools/kaniko/actions/workflows/unit-tests.yaml/badge.svg)](https://github.com/GoogleContainerTools/kaniko/actions/workflows/unit-tests.yaml)
[![Integration tests](https://github.com/GoogleContainerTools/kaniko/actions/workflows/integration-tests.yaml/badge.svg)](https://github.com/GoogleContainerTools/kaniko/actions/workflows/integration-tests.yaml)
[![Build images](https://github.com/GoogleContainerTools/kaniko/actions/workflows/images.yaml/badge.svg)](https://github.com/GoogleContainerTools/kaniko/actions/workflows/images.yaml)
[![Go Report Card](https://goreportcard.com/badge/github.com/GoogleContainerTools/kaniko)](https://goreportcard.com/report/github.com/GoogleContainerTools/kaniko)
![kaniko logo](https://raw.githubusercontent.com/GoogleContainerTools/kaniko/main/logo/Kaniko-Logo.png)
kaniko는 컨테이너 또는 Kubernetes 클러스터 내에서 Dockerfile로부터 컨테이너 이미지를 빌드하기 위한 도구입니다.
kaniko는 Docker 데몬에 의존하지 않으며 Dockerfile 내의 각 명령어를 유저스페이스에서 완전히 실행합니다. 이를 통해 표준 Kubernetes 클러스터와 같이 Docker 데몬을 쉽거나 안전하게 실행할 수 없는 환경에서도 컨테이너 이미지를 빌드할 수 있습니다.
kaniko는 이미지(`gcr.io/kaniko-project/executor`)로 실행되도록 설계되었습니다. 예상대로 작동하지 않을 수 있으므로 다른 이미지에서 kaniko executor 바이너리를 실행하는 것은 \*\*권장하지 않습니다\*\* - [Known Issues](#known-issues)를 참조하세요.
여러분의 의견을 들려주세요!
[#kaniko Kubernetes Slack](https://kubernetes.slack.com/messages/CQDCHGX7Y/)에 참여하세요.
:mega: kaniko에 대한 만족도와 개선해야 할 점을 파악할 수 있도록 \*\*[간단한 5문항 설문조사](https://forms.gle/HhZGEM33x4FUz9Qa6)\*\*에 참여해 주세요\*\*.
감사합니다! :dancers:
\_kaniko 기여에 관심이 있으시다면 [DEVELOPMENT.md](DEVELOPMENT.md)와 [CONTRIBUTING.md](CONTRIBUTING.md)를 참조하세요.\_

\*\*목차\*\* \_[DocToc](https://github.com/thlorenz/doctoc)\_로 생성됨
- [kaniko - 쿠버네티스에서 이미지 빌드하기](#kaniko---build-images-in-kubernetes)
- [🚨참고: kaniko는 Google에서 공식 지원하는 제품이 아닙니다🚨](#note-kaniko-is-not-an-officially-supported-google-product)
- [커뮤니티](#community)
- [kaniko는 어떻게 동작하나요?](#how-does-kaniko-work)
- [알려진 문제점](#known-issues)
- [데모](#demo)
- [튜토리얼](#tutorial)
- [kaniko 사용하기](#using-kaniko)
- [kaniko 빌드 컨텍스트](#kaniko-build-contexts)
- [Azure Blob Storage 사용하기](#using-azure-blob-storage)
- [프라이빗 Git 저장소 사용하기](#using-private-git-repository)
- [표준 입력(Standard Input) 사용하기](#using-standard-input)
- [kaniko 실행하기](#running-kaniko)
- [쿠버네티스 클러스터에서 kaniko 실행하기](#running-kaniko-in-a-kubernetes-cluster)
- [쿠버네티스 시크릿](#kubernetes-secret)
- [gVisor에서 kaniko 실행하기](#running-kaniko-in-gvisor)
- [Google Cloud Build에서 kaniko 실행하기](#running-kaniko-in-google-cloud-build)
- [Docker에서 kaniko 실행하기](#running-kaniko-in-docker)
- [캐싱](#caching)
- [레이어 캐싱](#caching-layers)
- [베이스 이미지 캐싱](#caching-base-images)
- [다양한 레지스트리로 푸시하기](#pushing-to-different-registries)
- [Docker Hub로 푸시하기](#pushing-to-docker-hub)
- [Google GCR로 푸시하기](#pushing-to-google-gcr)
- [Workload Identity를 사용하여 GCR로 푸시하기](#pushing-to-gcr-using-workload-identity)
- [Amazon ECR로 푸시하기](#pushing-to-amazon-ecr)
- [Azure Container Registry로 푸시하기](#pushing-to-azure-container-registry)
- [JFrog Container Registry 또는 JFrog Artifactory로 푸시하기](#pushing-to-jfrog-container-registry-or-to-jfrog-artifactory)
- [추가 플래그](#additional-flags)
- [`--build-arg` 플래그](#flag---build-arg)
- [`--cache` 플래그](#flag---cache)
- [`--cache-dir` 플래그](#flag---cache-dir)
- [`--cache-repo` 플래그](#flag---cache-repo)
- [`--cache-copy-layers` 플래그](#flag---cache-copy-layers)
- [`--cache-run-layers` 플래그](#flag---cache-run-layers)
- [`--cache-ttl duration` 플래그](#flag---cache-ttl-duration)
- [`--cleanup` 플래그](#flag---cleanup)
- [`--compressed-caching` 플래그](#flag---compressed-caching)
- [`--context-sub-path` 플래그](#flag---context-sub-path)
- [`--custom-platform` 플래그](#flag---custom-platform)
- [`--digest-file` 플래그](#flag---digest-file)
- [`--dockerfile` 플래그](#flag---dockerfile)
- [`--force` 플래그](#flag---force)
- [`--git` 플래그](#flag---git)
- [`--image-name-with-digest-file` 플래그](#flag---image-name-with-digest-file)
- [`--image-name-tag-with-digest-file` 플래그](#flag---image-name-tag-with-digest-file)
- [`--insecure` 플래그](#flag---insecure)
- [`--insecure-pull` 플래그](#flag---insecure-pull)
- [`--insecure-registry` 플래그](#flag---insecure-registry)
- [`--label` 플래그](#flag---label)
- [`--log-format` 플래그](#flag---log-format)
- [`--log-timestamp` 플래그](#flag---log-timestamp)
- [`--no-push` 플래그](#flag---no-push)
- [`--no-push-cache` 플래그](#flag---no-push-cache)
- [`--oci-layout-path` 플래그](#flag---oci-layout-path)
- [`--push-retry` 플래그](#flag---push-retry)
- [`--registry-certificate` 플래그](#flag---registry-certificate)
- [`--registry-client-cert` 플래그](#flag---registry-client-cert)
- [`--registry-map` 플래그](#flag---registry-map)
- [`--registry-mirror` 플래그](#flag---registry-mirror)
- [`--skip-default-registry-fallback` 플래그](#flag---skip-default-registry-fallback)
- [`--reproducible` 플래그](#flag---reproducible)
- [`--single-snapshot` 플래그](#flag---single-snapshot)
- [`--skip-push-permission-check` 플래그](#flag---skip-push-permission-check)
- [`--skip-tls-verify` 플래그](#flag---skip-tls-verify)
- [`--skip-tls-verify-pull` 플래그](#flag---skip-tls-verify-pull)
- [`--skip-tls-verify-registry` 플래그](#flag---skip-tls-verify-registry)
- [`--skip-unused-stages` 플래그](#flag---skip-unused-stages)
- [`--snapshot-mode` 플래그](#flag---snapshot-mode)
- [`--tar-path` 플래그](#flag---tar-path)
- [`--target` 플래그](#flag---target)
- [`--use-new-run` 플래그](#flag---use-new-run)
- [`--verbosity` 플래그](#flag---verbosity)
- [`--ignore-var-run` 플래그](#flag---ignore-var-run)
- [`--ignore-path` 플래그](#flag---ignore-path)
- [`--image-fs-extract-retry` 플래그](#flag---image-fs-extract-retry)
- [`--image-download-retry` 플래그](#flag---image-download-retry)
- [디버그 이미지](#debug-image)
- [보안](#security)
- [서명된 Kaniko 이미지 검증하기](#verifying-signed-kaniko-images)
- [Kaniko 빌드 - 프로파일링](#kaniko-builds---profiling)
- [Kaniko와 Manifest-tool을 사용한 멀티 아키텍처 컨테이너 매니페스트 생성하기](#creating-multi-arch-container-manifests-using-kaniko-and-manifest-tool)
- [일반적인 워크플로](#general-workflow)
- [제한 사항 및 주의점](#limitations-and-pitfalls)
- [예제 CI 파이프라인 (GitLab)](#example-ci-pipeline-gitlab)
- [개별 컨테이너 이미지 빌드하기](#building-the-separate-container-images)
- [컨테이너 매니페스트 병합하기](#merging-the-container-manifests)
- [버전 태그 추가에 관하여](#on-the-note-of-adding-versioned-tags)
- [다른 도구들과의 비교](#comparison-with-other-tools)
- [커뮤니티](#community-1)
- [제한 사항](#limitations)
- [mtime과 스냅샷 생성](#mtime-and-snapshotting)
- [참고 자료](#references)
## 커뮤니티
여러분의 의견을 들려주세요! Kubernetes Slack의 [#kaniko 채널](https://kubernetes.slack.com/messages/CQDCHGX7Y/)에 참여하세요.
## kaniko는 어떻게 동작하나요?
kaniko executor 이미지는 Dockerfile로부터 이미지를 빌드하고 이를 레지스트리에 푸시하는 역할을 담당합니다. executor 이미지 내부에서 베이스 이미지(Dockerfile의 FROM 이미지)의 파일 시스템을 추출합니다. 그 후 Dockerfile의 명령어들을 실행하며, 각 명령어 실행 후 유저스페이스에서 파일 시스템의 스냅샷을 찍습니다. 각 명령어 실행이 끝나면 변경된 파일들의 레이어(있는 경우)를 베이스 이미지에 추가하고 이미지 메타데이터를 업데이트합니다.
## 알려진 문제점
- kaniko는 Windows 컨테이너 빌드를 지원하지 않습니다.
- 공식 kaniko 이미지 외의 다른 Docker 이미지에서 kaniko를 실행하는 것은 구현 세부 사항으로 인해 지원되지 않습니다.
- 여기에는 공식 이미지에서 kaniko 실행 파일을 다른 이미지(예: Jenkins CI 에이전트)로 복사하는 것이 포함됩니다.
- 특히 chroot나 bind-mount를 사용할 수 없습니다. 컨테이너가 권한을 요구해서는 안 되기 때문에 자신의 컨테이너 루트에 직접 압축을 해제하므로 이미 존재하는 내용을 덮어쓸 수 있습니다.
- kaniko는 v1 레지스트리 API를 지원하지 않습니다 ([Registry v1 API Deprecation](https://www.docker.com/blog/registry-v1-api-deprecation/))
## 데모
![Demo](https://raw.githubusercontent.com/GoogleContainerTools/kaniko/main/docs/demo.gif)
## 튜토리얼
로컬 스토리지를 사용하는 kaniko의 자세한 예제는 [getting started tutorial](./docs/tutorial.md)을 참고하세요.
더 많은 문서와 동영상 튜토리얼은 [References](#References)를 참고하세요.
## kaniko 사용하기
kaniko를 사용하여 이미지를 빌드하고 푸시하려면 다음이 필요합니다:
1. [빌드 컨텍스트](#kaniko-build-contexts) (빌드할 대상)
2. [실행 중인 kaniko 인스턴스](#running-kaniko)
### kaniko 빌드 컨텍스트
kaniko의 빌드 컨텍스트는 이미지 빌드를 위해 Docker 데몬에 전달하는 빌드 컨텍스트와 매우 유사합니다. kaniko가 이미지를 빌드하는 데 사용할 Dockerfile이 포함된 디렉토리를 나타냅니다. 예를 들어 Dockerfile의 `COPY` 명령어는 빌드 컨텍스트 내의 파일을 가리켜야 합니다.
빌드 컨텍스트는 kaniko가 접근할 수 있는 위치에 저장해야 합니다. 현재 kaniko는 다음과 같은 스토리지 솔루션을 지원합니다:
- GCS Bucket
- S3 Bucket
- Azure Blob Storage
- Local Directory
- Local Tar
- Standard Input
- Git Repository
\_로컬 디렉토리 참고 사항: 이 옵션은 kaniko 컨테이너 내의 디렉토리를 의미합니다. 이 옵션을 사용하려면 빌드 컨텍스트를 컨테이너 내부로 디렉토리 형태로 마운트해야 합니다.\_
\_로컬 타르 참고 사항: 이 옵션은 kaniko 컨테이너 내의 tar gz 파일을 의미합니다. 이 옵션을 사용하려면 빌드 컨텍스트를 컨테이너 내부로 파일 형태로 마운트해야 합니다.\_
\_표준 입력 참고 사항: kaniko에서 허용하는 표준 입력은 `.tar.gz` 형식만 가능합니다.\_
GCS 또는 S3 버킷을 사용하는 경우, 먼저 빌드 컨텍스트의 압축된 tar 파일을 생성하여 버킷에 업로드해야 합니다. 실행되면 kaniko는 이미지 빌드를 시작하기 전에 빌드 컨텍스트의 압축된 tar 파일을 다운로드하고 압축을 풉니다.
압축된 tar 파일을 생성하려면 다음을 실행할 수 있습니다:
```shell
tar -C  -zcvf context.tar.gz .
```
그런 다음, 압축된 tar 파일을 버킷에 복사합니다. 예를 들어 gsutil을 사용하여 GCS 버킷에 복사할 수 있습니다:
```shell
gsutil cp context.tar.gz gs://
```
kaniko를 실행할 때 적절한 접두사와 함께 `--context` 플래그를 사용하여 빌드 컨텍스트의 위치를 지정하세요:
| 소스 | 접두사 | 예제 |
| ------------------ | --------------------------------------------------------------------- | ----------------------------------------------------------------------------- |
| 로컬 디렉토리 | dir://[kaniko 컨테이너 내의 디렉토리 경로] | `dir:///workspace` |
| 로컬 Tar Gz | tar://[kaniko 컨테이너 내의 .tar.gz 경로] | `tar:///path/to/context.tar.gz` |
| 표준 입력 | tar://[stdin] | `tar://stdin` |
| GCS Bucket | gs://[버킷 이름]/[.tar.gz 경로] | `gs://kaniko-bucket/path/to/context.tar.gz` |
| S3 Bucket | s3://[버킷 이름]/[.tar.gz 경로] | `s3://kaniko-bucket/path/to/context.tar.gz` |
| Azure Blob Storage | https://[계정].[azureblobhostsuffix]/[컨테이너]/[.tar.gz 경로] | `https://myaccount.blob.core.windows.net/container/path/to/context.tar.gz` |
| Git Repository | git://[저장소 URL][#참조][#커밋ID] | `git://github.com/acme/myproject.git#refs/heads/mybranch#` |
접두사를 지정하지 않으면 kaniko는 로컬 디렉토리로 간주합니다. 예를 들어 `kaniko-bucket`이라는 GCS 버킷을 사용하려면 `--context=gs://kaniko-bucket/path/to/context.tar.gz`를 전달하면 됩니다.
### Azure Blob Storage 사용하기
컨텍스트 파일로 Azure Blob Storage를 사용하는 경우, [Azure Storage 계정 액세스 키](https://docs.microsoft.com/en-us/azure/storage/common/storage-configure-connection-string?toc=%2fazure%2fstorage%2fblobs%2ftoc.json)를 쿠버네티스 시크릿을 통해 `AZURE\_STORAGE\_ACCESS\_KEY`라는 이름의 환경 변수로 전달해야 합니다.
### 프라이빗 Git 저장소 사용하기
[GitHub](https://blog.github.com/2012-09-21-easier-builds-and-deployments-using-git-over-https-and-oauth/)의 프라이빗 저장소에서 빌드 컨텍스트를 가져오기 위해 `Personal Access Tokens`를 사용할 수 있습니다. git URL의 일부로 포함하여 전달하거나(예: `git://TOKEN@github.com/acme/myproject.git#refs/heads/mybranch`), 환경 변수 `GIT\_TOKEN`을 사용할 수 있습니다.
사용자 이름을 명시적으로 지정하려면 `GIT\_USERNAME`과 `GIT\_PASSWORD`(비밀번호는 토큰)를 전달할 수도 있습니다.
### 표준 입력(Standard Input) 사용하기
kaniko를 실행하면서 표준 입력 빌드 컨텍스트를 사용하는 경우, docker 또는 kubernetes의 `-i, --interactive` 플래그를 추가해야 합니다. 실행 후 kaniko는 `STDIN`에서 데이터를 가져와 압축된 tar 형식으로 빌드 컨텍스트를 생성합니다. 그런 다음 이미지 빌드를 시작하기 전에 빌드 컨텍스트의 압축을 풉니다. 대화형 실행 중에 데이터가 파이프되지 않는 경우, `Ctrl+D`를 눌러 직접 EOF 신호를 보내야 합니다.
docker를 사용하여 `.tar.gz` 표준 입력 데이터로 kaniko를 대화형으로 실행하는 완전한 예제:
```shell
echo -e 'FROM alpine \nRUN echo "created from standard input"' > Dockerfile | tar -cf - Dockerfile | gzip -9 | docker run \
--interactive -v $(pwd):/workspace gcr.io/kaniko-project/executor:latest \
--context tar://stdin \
--destination=
```
임시 컨테이너를 사용하는 쿠버네티스 명령줄과 완전한 도커리스(dockerless) 방식을 사용하여 `.tar.gz` 표준 입력 데이터로 kaniko를 대화형으로 실행하는 완전한 예제:
```shell
echo -e 'FROM alpine \nRUN echo "created from standard input"' > Dockerfile | tar -cf - Dockerfile | gzip -9 | kubectl run kaniko \
--rm --stdin=true \
--image=gcr.io/kaniko-project/executor:latest --restart=Never \
--overrides='{
"apiVersion": "v1",
"spec": {
"containers": [
{
"name": "kaniko",
"image": "gcr.io/kaniko-project/executor:latest",
"stdin": true,
"stdinOnce": true,
"args": [
"--dockerfile=Dockerfile",
"--context=tar://stdin",
"--destination=gcr.io/my-repo/my-image"
],
"volumeMounts": [
{
"name": "cabundle",
"mountPath": "/kaniko/ssl/certs/"
},
{
"name": "docker-config",
"mountPath": "/kaniko/.docker/"
}
]
}
],
"volumes": [
{
"name": "cabundle",
"configMap": {
"name": "cabundle"
}
},
{
"name": "docker-config",
"configMap": {
"name": "docker-config"
}
}
]
}
}'
```
### kaniko 실행하기
kaniko를 배포하고 실행하는 방법에는 여러 가지가 있습니다:
- [쿠버네티스 클러스터에서](#running-kaniko-in-a-kubernetes-cluster)
- [gVisor에서](#running-kaniko-in-gvisor)
- [Google Cloud Build에서](#running-kaniko-in-google-cloud-build)
- [Docker에서](#running-kaniko-in-docker)
#### 쿠버네티스 클러스터에서 kaniko 실행하기
요구 사항:
- 표준 쿠버네티스 클러스터 (예: [GKE](https://cloud.google.com/kubernetes-engine/) 사용)
- [쿠버네티스 시크릿](#kubernetes-secret)
- [빌드 컨텍스트](#kaniko-build-contexts)
##### 쿠버네티스 시크릿
쿠버네티스 클러스터에서 kaniko를 실행하려면 표준 실행 중인 쿠버네티스 클러스터와 최종 이미지를 푸시하는 데 필요한 인증 정보가 포함된 쿠버네티스 시크릿이 필요합니다.
Google Cloud Registry에 인증하기 위한 시크릿을 생성하려면 다음 단계를 따르세요:
1. 최종 이미지를 푸시할 Google Cloud Console 프로젝트에서 `Storage Admin` 권한을 가진 서비스 계정을 생성합니다.
2. 이 서비스 계정의 JSON 키를 다운로드합니다.
3. 키 이름을 `kaniko-secret.json`으로 변경합니다.
4. 시크릿을 생성하려면 다음을 실행합니다:
```shell
kubectl create secret generic kaniko-secret --from-file=
```
\_참고: 빌드 컨텍스트와 동일한 GCP 프로젝트의 GCS 버킷을 사용하는 경우, 이 서비스 계정에는 해당 버킷에서 읽을 수 있는 권한도 있어야 합니다.\_
쿠버네티스 Pod 사양은 args 매개변수가 채워진 상태로 다음과 유사해야 합니다:
```yaml
apiVersion: v1
kind: Pod
metadata:
name: kaniko
spec:
containers:
- name: kaniko
image: gcr.io/kaniko-project/executor:latest
args:
- "--dockerfile="
- "--context=gs:///"
- "--destination="
volumeMounts:
- name: kaniko-secret
mountPath: /secret
env:
- name: GOOGLE\_APPLICATION\_CREDENTIALS
value: /secret/kaniko-secret.json
restartPolicy: Never
volumes:
- name: kaniko-secret
secret:
secretName: kaniko-secret
```
이 예제는 GCS 버킷에서 빌드 컨텍스트를 가져옵니다. 로컬 디렉토리 빌드 컨텍스트를 사용하려면 configMap을 사용하여 작은 빌드 컨텍스트를 마운트하는 것을 고려할 수 있습니다.
#### gVisor에서 kaniko 실행하기
[gVisor](https://github.com/google/gvisor)에서 kaniko를 실행하면 추가적인 보안 경계가 제공됩니다. 현재 컨테이너가 gVisor에서 실행 중인지 여부를 확인할 수 있는 방법이 없으므로, gVisor에서 kaniko를 실행하려면 `--force` 플래그를 추가해야 합니다.
```shell
docker run --runtime=runsc -v $(pwd):/workspace -v ~/.config:/root/.config \
gcr.io/kaniko-project/executor:latest \
--dockerfile= --context=/workspace \
--destination=gcr.io/my-repo/my-image --force
```
gVisor를 사용하기 위해 `--runtime=runsc`를 전달합니다. 이 예제는 빌드 컨텍스트를 위해 현재 디렉토리를 `/workspace`에 마운트하고, GCR 자격 증명을 위해 `~/.config` 디렉토리를 마운트합니다.
#### Google Cloud Build에서 kaniko 실행하기
요구 사항:
- [빌드 컨텍스트](#kaniko-build-contexts)
GCB에서 kaniko를 실행하려면 빌드 구성에 빌드 단계로 추가하세요:
```yaml
steps:
- name: gcr.io/kaniko-project/executor:latest
args:
[
"--dockerfile=",
"--context=dir://",
"--destination=",
]
```
kaniko는 이 빌드 단계에서 최종 이미지를 빌드하고 푸시합니다.
#### Docker에서 kaniko 실행하기
요구 사항:
- [Docker](https://docs.docker.com/install/)
로컬 Docker 데몬에서 kaniko executor 이미지를 실행하여 Dockerfile로부터 이미지를 빌드하고 푸시할 수 있습니다.
예를 들어 gcloud와 GCR을 사용할 때 다음과 같이 kaniko를 실행할 수 있습니다:
```shell
docker run \
-v "$HOME"/.config/gcloud:/root/.config/gcloud \
-v /path/to/context:/workspace \
gcr.io/kaniko-project/executor:latest \
--dockerfile /workspace/Dockerfile \
--destination "gcr.io/$PROJECT\_ID/$IMAGE\_NAME:$TAG" \
--context dir:///workspace/
```
또한 다음과 같이 사용할 수 있는 유틸리티 스크립트 [`run\_in\_docker.sh`](./run\_in\_docker.sh)가 있습니다:
```shell
./run\_in\_docker.sh   
```
\_참고: `run\_in\_docker.sh`는 빌드 컨텍스트의 절대 경로를 기준으로 한 Dockerfile의 경로를 기대합니다.\_
컨테이너 디렉토리 `/workspace`의 Dockerfile, 로컬 디렉토리 `/home/user/kaniko-project`의 빌드 컨텍스트, 그리고 원격 이미지 대상인 Google Container Registry를 지정하여 실행하는 예제:
```shell
./run\_in\_docker.sh /workspace/Dockerfile /home/user/kaniko-project gcr.io/$PROJECT\_ID/$TAG
```
### 캐싱
#### 레이어 캐싱
kaniko는 원격 저장소에 `RUN` 명령어(`--cache-run-layers` 플래그로 설정)와 `COPY` 명령어(`--cache-copy-layers` 플래그로 설정)로 생성된 레이어를 캐시할 수 있습니다. 명령어를 실행하기 전에 kaniko는 캐시에서 레이어를 확인합니다. 캐시가 존재하면 kaniko는 명령어를 실행하는 대신 캐시된 레이어를 풀하고 추출합니다. 존재하지 않으면 kaniko는 명령어를 실행한 다음 새로 생성된 레이어를 캐시에 푸시합니다.
캐시 미스가 발생한 후에는 kaniko가 캐시에서 레이어를 읽을 수 없습니다. 캐시에서 레이어를 찾지 못한 경우, 이후의 모든 레이어는 캐시를 참조하지 않고 로컬에서 빌드됩니다.
사용자는 `--cache=true` 플래그를 설정하여 캐싱을 활성화할 수 있습니다. 캐시된 레이어를 저장하기 위한 원격 저장소는 `--cache-repo` 플래그를 통해 제공할 수 있습니다. 이 플래그가 제공되지 않으면, 캐시 저장소는 제공된 `--destination`으로부터 유추됩니다.
#### 베이스 이미지 캐싱
kaniko는 kaniko 포드에 볼륨 마운트할 수 있는 로컬 디렉토리에 이미지를 캐시할 수 있습니다. 이를 위해서는 캐시가 읽기 전용이므로 먼저 캐시를 채워야 합니다. 당사는 `gcr.io/kaniko-project/warmer`에서 kaniko 캐시 워머(warmer) 이미지를 제공합니다:
```shell
docker run -v $(pwd):/workspace gcr.io/kaniko-project/warmer:latest --cache-dir=/workspace/cache --image= --image=
docker run -v $(pwd):/workspace gcr.io/kaniko-project/warmer:latest --cache-dir=/workspace/cache --dockerfile=
docker run -v $(pwd):/workspace gcr.io/kaniko-project/warmer:latest --cache-dir=/workspace/cache --dockerfile= --build-arg version=1.19
```
`--image`는 원하는 이미지 수만큼 지정할 수 있습니다. `--dockerfile`은 캐시할 Dockerfile의 경로로 지정할 수 있습니다. 이 명령어들은 결합되어 `cache`라는 이름의 로컬 디렉토리에 다이제스트별로 해당 이미지들을 캐시합니다. 캐시가 채워지면 위와 동일한 `--cache=true` 플래그로 캐싱을 활성화할 수 있습니다. 로컬 캐시의 위치는 `--cache-dir` 플래그를 통해 제공되며, 캐시 워머와 마찬가지로 기본값은 `/cache`입니다. 쿠버네티스 클러스터 및 영구 캐시 볼륨과 함께 사용하는 방법은 `examples` 디렉토리를 참고하세요.
### 다양한 레지스트리로 푸시하기
kaniko는 레지스트리에 이미지를 푸시하기 위해 Docker 자격 증명 헬퍼를 사용합니다.
kaniko는 GCR, Docker `config.json`, Amazon ECR을 기본 지원하지만, 다른 자격 증명 헬퍼를 구성하면 다른 레지스트리로 푸시할 수 있습니다.
#### Docker Hub로 푸시하기
Docker 레지스트리 사용자 이름과 비밀번호를 base64로 인코딩합니다.
echo -n USER:PASSWORD | base64
Docker 레지스트리 URL과 이전에 생성한 base64 문자열을 포함하는 `config.json` 파일을 생성합니다.
\*\*참고:\*\* v1 엔드포인트를 사용하세요. 자세한 내용은 #1209를 참고하세요.
```json
{
"auths": {
"https://index.docker.io/v1/": {
"auth": "xxxxxxxxxxxxxxx"
}
}
}
```
`/kaniko/.docker/config.json` 위치에 `config.json`을 두고 kaniko를 실행합니다.
```shell
docker run -ti --rm -v `pwd`:/workspace -v `pwd`/config.json:/kaniko/.docker/config.json:ro gcr.io/kaniko-project/executor:latest --dockerfile=Dockerfile --destination=yourimagename
```
#### Google GCR로 푸시하기
Google Cloud Registry에 인증하기 위한 자격 증명을 생성하려면 다음 단계를 따르세요:
1. 최종 이미지를 푸시할 Google Cloud Console 프로젝트에서 `Storage Admin` 권한을 가진 [서비스 계정](https://console.cloud.google.com/iam-admin/serviceaccounts)을 생성합니다.
2. 이 서비스 계정의 JSON 키를 다운로드합니다.
3. (선택 사항) 키 이름을 `kaniko-secret.json`으로 변경합니다. 변경하지 않는 경우 명령어에서 사용되는 이름(볼륨 부분)을 변경해야 합니다.
4. GOOGLE\_APPLICATION\_CREDENTIALS 환경 변수에 경로를 추가하여 컨테이너를 실행합니다.
```shell
docker run -ti --rm -e GOOGLE\_APPLICATION\_CREDENTIALS=/kaniko/config.json \
-v `pwd`:/workspace -v `pwd`/kaniko-secret.json:/kaniko/config.json:ro gcr.io/kaniko-project/executor:latest \
--dockerfile=Dockerfile --destination=yourimagename
```
#### Workload Identity를 사용하여 GCR로 푸시하기
GKE 클러스터에서 Workload Identity를 활성화한 경우, kaniko 포드 사양에 `GOOGLE\_APPLICATION\_CREDENTIALS`를 추가하지 않고도 workload identity를 사용하여 빌드된 이미지를 GCR로 푸시할 수 있습니다.
workload identity [활성화하기](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#enable\_on\_cluster) 및 [기존 앱 마이그레이션하기](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#migrate\_applications\_to)에 대해 자세히 알아보세요.
workload identity를 사용하여 인증하려면 Google Container Registry에 이미지를 푸시할 수 있는 `Storage.Admin` 권한이 있는 Google Service Account(GSA)에 바인딩된 Kubernetes Service Account(KSA)를 사용하여 kaniko 포드를 실행해야 합니다.
Kubernetes 서비스 계정, Google 서비스 계정을 생성하고 둘 사이에 IAM 정책 바인딩을 생성하여 Kubernetes 서비스 계정이 Google 서비스 계정 역할을 할 수 있도록 허용하는 자세한 단계는 [여기](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#authenticating\_to)를 따르세요.
Google 서비스 계정에 GCR로 푸시할 수 있는 올바른 권한을 부여하려면 다음 GCR 명령어를 실행하세요:
```
gcloud projects add-iam-policy-binding $PROJECT \
--member=serviceAccount:[gsa-name]@${PROJECT}.iam.gserviceaccount.com \
--role=roles/storage.objectAdmin
```
kaniko 포드가 네임스페이스 내에서 쿠버네티스 서비스 계정과 함께 실행되고 있는지 확인하세요.
#### Amazon ECR로 푸시하기
Amazon ECR [자격 증명 헬퍼](https://github.com/awslabs/amazon-ecr-credential-helper)가 kaniko executor 이미지에 내장되어 있습니다.
1. 자격 증명 구성
1. [인스턴스 역할 권한을 구성하여](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ECR\_on\_EKS.html) EC2 인스턴스 또는 EKS에서 ECR로 푸시할 때인스턴스 역할을 사용할 수 있습니다(AWS 관리 정책 `EC2InstanceProfileForImageBuilderECRContainerBuilds`는 ECR 이미지 업로드를 위한 광범위한 권한을 제공하며 구성 기준로 사용할 수 있습니다). 추가로, kaniko 포드 내에서 환경 변수로 `AWS\_SDK\_LOAD\_CONFIG=true`를 설정합니다. 인스턴스 프로파일이 있는 EC2 인스턴스에서 실행 중인 경우, kaniko가 올바른 자격 증명을 가져오도록 `AWS\_EC2\_METADATA\_DISABLED=true`를 설정해야 할 수도 있습니다.
2. 또는 클러스터 내에서 자격 증명에 접근할 수 있도록 `~/.aws/credentials` 파일에 대한 쿠버네티스 시크릿을 생성할 수 있습니다. 시크릿을 생성하려면 다음을 실행합니다:
`shell kubectl create secret generic aws-secret --from-file= `
쿠버네티스 Pod 사양은 args 매개변수가 채워진 상태로 다음과 유사해야 합니다. 시크릿의 AWS 자격 증명을 사용할 때만 `aws-secret` 볼륨 마운트와 볼륨이 필요하며, 인스턴스 역할을 사용할 때는 필요하지 않습니다.
```yaml
apiVersion: v1
kind: Pod
metadata:
name: kaniko
spec:
containers:
- name: kaniko
image: gcr.io/kaniko-project/executor:latest
args:
- "--dockerfile="
- "--context=s3:///"
- "--destination="
volumeMounts:
# 인스턴스 역할을 사용하지 않는 경우
- name: aws-secret
mountPath: /root/.aws/
restartPolicy: Never
volumes:
# 인스턴스 역할을 사용하지 않는 경우
- name: aws-secret
secret:
secretName: aws-secret
```
#### Azure Container Registry로 푸시하기
ACR [자격 증명 헬퍼](https://github.com/chrismellard/docker-credential-acr-env)가 kaniko executor 이미지에 내장되어 있으며, 이를 사용하여 잘 알려진 Azure 환경 정보로 인증할 수 있습니다.
자격 증명을 구성하려면 다음을 수행해야 합니다:
1. `config.json`의 `credStore` 섹션을 업데이트합니다:
```json
{ "credsStore": "acr" }
```
이 접근 방식의 단점은 모든 레지스트리에 대해 ACR 인증이 사용된다는 점이며, DockerHub, GCR 등에서도 풀(pull)하는 경우 실패하게 됩니다. 따라서 `credsStore` 대신 `credHelpers`를 사용하여 ACR 레지스트리에 대해서만 자격 증명 도구를 구성하는 것이 좋습니다:
```json
{ "credHelpers": { "mycr.azurecr.io": "acr-env" } }
```
새로운 설정을 configMap으로 마운트할 수 있습니다:
```shell
kubectl create configmap docker-config --from-file=
```
2. 자격 증명 구성
서비스 주체(Service Principal) 인증에 필요한 환경 변수가 포함된 쿠버네티스 시크릿을 생성하고 빌더 컨테이너에 노출할 수 있습니다.
```
AZURE\_CLIENT\_ID=
AZURE\_CLIENT\_SECRET=
AZURE\_TENANT\_ID=
```
위 항목들이 설정되지 않은 경우 인증은 관리 서비스 아이덴티티(MSI)로 대체되며 MSI 엔드포인트에 연락을 시도합니다. 이는 App Service 및 Azure Kubernetes Service와 같이 MSI 엔드포인트가 서비스가 실행 중인 MSI 컨텍스트를 인증하는 다양한 Azure 컨텍스트에서 작동합니다.
쿠버네티스 Pod 사양은 args 매개변수가 채워진 상태로 다음과 유사해야 합니다. Azure 서비스 주체 자격 증명을 사용할 때만 `azure-secret` 시크릿이 필요하며, 관리 서비스 아이덴티티를 사용할 때는 필요하지 않습니다.
```yaml
apiVersion: v1
kind: Pod
metadata:
name: kaniko
spec:
containers:
- name: kaniko
image: gcr.io/kaniko-project/executor:latest
args:
- "--dockerfile="
- "--context=s3:///"
- "--destination=mycr.azurecr.io/my-repository:my-tag"
envFrom:
# 서비스 주체로 인증하는 경우
- secretRef:
name: azure-secret
volumeMounts:
- name: docker-config
mountPath: /kaniko/.docker/
volumes:
- name: docker-config
configMap:
name: docker-config
restartPolicy: Never
```
#### JFrog Container Registry 또는 JFrog Artifactory로 푸시하기
Kaniko는 [JFrog Container Registry](https://www.jfrog.com/confluence/display/JFROG/JFrog+Container+Registry) 및 JFrog Artifactory 모두와 함께 사용할 수 있습니다.
JFrog Artifactory 레지스트리 사용자 이름과 비밀번호를 base64로 인코딩합니다.
echo -n USER:PASSWORD | base64
Artifactory Docker 로컬 레지스트리 URL과 이전에 생성한 base64 문자열을 포함하는 `config.json` 파일을 생성합니다.
```json
{
"auths": {
"artprod.company.com": {
"auth": "xxxxxxxxxxxxxxx"
}
}
}
```
예를 들어 Artifactory 클라우드 사용자의 경우 Docker 레지스트리는 다음과 같아야 합니다:
`..io`.
`/kaniko/.docker/config.json` 위치에 `config.json`을 두고 kaniko를 실행합니다.
docker run -ti --rm -v `pwd`:/workspace -v `pwd`/config.json:/kaniko/.docker/config.json:ro gcr.io/kaniko-project/executor:latest --dockerfile=Dockerfile --destination=yourimagename
이미지가 업로드된 후, JFrog CLI를 사용하여 빌드 정보를 Artifactory에 [수집](https://www.jfrog.com/confluence/display/CLI/CLI+for+JFrog+Artifactory#CLIforJFrogArtifactory-PushingDockerImagesUsingKaniko) 및 [게시](https://www.jfrog.com/confluence/display/CLI/CLI+for+JFrog+Artifactory#CLIforJFrogArtifactory-PublishingBuild-Info)하고, JFrog Xray를 사용하여 [빌드 취약점 스캔](https://www.jfrog.com/confluence/display/JFROG/Declarative+Pipeline+Syntax#DeclarativePipelineSyntax-ScanningBuildswithJFrogXray)을 트리거할 수 있습니다.
Jenkins Artifactory 플러그인을 사용하여 이미지의 빌드 정보를 수집하고 게시하려면 [스크립트형 파이프라인(scripted pipeline)](https://www.jfrog.com/confluence/display/JFROG/Scripted+Pipeline+Syntax#ScriptedPipelineSyntax-UsingKaniko) 및 [선언형 파이프라인(declarative pipeline)](https://www.jfrog.com/confluence/display/JFROG/Declarative+Pipeline+Syntax#DeclarativePipelineSyntax-ScanningBuildswithJFrogXray) 지침을 참고하세요.
### 추가 플래그
#### `--build-arg` 플래그
이 플래그를 사용하면 Docker와 유사하게 빌드 시점에 ARG 값을 전달할 수 있습니다. 여러 인자에 대해 여러 번 설정할 수 있습니다.
공백이 포함된 값을 전달하는 것은 기본적으로 지원되지 않습니다. executor 명령어를 호출하기 전에 IFS가 빈 값으로 설정되도록 해야 합니다. executor를 호출하기 전에 `export IFS=''`를 추가하여 설정할 수 있습니다. 다음 예제를 참고하세요:
```bash
export IFS=''
/kaniko/executor --build-arg "MY\_VAR='value with spaces'" ...
```
#### `--cache` 플래그
kaniko와 함께 캐싱을 활성화하려면 이 플래그를 `--cache=true`로 설정하세요.
#### `--cache-dir` 플래그
베이스 이미지를 위한 로컬 디렉토리 캐시를 지정하려면 이 플래그를 설정하세요. 기본값은 `/cache`입니다.
\_이 플래그는 `--cache=true` 플래그와 함께 사용해야 합니다.\_
#### `--cache-repo` 플래그
캐시된 레이어를 저장하는 데 사용할 원격 저장소를 지정하려면 이 플래그를 설정하세요.
이 플래그가 제공되지 않으면 `--destination` 플래그에서 캐시 저장소가 유추됩니다. `--destination=gcr.io/kaniko-project/test`인 경우 캐시된 레이어는 `gcr.io/kaniko-project/test/cache`에 저장됩니다.
\_이 플래그는 `--cache=true` 플래그와 함께 사용해야 합니다.\_
#### `--cache-copy-layers` 플래그
복사 레이어(copy layer)를 캐시하려면 이 플래그를 설정하세요.
#### `--cache-run-layers` 플래그
실행 레이어(run layer)를 캐시하려면 이 플래그를 설정하세요 (기본값=true).
#### `--cache-ttl duration` 플래그
캐시 시간 제한(시간 단위). 기본값은 2주입니다.
#### `--cleanup` 플래그
빌드가 끝날 때 파일 시스템을 정리하려면 이 플래그를 설정하세요.
#### `--compressed-caching` 플래그
캐시된 레이어에 대한 tar 압축을 방지하려면 이를 false로 설정하세요. 이렇게 하면 빌드 런타임은 증가하지만, 특히 대규모 빌드에서 메모리 사용량이 감소합니다. 메모리 부족(out of memory) 오류로 빌드가 실패하는 경우 `--compressed-caching=false`를 사용해 보세요. 기본값은 true입니다.
#### `--context-sub-path` 플래그
주어진 `--context` 내에서 하위 경로를 설정합니다.
예를 들어 컨텍스트가 git 저장소이고 루트 폴더 대신 하위 폴더 중 하나를 빌드하려는 경우 특히 유용합니다.
#### `--custom-platform` 플래그
docker build --platform xxx와 유사하게 호스트가 아닌 다른 기본 플랫폼으로 빌드할 수 있습니다. 값은 `--custom-platform=linux/arm` 형식이어야 하며, 허용되는 값은 [GOOS/GOARCH](https://gist.github.com/asukakenji/f15ba7e588ac42795f421b48b8aede63)에 나열되어 있습니다.
세 번째 매개변수로 추가하여 CPU 변형을 지정할 수도 있습니다(예: `--custom-platform=linux/arm/v5`). 현재 CPU 변형은 [GOARM](https://go.dev/wiki/GoArm#supported-architectures)에 나열된 대로 ARM 아키텍처에만 사용되는 것으로 알려져 있습니다.
\_OCI 이미지 사양의 제한으로 인해 결과 이미지는 CPU 변형에 대한 메타데이터를 제공할 수 없습니다.\_
\_이것은 가상화가 아니며 빌드 호스트에서 기본적으로 지원하지 않는 아키텍처를 빌드하는 데 도움이 될 수 없습니다. 예를 들어 amd64 호스트에서 i386을 빌드하거나 arm64 호스트에서 arm32를 빌드하는 데 사용됩니다.\_
#### `--digest-file` 플래그
컨테이너 내의 파일을 지정하려면 이 플래그를 설정하세요. 이 파일에는 빌드된 이미지의 다이제스트가 기록됩니다. 이를 사용하여 kaniko가 빌드한 정확한 이미지를 자동으로 추적할 수 있습니다.
예를 들어 플래그를 `--digest-file=/dev/termination-log`로 설정하면 해당 파일에 다이제스트가 기록되며, 이는 쿠버네티스에 의해 컨테이너의 `{{.state.terminated.message}}`로 자동 수집됩니다.
#### `--dockerfile` 플래그
빌드할 Dockerfile의 경로입니다. (기본값 "Dockerfile")
#### `--force` 플래그
컨테이너 외부에서 빌드를 강제합니다.
#### `--git` 플래그
빌드 컨텍스트가 git 저장소인 경우 클론할 브랜치 (기본값 branch=,single-branch=false,recurse-submodules=false,insecure-skip-tls=false)
#### `--image-name-with-digest-file` 플래그
빌드된 이미지의 다이제스트가 포함된 이미지 이름을 저장할 파일을 지정합니다.
#### `--image-name-tag-with-digest-file` 플래그
빌드된 이미지의 이미지 태그 및 다이제스트가 포함된 이미지 이름을 저장할 파일을 지정합니다.
#### `--insecure` 플래그
일반 HTTP 레지스트리로 이미지를 푸시하려는 경우 이 플래그를 설정하세요. 테스트 목적 전용이며 프로덕션 환경에서는 사용하면 안 됩니다!
#### `--insecure-pull` 플래그
일반 HTTP 레지스트리에서 이미지를 풀(pull)하려는 경우 이 플래그를 설정하세요. 테스트 목적 전용이며 프로덕션 환경에서는 사용하면 안 됩니다!
#### `--insecure-registry` 플래그
지정된 레지스트리에 접근할 때 일반 HTTP 요청을 사용하려면 `--insecure-registry `를 설정할 수 있습니다. 테스트 목적 전용이며 프로덕션 환경에서는 사용하면 안 됩니다! 여러 레지스트리에 대해 여러 번 설정할 수 있습니다.
#### `--label` 플래그
최종 이미지에 일부 메타데이터를 설정하려면 이 플래그를 `--label key=value`로 설정하세요. 이는 Dockerfile 내에서 `LABEL`을 사용하는 것과 동일합니다.
#### `--log-format` 플래그
로그 형식을 설정하려면 이 플래그를 `--log-format=`으로 설정하세요. 기본값은 `color`입니다.
#### `--log-timestamp` 플래그
`` 로그 형식에 타임스탬프를 추가하려면 이 플래그를 `--log-timestamp=`로 설정하세요. 기본값은 `false`입니다.
#### `--no-push` 플래그
레지스트리에 푸시하지 않고 이미지만 빌드하려는 경우 이 플래그를 설정하세요. 이는 `KANIKO\_NO\_PUSH` 환경 변수를 통해서도 정의할 수 있습니다.
참고: 이 경우에도 캐시 레이어는 레지스트리에 푸시됩니다. 캐시 레이어 푸시를 비활성화하려면 `--no-push-cache`를 사용하세요.
#### `--no-push-cache` 플래그
캐시 레이어를 레지스트리에 푸시하지 않으려면 이 플래그를 설정하세요. 레지스트리로 어떠한 레이어도 푸시하지 않기 위해 `--no-push`와 함께 사용할 수 있습니다.
#### `--oci-layout-path` 플래그
빌드된 이미지의 OCI 이미지 레이아웃이 배치될 컨테이너 내의 디렉토리를 지정하려면 이 플래그를 설정하세요. 이를 사용하여 kaniko가 빌드한 정확한 이미지를 자동으로 추적할 수 있습니다.
예를 들어 [Tekton 태스크](https://github.com/tektoncd/pipeline/blob/v0.6.0/docs/resources.md#surfacing-the-image-digest-built-in-a-task)에서 빌드된 이미지 다이제스트를 노출하려면, 이 플래그를 이미지 리소스 `outputImageDir`과 일치하도록 설정해야 합니다.
\_참고: 빌드된 이미지에 따라 이미지 매니페스트의 미디어 타입은 `application/vnd.oci.image.manifest.v1+json` 또는 `application/vnd.docker.distribution.manifest.v2+json`일 수 있습니다.\_
#### `--push-ignore-immutable-tag-errors` 플래그
태그 불변성(immutability)과 관련된 푸시 오류가 발생했을 때 Kaniko 프로세스가 성공으로 종료되도록 하려면 이 불리언 플래그를 `true`로 설정하세요.
예를 들어 동일한 태그를 푸시하는 병렬 빌드가 있고 어떤 빌드가 실제로 성공하는지 상관하지 않는 경우에 유용합니다.
기본값은 `false`입니다.
#### `--push-retry` 플래그
원격 대상으로 이미지 푸시가 실패할 경우 재시도할 횟수를 이 플래그에 설정하세요. 기본값은 `0`입니다.
#### `--registry-certificate` 플래그
특정 레지스트리와의 TLS 통신을 위한 인증서를 제공하려면 이 플래그를 설정하세요.
예상되는 형식은 `my.registry.url=/path/to/the/certificate.cert`입니다.
#### `--registry-client-cert` 플래그
인증을 위해 [mTLS가 필요한 레지스트리](https://docs.docker.com/engine/security/certificates/)와의 상호 TLS(mTLS) 통신을 위한 인증서/키 쌍을 제공하려면 이 플래그를 설정하세요.
예상되는 형식은 `my.registry.url=/path/to/client/cert.crt,/path/to/client/key.key`입니다.
#### `--registry-map` 플래그
레지스트리 참조를 다시 매핑하려는 경우 이 플래그를 설정하세요. 예를 들어 에어갭(air gap) 환경에서 유용합니다. 주어진 레지스트리에 대해 여러 미러를 설정하려는 경우 이 플래그를 두 번 이상 사용할 수 있습니다. 세미콜론으로 구분하여 단일 플래그에서 여러 리맵을 언급할 수도 있습니다. 첫 번째 미러에서 이미지를 찾을 수 없는 경우 Kaniko는 다음 미러를 시도하고, 마지막에는 원래 레지스트리로 대체(fallback)합니다.
레지스트리 맵은 `KANIKO\_REGISTRY\_MAP` 환경 변수를 통해서도 정의할 수 있습니다.
예상되는 형식은 `original-registry=remapped-registry[;another-reg=another-remap[;...]]`입니다.
이 플래그에 스키마가 포함된 URL을 \*\*지정할 수\*\* 있음에 유의하세요. 유효한 옵션은 다음과 같습니다:
- `index.docker.io=mirror.gcr.io`
- `gcr.io=127.0.0.1`
- `quay.io=192.168.0.1:5000`
- `index.docker.io=docker-io.mirrors.corp.net;index.docker.io=mirror.gcr.io;gcr.io=127.0.0.1`는 `index.docker.io`에 대해 `docker-io.mirrors.corp.net`을 시도한 다음 `mirror.gcr.io`를 시도하고, `gcr.io`에 대해서는 `127.0.0.1`을 시도합니다.
- `docker.io=harbor.provate.io/theproject`
#### `--registry-mirror` 플래그
기본값인 `index.docker.io` 대신 레지스트리 미러를 사용하려는 경우 이 플래그를 설정하세요. 여러 미러를 설정하려는 경우 이 플래그를 두 번 이상 사용할 수 있습니다. 첫 번째 미러에서 이미지를 찾을 수 없는 경우 Kaniko는 다음 미러를 시도하고, 마지막에는 기본 레지스트리로 대체합니다.
미러는 `KANIKO\_REGISTRY\_MIRROR` 환경 변수를 통해서도 정의할 수 있습니다.
예상되는 형식은 `mirror.gcr.io` 또는 `mirror.gcr.io/path`입니다.
이 플래그에 스키마가 포함된 URL을 \*\*지정할 수\*\* 있음에 유의하세요. 유효한 옵션은 다음과 같습니다:
- `mirror.gcr.io`
- `127.0.0.1`
- `192.168.0.1:5000`
- `mycompany-docker-virtual.jfrog.io`
- `harbor.provate.io/theproject`
#### `--skip-default-registry-fallback` 플래그
[registry-mirror](#flag---registry-mirror) 플래그에 나열된 미러 중 어느 것도 이미지를 풀(pull)할 수 없는 경우 빌드 프로세스를 실패하게 만들려면 이 플래그를 설정하세요.
이는 화이트리스트나 일부 이미지 제한을 구현하는 미러와 함께 사용해야 합니다.
[registry-mirror](#flag---registry-mirror)가 설정되지 않았거나 비어 있는 경우 이 플래그는 무시됩니다.
#### `--reproducible` 플래그
빌드된 이미지에서 타임스탬프를 제거하고 재현 가능(reproducible)하게 만들려면 이 플래그를 설정하세요.
#### `--single-snapshot` 플래그
이 플래그는 빌드 종료 시점에 파일 시스템의 단일 스냅샷을 찍으므로, 베이스 이미지에 단 하나의 레이어만 추가됩니다.
#### `--skip-push-permission-check` 플래그
푸시 권한 검사를 건너뛰려면 이 플래그를 설정하세요. 지연된 네트워크 정책(delayed network-policies)을 위해 Kaniko의 첫 번째 요청을 지연시키는 데 유용할 수 있습니다.
#### `--skip-tls-verify` 플래그
레지스트리로 푸시할 때 TLS 인증서 유효성 검사를 건너뛰려면 이 플래그를 설정하세요. 테스트 목적 전용이며 프로덕션 환경에서는 사용하면 안 됩니다!
#### `--skip-tls-verify-pull` 플래그
레지스트리에서 풀(pull)할 때 TLS 인증서 유효성 검사를 건너뛰려면 이 플래그를 설정하세요. 테스트 목적 전용이며 프로덕션 환경에서는 사용하면 안 됩니다!
#### `--skip-tls-verify-registry` 플래그
지정된 레지스트리에 접근할 때 TLS 인증서 유효성 검사를 건너뛰려면 `--skip-tls-verify-registry `를 설정할 수 있습니다. 테스트 목적 전용이며 프로덕션 환경에서는 사용하면 안 됩니다! 여러 레지스트리에 대해 여러 번 설정할 수 있습니다.
#### `--skip-unused-stages` 플래그
이 플래그가 `true`로 설정된 경우 사용된 스테이지인 경우에만 빌드합니다. 그렇지 않으면 기본적으로 대상 스테이지/Dockerfile의 끝에 도달할 때까지 불필요한 스테이지를 포함한 모든 스테이지를 빌드합니다.
#### `--snapshot-mode` 플래그
kaniko가 파일 시스템의 스냅샷을 찍는 방법을 설정하려면 `--snapshot-mode=` 플래그를 설정할 수 있습니다.
- `--snapshot-mode=full`이 설정된 경우, 스냅샷을 찍을 때 전체 파일 내용과 메타데이터가 고려됩니다. 성능은 가장 떨어지지만 가장 견고한 옵션입니다.
- `--snapshot-mode=redo`가 설정된 경우, 스냅샷을 찍을 때 파일 mtime, 크기, 모드, 소유자 uid 및 gid가 고려됩니다. 특히 프로젝트에 파일이 많은 경우 "full"보다 최대 50% 더 빠를 수 있습니다.
- `--snapshot-mode=time`이 설정된 경우, 스냅샷을 찍을 때 파일 mtime만 고려됩니다 ([mtime 관련 제한 사항](#mtime-and-snapshotting) 참고).
#### `--tar-path` 플래그
이미지를 해당 경로의 tarball로 저장하려면 이 플래그를 `--tar-path=`로 설정하세요. `--destination`도 함께 설정해야 합니다(예: `--destination=image`). 이미지를 tarball로만 저장하려면 `--no-push`도 설정해야 합니다.
#### `--target` 플래그
대상 빌드 스테이지가 무엇인지 나타내려면 이 플래그를 설정하세요.
#### `--use-new-run` 플래그
이 플래그를 사용하면 스냅샷에 전혀 의존하지 않는 Run 명령어의 실험적 구현이 활성화됩니다. 이 접근 방식에서는 어떤 파일이 변경되었는지 계산하기 위해 Run 명령어를 실행하기 전에 마커 파일이 생성됩니다. 그런 다음 전체 파일 시스템을 순회하여(700K 파일 기준 약 1~3초 소요) ModTime이 마커 파일보다 큰 모든 파일을 찾습니다. 이 새로운 run 명령어 구현을 통해 전체 빌드 시간이 단축되며 ~75% 범위의 성능 향상을 볼 수 있습니다. 이 새로운 run 모드는 전체 파일 시스템 스냅샷을 방지하여 성능을 향상시키는 대신 일부 경우에 정확성/올바름을 타협합니다("스냅샷"에서 파일을 놓칠 잠재적 가능성).
#### `--verbosity` 플래그
로깅 수준을 설정하려면 이 플래그를 `--verbosity=`로 설정하세요. 기본값은 `info`입니다.
#### `--ignore-var-run` 플래그
이미지 스냅샷을 찍을 때 /var/run을 무시합니다. 대상 이미지에서 /var/run/\\*를 보존하려면 false로 설정하세요. (기본값 true).
#### `--ignore-path` 플래그
이미지 스냅샷을 찍을 때 경로를 무시하려면 이 플래그를 `--ignore-path=`로 설정하세요. 무시할 경로가 여러 개인 경우 여러 번 설정할 수 있습니다.
#### `--image-fs-extract-retry` 플래그
이미지 파일 시스템을 추출하는 동안 재시도할 횟수를 이 플래그에 설정하세요. 기본값은 `0`입니다.
#### `--image-download-retry` 플래그
원격 이미지를 다운로드할 때 발생해야 하는 재시도 횟수를 이 플래그로 설정하세요. 연속적인 재시도는 지수 백오프(exponential backoff)와 1초의 초기 지연으로 발생합니다. 기본값은 0입니다.
### 디버그 이미지
kaniko executor 이미지는 scratch를 기반으로 하며 셸을 포함하지 않습니다. 진입할 수 있는 busybox 셸이 포함된 kaniko executor 이미지인 디버그 이미지 `gcr.io/kaniko-project/executor:debug`를 제공합니다.
셸 진입점으로 디버그 이미지를 실행할 수 있습니다:
```shell
docker run -it --entrypoint=/busybox/sh gcr.io/kaniko-project/executor:debug
```
## 보안
kaniko 자체만으로는 클러스터 내외부에서 신뢰할 수 없는 빌드를 실행하는 것을 \*\*안전하게 만들지 못합니다\*\*.
kaniko는 빌드 보안을 제공하기 위해 컨테이너 런타임의 보안 기능에 의존합니다.
컨테이너 내에서 kaniko에 필요한 최소 권한은 몇 가지 요소에 의해 결정됩니다:
- 베이스 이미지를 컨테이너 내에 압축 해제하는 데 필요한 권한
- 컨테이너 내에서 RUN 명령어를 실행하는 데 필요한 권한
압축 해제 권한이 필요 없는 최소한의 베이스 이미지(SCRATCH 등)가 있고, Dockerfile이 루트 사용자로 어떤 명령어도 실행하지 않는 경우 루트 권한 없이 kaniko를 실행할 수 있습니다. 기본적으로 Docker는 루트로 실행되므로 kaniko를 사용하려면 (어떤 의미에서는) 여전히 권한이 필요합니다.
클러스터에서 보안 정책을 생성하거나 업데이트하기 위해 [PodSecurityPolicy](https://cloud.google.com/kubernetes-engine/docs/how-to/pod-security-policies)의 어노테이션과 함께 [seccomp](https://kubernetes.io/docs/concepts/policy/pod-security-policy/#seccomp) 프로파일을 설정하여 Docker가 포드에서 사용하는 것과 동일한 기본 seccomp 프로파일을 달성할 수 있습니다.
## 서명된 Kaniko 이미지 검증하기
kaniko 이미지는 [cosign](https://github.com/sigstore/cosign)을 사용하여 버전 >= 1.5.2에 대해 서명됩니다!
공개 이미지를 검증하려면 [cosign](https://github.com/sigstore/cosign)을 설치하고 제공된 [공개 키](cosign.pub)를 사용하세요:
```
$ cat cosign.pub
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE9aAfAcgAxIFMTstJUv8l/AMqnSKw
P+vLu3NnnBDHCfREQpV/AJuiZ1UtgGpFpHlJLCNPmFkzQTnfyN5idzNl6Q==
-----END PUBLIC KEY-----
$ cosign verify -key ./cosign.pub gcr.io/kaniko-project/executor:latest
```
## Kaniko Builds - 프로파일링
빌드에 오랜 시간이 걸리는 경우, [Slow Jam](https://github.com/google/slowjam)을 사용하여 kaniko 함수 호출을 분석할 수 있는 지원이 최근 추가되었습니다. 프로파일링을 시작하려면:
1. [포드 정의](https://github.com/GoogleContainerTools/kaniko/blob/master/examples/pod-build-profile.yaml#L15)에 환경 변수 `STACKLOG\_PATH`를 추가합니다.
2. kaniko `debug` 이미지를 사용하는 경우, `pre-stop` 컨테이너 수명 주기 훅에서 파일을 복사할 수 있습니다.
## Kaniko와 Manifest-tool을 사용한 멀티 아키텍처 컨테이너 매니페스트 생성하기
Kaniko 자체가 현재 멀티 아키텍처 매니페스트 생성을 직접 지원하지는 않지만(기여 환영), [manifest-tool](https://github.com/estesp/manifest-tool) 같은 도구를 사용하여 여러 개의 개별 빌드를 단일 컨테이너 매니페스트로 병합할 수 있습니다.
### 일반적인 워크플로
멀티 아키텍처 매니페스트를 생성하기 위한 일반적인 워크플로는 다음과 같습니다:
1. 대상 아키텍처와 일치하는 빌드 호스트에서 Kaniko를 사용하여 개별 컨테이너 이미지를 빌드하고 적절한 ARCH 태그로 태깅합니다.
2. 개별 이미지를 컨테이너 레지스트리에 푸시합니다.
3. Manifest-tool이 주어진 템플릿에 따라 컨테이너 레지스트리의 개별 매니페스트를 식별합니다.
4. Manifest-tool이 개별 매니페스트를 참조하는 결합된 매니페스트를 푸시합니다.
![Workflow Multi-arch](https://raw.githubusercontent.com/GoogleContainerTools/kaniko/main/docs/images/multi-arch.drawio.svg)
### 제한 사항 및 주의점
다음 조건을 충족해야 합니다:
1. 원하는 아키텍처를 실행하는 빌드 머신에 대한 접근 권한이 필요합니다(에뮬레이터(예: QEMU)에서 Kaniko를 실행하는 것도 가능할 수 있으나 이 문서의 범위를 벗어납니다). 이는 github.com이나 gitlab.com과 같은 SaaS 빌드 도구를 사용할 때 명심해야 할 점입니다. 작성 시점 기준 두 플랫폼 모두 비 x86\_64 SaaS 러너를 지원하지 않으므로([GitHub](https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners#supported-runners-and-hardware-resources), [GitLab](https://docs.gitlab.com/ee/ci/runners/saas/linux\_saas\_runner.html#machine-types-available-for-private-projects-x86-64)), 직접 머신을 준비해야 합니다([GitHub](https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners), [GitLab](https://docs.gitlab.com/runner/register/)).
2. Kaniko가 원하는 아키텍처에서 실행할 수 있어야 합니다. 작성 시점 기준, 공식 Kaniko 컨테이너는 [linux/amd64, linux/arm64, linux/s390x, linux/ppc64le (*-debug 이미지 제외)](https://github.com/GoogleContainerTools/kaniko/blob/main/.github/workflows/images.yaml)를 지원합니다.
3. 선택한 컨테이너 레지스트리는 OCIv1 또는 Docker v2.2 호환이어야 합니다.
### 예제 CI 파이프라인 (GitLab)
자신에게 가장 적합한 자동화 도구를 찾는 것은 사용자의 몫입니다. GitHub workflows나 GitLab CI 같은 최신 CI/CD 시스템을 사용하는 것을 권장합니다. 작성자들 또한 GitLab CI를 사용하므로, 다음 예제들은 이 특정 플랫폼에 맞춰져 있습니다. 하지만 기본 원리는 다른 어디에도 적용될 수 있으며, 이 특정 플랫폼에 대한 사전 경험이 없더라도 따라올 수 있도록 예제들은 충분히 단순하게 유지되었습니다. 의문이 생기면 GitLab CI 키워드에 대한 종합적인 개요는 [gitlab-ci.yml reference page](https://docs.gitlab.com/ee/ci/yaml/index.html)를 방문하세요.
#### 개별 컨테이너 이미지 빌드하기
gitlab-ci.yml:
```yaml
# 컨테이너 빌드를 위한 작업 정의
build-container:
stage: container-build
# 원하는 아키텍처에 대한 병렬 빌드 실행
parallel:
matrix:
- ARCH: amd64
- ARCH: arm64
tags:
# 적합하고 미리 구성된 러너에서 각 빌드 실행 (대상 아키텍처와 일치해야 함)
- runner-${ARCH}
image:
name: gcr.io/kaniko-project/executor:debug
entrypoint: [""]
script:
# kaniko를 사용하여 현재 아키텍처용 컨테이너 이미지 빌드
- >-
/kaniko/executor --context "${CI\_PROJECT\_DIR}" --dockerfile
"${CI\_PROJECT\_DIR}/Dockerfile" # 이미지를 GitLab 컨테이너 레지스트리에 푸시하고 현재 아키텍처를 태그로 추가 --destination
"${CI\_REGISTRY\_IMAGE}:${ARCH}"
```
#### 컨테이너 매니페스트 병합하기
gitlab-ci.yml:
```yaml
# 병합된 매니페스트를 생성하고 푸시하기 위한 작업 정의
merge-manifests:
stage: container-build
# 병합하기 전에 모든 컨테이너가 빌드되어야 함
# 또는 나중 단계에서 실행되도록 작업이 구성될 수 있음
needs:
- job: container-build
artifacts: false
tags:
# manifest-tool 이미지가 지원하는 모든 아키텍처에서 실행 가능
- runner-xyz
image:
name: mplatform/manifest-tool:alpine
entrypoint: [""]
script:
- >-
manifest-tool # 컨테이너 레지스트리 인증
--username=${CI\_REGISTRY\_USER} --password=${CI\_REGISTRY\_PASSWORD} push
from-args # 병합할 아키텍처 정의 --platforms
linux/amd64,linux/arm64 # "ARCH"는 플랫폼 정의의 적절한 아키텍처로 # manifest-tool에 의해 자동으로 교체됨
--template ${CI\_REGISTRY\_IMAGE}:ARCH # 레지스트리로 푸시될 최종 결합된 이미지의 이름 --target ${CI\_REGISTRY\_IMAGE}
```
#### 버전 태그 추가에 관하여
이전 예제에서는 너무 많은 플랫폼 및 워크플로 특정 코드가 추가되는 것을 막기 위해 의도적으로 버전이 지정된 태그 이미지(모든 빌드가 "latest"로 태그됨)를 사용하지 않았습니다.
그럼에도 불구하고 GitLab에서 (동적) 버전 관리를 처리하는 방법에 관심이 있는 분들을 위해 간략한 개요를 설명합니다:
- 태그된 릴리스 빌드에만 관심이 있는 경우, 태그 파이프라인을 실행할 때 [GitLab 미리 정의된](https://docs.gitlab.com/ee/ci/variables/predefined\_variables.html) `CI\_COMMIT\_TAG` 변수를 간단히 사용할 수 있습니다.
- 우리처럼 릴리스 외에 추가로 컨테이너 이미지를 빌드하려는 경우 상황이 조금 더 복잡해집니다. 우리의 경우, 빌드 및 병합 작업 전에 실행되는 추가 작업을 추가하고(빌드 및 병합 작업의 `needs` 섹션을 적절히 확장하는 것을 잊지 마세요), 기본 브랜치에서 실행될 때는 태그를 `latest`로, 다른 브랜치에서 실행될 때는 커밋 해시로, 태그 파이프라인에서 실행될 때는 릴리스 태그로 설정하도록 했습니다.
gitlab-ci.yml:
```yaml
container-get-tag:
stage: pre-container-build-stage
tags:
- runner-xyz
image: busybox
script:
# 다른 모든 브랜치는 현재 빌드된 커밋 SHA 해시로 태그됨
- |
# 파이프라인이 기본 브랜치에서 실행되는 경우: 태그를 "latest"로 설정
if test "$CI\_COMMIT\_BRANCH" == "$CI\_DEFAULT\_BRANCH"; then
tag="latest"
# 파이프라인이 태그 파이프라인인 경우, 태그를 git 커밋 태그로 설정
elif test -n "$CI\_COMMIT\_TAG"; then
tag="$CI\_COMMIT\_TAG"
# 그 외에는 태그를 git 커밋 sha로 설정
else
tag="$CI\_COMMIT\_SHA"
fi
- echo "tag=$tag" > build.env
# 빌드 및 병합 작업으로 태그 전달.
# 참고: https://docs.gitlab.com/ee/ci/variables/#pass-an-environment-variable-to-another-job
artifacts:
reports:
dotenv: build.env
```
## 다른 도구들과의 비교
유사한 도구는 다음과 같습니다:
- [BuildKit](https://github.com/moby/buildkit)
- [img](https://github.com/genuinetools/img)
- [orca-build](https://github.com/cyphar/orca-build)
- [umoci](https://github.com/openSUSE/umoci)
- [buildah](https://github.com/containers/buildah)
- [FTL](https://github.com/GoogleCloudPlatform/runtimes-common/tree/master/ftl)
- [Bazel rules\_docker](https://github.com/bazelbuild/rules\_docker)
이 모든 도구는 서로 다른 접근 방식으로 컨테이너 이미지를 빌드합니다.
BuildKit(및 `img`)은 컨테이너 내에서 루트가 아닌 사용자로 수행할 수 있지만 중첩 컨테이너를 생성하려면 seccomp와 AppArmor를 비활성화해야 합니다.
`kaniko`는 실제로 중첩 컨테이너를 생성하지 않으므로 seccomp와 AppArmor를 비활성화할 필요가 없습니다. BuildKit은 QEMU를 활용하여 멀티 아키텍처 컨테이너의 "크로스 빌드(cross-building)"를 지원합니다.
`orca-build`는 Dockerfile에서 이미지를 빌드하기 위해 `runc`에 의존하며, 이는 컨테이너 내에서 실행될 수 없습니다(위의 `img`와 비슷한 이유로). `kaniko`는 `runc`를 사용하지 않으므로 커널 네임스페이싱 기술을 사용할 필요가 없습니다.
그러나 `orca-build`는 Docker나 권한 있는 데몬이 필요하지 않습니다(따라서 권한 없이 완전히 빌드 수행 가능).
`umoci`는 어떤 권한도 없이 작동하며 추출되는 루트 파일 시스템에 대한 제한도 없습니다(파일 시스템이 충분히 복잡한 경우 추가 처리가 필요하지만). 그러나 `Dockerfile`과 같은 빌드 도구가 없습니다(이러한 빌더(`orca-build` 등)를 빌드하는 데 사용할 수 있는 약간 더 낮은 수준의 도구입니다).
`Buildah`는 OCI 이미지 빌드를 전문으로 합니다. Buildah의 명령어는 Dockerfile에서 볼 수 있는 모든 명령어를 복제합니다. 이를 통해 루트 권한 없이도 Dockerfile 유무에 관계없이 이미지를 빌드할 수 있습니다. Buildah의 궁극적인 목표는 이미지를 빌드하기 위한 더 낮은 수준의 coreutils 인터페이스를 제공하는 것입니다. Dockerfile 없이 이미지를 빌드할 수 있는 유연성 덕분에 다른 스크립팅 언어를 빌드 프로세스에 통합할 수 있습니다. Buildah는 간단한 fork-exec 모델을 따르며 데몬으로 실행되지 않지만, 다른 도구에 내장(vendored)될 수 있는 golang의 포괄적인 API를 기반으로 합니다.
`FTL`과 `Bazel`은 이미지의 하위 세트에 대해 가능한 가장 빠른 Docker 이미지 생성을 달성하는 것을 목표로 합니다. 이는 kaniko가 제공하는 일반적인 Dockerfile 지원과 함께 사용할 수 있는 특수 케이스 "빠른 경로(fast path)"로 생각할 수 있습니다.
## 커뮤니티
[kaniko-users](https://groups.google.com/forum/#!forum/kaniko-users) Google 그룹
kaniko에 기여하려면 [DEVELOPMENT.md](DEVELOPMENT.md)와 [CONTRIBUTING.md](CONTRIBUTING.md)를 참고하세요.
## 제한 사항
### mtime과 스냅샷 생성
스냅샷을 찍을 때 kaniko의 해싱 알고리즘은 파일이 변경되었는지 여부를 결정하기 위해 파일의 [`mtime`](https://en.wikipedia.org/wiki/Inode#POSIX\_inode\_description)을 포함합니다([`--snapshot-mode=time`](#--snapshot-mode)의 경우 mtime만 사용). 안타깝게도 파일 변경이 발생한 시점과 `mtime`이 업데이트되는 시점 사이에는 지연이 존재합니다. 즉:
- 시간 전용 스냅샷 모드(`--snapshot-mode=time`)의 경우 kaniko가 `RUN` 명령어로 인한 변경 사항을 완전히 놓칠 수 있습니다.
- 기본 스냅샷 모드(`--snapshot-mode=full`)의 경우 `RUN` 명령어가 파일을 수정했지만 \*\*내용은 변경되지 않은\*\* 경우 kaniko가 레이어를 추가할지 여부는 이론적으로 비결정적입니다. 이는 \*\*내용에는 영향을 미치지 않으며\*\* 여전히 올바르게 유지되지만, 레이어 수에는 영향을 미칩니다.
\_참고로 이러한 문제는 현재 이론상으로만 존재합니다. 이 문제가 발생하는 경우 [이슈를 생성해 주세요](https://github.com/GoogleContainerTools/kaniko/issues)。\_
### Dockerfile 명령어 `--chown` 지원
Kaniko는 현재 `COPY --chown` 및 `ADD --chown` Dockerfile 명령어를 지원합니다. `RUN --chown`은 지원하지 않습니다.
## 참고 자료
- [Kaniko - Building Container Images In Kubernetes Without Docker](https://youtu.be/EgwVQN6GNJg)

kaniko

Explore Similar Repositories

Was this content helpful?

Recent Feedback

Download README