GitOps와 ArgoCD

이번 포스팅에서는 GitOps가 무엇인가에 대해서 알아보고 그 구현체인 ArgoCD에 대해서 알아보겠습니다.

GitOps

GitOps란 Weaveworks라는 회사에서 처음 쓰기 시작하였고 CI/CD 파이프라인 중 특별히 Delivery에 초점을 가지고 탄생한 개념입니다.

GitOps을 설명하기 전에 “Single source of truth” (SSOT), 직역하자면 단일 진실의 원천에 대해서 먼저 짚고 넘어가면 좋을 것 같습니다. 단일 진실의 원천을 풀어서 설명하자면, 어떠한 진실(결과)의 원인이 오직 단일한 원천(이유)에서 나왔다는 것을 의미합니다.
이것을 소프트웨어 Delivery (Deployment)에 적용해 보겠습니다.

단일한 방법으로의 소프트웨어 배포

우리가 어떤 소프트웨어를 개발하여 그것을 운영 환경에 반영할때 다양한 방법을 통해서 배포할 수 있습니다.
예를 들어, 자바 WAR 파일을 운영 환경의 Tomcat 서버에 배포를 한다고 했을 때, scp를 이용하여 파일을 배포할 수도 있고 S3에 파일을 올려놓고 운영 서버에서 그것을 다운 받을 수도 있습니다. 조금 더 체계적으로 배포를 하고 싶으면 ansible이나 chef 같은 툴을 이용하여 소프트웨어를 배포할 수도 있습니다.
소프트웨어를 배포 방법하는 방법이 다양하면 쉽게 문제가 발생할 소지가 많아지게 됩니다. 사람마다 배포하는 방법이 달라 human error가 증가하게 될 수 있고 다양한 배포 방법이 서로 충돌할 여지가 생길 수 있습니다.

이러한 문제 때문에 GitOps에서는 소프트웨어 배포 과정을 조금 더 체계적으로 관리하고 자동화하기 위해 모든 배포 정의를 한 곳에서 관리하고 오직 한가지 방법으로 배포하는 것을 추구합니다.

항상 원천의 상태를 완벽히 반영하는 배포

GitOps에서는 배포상태의 모습을 항상 원천과 동일하게 맞출려고 노력합니다.

“단일 진실의 원천” 방법을 통해 얻을 수 있는 장점

현재 배포환경의 상태를 쉽게 파악할 수 있습니다.

배포환경에 들어가서 상태를 파악할 필요 없이 원천(배포 작업서)만 살펴보면 되기 때문입니다.

빠르게 배포할 수 있게 됩니다.

단일한 방법으로 소프트웨어를 배포하여 표준화 시켰기 때문에 쉽게 배포 자동화를 할 수 있고 이것은 더 빠르고 지속적인 배포를 가능케 합니다.

안정적으로 운영 환경에 배포할 수 있습니다.

사람의 손을 거치지 않기 때문에 운영 반영에 발생할 수 있는 human error를 최소화 할 수 있습니다. 배포를 관장하는 사람은 원천의 상태만 잘 확인하면 됩니다.

지금까지 SSOT, 단일 진실의 원천에 대해서 설명 드렸는데 GitOps에서는 이름에서 알 수 있듯이 > Git 저장소를 (단일 진실의) “원천”으로 사용합니다.

GitOps에서는 소프트웨어를 배포할 때, Git 저장소에 배포를 위한 작업 정의서를 기술하여 repository에 저장하면 GitOps의 구현체가 (이 글에서는 ArgoCD가) 배포상태를 원천과 맞추기 위해 Git repository에 저장된 배포 정의서를 읽어와서 운영 환경에 변경 사항을 반영합니다.

특히 쿠버네티스와 같이 선언형 (declarative description) 명령와 같은 배포 형태인 경우, Git 저장소에 원하는 배포 형태를 선언하기만 하면 그것을 운영에 반영하는 것은 굉장히 쉽습니다.

GitOps Pipeline

GitOps의 핵심은 Git 저장소에 저장된 쿠버네티스 매니페스트 같은 파일을 이용하여, 배포를 선언적으로 한다는 것입니다. 즉, Git에 저장된 매니페스트가 쿠버네티스 클러스터에도 똑같이 반영된다는 것입니다.

GitOps의 구현체 ArgoCD

GitOps는 특정 소프트웨어나 프로덕트가 아닌 철학 혹은 방법론에 더 가깝습니다.

GitOps에서 요구하는 원칙

1. 선언형 배포 작업 정의서

배포 방법이 명령형 방식으로 정의된 것이 아니라 배포된 상태가 어떤 모양을 가져야 할지 선언되어 있는 방식으로 정의가 되어 있어야 합니다.
이것은 사용자가 배포의 원하는 상태 (desired state)를 선언적으로 정의하였다는 것을 의미합니다. 이를 통해 Git 저장소에 단일 진실의 원천 조건을 만족할 수 있습니다. 배포 작업 정의서가 선언형으로 되어 있으면 더 쉽게 배포할 수 있으며 문제 발생시, 롤백하기도 쉽습니다. 또한 장애 등으로 인해 손상된 배포 환경을 자가 치유하기 유리합니다.

2. Git을 이용한 배포 버전 관리

Git에 모든 배포에 관련된 정보가 정의되어 있어야 하며, 각 버전이 Git 저장소에 기록이 되어 있어야 합니다. 이를 통해 사용자는 쉽게 예전 버전으로 롤백을 하거나 새로운 버전으로 업그레이드를 할 수 있게 됩니다.

3. 변경 사항 운영 반영 자동화

사용자는 Git 저장소에 선언형 정의서를 저장하게 되면 실제 배포가 일어나는 작업은 자동으로 이루어져야 합니다. 이것을 책임지는 주체가 ArgoCD와 같은 배포 주체(deploy operator)가 됩니다. 이를 통해 human error를 줄이고 지속적 빌드/배포를 가능하게 만듭니다.

4. 자가 치유 및 이상 탐지

사용자가 원하는 배포 상태 (desired state)를 작성하게 되면 실제 배포 환경이 그에 맞게 유지되고 있는지 책임지는 것 또한 배포 주체(deploy operator)가 됩니다. 배포를 관장하는 소프트웨어가 주체가 되어 현재 배포 상태를 확인하고 Git 저장소의 변경 사항 등이 없는지를 체크하여 운영 환경에 반영하는 역할을 합니다.

이러한 원칙들을 가지고 소프트웨어를 배포하는 모든 Agent를 우리는 GitOps의 구현체 (Deploy Operator)라 부를 수 있습니다. 현재 GitOps의 구현체로 ArgoCD 뿐만 아니라 Weaveworks flux, Codefresh, Jenkins X 등 다양한 소프트웨어들이 존재합니다.

ArgoCD 사용하기

1. 아르고 CD 설치

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

그러면 argocdArgo CD 서비스 및 애플리케이션 리소스가 위치할 새 네임스페이스가 생성됩니다.

설치 매니페스트에는 네임스페이스 ClusterRoleBinding를 참조하는 리소스가 포함됩니다 argocd. Argo CD를 다른 네임스페이스에 설치하는 경우 네임스페이스 참조를 업데이트해야 합니다.

UI, SSO, 다중 클러스터 기능에 관심이 없다면 핵심 Argo CD 구성 요소만 설치할 수 있습니다.

CLI 액세스 argocd login --core를 구성 하고 3-5단계를 건너뛰는 데 사용 합니다.

2. 아르고 CD CLI 다운로드

https://github.com/argoproj/argo-cd/releases/latest 에서 최신 Argo CD 버전을 다운로드 하십시오 . 자세한 설치 지침은 CLI 설치 설명서 를 통해 찾을 수 있습니다 .

Mac, Linux 및 WSL Homebrew에서도 사용 가능:

brew install argocd

3. Argo CD API 서버에 액세스

기본적으로 Argo CD API 서버는 외부 IP로 노출되지 않습니다. API 서버에 액세스하려면 다음 기술 중 하나를 선택하여 Argo CD API 서버를 노출합니다.

• 서비스 유형 로드 밸런서
  argocd-server 서비스 유형을 LoadBalancer다음 으로 변경하십시오.

kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}'

• 포트 포워딩
  Kubectl 포트 포워딩을 사용하여 서비스를 노출하지 않고 API 서버에 연결할 수도 있습니다.

kubectl port-forward svc/argocd-server -n argocd 8080:443

그런 다음 https://localhost:8080을 사용하여 API 서버에 액세스할 수 있습니다.

혹은 노드 포트로 변경할것!

k edit svc argocd-server -n argocd

Argo CD CLI 설치

argocd cli 설치
(argocd 버전) https://github.com/argoproj/argo-cd/releases

$ VERSION=v2.4.4; curl -sL -o argocd https://github.com/argoproj/argo-cd/releases/download/$VERSION/argocd-linux-amd64
$ chmod +x argocd
$ sudo mv argocd /usr/local/bin/argocd

4. 로그인방법

ID : admin
pass: 암호화로 되어있을겁니다.
암호 변경은 4-1을 참조하세요

계정 의 초기 비밀번호 는 자동 생성되어 Argo CD 설치 네임스페이스에 이름이 지정된 비밀 admin필드에 일반 텍스트로 저장됩니다 . 다음을 사용하여 이 비밀번호를 간단히 검색할 수 있습니다 .passwordargocd-initial-admin-secretkubectl

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d; echo

argocd-initial-admin-secret암호를 변경한 후에는 Argo CD 네임스페이스에서 삭제해야 합니다. 비밀은 초기에 생성된 암호를 명확하게 저장하고 언제든지 안전하게 삭제할 수 있는 것 외에 다른 용도로 사용되지 않습니다. 새 관리자 암호를 다시 생성해야 하는 경우 Argo CD에서 요청 시 다시 생성됩니다.

4-1. 위 의 사용자 이름 admin과 암호를 사용하여 Argo CD의 IP 또는 호스트 이름에 로그인합니다.

#argocd login IP
 argocd account update-password
 
 argocd login 192.168.100.10
WARNING: server certificate had error: x509: cannot validate certificate for 10.96.178.5 because it doesn't contain any IP SANs. Proceed insecurely (y/n)? y
Username: admin
Password: **9pZFe4FQVrTTNLHX**

CLI 환경은 Argo CD API 서버와 통신할 수 있어야 합니다.
위의 3단계에서 설명한 대로 직접 액세스할 수 없는 경우 다음 메커니즘 중 하나를 통해 포트 전달을 사용하여 액세스하도록 CLI에 지시할 수 있습니다.
1) --port-forward-namespace argocd 모든 CLI 명령에 플래그를 추가합니다.
또는
2) ARGOCD_OPTS환경 변수 설정: export ARGOCD_OPTS='--port-forward-namespace argocd'.

다음 명령을 사용하여 암호를 변경합니다.

argocd account update-password

5. 앱을 배포할 클러스터 등록 (선택 사항)

이 단계는 클러스터의 자격 증명을 Argo CD에 등록하며 외부 클러스터에 배포할 때만 필요합니다.
Argo CD가 실행 중인 동일한 클러스터에 내부적으로 배포할 때 https://kubernetes.default.svc를 애플리케이션의 K8s API 서버 주소로 사용해야 합니다.

먼저 현재 kubeconfig의 모든 클러스터 컨텍스트를 나열합니다.

kubectl config get-contexts -o name

목록에서 컨텍스트 이름을 선택하고 에 제공하십시오 argocd cluster add CONTEXTNAME. 예를 들어 docker-desktop 컨텍스트의 경우 다음을 실행합니다.

argocd cluster add docker-desktop

argocd-manager위의 명령 은 해당 kubectl 컨텍스트의 kube-system 네임스페이스에 ServiceAccount( )를 설치하고 서비스 계정을 관리자 수준 ClusterRole에 바인딩합니다. Argo CD는 이 서비스 계정 토큰을 사용하여 관리 작업(예: 배포/모니터링)을 수행합니다.

역할 의 규칙은 제한된 이름 공간 , 그룹 , 종류 집합 에 대한 권한 argocd-manager-role만 갖도록 수정할 수 있습니다 . 그러나 Argo CD 가 작동하려면 클러스터 범위 에서 권한이 필요합니다.

6. Git 리포지토리에서 애플리케이션 생성

Argo CD의 작동 방식을 보여주기 위해 방명록 애플리케이션이 포함된 예제 저장소가 https://github.com/argoproj/argocd-example-apps.git 에서 제공됩니다.

CLI를 통해 앱 만들기

다음 명령을 사용하여 예제 방명록 애플리케이션을 만듭니다.

argocd app create guestbook --repo https://github.com/argoproj/argocd-example-apps.git --path guestbook --dest-server https://kubernetes.default.svc --dest-namespace default

UI를 통해 앱 만들기

Argo CD 외부 UI에 대한 브라우저를 열고 브라우저에서 IP/호스트 이름을 방문하여 로그인하고 4단계에서 설정한 자격 증명을 사용합니다.

로그인 후 아래와 같이 + New App 버튼을 클릭합니다.

앱에 이름 guestbook을 지정하고 프로젝트를 사용 하고 동기화 정책을 다음 default과 같이 Manual로 둡니다.

리포지토리 URL을 github repo url로 설정 하여 https://github.com/argoproj/argocd-example-apps.git repo를 Argo CD에 연결하고 개정판을 그대로 두고 HEAD경로를 guestbook다음 으로 설정합니다.

Destination 의 경우 클러스터 URL을 https://kubernetes.default.svc (또는 in-cluster클러스터 이름의 경우)로 설정하고 네임스페이스를 default다음 으로 설정합니다.

위의 정보를 입력한 후 UI 상단의 Create guestbook 를 클릭하여 애플리케이션을 생성합니다.

7. 애플리케이션 동기화(배포)

CLI를 통한 동기화

방명록 애플리케이션이 생성되면 이제 상태를 볼 수 있습니다.

$ argocd app get guestbook
Name:               guestbook
Server:             https://kubernetes.default.svc
Namespace:          default
URL:                https://10.97.164.88/applications/guestbook
Repo:               https://github.com/argoproj/argocd-example-apps.git
Target:
Path:               guestbook
Sync Policy:        <none>
Sync Status:        OutOfSync from  (1ff8a67)
Health Status:      Missing

GROUP  KIND        NAMESPACE  NAME          STATUS     HEALTH
apps   Deployment  default    guestbook-ui  OutOfSync  Missing
       Service     default    guestbook-ui  OutOfSync  Missing

OutOfSync 애플리케이션 상태는 애플리케이션이 아직 배포되지 않았으며 Kubernetes 리소스가 생성되지 않았기 때문에 초기 상태입니다.
애플리케이션을 동기화(배포)하려면 다음을 실행합니다.

argocd app sync guestbook

이 명령은 저장소에서 매니페스트를 검색하고 매니페스트를 수행합니다
이제 방명록 앱이 실행 중이며 이제 해당 리소스 구성 요소, 로그, 이벤트 및 평가된 상태를 볼 수 있습니다.

UI를 통한 동기화

# argocd app create dev-project --repo https://github.com/tommypagychoi/argocd-demo.git --path kustomize-demo --dest-server https://kubernetes.default.svc --dest-namespace dev

참조
https://argo-cd.readthedocs.io/en/stable/getting_started/
https://coffeewhale.com/kubernetes/gitops/argocd/2020/02/10/gitops-argocd/
https://tommypagy.tistory.com/363