이번 포스팅은 GitOps의 핵심 개념, 동작 방식과 그 구현체인 ArgoCD에 대한 주제를 다룹니다.

GitOps?

GitOps라는 용어는 Weaveworks 회사에서 처음 사용되어 지금까지 많은 영향력을 끼쳐왔는데요, 클라우드 네이티브 애플리케이션을 지속적인 배포(Continous Delivery;CD)를 구현하는 방법입니다. 

GitOps 배포 동작 방식

핵심 개념은 다음과 같습니다.

  • 프로덕션 환경에서 목표로하는 인프라에 대한 선언적인 정의서(declarative descriptions)가 포함된 Git 저장소(Repository)와 실제 프로덕션 환경이 일치하도록 자동화된 프로세스를 구축하는 것입니다.
  • 즉, 새로 배포할 땐 Git 저장소만 업데이트하면 프로덕션 환경에 자동으로 반영이 되는 것입니다.

선언적인 정의서(declarative descriptions)

핵심 개념에서 언급된 선언적인 정의서(declarative descriptions)는 쿠버네티스의 매니페스트로 생각하면 쉽게 이해할 수 있습니다.

선언적으로 작성한 쿠버네티스의 매니페스트는 어떤 리소스를 어떻게 배포할 것인지에 대한 내용이 담겨있습니다.

apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  selector:
    app: view
    tier: frontend
  ports:
    - protocol: TCP
      port: 80
      nodePort: 30956
      targetPort: 80
      name: http
  type: NodePort

위의 예시는 nginx 서비스 객체를 선언적으로(declaratively) 정의한 내용입니다. 이렇게 작성한 정의서를 기반으로 쿠버네티스는 어떻게 구성해야하는지 빠르게 확인할 수 있으면서 공유하기도 쉽습니다.

단일 진실의 원천 (Single Source Of Truth; SSOT)

또 다른 핵심 개념으로 Git 저장소(Repository)는 단인 진실의 원천(또는 공급원)으로 사용됩니다.

먼저 단일 진실의 원천(Single Source Of Truth; SSOT)에 대해 짚고 넘어가보죠.

 

"진실(결과)는 오직 한 가지의 원천(공급원)에서 비롯된다"는 의미의 단일 진실의 원천(또는 단일 진실의 공급원)은 커피고래님 블로그에 쉬운 예시가 있습니다.

먼저 어떤 아이가 울고 있으면(결과) 그것은 오직 아이스크림을 땅바닥에 떨어뜨렸기 때문(이유)라고 가정합니다.

어느 시점에 아이의 상태를 봤을 때 아이가 울고 있으면(결과=진실) 그 이유는 넘어져서 또는 혼나서 우는게 아닙니다.
오직 아이가 아이스크림을 떨어뜨려서(이유=원천=공급원)입니다.

 

위의 예시를 애플리케이션을 개발하고 배포할 때로 빗대어 생각해 볼 수 있습니다.

개발이 완료된 애플리케이션은 여러 방식으로 배포할 수 있습니다. 예를 들면, GitHub Actions를 이용해 배포를 할 수도 있고, 직접 빌드된 파일을 옮기는 식으로 배포도 가능합니다. 만약 여러 개발자들이 버그를 고치고 배포를 할 때마다 서로 다른 방식으로 배포를 한다면 human error가 발생할 가능성이 높아지는 문제가 다분해집니다.

 

이를 해결하기 위해 단일 진실의 원천으로 Git 저장소를 사용하는 GitOps가 있습니다.

GitOps를 사용해야 하는 이유

선언적인 정의서를 통해 애플리케이션을 배포하는 구성 요소를 확인하고 공유하기 쉽고, 단일 진실의 원천으로 Git 저장소를 사용하는 GitOps에 대해 조금 더 알게되었는데요, GitOps를 사용하면 더 좋은 장점들은 명확합니다.

  • Git 기반 워크플로우로 인해 배포 속도가 더 빨라집니다.
    • 모든 변경 사항을 기록하고 추적하는 Git 저장소를 통해 최종적으로 원하는 프로덕션 환경과 실제 프로덕션 환경을 일치시킵니다.
  • 장애 복구가 쉽고 빠릅니다
    • Git 저장소를 통해 시간이 지남에 따라 배포 환경이 어떻게 변했는지 완전하게 파악할 수 있습니다. 장애가 발생하면 Git에서 Revert를 실행하는 것만으로 프로덕션 환경도 Sync되어 쉽게 복원됩니다.
  • 자격 증명 관리가 쉬워집니다.
    • Git 저장소와 이미지 레지스트리(Docker Image 저장소)에 대해 접근만 할 수 있으면 됩니다.
  • 배포 자체가 스스로 문서화되어 있습니다.
    • 어떤 파일이 변경되었는지 ssh 접속으로 서버를 헤집고 다닐 필요가 없습니다. 단일 진실의 원천인 Git 저장소의 배포 브랜치만 확인하면 모든 변경 사항에 대해 확인할 수 있습니다.
  • 선언적인 정의서(매니페스트)로 인해 변경 사항을 팀 내에서 공유하기 원활해집니다.
    • 누구나 잘 작성된 커밋 메시지를 통해 인프라 변경 사항을 재현하고 확인할 수 있습니다.

GitOps의 배포 전략

이제 Git 저장소를 통해 배포한다는 것은 알았습니다.

그렇다면 특정 브랜치에 push가 됐을 때 배포가 될지, 폴링 방식으로 pull을 통해 배포가 될지 구현할 수 있습니다.

Push 기반 배포

push 기반 배포 워크플로우

코드가 커밋되어 배포 전용 브랜치(마스터 브랜치)에 푸시될 때마다 배포하는 전략입니다. 단순한 전략이라 인기가 많습니다.

이 배포 전략은 저장소의 푸시 같은 외부 이벤트(트리거)가 프로덕션 환경에 배포로 이어지는데, API 호출같은 외부 이벤트에는 자격 증명이 필요하기 때문에 보안 이슈가 발생할 수 있습니다.

구현체로는 Jenkins, CircleCI, Travis CI 등이 있습니다.

Pull 기반 배포

pull 기반 배포 워크플로우

프로덕션 환경의 Operator가 지속적으로 저장소(Repository)를 확인하고, 실제 프로덕션 환경과 비교하여 차이점이 있을 때마다 프로덕션 환경이 저장소와 일치하도록 배포를 동작시키는 흐름입니다. Push 기반 배포 전략과는 달리 프로덕션 환경 내부(클러스터 내부)에서 확인하므로 자격 증명 관련 보안 이슈 가능성은 줄어듭니다.

구현체로 ArgoCD, JenkinsX, Flux(GitOps 용어를 만든 Weaveworks 회사의 제품)이 있습니다.

ArgoCD 란?

ArgoCD는 대표적인 GitOps의 구현체입니다. 기본적으로 Pull 기반 배포 전략을 사용합니다. (Push 배포도 가능합니다.)

ArgoCD 아키텍처

  • ArgoCD는 클러스터 내의 Operator가 되어 자동화된 배포 프로세스를 책임집니다.
  • GitOps의 방법론처럼 ArgoCD는 단일 진실의 원천(SSOT)인 Git 저장소를 통해 선언적인 정의서인 쿠버네티스 매니페스트(deployment.yaml 등)를 읽고, 클러스터에 배포 환경을 구성합니다.
  • Git 저장소의 배포 브랜치에 있는 선언적인 정의서(매니페스트)에 따라 배포하거나, 롤백을 할 수 있습니다.
  • 선언적인 정의서에 따라 원하는 프로덕션 환경이 되도록 지속적으로 Git 저장소를 체크하고 변경 사항을 반영합니다.

ArgoCD 설치

https://argo-cd.readthedocs.io/en/stable/getting_started/ 공식 문서를 통해 빠른 설치와 적용을 할 수 있습니다.

먼저 `kubectl`로 ArgoCD를 쿠버네티스 클러스터 내에 설치합니다. 설치 전 `kubeconfig`를 확인하고 설치하고자하는 클러스터 컨텍스트로 변경이 필요합니다.

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

기본적으로 argocd 라는 네임스페이스에 설치되며, `ClusterRoleBinding` 리소스가 argocd 네임스페이스를 참조하므로 우선 네임스페이스 변경없이 설치하겠습니다.

kubectl get pod -n argocd

# 실행 결과
NAME                                                READY   STATUS    RESTARTS
argocd-application-controller-0                     1/1     Running   0       
argocd-applicationset-controller-5c787df94f-v8tgb   1/1     Running   0       
argocd-dex-server-55d5769f46-lljd9                  1/1     Running   0       
argocd-notifications-controller-7ccbd7fb6-lc9jp     1/1     Running   0       
argocd-redis-587d59bbc-pkv64                        1/1     Running   0       
argocd-repo-server-76f6c7686b-w5wgs                 1/1     Running   0       
argocd-server-64fcc786c-f7xth                       1/1     Running   0

웹 UI에 접속하기

ArgoCD 설치가 완료되어 파드들이 실행 중이라면 웹 UI에 접속할 수 있습니다.

이번 포스팅에서는 임시로 접속하는 `port-forward` 방식으로 접근하겠습니다.
Ingress 서비스를 통해 argocd-server를 외부로 노출시키는 방법은 https://argo-cd.readthedocs.io/en/stable/operator-manual/ingress/ 를 참고해 주세요.

 

포트 포워딩

kubectl port-forward svc/argocd-server 8080:80 -n argocd

포트 포워딩을 하면 localhost:8080 경로를 통해 ArgoCD UI에 접속할 수 있습니다.

  • Username과 Passward는 admin 계정을 사용해야 합니다. Password는 ArgoCD 설치 시 등록된 쿠버네티스 시크릿에서 확인할 수 있습니다. 
    • Username: admin
    • Password: 아래 명령어로 확인
kubectl get secret argocd-initial-admin-secret -n argocd -o jsonpath='{.data.password}' | base64 --decode

# 실행 결과
sO2aifhRZFyZALQb

 

접속 화면

메인 대시보드에서 애플리케이션의 리스트를 확인할 수 있습니다.

`New APP` 버튼을 눌러 새로 배포를 해보겠습니다.

kubeconfig가 설정되어 있다면 Cluster URL은 `https://kubernetes.default.svc`로 설정해도 됩니다.

 

설정을 마치고 `CREATE` 버튼을 누르면 배포가 진행됩니다.

배포를 마치고 카드를 클릭하면 대시보드에서 쿠버네티스 클러스터 내의 리소스들을 확인할 수 있습니다.

이미지에선 Git 저장소와 Synced 된 것이 확인됩니다.

참고

'DevOps' 카테고리의 다른 글

Argo Rollouts를 이용한 Blue-Green 배포 전략 적용하기  (0) 2025.01.07
GitHub Actions + ArgoCD로 k8s 클러스터 환경에서 CI/CD 구축하기  (0) 2025.01.05
GitOps에서 SealedSecret으로 안전하게 Secret 관리하기  (0) 2025.01.04

티스토리툴바