ArgoCD를 통해서 Application 배포
지난번 포스팅에서 ArgoCD를 구축하는 방법을 정리했습니다.
이어서 Application을 만들고 Git Ops 워크플로우를 적용해봅시다.
1. Git Ops 워크플로우란
GitOps 워크플로우란 Git Repository를 통해 Application 배포 및 관리를 수행하는 것을 뜻합니다.
Application의 상태와 구성이 Git 저장소에 정의되어있으며, 변경사항이 Commit 되면 ArgoCD를 통해서
Application 배포가 이뤄지게 됩니다.
위와 같은 워크플로우 적용을 위해서는 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.ymlresources를 통해 ../../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 형태를 구성하고 있네요.