일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- CI/CD
- MLflow
- Argo
- nginx ingress
- 카오스 엔지니어링
- serving
- keda
- gitops
- Model Serving
- Kubernetes 인증
- operator
- Kubeflow
- Kopf
- eBPF
- xdp
- Litmus
- argocd
- kubernetes operator
- 오퍼레이터
- opensearch
- CANARY
- blue/green
- tekton
- Continuous Deployment
- opentelemetry
- Pulumi
- knative
- Kubernetes
- mlops
- seldon core
- Today
- Total
Kubernetes 이야기
Docker 없이 Docker Image 만들기 ( Kaniko ) 본문
Kaniko
Kaniko 는 Dockerfile을 이용하여 Container Image를 빌드하고 Registry에 Push하는 도구이다.
Kaniko는 Docker와 달리 Docker daemon 없이 빌드가 가능하다. 즉 Docker enging 설치를 하지 않아도 사용자가 만든 Dockerfile을 이용하여 이미지를 빌드할 수 있다.
제약사항은 아래와 같다.
Kaniko는 Windows 컨테이너 빌드를 지원하지 않는다.
Kaniko는 v1 Registry API를 지원하지 않는다.
Kaniko 는 컨테이너 내부에서 실행되는 gcr.io/kaniko-project/executor 실행 이미지를 사용하여 빌드한다.
Dockerfile 내부의 각 명령 을 순서대로 실행하고 각 명령 후에 파일 시스템의 스냅샷을 만든고,
파일 시스템에 변경 사항이 있는 경우 실행 프로그램은 파일 시스템 변경 사항의 스냅샷을 "diff" 계층으로 만들고 이미지 메타데이터를 업데이트한다.
Kaniko는 gcr.io/kaniko-project/executor 라는 Container 이미지로 실행하기 때문에 일반적인 linux 에 설치하는 형태가 아닌 Kubernetes Cluster에서 실행한다. ( Kubernetes도 Docker engine 없이 Containerd 또는 cri-o 같은 Container Runtime 을 사용한다. )
사용법
Kaniko 사용법을 테스트 하기 전에 kaniko executor container에서 사용하는 arguments 에 대해 먼저 알아보자.
- Dockerfile ( --dockerfile ) : dockerfile
- Context ( --context ) : 이미지를 빌드하는 데 사용하는 디렉토리를 참조하는 Docker 의 빌드 컨텍스트와 유사하다.
- Destination ( --destination ) : 이미지를 Push 하기 위한 Container Registry
Context는 아래와 같은 source를 사용할 수 있다.
Source | Prefix | Example |
Local Directory | dir://[path to a directory in the kaniko container] | dir:///workspace |
Local Tar Gz | tar://[path to a .tar.gz in the kaniko container] | tar://path/to/context.tar.gz |
Standard Input | tar://[stdin] | tar://stdin |
GCS Bucket | gs://[bucket name]/[path to .tar.gz] | gs://kaniko-bucket/path/to/context.tar.gz |
S3 Bucket | s3://[bucket name]/[path to .tar.gz] | s3://kaniko-bucket/path/to/context.tar.gz |
Azure Blob Storage | https://[account].[azureblobhostsuffix]/[container]/[path to .tar.gz] | https://myaccount.blob.core.windows.net/container/path/to/context.tar.gz |
Git Repository | git://[repository url][#reference][#commit-id] | git://github.com/acme/myproject.git#refs/heads/mybranch#<desired-commit-id> |
사용전에 먼저 ghcr.io container regitry에 push 하기 위한 계정 정보를 저장하자.
DOCKER_USERNAME=[...]
DOCKER_PASSWORD=[...]
DOCKER_SERVER=https://ghcr.io
kubectl create secret docker-registry regcred \
--docker-server=${DOCKER_SERVER} \
--docker-username=${DOCKER_USERNAME} \
--docker-password=${DOCKER_PASSWORD} -n test
또는 Secrect를 만들어 pod에 env로 연결한다.
apiVersion: v1
kind: Secret
metadata:
name: github
namespace: test
type: Opaque
stringData:
password: ""
username: ""
apiVersion: v1
kind: Pod
metadata:
name: kaniko
namespace: test
spec:
containers:
- name: kaniko
image: gcr.io/kaniko-project/executor:debug
args:
- "--dockerfile=Dockerfile"
- "--context=git://github.com/kmaster8/kubernertes.git"
- "--context-sub-path=./simple-flask"
- "--destination=ghcr.io/kmaster:hello"
volumeMounts: # volumeMount or env 선택
- name: kaniko-secret
mountPath: /kaniko/.docker/
env: # volumeMount or env 선택
- name: GIT_PASSWORD
valueFrom:
secretKeyRef:
name: github
key: password
- name: GIT_USERNAME
valueFrom:
secretKeyRef:
name: github
key: username
restartPolicy: Never
volumes: # env 선택 시 불필요
- name: kaniko-secret
secret:
secretName: regcred
items:
- key: .dockerconfigjson
path: config.json
이제 kaniko pod를 실행해 보자.
# kubectl create -f pod.yaml -n test
pod/kaniko created
# kubectl logs -f -n test kaniko
DEBU[0000] Getting source context from git://github.com/kmaster8/kubernertes.git
DEBU[0000] Getting source from reference
Enumerating objects: 24, done.
Counting objects: 100% (24/24), done.
Compressing objects: 100% (14/14), done.
Total 24 (delta 8), reused 24 (delta 8), pack-reused 0
DEBU[0000] Build context located at /kaniko/buildcontext/simple-flask
DEBU[0000] Copying file /kaniko/buildcontext/simple-flask/Dockerfile to /kaniko/Dockerfile
TRAC[0000] Adding /var/run to initialIgnoreList
E0227 09:12:39.482214 1 aws_credentials.go:77] while getting AWS credentials NoCredentialProviders: no valid providers in chain. Deprecated.
For verbose messaging see aws.Config.CredentialsChainVerboseErrors
DEBU[0007] Skip resolving path /kaniko/Dockerfile
DEBU[0007] Skip resolving path /kaniko/buildcontext/simple-flask
DEBU[0007] Skip resolving path /cache
DEBU[0007] Skip resolving path
DEBU[0007] Skip resolving path
DEBU[0007] Skip resolving path
DEBU[0007] Skip resolving path
DEBU[0007] Built stage name to index map: map[]
INFO[0007] Retrieving image manifest python:3.8-slim
INFO[0007] Retrieving image python:3.8-slim from registry index.docker.io
INFO[0012] Built cross stage deps: map[]
INFO[0012] Retrieving image manifest python:3.8-slim
...
INFO[0022] Adding exposed port: 5000/tcp
INFO[0022] CMD ["python3", "-m", "flask", "run", "--host=0.0.0.0"]
DEBU[0022] mapping stage idx 0 to digest sha256:9aa86e6a97b149e5e55b7dfb93b6cc7a7cf09fb56785aeed293ad73fcb5b94eb
DEBU[0022] mapping digest sha256:9aa86e6a97b149e5e55b7dfb93b6cc7a7cf09fb56785aeed293ad73fcb5b94eb to cachekey
INFO[0022] Pushing image to ghcr.io/kmaster8/hello
Registry 서버에서 보면
정상적으로 push 된 것을 볼 수 있다.
'Kubernetes > devops' 카테고리의 다른 글
Argo workflow 를 활용하여 CI/CD 구축하기 (SonarQube) (2) | 2022.03.03 |
---|---|
Argo rollout을 통한 Blue/Green CD (Continuous Deployment) 구축하기 (2) - Blue/Green 배포 (0) | 2022.02.27 |
Argo rollout을 통한 CD (Continuous Deployment) 구축하기 (1) - Canary 배포 (0) | 2022.02.25 |
Flagger를 사용한 CD ( Continuous Deployment ) 구축하기 (0) | 2022.02.23 |
Kubernetes의 다양한 배포방식 (3) Canary 배포 (0) | 2022.02.20 |