[Kubernetes] Deploy Tool(Feat. ArgoCD)

안녕하세요? 정리하는 개발자 워니즈입니다. 이번시간에는 Kubernetes Deploy Tool에 대해서 알아보고, 필자가 속한 프로젝트에서는 어떤 구성으로 진행을 하고 있는지를 정리해보고자합니다.

지난 글들은 아래를 참고 해주시면 됩니다.

• 쿠버네티스 1편 : 설치 가이드
• 쿠버네티스 2편 : pod
• 쿠버네티스 3편 : service
• 쿠버네티스 4편 : deployment
• 쿠버네티스 5편 : pod 설정
• 쿠버네티스 6편 : 배포 전략
• 쿠버네티스 7편 : volume
• 쿠버네티스 8편 : daemonset
• 쿠버네티스 9편 : 테라폼을 통한 클러스터 구성
• 쿠버네티스 10편 : eks에서 volume 사용하기
• 쿠버네티스 11편 : helm
• 쿠버네티스 12편 : helm chart template
• 쿠버네티스 13편 : helm deploy
• 쿠버네티스 14편 : fluentd를 통한 log수집
• 쿠버네티스 15편 : chartmuseum
• 쿠버네티스 16편 : 배포툴(ArgoCD 설치방법/사용법)
• 쿠버네티스 17편 : 배포툴(ArgoCD 구성/알람)
• 쿠버네티스 18편 : 쿠버네티스 Autoscailing
• 쿠버네티스 19편 : 쿠버네티스 로깅 아키텍처

우선 kubernetes에는 여러가지 Deploy Tool이 존재합니다. 가장 많이 들어봤을 법한 것이 Spinnaker 일 것입니다. 필자도 예전부터 굉장히 익숙하게 들어왔었고, 특히 넷플릭스에서 만들어 사용하다보니까 Container쪽에서는 Deploy Tool로 자리를 잡아가는 것으로 보였습니다 .

그럼 개별적으로 어떠한 특징이 있고, 필자는 왜 ArgoCD를 사용하게 되었는지의 순서대로 정리를 해보도록 하겠습니다.

1. Spinnaker vs. Argo CD

우선 2개의 대표적인 k8s의 Deploy 툴에 대해서 정리를 하도록 하겠습니다. 사실 뭘 하든 직접 써보고 겪어봐야 장점/단점이 느껴지긴 할것 같습니다. 필자는 최근에 spinnaker를 직접 helm chart를 이용해서 설치하는데 도저히 가이드대로 진행을 해도 안되길래… 포기를 했었습니다.

그러다가 찾아보니 단점에 다소 무거움 이 있어가지고.. 실제로 무겁기도 하고 서비스가 잘 올라오지도 않습니다.

그래서 좀더 light 한것을 찾게 되었고, ArgoCD가 적합하다고 느꼇습니다.

1-1. Spinnaker

장점

• Multi-Cloud용 Continuous Delivery/Deployment Platform
• 다양한 pipeline 형태로 배포가 가능하고 Rollback이 쉬움
• 빠른 배포가 가능
• 여러번 배포가 용이
• 유연한 pipeline management system을 가지고 있음
• 다양한 배포전략 (Blue-Green, Rolling Red/Black, Canary)
• community 활동 활발 (github, slack)
• VM과 Container 동시에 통합관리 가능
• CI통합 용이(Jenkins)
• CLI를 통한 설치 및 관리(halyard)
• VM, Helm Packaging 가능
• RBAC(역할기반접근통제) 지원
• Notification – Email, Slack, Hipchat등
• Safe Deployment – Judgement (승인기능)

단점

• 러닝커브가 좀 있음.
• 다소 무거움
• 작은 규모 서비스에는 적합하지 X

1-2. Argo CD

Argo CD를 설명하기 앞서서 GitOps의 개념에 대해서 설명을 하겠습니다.

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

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

즉, git(단하나의 원천이자 진실)의 내용과 유기적으로 sync를 맞추면서 변경사항이 있으면, 표기를 해주고 현재의 sync가 맞다면 정상 상태를 표현해주는 방식입니다.

장점

• 현재 배포환경의 상태를 쉽게 파악할 수 있습니다. 배포환경에 들어가서 상태를 파악할 필요 없이 원천(배포 작업서)만 살펴보면 되기 때문입니다.
• 빠르게 배포할 수 있게 됩니다. 단일한 방법으로 소프트웨어를 배포하여 표준화 시켰기 때문에 쉽게 배포 자동화를 할 수 있고 이것은 더 빠르고 지속적인 배포를 가능케 합니다.
• 안정적으로 운영 환경에 배포할 수 있습니다. 사람의 손을 거치지 않기 때문에 운영 반영에 발생할 수 있는 human error를 최소화 할 수 있습니다. 배포를 관장하는 사람은 원천의 상태만 잘 확인하면 됩니다.

단점

• 복합적인 배포 ( bluen/gree, canary 배포 등)에 대해서 지원을 하지 않습니다.
• 대규모 멀티 클라우드 환경에서는 적합하지 X

2. 설치 방법

AWS EKS 클러스터 내부에 ArogoCD를 세팅하는 방법에 대해서 정리를 해보도록 하겠습니다.

설치방법은 꽤나 간단합니다. 이미 각 resource별로 정리가 되어있는, yaml 파일을 다운받아다가 설치만 진행하면됩니다.

• 설치

# argocd 네임스페이스 생성 
$ kubectl create namespace argocd

# Argo CD 배포
$ kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# 설치하고 나면, https만을 지원하는 것으로 되어있다. (불필요시 insecure모드로 진행합니다.)
# argocd-server의 deployment 파일 내에 아래 내용중 - --insecure추가
# 다시 argocd-server의 deployment만 재배포 
    spec:
      containers:
      - command:
        - argocd-server
        - --staticassets
        - /shared/app
        - --insecure

# Argo CD API Server에서 외부 통신을 할 수 있도록 Argo CD의 Service의 Type을 Load Balancer로 변경(AWS에서는 Classic Load Balancer로 배포됨)
$ kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}'

• Admin 패스워드 변경

#argocd CLI 설치 
curl -LO https://github.com/argoproj/argo-cd/releases/download/v1.4.2/argocd-linux-amd64
chmod u+x argocd-linux-amd64
sudo mv argocd-linux-amd64 /usr/local/bin/argocd

#path에 명령어 사용가능하도록 변경
export PATH=/usr/local/bin:$PATH
echo 'export PATH=/usr/local/bin:$PATH' >> ~/.bashrc

#설치 확인을 위해 argocd 명령어 실행
$ argocd
argocd controls a Argo CD server

#비번 변경을 위해 로그인을 해줍니다.
$ argocd login 
$ argocd login a34488e9daa2a11ea8a77020f569fbb4-1162222955.us-east-1.elb.amazonaws.com
WARNING: server is not configured with TLS. Proceed (y/n)? y
Username: admin
Password: 
'admin' logged in successfully


#argoCD CLI를 통한 비밀번호 변경
ARGOCD_SERVER=`kubectl get pods -n argocd -l app.kubernetes.io/name=argocd-server -o name | cut -d'/' -f 2` 
ARGOCD_SERVER_HOST=`kubectl get svc argocd-server -o json -n argocd | jq -r '.status.loadBalancer.ingress[0].hostname'`

# Argo CD 비밀번호 변경
$ argocd account update-password
*** Enter current password: # ARGOCD_SERVER와 동일
*** Enter new password: # 변경할 비밀번호 입력
*** Confirm new password: # 변경할 비밀번호 재입력(확인)

• 접속 테스트

#신규로 생성된 elb의 CNAME으로 접속을 함. 
$ kubectl get svc argocd-server -n argocd -o json | jq -r '.status.loadBalancer.ingress[0].hostname'

3. 사용 방법

argoCD를 설치까지 했으니, 이번에는 간단한 사용법에 대해서 정리를 해보도록 하겠습니다.

다음의 순서대로만 진행을 하면 사용하는 cluster내에서 helm chart를 손쉽게 배포할 수 있습니다.

• 원격 저장소 지정

원격 저장소(git)에 저장되어있는 helm chart를 불러옵니다. 필자 같은 경우는 특정 프로젝트 하위로 사용하는 모든 helm chart를 저장하고 있습니다.

위의 그림과 같이 셋팅을 해두었었고, argoCD web 페이지에 접속해서는 다음과 같이 셋팅을 해야합니다.

repositories를 클릭해서 셋팅을 진행해 줍니다.

위와 같이 셋팅을 완료하면, 아래와 같이 연결된 상태가 노출이 됩니다.

• Application 생성

이제 본격적으로 Application 을 생성해보도록 하겠습니다. argoCD를 적용해보니, 여기서 말하는 Application의 개념은 배포할 한개의 Helm chart를 의미합니다. 그럼 배포할 헬름챠트를 셋팅해두겠습니다.

[Create Application]을 클릭합니다.

클릭 한 뒤, 아래와 같은 내용을 입력합니다.

상위의 Application Name, Project, 하단부에 in-cluster, namespaces도 있는데 이부분은 알맞게 셋팅을 합니다.

최종적으로 셋팅을 완료하면 아래와 같이 Application이 생성이 되어있고, OutOfSync라고 노출이 됩니다.

• Synchronizing

이제 git과 연동이 되어있으니, sync만 맞추어 주면, 정상적으로 gitops가 진행이 됩니다. git과 지속적으로 상태를 체크하면서 sync를 맞추는 작업(배포)가 진행이 됩니다.

상단의 sync 버튼을 눌러도되고, 해당 Application을 클릭해서 접속해서 sync버튼을 눌러도됩니다.

버튼을 누르게 되면 우측에 화면이 노출되면서, 실 작업이 진행이 됩니다.

4. 마치며…

여러가지 툴에 대해서 조사를 하고 알아보았지만, argoCD 처럼 간단하게 사용할 수 있는 툴이 없었던것 같습니다. 우선 필자가 속한 프로젝트에서는 단순하게 미들웨어를 컨테이너에 넣고 pod으로 배포해주는 작업(roling update)을 진행하는데요. 이런부분에서 간단한 작업 처리에 argoCD가 제격이라고 생각했습니다.

다음이시간에는 argoCD를 jenkins와 연계해서 배포까지 진행하는 작업을 포스팅해보도록 하겠습니다.