Argo CD Intro: how to deploy an app with Argo CD
최근에 사내에서 Argo CD를 새로운 CD tool(Continuous Deployment)로서 도입하는 것이 진행 중이다. 기존에 사용하고 있던 CD tool은 Spinnaker인데, 일부 불편한 점들이 있었다. Argo CD 사용법에 대해 알아보고 기존 Spinnaker 사용 경험 대비 어떤 점이 개선되었는지 비교해보려 한다.
Intro
Argo Workflow라는 것도 있는데, Argo CD와 혼동하지 말자.
Argo CD Installation(Set up)은 사내 DevOps 엔지니어 분께서 진행해주셨기 때문에, 본 포스트에서는 다루지 않는다. 설치된 Argo CD에서 UI를 통해 Argo CD Application을 배포하는 기초적인 방법에 집중한다.
Overview
본 포스트의 내용은 아래 Argo CD 공식 문서를 기반으로 작성되었다.
What is Argo CD
- Kubernetes CD tool (K8s를 위한 CD tool)
- Delarative (선언적 방법을 사용함)
- GitOps (Git repo를 source of truth로 사용함)
Why Argo CD
- App 정의, 설정, 환경은 delarative해야 함 & 버전 관리 되어야 함
- App 배포 & 라이프 사이클 관리는 자동화, auditable, 이해하기 쉬워야 함
Argo CD를 사용하면 이러한 방식으로 Application을 배포 및 운영할 수 있다는의미
Argo CD 배포 방법
K8s namespace(e.g. argocd)에 Argo CD 리소스들을 배포함
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yamlHow it works
GitOps
- Git repo를 source of truth로 함
- 원하는 app state를 정의함
K8s manifest 명세 방식
- kustomize
- helm
- ksonnet
- jsonnet
- Plain directory of yaml/json manifests
- custom plugin
우리 회사는 Helm을 사용하여 K8s resource들을 정의하고 있다
Automated deployment
- App deployment는 git branch 등의 업데이트를 track할 수 있음
Architecture
- Argo CD는 K8s controller로서 구현됨
- 실행 중인 App들을 모니터링 & 상태 비교 (current vs desired)
K8s Controller: https://kubernetes.io/ko/docs/concepts/architecture/controller/
K8s controller는 cluster를 watch & cluster의 상태를 desired state에 가깝게 만듬
- desired state를 벗어난 App은 OutOfSync로 취급됨
- curent vs desired state의 차이는 시각화되어 보여짐
- App을 desired state로 자동 또는 수동으로 sync할 수 있는 기능들을 제공함
- Git repo에서 desired state의 어떤 변경이든 자동으로 적용될 수 있음
Core Concepts
이 부분은 공식 문서에 이미 간결하게 정리되어 있어서, 아래 링크로 대체한다.
User Guide
Projects
Argo CD Web UI에서 Application을 생성할 때, application을 생성할 project를 지정해야 한다.
project는 application들의 묶음이며, 여러 팀들이 Argo CD를 사용할 때 유용하다.
project는 아래 기능들을 제공한다
- 어떤 git source로부터 배포할 수 있는지 제한
- 어느 k8s cluster 또는 namespace로 배포할 수 있는지 제한
- 어떤 종류의 object가 배포될 수 있는지 제한 (e.g. RBAC, CRDs, …)
- Project role을정의하고 application RBAC를 제공
예를 들어, A application을 생성하고 이를 B project에 할당할 수 있다.
이 경우 A application은 B project에 설정된 git source와 k8s cluster, ns 그리고 k8s object만을 사용하여 배포할 수 있다.
처음에는 default project에 App을 생성하면 된다.
여기서 말하는 Application이라는 것은 Argo CD에서 정의한 K8s CRD이다. (Core concepts 문서에 나와있듯이)
App 생성 시 project에 설정되지 않은 값을 사용할 경우 아래와 같은 에러 메시지를 확인할 수 있다
Hands On
Argo CD에 Web UI로 접근해서 App을 생성 및 배포해보자.
우리 회사의 경우, 회사 오피스 IP 또는 VPN을 통해서만 argocd web에 접근할수 있으며, Keycloak을 통해 로그인할 수 있다.
Argo CD에 로그인한 후 좌측 상단의 Create App 버튼을 누르면 아래와 같은 창을 볼 수 있다
- App name: 자유롭게 지정하면 된다
- Project: default project를 사용하면 된다
- Sync policy: 처음에는 manual로 두면 된다. 이 기능을 통해 git push hook을 통해 automated deployment를 설정할 수 있다.
- Source: GitHub repository를 사용하였다. repo 내에서 Helm chart directory를 path로 지정하였다.
사내 repository는 private이므로, 접근하려면 인증이 필요하다. 우리는 credential template을 통해 설정하였다.
- Destination: Argo CD App을 배포할 k8s cluster 및 namespace를 설정한다.
현재 cluster에 배포하기 위해 다음 값으로 지정하였다: https://kubernetes.default.svc
- Directory: source가 helm chart일 경우 helm으로 변경해준다. 그러면 helm override values를 지정할 수 있는 UI를 볼 수 있다.
Helm chart override values까지 적절히 설정해주고 App을 생성하였다.
Argo CD App을 생성한 후에는 Sync를 통해 App을 배포할 수 있다.
단, app을 배포할 ns를 생성 및 istio-injection 라벨링 등을 먼저 해줘야 한다. App 생성 시 auto-create namespace 옵션이 존재하긴 하지만 라벨링은 할 수 없는 듯하다.
PreSync를 활용하면 가능하지 않을까 싶긴 한데, 아직 PoC해보지 못한 상태이다.
여차저차, K8s ns 생성 및 label까지 해주고, Argo CD UI에서 Sync App을 실행시켜주면, Tree 형식으로 시각화된 App 내의 k8s resource들을 확인할 수 있다.
Sync가 실패하면 sync failed 메시지를 볼 수 있고, 성공하면 sync success 메시지를 볼 수 있다. sync 후 배포된 application의 live state가 desired state와 다르다면 OutOfSync 상태가 될 것이다.
GitOps for values
Web UI에서 설정하는 Helm override values는 Git으로 관리되지 않으며, change history를 tracking할 수 없다.
Argo CD Application manifest 자체를 Git에서 관리하는 방법을 통해 위 문제를 해결할 수 있다.
Spinnaker over Argo CD
이제 Spinnaker 사용 경험과 Argo CD를 비교해보자.
GitOps
우선 기존에 Spinnaker 사용 시에 pipeline에서 사용하는 Helm chart 버전 관리 및 override values 관리가 제대로 되지 않았다.
S3에 업로드된 특정 version의 Helm chart tgz 파일을 가져오는 방식으로 pipeline이 구성되었기 때문인데, S3가 아니라 Git repo로부터 가져오도록 설정할 수도 있었다.
확인해보니 Helm chart 및 value artifact 둘다 Git으로부터 가져올 수 있었다.
즉, Spinnaker도 Argo CD에서 강조하는, GitOps 환경을 셋업할 수 있다.
하지만 Argo CD에서는 이러한 차트 버전 또는 values 변경으로 인해 발생하는 app diff를 보여주기 때문에, Argo CD에게 +1점을 주었다.
Pipeline failed Error Message
Spinnaker pipeline에서 배포 실패 시, 굉장한 에러 메시지들이 나온다.
DevOps 측면에서 CD tool을 제공할 때, 서버 개발자들이 배포 파이프라인에 대한 이해 없이도 배포가 가능하기를 기대한다. 하지만 Spinnaker 배포 시 발생하는 에러 메세지는 스스로 해결하기에 너무 어려웠다. (DevOps 엔지니어 조차도 파악하기 어려웠다. 즉, 직관적이지 않았다.)
Argo CD는 아직 많이 사용해보지 않았지만, 지금까지 확인한 error message들은 대부분 직관적이어서 파악하기 쉬웠다.
비직관적인 Pipeline parameter
Argo CD와 달리, Spinnaker는 pipeline 실행 시에 parameter를 설정할 수 있었다.
그런데 이 parameter의 설정이 또 꽤나 복잡해서, 사용되지 않는 parameter도 존재했다.
차라리 별도 parameter 없이 Git repo에서만 설정값을 관리하는 Argo CD가 더 나아 보였다. 다시 Argo CD +1점.
Conclusion
본 포스트에서는 Argo CD 공식 문서에 나와있는 기본적인 내용들을 읽어보고, Argo CD에서 App을 생성 및 배포하는 방법에 대해서 알아 보았다.
기존에 사용하던 Spinnaker 사용 경험과 Argo CD도 비교해보았다.
Spinnaker도 유용한 툴이지만, 우리 회사의 현재 상황에서는 Argo CD가 더 사용하기 편리할 듯하다. (이제 사용해봐야 겠지만)
