내 k8s 클러스터를 위한 CD 솔루션을 찾고 있습니다. 이제 태그가 포함된 커밋을 푸시한 후 dev-*
dockerhub는 태그가 지정된 새 이미지를 생성합니다 dev-latest
. 내 배포 구성은 다음과 같습니다.
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-image-backend-local-deployment
labels:
app: my-image
type: web
spec:
replicas: 2
minReadySeconds: 15
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 25%
maxSurge: 1
selector:
matchLabels:
app: my-image
template:
metadata:
labels:
app: my-image
spec:
imagePullSecrets:
- name: regcred
containers:
- name: backend
image: cosmicfruit/my-image:dev-latest
imagePullPolicy: IfNotPresent
envFrom:
- secretRef:
name: my-image-backend-local-secret
ports:
- containerPort: 8000
readinessProbe:
httpGet:
path: /flvby
port: 8000
initialDelaySeconds: 10
periodSeconds: 5
- name: celery
image: cosmicfruit/my-image:dev-latest
imagePullPolicy: IfNotPresent
workingDir: /code
command: ["/code/run/celery.sh"]
envFrom:
- secretRef:
name: my-image-backend-local-secret
- name: redis
image: redis:latest
imagePullPolicy: IfNotPresent
새 이미지가 포드에 자동으로 배포되기를 원하는데 관련 솔루션을 찾을 수 없습니다.
UPDdev-0.1.*
(*는 숫자) 태그가 있는 새 이미지가 레지스트리에 푸시된 후 내 이미지가 자동으로 배포되기를 원합니다 . 코드를 푸시하고 이미지에 내장한 후에는 아무것도 하고 싶지 않습니다. 나는 CD Foundation의 몇 가지 프로젝트인 Jenkins X, Spinnaker 및 Tekton을 발견했으며 그 중 일부는 내 아이디어를 구현하는 데 도움이 될 수 있지만 동물원에 애완동물이 한 마리도 더 없어도 구현하면 좋을 것 같습니다.
답변1
이미지 참조 및 매니페스트
kind: Deployment
Kubernetes는 매니페스트가 변경될 때마다 롤링 배포 전략을 사용하는 등 배포를 관리합니다 .
이제 dev-* 태그를 사용하여 커밋을 푸시한 후 dockerhub는 dev-latest 태그가 지정된 새 이미지를 생성합니다.
이것의 주요 문제점은 다음을 사용한다는 것입니다.같은모든 이미지의 태그 이름. 이는 귀하의 kind: Deployment
매니페스트가~ 아니다이미지가 업데이트될 때 업데이트되므로 매니페스트에 변경 사항이 없으므로 Kubernetes는 새로운 롤링 배포를 시작하지 않습니다.
좋은 방법은 이미지를 푸시할 때마다 고유한 이미지 태그를 사용한 다음 kind: Deployment
이 새 이미지 태그 이름으로 매니페스트를 업데이트하여 Kubernetes가 자동으로 새 롤링 배포를 트리거하도록 하는 것입니다.
일부 이미지 레지스트리는 "불변 태그 이름"을 사용하도록 구성할 수 있습니다.시행빌드된 모든 이미지에 대해 항상 고유한 태그 이름을 사용합니다. 또는 다음을 사용할 수 있습니다.전체 이미지 다이제스트kind: Deployment
태그 이름이 동일하더라도 고유한 이미지 참조를 가질 수 있도록 매니페스트 에 포함 됩니다(이미지 다이제스트는 콘텐츠의 해시입니다).
요약하자면:
- 모든 빌드에 고유한 이미지 태그 이름을 사용하세요.
kind: Deployment
새 태그 이름으로 매니페스트를 업데이트합니다.kind: Deployment
Git과 같은 버전 제어에서 매니페스트(및 기타 yaml 매니페스트)를 유지합니다 .- 이미지를 참조할 때 매니페스트에서 전체 이미지 다이제스트를 사용하는 것을 고려하세요.
프로세스 및 자동화
매니페스트를 업데이트하고 이를 클러스터에 적용하는 것은 여러 가지 방법으로 수행할 수 있지만 모든 변경 후 업데이트된 매니페스트를 클러스터에 적용하기 전에 항상 Git 리포지토리에 저장하는 것이 좋습니다. 이런 방식으로 변경된 사항에 대해 좋은 추적성을 얻을 수 있으며 문제가 발생한 경우 작업 버전으로 돌아가는 것이 더 쉽습니다.
위에서 설명한 대로 필요한 단계를 사용하는 또 다른 중요한 방법은 다음과 같습니다.오토메이션이를 위해. Git 리포지토리를 변경할 때마다 수동 단계 없이 자동화된 프로세스를 실행하여 작업을 수행하는 것이 좋습니다. 역사적으로 Jenkins는 이를 위한 인기 있는 도구였지만, 오래되었고 컨테이너 환경에서 잘 실행되도록 설계되지 않았습니다. 이제 다음과 같은 도구를 사용하는 것이 좋습니다.GitHub 작업,구글 클라우드 빌드또는 Kubernetes 클러스터 내의 최신 시스템텍톤 파이프라인
Tekton을 사용하여 파이프라인 구축 및 배포
Kubernetes 클러스터에서 Tekton을 사용하기로 선택한 경우 다음과 같이 프로젝트를 구성할 수 있습니다.
- 코드 저장소에 코드 변경 내용을 Git으로 푸시
- ㅏ텍톤 트리거Git 시스템에서 이벤트를 수신하고 새로운
PipelineRun
. - 그만큼텍톤 파이프라인git-clone, 코드 빌드, 테스트 실행, 이미지 빌드 및 푸시에 대한 단계가 포함되어 있습니다. 결과는 이미지 다이제스트 또는 레이블입니다. 그런 다음 이전 작업이 모두 성공하면
kind: Deployment
매니페스트를 새로운 이미지 다이제스트로 업데이트하고 매니페스트가 있는 저장소에 git-push를 업데이트하는 파이프라인의 마지막 작업이 있습니다 . - 매니페스트를 클러스터에 적용하는 배포 파이프라인이 트리거됩니다(선택한 배포 전략, 롤링 배포 또는 점진적 배포 또는 카나리아 배포 사용).
도서 추천
Kubernetes 가동 및 실행2판(2019년부터) - 새로운 장이 포함되어 있습니다.18. 애플리케이션 구성매니페스트 및 버전 제어를 사용하여 배포를 관리하는 방법을 설명합니다.
지속적인 전달- 사용 방법에 대한 고전적인 책파이프라인 빌드 및 배포그리고 자동화.
대안
나는 CD Foundation의 몇 가지 프로젝트인 Jenkins X, Spinnaker 및 Tekton을 발견했으며 그 중 일부는 내 아이디어를 구현하는 데 도움이 될 수 있지만 동물원에 애완동물이 한 마리도 더 없어도 구현하면 좋을 것 같습니다.
Kubernetes에 배포~할 수 있다선언적 매니페스트를 사용하지 않고 수행하고 대신명령형 명령버전 제어 변경이 없지만 이것은정말 낙담했다전문적인 환경을 위해. 자동화된 파이프라인을 설정하고 구성하는 데 시간이 좀 걸리더라도 선언적이고 재현 가능한 방식으로 이를 수행하는 것이 중요합니다.
답변2
마침내 나는 kubernetes용 CD에서 기대했던 것과 정확히 일치하는 멋진 도구 "keel.sh"를 발견했습니다.