Argo Project를 사용하여 CI/CD 구축하기

졸업 프로젝트를 진행하며 Spring Boot 어플리케이션에 대한 CI/CD를 구축해야하는 니즈가 있었고 다양한 도구들을 살펴보다가 쿠버네티스에 친화적인 Argo 프로젝트를 사용하였습니다. 이번 글에서는 Argo Project인 Argo Event와 Argo Workflow를 이용한 CI와 Argo CD를 이용한 CD 아키텍쳐를 구축하는 과정에 대해 다뤄보고자 합니다.

---

CI Overview

이번 글에서 구축할 CI 과정을 간략하게 소개하면 다음과 같습니다.

1. Github Webhook를 Argo Event가 받아 CI Workflow 활성화
2. 애플리케이션 단위 테스트 수행
3. 도커 이미지 빌드
4. GCR에 이미지 푸시
5. Deploy Repository의 Kustomize 파일 수정(최신 태그를 반영한 이미지)
6. Deploy Repository에 Pull Request 생성

---

Argo Event

이제 Github의 Webhook을 통해 Push Event를 받는 Argo Event를 생성해보도록 하겠습니다.

---

Argo Event Architecture

먼저 Argo Event의 아키텍쳐는 아래 그림과 같습니다.

출처 : https://argoproj.github.io/argo-events/concepts/architecture/

 

Argo Event의 컴포넌트는 다음과 같은 역할을 수행합니다.

• Event Source
  외부로부터 받을 이벤트에 대한 설정을 정의합니다.
• Eventbus
  Event Source와 Event Sensor를 연결하기 위한 전송 계층으로 동작합니다.
• Event Sensor
  event dependency의 집합과 trigger를 정의합니다. 여기서 event dependency 집합은 input, trigger는 output의 개념으로 생각하면 됩니다.
• Trigger
  Event Sensor에 의해 수행될 활동을 의미합니다.

---

Custom Resource 설치

먼저 필요한 Argo Event CR을 다운받습니다.

> kubectl apply -f \
https://raw.githubusercontent.com/argoproj/argo-events/stable/manifests/namespace-install.yaml

---

Event Bus 배포

다음으로 Event Source와 Event Sensor간의 데이터 전송을 위한 Event Bus을 배포합니다.

kubectl apply -n argo-events -f \
https://raw.githubusercontent.com/argoproj/argo-events/stable/examples/eventbus/native.yaml

---

Github Argo Event 연동

admin:repo_hook 권한을 가진 Github API 토큰을 생성하고 인코딩하여 argo-events 네임스페이스에 시크릿으로 등록합니다.

Encoding

echo -n <api-token-key> | base64

github-access

apiVersion: v1
kind: Secret
metadata:
  name: github-access
  namespace: argo-events
type: Opaque
data:
  token: <access token>
  username: <github username>
  password: <github password>

---

Event Source

argo event repo를 참고한 github event-source는 다음과 같습니다.

- event-source.yaml

apiVersion: argoproj.io/v1alpha1
kind: EventSource
metadata:
  component: github-event-source
  name: github-event-source
  namespace: argo-events
spec:
  type: "github"
  github:
    source_repo:
      # owner of the repo
      owner: seongpyoHong
      # repository name
      repository: argo-ci-cd
      # Github will send events to following port and endpoint
      webhook:
        # endpoint to listen to events on
        endpoint: /push
        # port to run internal HTTP server on
        port: "12000"
        # HTTP request method to allow. In this case, only POST requests are accepted
        method: POST
        # url the event-source will use to register at Github.
        # This url must be reachable from outside the cluster.
        # The name for the service is in `<event-source-name>-eventsource-svc` format.
        # You will need to create an Ingress or Openshift Route for the event-source service so that it can be reached from GitHub.
        url: "http://github-event-source-eventsource-svc.argo-events.svc:12000"
      # type of events to listen to.
      # following listens to everything, hence *
      # You can find more info on https://developer.github.com/v3/activity/events/types/
      events:
        - "push"

      # apiToken refers to K8s secret that stores the github api token
      apiToken:
        # Name of the K8s secret that contains the access token
        name: github-access
        # Key within the K8s secret whose corresponding value (must be base64 encoded) is access token
        key: token
      # type of the connection between event-source and Github.
      # You should set it to false to avoid man-in-the-middle and other attacks.
      insecure: true
      # Determines if notifications are sent when the webhook is triggered
      active: true
      # The media type used to serialize the payloads
      contentType: json

기존에 존재하는 Gateway라는 CR을 통해 Event Source와 Event Sensor를 연결해주는 서비스를 생성했었지만, 최신 릴리즈 버전에서는 Gateway가 event source에 포함되었기 때문에 따로 생성하지 않아도 됩니다.

 

- event-source-svc

apiVersion: v1
kind: Service
metadata:
  name: github-event-source-eventsource-svc
  namespace: argo-events
spec:
  selector:
    eventsource-name: github-event-source
  ports:
  - port: 12000
    targetPort: 12000
  type: LoadBalancer  

공식 문서를 참고하면 Github의 webhook이 접근할 수 있는 서비스를 정의해야합니다. 이를 위해 <event-source-name>-eventsource-svc 라는 이름의 service를 통해 노출합니다.

---

Event Sensor 생성

다음으로 Github Event Source를 받아서 설정된 Trigger를 수행하는 Event Sensor를 생성합니다. CI 과정을 전부 수행하기 전에 앞서 간단하게 Pod을 생성하는 trigger를 설정하여 테스트 해보도록 하겠습니다.

- Event Sensor (Pod Create)

apiVersion: argoproj.io/v1alpha1 
kind: Sensor 
metadata: 
  name: webhook 
  namespace: argo-events 
spec: 
  template: 
    serviceAccountName: argo-events-sa 
  dependencies: 
    - name: test-dep
      eventSourceName: github-event-source 
      eventName: source_repo 
  triggers: 
    - template: 
        name: webhook-pod-trigger 
        k8s: 
          group: "" 
          version: v1 
          resource: pods 
          operation: create 
          source: 
            resource: 
              apiVersion: v1 
              kind: Pod 
              metadata: 
                generateName: hello-world- 
              spec: 
                serviceAccountName: argo-events-sa 
                containers: 
                  - name: hello-container 
                    args: 
                    - "hello-world" 
                    command: 
                    - cowsay 
                    image: "docker/whalesay:latest" 
          parameters: 
            - src: 
                dependencyName: test-dep 
              dest: spec.containers.0.args.0

이제 등록한 Repository에서 event를 보내면 Event Source와 Event Sensor는 다음과 같은 로그를 보여줍니다.

 

Event Source Log

{"level":"info","ts":1604321990.023797,"logger":"argo-events.eventsource","caller":"webhook/webhook.go:187","msg":"new event received, dispatching it...","eventSourceName":"github-event-source","eventSourceType":"github","eventName":"source_repo","eventSourceName":"github-event-source","eventName":"source_repo"}

Event Sensor Log

{"level":"info","ts":1604321990.0337672,"logger":"argo-events.sensor","caller":"standard-k8s/standar-k8s.go:163","msg":"creating the object...","sensorName":"webhook"} {"level":"info","ts":1604321990.055359,"logger":"argo-events.sensor","caller":"sensors/listener.go:266","msg":"successfully processed the trigger","sensorName":"webhook","triggerName":"webhook-pod-trigger"}

---

CI를 위한 Trigger 설정

Pod을 생성하던 Trigger에서 이제 CI 작업 (Run Test, Build Docker Image, Push Image to Registry)를 수행하도록 변경해보겠습니다. 이 때, Trigger는 Argo Workflow를 활용하여 Unit Test, Docker Image Build, Docker Image Push 작업을 수행하도록 설정해보려고 합니다.

Why Argo Workflow?

CI에 사용되는 Argo Workflow는 이런 장점들을 가지고 있습니다.

1. 각 단계의 Job이 서로 다른 컨테이너에서 개별적으로 이루어지기 때문에, 실행 환경의 독립성이 보장됩니다.
2. 하나의 역할만을 담당하는 Job을 독립적으로 개발할 수 있고 이로 인해 재사용성을 높일 수 있습니다.

하지만, 모든 기술에 장단점이 있듯이 Argo Workflow에 대한 단점도 존재합니다.

1. 각 Job은 독립된 Pod의 생성이 필요합니다. 따라서 Pod의 생성과 삭제에 대한 오버헤드를 고려해야 합니다.
2. Job간의 데이터를 공유하기 위한 추가 Artifact가 필요합니다.

https://coffeewhale.com/kubernetes/workflow/argo/2020/02/14/argo-wf/ 글을 참고하였습니다.

---

Argo Workflow 설치

먼저 Argo Workflow 실행을 위해 필요한 CR들을 다운받습니다. 이때 namespace는 argo로 설정합니다.

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

 

이후 CI/CD 과정에서 git repository에 접근하기 위해 필요한 정보들을 secret으로 정의해줍니다.

1. source / deploy repository에 대해 ssh private key가 필요하므로 2개의 시크릿 생성합니다.- ssh-privatekey(source repo)

   apiVersion: v1
   kind: Secret
   metadata:
     name: source-key
     namespace: argo
   type: Opaque
   data:
     ssh-privatekey: <ssh private key for source repository>

   - ssh-privatekey (deploy key)
2. apiVersion: v1 kind: Secret metadata: name: deploy-key namespace: argo type: Opaque data: ssh-privatekey: <ssh private key for deploy repository>

2. repository에 push, commit, pull request를 수행하기 위한 정보를 담은 secret을 생성합니다.

• github-access
• apiVersion: v1 kind: Secret metadata: name: github-access namespace: argo-events type: Opaque data: token: <access token> username: <github username> password: <github password>

다음으로 테스트가 완료된 이미지를 GCR에 push하고, artifacts를 저장하기 위한 저장소로 GCS를 사용하기 위한 권한이 담겨있는 gcp credential secret을 생성합니다. 아래에서 google.json은 GCS와 GCR에 대한 IAM을 설정한 구글 서비스 계정의 키 파일입니다. GCP의 서비스 계정에 대해서 자세한 설명은 링크를 참고하시기 바랍니다.

> kubectl create secret generic argo-gcp --namespace=argo --from-file=google.json

---

WorkflowTemplate

workflowTemplate은 workflow를 미리 정의해놓은 리소스로 event sensor에서 가져다 쓸 수 있도록 해줍니다.

CI 과정에서 필요한 workflowTemplate을 정의하고 event sensor의 trigger에서 각 단계에 필요한 Argo Workflow를 생성하도록 수정합니다.

주의할 점

1. ClusterRole 생성
namespace-install.yaml으로 설치한 argo-event-sa 서비스 계정은 argo 네임스페이스의 리소스에 접근할 권한이 없기 때문에 clusterRoleBindind을 통해 접근 권한을 설정해줘야 합니다.

- ClusterRole & ClusterRoleBinding

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: argo-cluster-role
rules:
  - apiGroups:
      - argoproj.io
    resources:
      - workflows
      - workflowtemplates
    verbs:
      - create
      - get
      - list
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: argo-trigger
  namespace: argo
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: argo-cluster-role
subjects:
  - kind : ServiceAccount
    name: argo-events-sa
    namespace: argo-events
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: argo-trigger
  namespace: argo-events
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: argo-cluster-role
subjects:
  - kind : ServiceAccount
    name: argo-events-sa
    namespace: argo-events

2. Default Artifact 등록

Job 간에 데이터를 주고 받을 때, parameter와 artifact를 통해서 주고 받을 수 있습니다. 이 중 artifact를 이용하려면 mino, s3, gcs와 같은 object storage를 default artifact로 설정해줘야 합니다.

공식 문서를 참고한 GCS 설정은 다음과 같습니다. 저는 GCS에 대한 권한과 GCR의 권한을 모두 하나의 서비스 계정에 설정했기 때문에 GCR에 대한 secret을 생성할 때와 같은 credential을 사용했습니다.

$ kubectl edit configmap workflow-controller-configmap -n argo # assumes argo was installed in the argo namespace 
... 
data:  
  artifactRepository: |  
    gcs:  
      bucket: argo-ci-artifacts  
      endpoint: storage.googleapis.com  
      serviceAccountKeySecret:  
      name: argo-gcp  
      key: google.json

---

코드

전체 코드는 너무 길어 링크를 참조합니다.

• Event Sensor
• WorkflowTemplate

각 WorkflowTemplate에 대한 기능은 다음과 같습니다.

• git-checkout-private
  source repository를 artifact에 checkout 하고, commit id를 통해 docker image에 사용할 tag를 생성
• run-test
  이 글에서는 Spring Boot 어플리케이션을 사용했기 때문에 gradle을 통해 작성된 단위 테스트를 수행하고 모두 성공 시 jar 파일을 생성해 artifact에 저장
• build-and-push
  단위 테스트가 성공한 source repository의 dockerfile을 통해 이미지를 빌드하고 GCR에 푸시
• git-new-branch
  deploy repository에 새로운 branch 생성
• kustomize-image
  deploy repository에 있는 kustomization.yaml 파일을 위의 과정에서 푸시된 이미지를 사용하도록 태그 수정
• git-commit
  deploy repository에 변경 사항을 commit
• git-pr
  deploy repository에 Pull Request를 생성

---

Argo Server (UI)

CI를 수행한 결과를 UI로 보고싶다면 argo namespace의 argo-server를 외부로 노출시켜 접속하면 됩니다. 위의 설정을 통한 결과 화면은 다음과 같습니다.

---

Argo CD

Argo CD는 GitOps 방식을 지원하는 CD 도구입니다.

GitOps란?

GitOps란 쿠버네티스 리소스에 대한 메니페스트 저장소로 github을 사용하는 방식을 의미합니다.

출처 : https://www.weave.works/technologies/gitops/

---

SSOT

GitOps의 장점을 보기 전에 SSOT(Single Source Of Truth), 단일 진실의 원천에 대해 먼저 알아보도록 하겠습니다.

단일 진실의 원천이란 어떤 진실에 대한 원천이 단 하나만 존재한다는 의미로 GitOps는 모든 배포를 위한 정의를 Git에서 관리하여 SSOT를 따릅니다.

SSOT를 통해 얻을 수 있는 장점은 다음과 같습니다.
1. 배포를 위한 정의가 Git에 모두 존재하기 때문에 현재 상태를 파악하기 쉽습니다.
2. 배포 방법을 통일하였기 때문에 자동화가 용이하며, 여러 배포 방법을 사용했을 때 발생할 수 있는 실수가 줄어듭니다.

https://coffeewhale.com/kubernetes/workflow/argo/2020/02/14/argo-wf/ 글을 참고하였습니다.

---

GitOps의 장점?

weavework의 문서를 참고한 GitOps의 장점은 다음과 같습니다.

• 생산성 향상
  통합 피드백 제어 루프를 통한 지속적인 배포 자동화는 평균 배포 시간을 단축할 수 있습니다.
• 향상된 개발자 환경
  개발자들은 Git을 사용하여 kubernetes의 내부를 알 필요 없이 kubernetes에 대한 업데이트와 기능을 보다 신속하게 관리할 수 있습니다.
• 개선된 안정성
  Git 워크플로우를 사용하여 클러스터를 관리하면 Kubernetes 외부에서 모든 클러스터 변경에 대한 편리한 감사 로그를 얻을 수 있습니다.
• 높은 신뢰성
  Git의 rollback/revert 및 fork 기능을 통해 안정적이고 재현 가능한 롤백을 얻을 수 있습니다. 또한 전체 시스템이Git에 기록되어 있기 때문에 장애 발생 후 복구해야 하는 단일 출처도 있으므로 복구(MTTR)시간을 단축할 수 있습니다.
• 일관성 및 표준화
  CI, CD를 포함한 운영업무가 Git을 통해서 일관되게 관리됩니다.

이제 Argo CD를 설치하고 CI 작업 결과물인 메니페스트 파일을 통해 배포를 진행해보겠습니다.

---

Install

먼저 아래 명령어를 통해 Argo CD를 위한 CR을 생성하고 UI에 접근하기 위해 argocd-server의 서비스 타입을 LoadBalancer로 변경합니다.

kubectl create namespace argocd kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}'

Setting

Argo CD 설정은 UI를 통해서 수행할 수 있습니다. UI가 그리 어렵지 않으니 메인 페이지의 New App을 클릭해서 정보를 입력해보도록 합니다.

 

이 작업을 UI가 아닌 코드로 관리하려면 Argo CD가 제공하는 Application CR을 정의하여 사용하면 됩니다. Application CR의 메니페스트는 다음과 같습니다.

application.yaml

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: spring-boot
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
  project: default
  source:
    repoURL: <SSH address of deploy repository>
    targetRevision: master
    path: .
  destination:
    server: https://kubernetes.default.svc
    namespace: default

이 때, Private Repository를 사용하기 위해서는 ssh private key나 username/password secret이 필요합니다. argocd docs를 참고하여 repository에 대한 설정이 담겨있는 ConfigMap을 생성합니다.

repository.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cm
  namespace: argocd
  labels:
    app.kubernetes.io/name: argocd-cm
    app.kubernetes.io/part-of: argocd
data:
  repository: |
    - url: <deploy repository url>
      sshPrivateKeySecret:
        name: deploy-key
        key: sshPrivateKey

여기서 주의할 점은 repository의 http 주소가 아닌 url을 입력해야 합니다.

---

Result

위에서 입력한 정보에 따라 Springboot Deployment와 Service가 배포된 것을 확인할 수 있습니다.

 

TODO

sprintboot에서 필요한 GCS 접근 권한을 GKE Workload Identity를 통해 service account로 해결하려 했습니다. 하지만 application layer에서 인증을 사용할 때에는 service account를 사용하지 않고 환경 변수인 GOOGLE_APPLICATION_CREDENTIALS 을 통해 key.json을 찾게 되어 GCS API에 대해 403에러가 발생하였고, 이에 따라 secret을 미리 설정 해놓는 방식을 사용하였습니다. 이 부분에 대해서는 CD 과정에서 Secret을 관리하는 방법에 대해 Best Practice를 알아보고 적용하는 과정이 필요합니다. 

블로그에 사용된 모든 코드는 Github에 존재합니다.

---

참고 자료

• https://www.arctiq.ca/our-blog/2020/7/13/ci-cd-with-argo/
• https://medium.com/axons/ci-cd-with-argo-on-kubernetes-28c1a99616a9
• https://argoproj.github.io/argo/
• https://argoproj.github.io/argo-events/
• https://argoproj.github.io/argo-cd/
• https://www.weave.works/technologies/gitops/
• https://coffeewhale.com/kubernetes/workflow/argo/2020/02/14/argo-wf/