90DaysOfDevOps (Day 33)

고태규·2025년 10월 30일

devops

DevOps

목록 보기

32/50

해당 스터디는 90DaysOfDevOps
https://github.com/MichaelCade/90DaysOfDevOps
를 기반으로 진행한 내용입니다.

Day 33 - GitOps made simple with ArgoCD and GitHub Actions

1. GitOps와 GitOps의 4가지 원칙

깃옵스 (GitOps)란 기본적으로 Git 저장소를 애플리케이션 배포 및 인프라의 '신뢰할 수 있는 단일 출처 (Source of Truth)' 로 사용하는 것을 의미한다.

모든 것이 버전 관리되는 Git 저장소에 저장되며, 해당 저장소가 배포와 인프라 생성을 추진하는 공급원이 되는 것이다.

깃옵스는 특정 소프트웨어나 기술이 아니라, 데브옵스나 애자일 원칙처럼 하나의 '이념(ideology)' 에 가깝다. 해당 이념은 4가지 명확한 핵심 원칙을 기반으로 한다.

깃옵스의 4가지 핵심 원칙

선언적(Declarative) 특성
- GitOps 시스템은 선언적이어야 함.
- 선언적이라는 것은 "최종 상태가 어떠해야 하는지" 만을 정의하는 것을 의미
- 시스템은 그 최종 상태에 도달하기 위한 정확한 단계를 스스로 파악하여 실행해야함.
버전 관리 및 불변성(Versioned and Immutable)
- 모든 선언적 구성은 Git 저장소를 통해 관리되어야 함.
- Git 저장소를 사용하면 모든 변경 사항이 자동으로 버전 관리되고, 불변성을 보장받게 됨.
- 구성에 대한 모든 변경 내역이 Git 저장소에 명확하게 추적됨.
자동으로 풀(Pulled Automatically)
- GitOps Agent 가 필요
- 선언적 구성을 저장한 Git 저장소를 특정 간격으로 지속적으로 풀링 (pulling) 함.
- 현재 상태와 저장소의 상태를 비교하며 변경이 필요한지 아닌지를 항상 확인함.
지속적으로 일치(Continuously Reconciled)
- 만약 에이전트가 Git 저장소의 '신뢰할 수 있는 단일 출처'와 실제 배포된 상태 간의 차이점을 발견하면, 에이전트는 이 차이점을 즉시 일치 (reconcile) 시킴.
- 실제 배포 상태를 Git에 정의된 원하는 상태로 자동으로 변경

2. Argo CD와 GitHub Actions

많은 이들이 깃옵스 구현을 어렵고 복잡하게 생각하며, 도구 선택에 부담을 느낀다.

하지만 핵심은 상황을 너무 복잡하게 만들지 않고 간단한 것에 집중하는 것이다. 깃옵스 시작 시 너무 과하게 설계할 필요가 없다.

Flux든 Argo CD든, 하나의 깃옵스 도구를 선택하고 그것을 꾸준히 사용하는 것이 좋다.

해당 프레젠테이션에서는 Argo CD와 GitHub Actions만을 사용하여 깃옵스의 핵심 이념을 구현하는 워크플로우를 구축한다.

2-1. 구현 GitOps 흐름도

개발자가 어플리케이션 코드를 수정하고 Git에 Commit
해당 Commit은 GitHub Action을 트리거
GitHub Action은 최신 커밋을 기반으로 새 컨테이너 이미지를 빌드하고, 이미지 레지스트리로 푸시 (Push)
이미지 푸시가 완료되면, GitHub Action은 배포 매니페스트 (예: Helm Chart)를 새 이미지 태그로 업데이트하여 새 커밋을 생성
깃옵스 에이전트인 Argo CD는 해당 배포 매니페스트 저장소를 풀링하다가, 새 커밋으로 인한 변경 사항을 감지
- 5-1. Argo CD는 특정 풀링 간격 (기본 3분)이 있으므로, 즉시 변경을 감지하지 못할 수 있음.
- 5-2. 새로고침(Refresh) 버튼을 클릭하면, Argo CD가 Git 저장소와 클러스터 상태를 비교하고, 동기화되지 않음(Out of Sync) 상태임을 감지
- 5-3. 수동 동기화를 위해 동기화(Sync) 버튼을 클릭
Argo CD는 해당 변경 사항을 클러스터에서 이미 실행 중인 애플리케이션과 비교하여 새 이미지 태그를 가진 Pod를 배포하고 이전 파드를 삭제하는 일치 (reconcile) 작업 수행
결과적으로, 개발자가 커밋한 코드가 자동으로 프로덕션에 배포

이 과정이 가능했던 핵심 설정 두 가지는 Argo CD 애플리케이션 정의와 GitHub Actions 워크플로우이다.

2-2. Argo CD 어플리케이션 설정 (YAML)

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: go-server-prod 
spec:
  destination:
    name: in-cluster # 배포할 클러스터
    namespace: prod  # 배포할 네임스페이스
  source:
    path: chart # 저장소 내 모니터링할 매니페스트 경로
    repoURL: https://github.com/ragad/GitHub-sample.git # 모니터링할 Git 저장소 주소이
    targetRevision: HEAD # 항상 최신 커밋 (HEAD)을 추적
    helm:
      valueFiles: # 헬름 (Helm)을 사용하며, 해당 values 파일을 사용
        - values.yaml
  project: default 
  syncPolicy:
    syncOptions:
      - CreateNamespace=true # 'prod' 네임스페이스가 없으면 자동 생성

2-3. GitHub Actions 워크플로우 설정 (YAML)

코드가 푸시되었을 때 이미지 빌드, 푸시, 그리고 매니페스트 업데이트를 담당하는 워크플로우이다.

name: GitOps
on:
  push:
    paths: # main.go 파일이 변경될 때만 이 워크플로우를 실행
      - 'main.go'
jobs:
  build: # 'build' 작업
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Docker Hub 로그인
        uses: docker/login-action@v2
        with:
          username: ${{ secrets.DOCKERHUB_USERNAME }} # 시크릿을 사용하여 Docker Hub에 로그인
          password: ${{ secrets.DOCKERHUB_TOKEN }}
      - name: 이미지 빌드 및 푸시
        uses: docker/build-push-action@v4
        with:
          push: true
          tags: your-docker-id/go-server:${{ github.sha }}
  update: # 'update' 작업
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: 헬름 매니페스트 업데이트
        run: |
          # sed 명령어를 사용해 chart/values.yaml 파일의 'tag' 값을
          #    방금 빌드한 이미지 태그(github.sha)로 교체
          sed -i 's/tag: .*/tag: ${{ github.sha }}/' chart/values.yaml
      - name: 변경 사항 커밋 및 푸시
        run: |
          git config --global user.name 'github-actions'
          git config --global user.email 'github-actions@github.com'
          git commit -am "이미지 태그 업데이트: ${{ github.sha }}"
          git push # 변경된 values.yaml 파일을 다시 저장소로 푸시

해당 워크플로우가 실행되면 build 작업이 커밋 SHA를 태그로 이미지를 빌드하고 푸시한다.

그다음, update 작업이 chart/values.yaml 파일의 tag 값을 새로운 SHA 값으로 변경한 뒤, 그 변경 사항을 다시 Git 저장소에 커밋한다.

해당 과정의 커밋이 Argo CD가 감지하게 될 '변경 사항'이며, 이로써 전체 GitOps 파이프라인이 완성된다.

3. GitOps 도입의 4가지 핵심 이점

변경 이력 추적 (History)
- 모든 배포와 매니페스트 변경 사항이 Git 저장소에 이력으로 남기 때문에, 이를 통해 시간이 지남에 따라 시스템이 어떻게 변화했는지 명확하게 볼 수 있음.
- 만약 장애가 발생하면, 어떤 커밋이 문제를 일으켰는지 즉시 파악할 수 있고, 해당 커밋을 되돌리기만 하면 됨.
- 커밋을 되돌리면 Git의 HEAD가 바뀌고, Argo CD는 이를 감지하여 자동으로 이전 상태로 롤백
표준화 및 거버넌스 (Standardization and Governance)
- 깃옵스를 사용하면 Git 저장소가 클러스터와 상호작용하는 유일한 Gateway 역할을 함.
- 깃옵스 하에서는 모든 변경이 Git을 통해서만 이루어져야 하므로, 모든 것이 표준화되고 시스템 상태에 대한 완전한 Governance (통제)를 갖게 됨.
보안 (Security)
- 더 이상 개발자나 다른 팀원들에게 프로덕션 클러스터의 kubectl 접근 권한을 직접 줄 필요가 없음.
- 개발자들에게는 Argo CD가 모니터링하는 Git 저장소에 풀 리퀘스트 (PR) 를 생성할 권한만 부여하면 됨.

신속한 배포 (Ship things faster)
- 깃옵스 파이프라인을 설정하고 나면, 모든 변경은 버전 관리 시스템에 의해 통제됨.
- 개발자들은 자신의 코드 변경 사항을 커밋하고 푸시하기만 하면 되며, 테스트, 빌드, 배포의 전체 사이클을 자동화하여 훨씬 더 빠르고 안정적으로 서비스를 제공할 수 있음.