ArgoCD를 통해서 Application 배포

지난번 포스팅에서 ArgoCD를 구축하는 방법을 정리했습니다.

이어서 Application을 만들고 Git Ops 워크플로우를 적용해봅시다.

 

1. Git Ops 워크플로우란

GitOps 워크플로우란 Git Repository를 통해 Application 배포 및 관리를 수행하는 것을 뜻합니다.

Application의 상태와 구성이 Git 저장소에 정의되어있으며, 변경사항이 Commit 되면 ArgoCD를 통해서

Application 배포가 이뤄지게 됩니다.

출처: https://www.cncf.io/blog/2020/12/17/solving-configuration-drift-using-gitops-with-argo-cd/

 

위와 같은 워크플로우 적용을 위해서는 Git Repository에 저장될 정의가 중요할 것입니다.

여기서 kustomize라는 쿠버네티스의 오브젝트 선언형 관리 방법을 적용해 볼 수 있습니다.

 

 

2. Kustomize로 Application 정의

여기서는 Base + Overlay 개념을 이용할 것입니다.

아래와 같은 디렉토리로 필요한 오브젝트들을 선언해줬습니다.

├── api-server
│   ├── base
│   │   ├── deployment.yml
│   │   ├── ingress.yml
│   │   ├── kustomization.yml
│   │   └── service.yml
│   └── overlays
│       ├── dev
│       │   ├── kustomization.yml
│       │   ├── patchDeployment.yml
│       │   ├── patchIngress.yml
│       │   └── patchService.yml
│       └── prod

실제 현업에서도 많이 사용하는 방식입니다.

base는 일종의 껍데기(?) 같은 역할을 합니다. 쿠버네티스의 리소스(배포, 서비스, 인그레스 등)를 정의합니다.

overlay는 base를 참조합니다. 보통 환경(dev, stage, prod) 등으로 구분하여 사용할 수 있습니다.

 

실제 각 환경에 배포되는 내용은 overlay 하위의 내용이 될 것입니다.(overlay가 base를 덮어쓴다고 표현해도 될지 모르겠네요.🤔)

 

3. Deployment, Service, Ingress 정의

# base/deployment.yml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
spec:
  replicas: 1
  template:
    metadata:
      name: api-server
    spec:
      containers:
        - name: nginx
          image: nginx

# base/ingress.yml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-nginx
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
    - host: host.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: nginx
                
# base/service.yml
apiVersion: v1
kind: Service
metadata:
  name: api-server
spec:
  ports:
    - name: svc-port
      port: 8080
      targetPort: 8080
  type: ClusterIP

위와 같이 base를 정의 해줬습니다.

실제 배포시에는 overlay/{환경}/** 를 사용할 것이기 때문에 껍데기로 구성해놨다고 보면 될 것 같네요.

 

# base/kustomization.yml
resources:
- deployment.yml
- ingress.yml
- service.yml

commonLabels:
  app: api-server

그리고 위와 같이 kustomization.yml 까지 만들어 줍니다.

 

이후 overlays/dev 하위에도 오브젝트들을 정의 해봅시다.

# overlays/dev/patchDeployment.yml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
spec:
  replicas: 1
  template:
    metadata:
      name: api-server
    spec:
      containers:
        - name: api-server
          image: springboot-exam:0.0.1 # 실제 배포될 Application 이미지로 수정해줬습니다.
          ports:
            - containerPort: 8080
            
 # overlays/dev/patchIngress.yml, overlays/dev/patchService.yml 은 base의 것과 같습니다.

실무에서는 아마 base와 overlays의 정의가 상이할 것입니다.

저는 테스트를 위해 deployment의 컨테이너 이미지만 다른걸로 변경했어요.

 

# overlays/dev/kustomization.yml
resources:
- ../../base

namespace: api

namePrefix: dev-

commonLabels:
  env: dev

patches:
- path: patchDeployment.yml
- path: patchIngress.yml
- path: patchService.yml

resources를 통해 ../../base를 참조해줬습니다.

구버전에서는 bases라는 속성을 이용할텐데, 최신 쿠버네티스에서는 deprecated 된듯합니다.

namePrefix 지정해줍니다.

 

그리고 patchs 속성을 이용해서 overlay의 오브젝트 정의를 기입해줍니다.

위처럼 작성 후 git repository에 푸시해줍니다.

 

4. ArgoCD에서 application 추가하기

둘 중 하나의 버튼을 눌러줍니다.

 

상단에서 application 이름과 project를 지정한 뒤

위 캡쳐처럼 git repository 와 path를 지정해주세요.

 

만약 path가 안뜬다면? kustomize 양식에 오류가 있을 가능성이 높습니다.
즉, yml파일을 제대로 파싱하지 못해서 k8s에서 오브젝트를 인식못하는 거죠.
yml파일이 제대로 작성되었는지 확인 하는 명령어가 있습니다.
~ kubectl kustomize 디렉토리(.와 같이 상대 경로 입력 가능)

 

사용할 클러스터 주소를 입력해주고(여기서는 로컬 pc에 구축된 minikube를 사용)

namespace를 입력해줍니다.

앞서 입력한 overlays/dev/kustomization.yml의 namespace 일치하게 입력해줘야합니다.

 

그리고 생성 버튼을 눌러봅시다.

 

5. 결과 확인

위 캡처처럼 쿠버네티스 리소스들이 하나의 application 형태를 구성하고 있네요.