마루옵스서버 · 네트워크 · AI 기술 노트

소개문의

[Git·GitOps 20] GitOps의 네 원칙과 앱·배포 설정 저장소 나누기

Virginia Tech 데이터센터의 장비 통로

참고 사진 · Virginia Tech 데이터센터의 장비 통로 · 사진: Christopher Bowns / 원본 / CC BY-SA 2.0 · 목록용 크기 조정

YAML을 Git에 보관하면 변경 기록은 남습니다. GitOps에서는 여기에 실제 시스템을 계속 관찰하고, 기록한 상태와 맞추는 에이전트가 더해집니다. 사람이 매번 배포 명령을 실행하지 않아도 차이를 확인하고 조정하는 구조예요.

이 글부터 Kubernetes를 알고 있는 독자를 대상으로 깊이를 높입니다. Pod, Deployment, Service와 kubeconfig가 익숙하지 않다면 사이트의 Kubernetes 실습을 먼저 진행하는 편이 좋습니다. 기존 Git 기본 사용만 필요한 독자는 앞의 협업·서버 편까지 활용해도 됩니다.

Git·GitOps 전체 연재 · 20 / 24

이 글의 목차

네 원칙을 운영 동작으로 연결한다

OpenGitOps v1.0.0은 원하는 상태를 선언하고, 변경 이력을 보존하며, 에이전트가 이를 자동으로 가져와 지속적으로 조정하는 원칙을 제시합니다. 아래 표는 그 원칙을 이 연재의 구성에 맞춰 풀어 쓴 것입니다.

원칙이 실습에서의 의미
선언형 상태Deployment의 replica·이미지 등을 YAML에 기록
버전과 불변 이력검토한 커밋과 이미지 digest로 기준 식별
에이전트가 자동으로 가져옴Argo CD가 Git 저장소를 읽음
지속적 조정Git과 클러스터의 차이를 반복 관찰·처리

CI가 Git에 설정을 기록한 뒤 kubectl apply를 한 번 실행하는 방식은 지속적으로 조정하는 컨트롤러가 없는 구조일 수 있습니다. 어느 방식이든 사용할 수 있지만, 복구와 권한을 설명할 때 같은 구조라고 부르지 않습니다. 원칙의 원문은 OpenGitOps에서 확인할 수 있습니다.

앱 코드와 운영 선언의 권한을 나눈다

학습에서는 두 저장소를 사용합니다. gitops-demo는 Python 테스트와 CI를 배우는 코드 저장소이고, gitops-config는 nginx 배포 예제를 담는 저장소입니다. CI 학습과 Kubernetes 조정 실습의 역할을 분명히 하면서 복잡한 앱 빌드 설정을 덜어내기 위한 구성입니다.

gitops-demo/
  greeting.py
  test_greeting.py
  Jenkinsfile
  .github/workflows/ci.yml

gitops-config/
  environments/
    dev/
      deployment.yaml
  bootstrap/
    project.yaml
    application.yaml

배포 저장소를 나누면 앱을 개발할 권한과 운영 환경을 바꿀 권한을 별도로 검토하기 쉽습니다. 한 저장소로도 시작할 수 있지만 경로별 소유자, 필수 리뷰, 컨트롤러가 읽는 범위를 신중하게 정해야 해요. 저장소 수를 늘리는 것 자체가 목적은 아닙니다.

bootstrap/에는 관리자가 Argo CD에 등록할 정의를 두고, Application은 environments/dev만 읽습니다. 부트스트랩 파일이 있다고 자동으로 적용되는 것은 아닙니다. 특히 AppProject와 Application을 수정할 권한은 배포 권한과 연결되므로 별도로 제한합니다.

개발 환경에서 시작해 운영으로 승격한다

처음에는 environments/dev 한 곳만 만듭니다. 운영 실습이 필요해졌을 때 prod 경로와 별도의 검토 규칙을 추가합니다. 같은 이미지를 쓰더라도 replica, 리소스, 연결 대상이 다르므로 변경 diff를 확인합니다.

앱 CI → 검증된 이미지 digest 생성
          ↓
개발 설정 PR → 개발 환경 검증
          ↓
같은 digest의 운영 설정 PR → 승인 → 운영 컨트롤러 조정

브랜치 하나를 환경 하나와 대응시키는 방법도 있지만 cherry-pick과 분기 차이를 관리해야 합니다. 여기서는 main의 환경별 디렉터리를 사용해 승격할 값이 diff에 보이도록 합니다. Helm이나 Kustomize로 중복을 줄이기 전에는 작은 원본 YAML로 동작부터 확인합니다.

컨트롤러도 아무 권한이나 가져서는 안 된다

Git 읽기 키, 대상 클러스터, 허용 namespace와 리소스를 정합니다. 저장소 쓰기 권한을 가진 사람이 곧 클러스터에 어떤 리소스든 배포할 수 있는 구조인지 검토해야 합니다. 21편의 AppProject는 출처와 대상 범위를 좁히지만 클러스터의 RBAC와 네트워크 경계를 대신하지는 않습니다.

Argo CD의 배포 저장소 분리와 Git 변경 흐름은 공식 모범 사례를 참고했습니다. 다음 편에서는 기본 자동화를 잠시 끈 상태로 첫 diff와 수동 동기화를 확인합니다.

이전 글 · [Git·GitOps 19] CI 다음의 CD: 승인·산출물 승격·이미지 digest · 다음 글 · [Git·GitOps 21] Argo CD 첫 배포: 설치·AppProject·저장소 인증 · 연재 목록과 예제 파일

댓글

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다

닉네임·이메일·댓글 내용·IP 주소·브라우저 정보는 댓글 게시 및 관리에 사용됩니다. 이메일과 접속 정보는 공개 댓글에 표시하지 않습니다. 개인정보 요청은 운영자 이메일로 보내 주세요. 개인정보처리방침