Argo CD는 언제 사용할 수 있을까?

kubernetes 클러스터는 여러 서버를 하나의 운영 환경처럼 묶어 놓은 것이다.

 

kubernetes에게 요청하는 예시는 아래와 같다.

 

• kubernetes에 내 스프링 부트 앱을 컨테이너 이미지 a:v1로 3개 띄우기.
• 8080 포트를 사용하고, 외부에서는 service로 접근.
• 앱이 죽으면 다시 살리기.
• 새 버전이 나오면 순차적으로 교체.

 

등의 요청을 yaml 파일로 작성한다.

 

즉, kubernetes 클러스터에 배포한다는 말은,

 

서버에 직접 들어가서 앱을 실행하는 게 아니라, kubernetes API server 에 본인이 원하는 상태를 전달하고,

kubernetes가 그 상태대로 앱을 띄우고 관리하게 하는 것이다.

 

배포 흐름을 정리해 보자면,

 

개발자가 코드 수정 -> github에 코드 push -> jenkis 또는 github actions가 빌드 -> docker 이미지 생성

-> docker hub 같은 이미지 저장소에 push -> kubernetes 배포 설정의 이미지 버전 변경

-> kubernetes 클러스터에 적용 -> pod가 새 버전으로 교체

 

역할을 나눠 보자면,

 

jenkins, github actions: 코드 빌드 + docker 이미지 생성

docker registry: 이미지 저장

kubernetes: 컨테이너 실행 및 운영

 

이렇게 된다.

 

Argo CD를 쓰는 이유는,

kubernetes에 배포하려면 원래는 개발자가

kubectl apply -f a.yaml 명령어를 사용해야 하지만, 이 방식이 커지면 관리가 어려워진다.

 

관리가 어려워지는 이유는 여러가지가 있는데,

• 누가 언제 배포했는지 헷갈림.
• 서버에서 직접 명령어를 치면 기록이 분산됨.
• 실제 클러스터 상태와 git에 있는 설정이 달라질 수 있음.
• 장애가 났을 때 이전 버전으로 되돌리기 번거로움.
• 운영자가 수동으로 명령어를 잘못 칠 수 있음.

 

등이 있다.

 

그래서 Argo CD는 git에 있는 배포 설정을 정답으로 보고, kubernetes 클러스터 상태를 그 정답과 똑같이 맞춰주는 도구이다.

이 방식을 GitOps 라고 한다.

 

Argo CD가 없는 방식

개발자 또는 jenkins -> kubectl apply 직접 실행 -> kubernetes 반영

 

Argo CD 있는 방식

개발자 -> git에 kubernetes YAML 수정해서 push -> Argo CD가 git 변경 감지 -> Argo CD가 kubernetes 클러스터에 자동 반영

 

즉, 개발자(사람)가 직접 클러스터에 명령어를 날리는 게 아니라,

git만 수정하면 Argo CD가 알아서 클러스터를 맞춰주는 구조이다.

 

Argo CD를 쓰는 이유를 정리해 보자면,

 

1) 배포 상태가 git에 남는다.

 - 누가 언제 어떤 이미지 버전으로 변경했는지 git commit으로 남기 때문에 추적이 쉽다.

 

2) 롤백이 쉽다.

 - 문제가 생기면 git에서 이전 커밋으로 되돌리면 된다. 다시 이전 상태로 맞춰준다.

 

3) 수동 배포 실수를 줄인다.

 - 운영 서버에서 직접 명령어를 치는 방식은 실수 가능성이 있고, 운영/개발 클러스터를 헷갈릴 수도 있는데

 Argo CD는 git에 승인된 설정을 기준으로 배포하니까 훨씬 안전하다.

 

4) 현재 상태를 눈으로 볼 수 있다.

 - Argo CD UI에서 어떤 앱이 배포되어 있는지, git과 클러스터 상태가 같은지, pod가 정상인지 등을 확인할 수 있다.

 

마지막으로 Argo CD와 jenkins는 역할이 다른데,

 

jenkins는 빌드/ 테스트/이미지 생성

Argo CD는 kubernetes에 배포/동기화

 

역할을 한다.

 

예를 들어 spring boot 프로젝트라면

 

jenkins: github에서 코드를 가지고 옴 -> 테스트 실행 -> jar 빌드 -> docker 이미지 생성 -> 이미지 저장소에 push

Argo CD: git의 k8s 배포 설정 확인 -> 변경된 이미지 버전 감지 -> kubernetes 클러스터에 반영

 

즉, jenkins가 배포까지 할 수도 있지만, Argo CD를 사용하면 배포 부분을 GitOps 방식으로 분리한다.

 

Argo CD를 사용하기 어려운 환경도 있는데

 

1) git을 사용하지 않고 svn만 사용하는 경우

 - Argo CD가 바라볼 git 저장소의 원하는 상태가 없기 때문에 gitops 흐름을 만들기 어렵다.

 

2) kubernetes를 사용하지 않는 경우

 - vm에 직접 jar을 배포하거나 FTP로 파일을 올리는 구조라면 맞지 않다.

 

3) 배포 설정이 코드로 관리되지 않는 경우

 - 운영자가 서버에 직접 접속해서 설정을 변경하거나, 문서/수동 절차로만 배포한다면 Argo CD를 굳이 사용할 필요가 없기 때문이다.

 

4) 보안 정책상 Argo CD가 저장소나 클러스터에 접근할 수 없는 경우

 

가 있다.

 

다음에는 실습 중 오류 및 실습 정리를 써 보겠다.