Motivation
•
CI/CD pipeline을 설계하면서 BP가 무엇인지 궁금증이 유발…
CI and CD Can Be Decoupled
… Jenkins와 같은 성공적인 단일 DevOps 시스템은 CI와 CD 모두를 목표로 하기에 사람들은 CI와 CD를 한데 묶어 생각하는 경향이 있다. 하지만 Kubernetes, microservice, 그리고 클라우드 네이티브 아키텍처가 출현하면서, CI/CD를 포함한 많은 패러다임이 분리되기 시작했다 …
Key Idea
•
CI와 CD의 decoupling : legacy의 경우 CI / CD 연동에 단일 process(e.g. Jenkins Pipeline)이기에 coupling 발생
•
비동기 활용 : GitOps Controller(e.g. Argo CD)에 의한 비동기식 연동 활용
GitOps의 CI/CD pipeline Models
책에서는 GitOps 기반 pipeline 구현을 위한 3가지 모델을 제시. 첫 번째 것은 사실 상 GitOps라고 보기 어렵고(legacy DevOps) 두 번째는 혼합 단계로서, 사실 상 마지막 모델을 GitOps pipeline으로 추천.
CI가 관리하는 모델 (CI managed model)
•
DevOps의 대부분에서 특히 Jenkins를 통해 채용한 방식. 전체 프로세스를 Jenkins pipeline이 관리
•
GitOps에 반하는 모델이며 일반적으로 부유하는(floating) 태그(e.g. dev, stage, prod)를 사용하며 이 태그를 붙이는 것은 CI의 일임.
•
환경간의 게이트가 없을 경우(dev → test로의 전환)에 적합하여 완전 자동화가 가능
장점
•
전통적 CI/CD 모델로서 많은 사람들에게 익숙함
•
기존 프로세스와 도구를 바꿀 필요가 없음. 따라서 GitOps 초기 검토 시 유리하며 기존 프로세스를 (상당부분) 재사용이 가능.
단점
•
기존 프로세스에 GitOps Controller를 사용할 경우 layer가 하나 더 추가되는 복잡성 유발
•
따라서 다앙한 corner case 처리 - refactoring이 필요하게 됨.
CI에 의한 게시 및 GitOps에 의한 CD (Triggered and CD via GitOps)
•
CI가 전체를 관장하지만 배포에서는 GitOps Controller를 사용하는 모델
•
배포를 위해 CI는 GitOps Controller를 trigger하고 기다리며, 완료되면 확인/테스트를 진행.
•
GitOps Controller를 사용하지만 동기식 모델임.
•
환경 간의 게이트가 없을 경우(dev → test로의 전환)에 적합하여 완전 자동화가 가능
장점
•
GitOps 원칙을 지키기에 git에서 클러스터의 상태를 확인 가능함.
•
선형적 구성의 단순성 덕분에 따르기 좋으며 문제 발생 시에도 해결이 용이함
단점
•
CI Managed Model과 동일하게 GitOps Controller로 인한 복잡성 유발
CI에 의한 게시 및 GitOps에 의한 소유 (Triggered and GitOps Owned)
그림이 설명에 맞아보이지 않음. 하지만 원본이 이렇게 되어 있기에…(pipeline 1, 2로 분리 등은 좋은데, 작은 사각형의 설명이 영…)
•
CI는 image를 생성하고 CD를 위한 manifest 변경 Pull Request를 생성하는 것으로 종료, 이후 CD는 GitOps Controller가 담당.
•
또는 PR 생성 없이 자동으로 manifest 변경을 merge하여 CD가 실행되도록 한후, hook을 사용하여 배포 완료 시 추가 작업이 가능하도록 함.
장점
•
CI와 CD가 명시적으로 분리되어 통합 시 직면하게될 여러 문제를 피할 수 있음
•
CI와 CD를 담당하는 시스템이 각기 다름… decoupling에 의한 안정성 증대
단점
•
선형 프로세스가 아니라 이해가 어려울 수 있음
•
loosely coupled process이므로 이슈 추적성이 저하될 수 있음
References
•
The Path to GitOps