ArgoCD
쿠버네티스 환경에 친화적인 선언적 GitOps CD 도구
GitOps?
Git 저장소에 정의된 상태와 실제 환경의 상태를 지속적으로 비교하고 동기화하는 방식
Git 저장소만이 오직 유일한 진실된 원천(Single Source of Truth)임을 원칙으로 삼는다
⇒ “선언형” 방식에 초점을 두고, “원하는 상태”를 정의하고 이를 실제환경에 반영하려는 철학
Sync
repository의 코드 상태(Desired State)와 클러스터의 Application의 상태(Live State)를 비교해서 일치시키려는 작업
두 상태의 비교 결과에 따라 Synced / OutOfSync로 나뉘는 것을 볼 수 있다.
argoCD에서는 Application과 Project라는 단위로 리소스를 정의한다.
Application은 manifest 파일에 정의된 쿠버네티스 리소스의 묶음으로 CRD 형태로 구성된다.
Project는 Application의 상위 단위로, 모든 Application은 Project에 속하도록 구성된다.
실습
쿠버네티스 클러스터의 리소스들을 코드로 모아둔 Repository를 바라보고 Sync하는 argoCD를 구성해보도록 한다.
먼저, 아래와 같이 쿠버네티스 manifest 파일의 repository를 구성한다.
이제 이 repo를 기준으로 argoCD가 클러스터 내의 Application과 동기화하도록 구성할 것이다.
argoCD는 Helm을 통해 설치하도록 한다.
helm repo add argo https://argoproj.github.io/argo-helm
kubectl create ns argo
# values.yaml : https://raw.githubusercontent.com/argoproj/argo-helm/main/charts/argo-cd/values.yaml
helm install argocd argo/argo-cd -f values.yaml -n argo
argoCD를 클러스터에 설치하면 GUI로써 접근할 수 있는 웹 서버 파드가 구동된다. (argocd-server)
이 파드에 포트포워딩하거나 ingress/nodeport를 통해서 연결할 수 있고, 이번에는 간단하게 포워딩을 통해서 로컬로 접근하도록 구성한다.
kubectl port-forward svc/argocd-server 8888:80 -n argo
# helm으로 설치하고 포트포워딩 접근하는 경우, 설정 변경 필요
...
## Server properties
# -- Run server without TLS
server.insecure: true
...
초기 패스워드는 Secret 객체로 저장되기에 아래와 같이 확인할 수 있다.
kubectl -n argo get secret argocd-initial-admin-secret \
-o jsonpath="{.data.password}" | base64 -d
이제 argoCD에 쿠버네티스 manifest가 저장된 repo를 연동한다.
연동 방법은 GUI와 CLI 모두 사용가능하며, 먼저 GUI를 통한 Application을 추가해보도록 한다.
Applications > New App으로 Application 추가를 시작한다.
이후, 크게 4개 섹터의 값을 입력해서 Application을 추가한다.
- General : Application, Project 이름과 Sync 관련 옵션 (Auto / Manual)
- Source : 폴링할 기준 Repository, Repository URL에는 Repo의 Git 주소를 작성한다.
- Destination : Git Repo 내용을 적용할 대상 클러스터와 namespace, Cluster URL에는 클러스터의 DNS URL을 작성한다.
- Parameter : argoCD의 배포는 Helm 차트와 yaml/json manifest 파일, Kustomize Application을 지원한다.
Application을 생성하면 OutOfSync 상태로 생성되며, Auto Sync까지 대기하거나 직접 Sync를 맞춰주면 Git repo와 클러스터 내의 Application이 Sync된 것을 볼 수 있다.
Application의 구조와 Live Manifest 코드를 함께 확인할 수도 있다.
이 상황에서 간단하게 app의 라벨만 변경을 해서 repo에 수정내용을 push해본다.
Sync가 맞춰지면, Repo에 push한 내역대로 클러스터 Application 상태가 변경된 것을 확인할 수 있다.
(기존 리소스를 삭제하거나 변경하는 내역이 포함되면, Prune 옵션의 여부에 따라 기존 리소스의 삭제를 수행하게 된다.)
SSOT (Single-Source of Truth)
그렇다면, 임의로 클러스터 내의 Application 리소스를 수정하면 어떻게 될까?
kubectl scale deployment blue-deploy --replicas=5
GitOps가 추구하는 SSOT 원칙에 따라서 오직 Git repo의 상태만을 추구하기 때문에, 클러스터 리소스를 임의로 수정하더라도 repo 내용에 맞게 적용되는 것을 볼 수 있다.
이렇게 쿠버네티스 리소스의 repo와 argoCD를 통해 간단한 CD 파이프라인을 구성해보았다.
여기서 더 확장시켜 Application의 CI 작업과 연동하면 완전한 CICD 파이프라인을 구성하게 될 것이다.
다음으로는 github action을 통한 CI와 argoCD를 통한 CD를 융합한 온전한 CICD 파이프라인을 구축해보도록 한다.
