AWS EKS ArgoCD 환경 구축하기 [2/2]

지난번 포스트에 이어 작성하겠다.

 

AWS EKS ArgoCD 환경 구축하기 [1/2]

 

ArgoCD Application

Application은 ArgoCD가 쿠버네티스 리소스들을 배포하는 기본적인 단위이다.

 

https://argo-cd.readthedocs.io/en/stable/user-guide/application-specification/

Application Specification Reference - Argo CD - Declarative GitOps CD for Kubernetes

 

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook
  # You'll usually want to add your resources to the argocd namespace.
  namespace: argocd
  # Add this finalizer ONLY if you want these to cascade delete.
  finalizers:
    # The default behaviour is foreground cascading deletion
    - resources-finalizer.argocd.argoproj.io
    # Alternatively, you can use background cascading deletion
    # - resources-finalizer.argocd.argoproj.io/background
  # Add labels to your application object.
  labels:
    name: guestbook
spec:
  # The project the application belongs to.
  project: default

...

 

Application을 정의하는 yaml 파일 중 일부이다.

 

Application은 쿠버네티스가 관리하는 리소스가 아닌 ArgoCD 측에서 만든

 

CRD(Custom Resource Definition) 이므로, apiVersion이 기존의 리소스들과는 다르다.

 

kubectl 명령어를 이용해 생성할 수 있지만, 이전에 만들어둔 GUI를 통해서도 만들 수 있다.

 

New App 버튼을 누르면 Application 을 정의할 수 있는 창이 열리게 된다.

 

하나하나씩 파헤쳐보자.

 

General

Edit as yaml 버튼을 누르면 yaml 파일 에디터가 열린다.

 

하나의 Project는 여러 개의 Application을 가질 수 있다.

 

Sync Policy

Sync란 무엇을 뜻하는걸까?

 

바로, GitOps의 핵심인 Manifest의 변화를 감지하며 클러스터의 상태를 동기화 시키는 것을 말한다.

 

말 그대로 ArgoCD의 핵심 기능이며 option으로는 Manual과 Automatic이 있다.

 

본 포스트에서는 완전히 자동화된 CI CD 파이프라인 구축을 위해 Automatic으로 설정하였으나,

 

규모가 큰 애플리케이션이나 서비스의 production 환경으로의 배포는 매우 민감하고 중요하므로

 

Manual 하게 진행하는 경우가 많다고 한다. (default가 Manual 인것을 미루어 보아 권장하는 방식임을 알 수 있다)

 

Source

Source도 핵심 요소이다.

 

GitOps로 관리할 Manifest Repo의 URL을 지정한다.

 

또한 어떤 브랜치를 기준으로 Sync를 맞출건지, 해당 Repo의 path중 어디 위치에 Manifest 파일이 담긴지를 설정한다.

 

Destination

마지막 Destination은 Sync를 맞춘 애플리케이션을 배포할 클러스터를 설정한다.

 

우리는 로컬에 ArgoCD가 설치된 EKS 환경의 default 네임스페이스에 배포할것이므로 CoreDns를 사용한다.

 

여기까지 설정한 다음, Application을 생성하였다.

 

Sync

Sync는 ArgoCD의 가장 핵심적인 기능이다.

 

우리는 Application을 생성하면서 Sync policy를 Automatic으로 설정하였다.

 

미리 만들어둔 Manifest Repo에 Helm Chart를 Push한 이후, Application에 연결해주었다.

 

브랜치도 dev 브랜치를 명시했으니, 앞으로 Manifest Repo의 dev 브랜치에 변화가 생길때마다

 

자동으로 클러스터와 Sync 할 것이다. 할 것이라고 생각했다.

 

하지만 Jenkins에서 성공적으로 CI 과정을 마친 다음, Manifest Repo의 dev 브랜치에 푸쉬해도 ArgoCD는 무응답이었다.

 

왜 이런 결과가 나온것일까?

 

우선 Sync Status와 Last Sync에 대해 이해할 필요가 있었다.

 

Sync Status

Sync Status는 현재 Application의 상태가 Manifest Repo에 선언된 상태가 일치하는지를 나타낸다.

 

가질 수 있는 상태 값으로는 Synced와 Out of Sync가 있다.

 

Synced는 말 그대로 개발자가 선언한 Manifest와 완전히 동기화 되었다는 뜻이며,

 

Out of Sync는 Manifest와 Application의 상태가 다르다는 뜻이다.

 

Last Sync

Last Sync는 우리가 설정한 Sync Policy에 따라 Sync 작업을 했을 때, 마지막 Sync 작업에 대한 상태를 나타낸다.

 

표시되는 정보로는 성공과 실패 여부, 리비전, 타임 스탬프등이 있다.

 

차이점

언뜻 보기에는 별 차이가 없어 보인다. 그림으로 이해해보자.

 

 

위 그림은 Manifest Repo의 Head Revision이 abc123인 경우이며,

 

Automatic Sync Policy에 의해 성공적으로 클러스터와 Sync가 된 상황이다.

 

하지만 여기서, ArgoCD Application이 만들어 낸 쿠버네티스 리소스를

 

개발자가 수동으로 조작하여 변경이 일어난다고 가정해보자.

 

 

Manifest Repo의 Revision에 명시된 정보와 다르기에, Sync Status는 Out of Sync 상태로 변하게 된다.

 

하지만 Last Sync는 여전히 마지막으로 Sync를 맞춘 Revision에 대한 정보를 나타내고 있다.

 

여기서 의문이 들 수 있다.

 

분명 Sync Policy를 Automatic으로 설정하지 않았는가?

 

왜 바로 안바뀌는 것일까?

 

이 부분에서 좀 헤맸었는데, 정답은 ArgoCD에서 정해놓은 임의의 delay에 있었다.

 

https://argo-cd.readthedocs.io/en/stable/user-guide/auto_sync/

Automated Sync Policy - Argo CD - Declarative GitOps CD for Kubernetes

공식 문서를 읽다보면 맨 아래에 최대 3분 가까이 delay될 수 있도록 default 값이 설정되어 있다고 한다.

 

즉, Manifest Repo의 Head Revision이 업데이트 되어도 최대 3분동안 Sync가 안될수 있는 상황이다.

 

이를 어떻게 해결할 수 있을까?

 

Sync Webhook

ArgoCD의 ConfigMap의 delay를 수정하는 방법도 있겠지만, 시도해 보지 않았다.

 

이유는 delay를 0으로 설정하게 된다면 쓸데 없는 Polling에 자원이 낭비될 것 같았기 때문이다.

 

아마 default값이 0이 아닌 이유도 이와 같을 것이다.

 

따라서 Polling 방식이 아닌 Push 방식으로 효율적인 배포가 일어나는 방법을 생각했다.

 

다행히 Webhook으로 Sync를 Trigger 하는 방법에 대해 공식문서에서 설명을 적어놓았다.

 

https://argo-cd.readthedocs.io/en/stable/operator-manual/webhook/

Git Webhook Configuration - Argo CD - Declarative GitOps CD for Kubernetes

 

이전 Jenkins Webhook과 비슷하게 URL만 잘 지정해주면 된다.

 

이렇게 Webhook을 설정하고 난 다음 다시 Push를 하니 성공적으로 delay 없이 바로 Sync가 되었다.

 

Slack 연동

이렇게 ArgoCD까지 설정하여 자동화된 CI / CD 파이프라인을 구축하였으나,

 

코드 Push -> 빌드 -> 배포 까지 약 3~4분정도 걸리는 시간동안 진행 현황을 매번 확인하기 귀찮았다.

 

상세한 진행 현황까지는 아니더라도 빌드와 배포가 됐을 때

 

Revision, 성공/실패 여부 정도만 Slack을 통해 받아보고 싶었다.

 

ArgoCD와 Slack을 연동하기 위해, 관련 정보를 찾아보다가

 

원래는 Notification 패키지가 따로 있어 추가적으로 설치를 해주어야 했지만,

 

최근에 ArgoCD 측에서 정식 패키지에 포함시켰다는 글을 보았다.

 

https://argocd-notifications.readthedocs.io/en/stable/services/slack/

Slack - Argo CD Notifications

 

혹시나 하는 마음에 3000줄이 넘는 values yaml 파일을 뒤져보았고 notification과 관련된 항목을 찾을 수 있었다.

 

Slack Token, App과 같은 설정은 위의 공식문서를 참고하였다.

 

Notification을 발생시킬 trigger를 설정한다.

다행히도 꽤나 많은 수의 템플릿들이 주석 처리 되어있었고, 이중 원하는것만을 주석 해제한 다음,

 

helm upgrade를 진행하였다.

 

그 결과, 빌드와 배포가 일어날 때 마다 메세지를 받아볼 수 있었다.

 

Jenkins

Jenkins는 Helm을 통해 설정하지 않고 Jenkinsfile 내에 코드를 삽입했다.

ArgoCD

 

 

최종 CI / CD 파이프라인

 

1. 백엔드 개발자는 각 서비스 Repo의 dev 브랜치로 push 한다.

 

2. 각 서비스 Repo별 Webhook이 발생 된다.

 

3. 미리 정의한 Jenkins Pipeline을 진행 하며 (CI), 빌드의 결과물로 생성되는 yaml 파일로 Swagger OAS를 수정한다.

 

4. AWS ECR에 새롭게 변경된 Tag를 가진 이미지를 push 한다.

 

5. 새롭게 변경된 Tag를 기준으로 Helm chart Manifest 수정 및 push 하낟.

 

6. Helm chart Repo Webhook이 발생 된다.

 

7. ArgoCD는 변경된 Manifest를 기준으로 Sync Application 과정을 수행한다. (CD)