ArgoCD

• 쿠버네티스 환경에서 GitOps 기반의 CD(Continuous Deployment) 도구 (GitOps CD tools for k8s)
• 대상 환경에서 원하는 상태의 배포 자동화를 지원 (Automate the deployment of the desired state in target env)
• 쿠버네티스에서 지원하는 다양한 리소스 형태를 지원 (k8s menifests can be specified in serveral ways)
  • kubstomize, helm, yaml, ...

ArgoCD 구성 요소

ArgoCD는 크게 3가지 컴포넌트(서버)로 구성

• API server, Repository Server, Application Controller

API server

• 사용자(or 관리자) UI 또는 CLI를 통해 접근
• 다른 서비스에서 gRPC 또는 REST API를 통해 접근
• Git webhook event를 통해 접근
• 철학적으로 ArgoCD는 외부의 identity provider에게 권한을 위임해서 인증/인가 구현
• ArgoCD는 RBAC을 통해 권한을 관리

Repository Server

• Git repository에 대한 캐싱
  • Git에 있는 일련의 현상을 k8s 워크로드에 싱크해주는 게 ArgoCD의 목적
• helm, yaml 파일들을 k8s manifest로 변경

Application Controller

• k8s controller
• reconciliation(지속적으로 비교해서 current state을 desired state로)을 담당

ArgoCD Project & Application

Project는 Application을 그룹으로 관리하는 개념으로, Appliction은 생성할 때 Project를 선택해야 하고 Project는 0개 이상 Application을 가질 수 있음

• Project: 여러 application의 묶음 (k8s의 namespace)
• Application: k8s의 workload에 맵핑

ArgoCD 도입과 배포 프로세스

ArgoCD 도입 시 아래와 같은 형태로 배포 프로세스를 가져갈 수 있음

1. 사용자는 기능(피처) 개발을 진행 후 해당 코드를 Source Repository에 푸시
2. 구축된 CI 파이프라인을 통해 해당 소스의 도커 이미지 빌드 및 이미지 레지스트리에 등록
3. CI 프로세스에서 생성된 이미지에 대해 트리거를 통해 ArgoCD와 Sync 되어 있는 GitOps Repository에 원하는 버전을 적용(푸시)
4. Webhook 또는 ArgoCD polling을 통해 GitOps Repository에 선언된 리소스와 쿠버네티스 클러스터 상의 리소스를 확인 및 비교
5. GitOps Repository에 선언된 리소스와 배포된 리소스의 상태가 다른 경우 GitOps Repository에 선언된 리소스를 자동화 적용

Reference

• ArgoCD - Github
• ArgoCD - Docs

CI (Continuous Integration)

• 빌드/테스트 자동화 과정
• CI를 성공적으로 구현할 경우 애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어 공유 리포지토리에 통합되므로 여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌할 수 있는 문제를 해결
• 커밋할 때마다 빌드와 일련의 자동 테스트가 이루어져 동작을 확인하고 변경으로 인해 문제가 생기는 부분이 없도록 보장
• Compile, Build, Unit test, Integration Test, Static analysis

CI common practices

• Maintain a code repository
  • Application should be buildable from a fresh checkout without requiring additional dependencies
• Automate the build & Keep the build fast
• Everyone commits to the baseline every day & Every commit (to baseline) should be built
• Every bug-fix commit should come with a test case
• Test in a clone of the production environment(Staging)

CD (Continuous Deployment)

• 배포 자동화 과정
• 지속적인 서비스 제공(Continuous Delivery) 또는 지속적인 배포(Continuous Deployment)를 의미
• 코드 변경이 파이프라인의 이전 단계를 모두 성공적으로 통과하면 수동 개입 없이 해당 변경 사항이 프로덕션에 자동으로 배포
• 간단한 코드 변경이 정기적으로 마스터에 커밋되고, 자동화된 빌드 및 테스트 프로세스를 거치며 다양한 사전 프로덕션 환경으로 승격되며, 문제가 발견되지 않으면 최종적으로 배포

CI/CD 종류

• Jenkins
• CircleCI
• TravisCI
• Github Actions
• Argo

CI/CD 적용 전과후 비교

CI/CD를 적용하기 전

1. 개발자들이 개발하여 코드를 수정
2. 각자의 feature 브랜치에 코드를 push (but, 어느 한 부분에서 에러가 발생한 경우 개발자들은 순간순간 확인이 어려움)
3. 각자의 코드를 git에 올리고 통합(Intergration)
4. 에러가 발생했지만 어느 부분에서 에러가 났는지 모르므로 다시 어디부분에 에러가 있는지 디버깅하고 코드를 수정
5. (1) ~ (4)의 과정을 반복
6. 많은 시간을 할애하여 에러가 해결되었으면 배포. 하지만 배포과정 또한, 개발자가 직접 배포과정을 거치므로 많은 시간이 소요됨

CI/CD를 적용 후의 과정

1. 개발자들이 개발하여 feature 브랜치에 코드를 push
2. git push를 통해 Trigger되어 CI서버에서 알아서 Build, Test, Lint를 실행하고 결과를 전송
3. 개발자들은 결과를 전송받고 에러가 난 부분이 있다면 에러부분을 수정하고 코드를 master 브랜치에 merge
4. master 브랜치에 코드를 merge하고 Build, Test가 정상적으로 수행이 되었다면 CI 서버에서 알아서 Deploy 과정을 수행

Reference

• https://www.redhat.com/ko/topics/devops/what-is-ci-cd
• https://seosh817.tistory.com/104
• https://en.wikipedia.org/wiki/Continuous_integration
• https://en.wikipedia.org/wiki/Continuous_delivery