•
IaC : 인프라를 코드로 관리
•
GitOps : Git을 인프라의 단일 진실 공급원(Single Source of Truth)으로 사용
즉, GitOps는 IaC를 “어떻게 운영할 것인가”의 방법론
만약 IaC만 사용한다면?
개발자 A가 로컬에서 terraform apply를 실행하고, 개발자 B도 로컬에서 실행할 거다. 그럼 누가 무엇을 배포했는지 Git에는 기록이 없다.
GitOps를 활용한다면?
GitOps는 앞서 말했듯이 “IaC의 운영 방법론”이다. 즉, “IaC와 Git 중심의 워크플로우”다. 다음과 같다 :
# 1. 코드 수정
git add .
git commit -m "VM 크기 변경"
git push
# 2. Git push가 트리거
# -> CI/CD 파이프라인 자동 실행
# -> terraform apply 자동 실행
Bash
복사
IaC는 “코드로 관리한다”가 포인트이고, GitOps는 “Git에 push하는 행위가 곧 배포”라는 규칙을 갖고 있다는게 포인트이다.
# 전통적 CI/CD와 GitOps의 차이
나는 IaC를 도입하기 전까지는 계속 코드 push → CI/CD → 자동 배포 과정을 통해 서버를 개발하고 배포해왔었다. 그럼 이제 IaC와 GitOps를 배웠는데 무슨 차이가 있을까?
## 핵심은 애플리케이션 코드 배포 vs 인프라 배포
기존 CI/CD는 다음 과정을 거쳤다 :
코드 push -> 빌드 -> 컨테이너 이미지 생성 -> 서비스에 배포
# 서비스에 배포한다 = ECS에 배포하거나 EC2에서 컨테이너를 실행하는 것
Markdown
복사
여기서 서비스는 Azure App Service, Azure Container Apps 등등이 될 수 있다. 중요 포인트는 “인프라는 이미 존재한다고 가정”하는 것이다. 우리는 늘 콘솔에서 서비스를 생성하고 그 곳에 배포했다.
그러나 GitOps 방법론은 다음과 같은 과정이다 :
1. 인프라 코드(Terraform) push -> 인프라 생성/변경
2. 애플리케이션 코드 push -> 앱 배포
Markdown
복사
그러니까 정리하자면, 전통적인 CI/CD는 애플리케이션을 빌드해서 서비스에 올리는 것을 Git으로 관리하는 것이고, GitOps는 인프라 자체를 생성하는 것과 애플리케이션 빌드 및 서비스에 배포하는 것 모두를 Git으로 관리하는 것이다.
1단계 : 수동 인프라 + 수동 배포
↓
2단계(전통 CI/CD) : 수동 인프라 + 자동 배포
↓
3단계(GitOps) : 자동 인프라 + 자동 배포
Markdown
복사