- Kubernetes Cluster: ArgoCD가 배포될 클러스터가 필요합니다. 현재 kOps로 EC2에 배포되어 있습니다.
- AWS Load Balancer Controller: Ingress 리소스를 ALB로 제공하기 위해 필요합니다. kOps의 add-on으로 설치되어 있습니다.
.
.
├── apps
│ ├── bzt
│ ├── demo-service
│ ├── elastic
│ ├── kustomization.yaml
│ ├── monitoring
│ ├── redis-ha
│ └── tektonci
├── bootstrap
│ ├── base
│ └── overlays
├── components
│ └── argocd
├── core
│ ├── kustomization.yaml
│ └── secrets
├── docs
│ ├── README.md
│ ├── assets
│ └── listener-patch.md
├── infra
│ ├── README.md
│ ├── cluster.tmpl.yaml
│ ├── cluster.yaml
│ ├── create-iam-role.sh
│ ├── create-s3-buckets.sh
│ └── values.yaml
└── manifests
├── backend
├── bzt
├── elastic
├── redis-ha
└── tektonci
| Directory | Description |
|---|---|
| bootstrap | 클러스터 설정을 부트스트랩핑하는 항목입니다. 일반적으로 CRD 혹은 설치 매니페스트입니다. - base : 기본이 되는 설정입니다. ArgoCD, Tekton 매니페스트를 설치합니다.- overlays: 클러스터 별 설정입니다.현재 overlays/default는 components 및 core를 포함하고 있습니다. |
| core | 클러스터 관련 YAML이 위치하는 곳입니다. 현재 secrets에 imagePullSecret이 포함되어 있습니다. |
| components | GitOps 컨트롤러의 구성 요소가 있는 곳입니다. ArgoCD의 구성이 이 곳에 들어갑니다. 기본적으로 리소스 접근을 위한 RBAC, 레포지토리 접근을 위한 Secret, 각 컨트롤러를 노출하기 위한 Ingress 등이 포함될 수 있습니다. |
| apps | 배포 대상 워크로드가 있는 곳입니다. ArgoCD에 의해 배포됩니다. |
| manifests | 배포 대상 매니페스트가 있는 곳입니다. Tekton에 의해 알부 Manifests가 업데이트 됩니다. |
| infra | 클러스터를 생성하기 위한 설정이 있는 곳입니다. terraform, kops 등 인프라 구성이 위치합니다. |
Tekton은 Kubernetes 기반의 오픈소스 CI/CD 프레임워크입니다.
빌드 / 테스트 / 배포 등의 작업 파이프라인을 유연하게 구성할 수 있으며,
이 프로젝트에서는 CI 컴포넌트로 사용됩니다.
Note
이해의 편의를 위해 그림 및 설명에 일부 생략된 요소가 있습니다.
레포지토리 구조상 Webhook을 단일 엔드포인트로 수신하고 있기 때문에, Path 기반 라우팅을 할 수 없습니다.
따라서 다음과 같은 프로세스를 거칩니다.
EventListener가 Source Repository의 Webhook을 수신합니다.EventListener는 등록된Trigger들에게 해당 Payload를 전달합니다.- 그림 상
Filter역할을 하는Interceptor가 Github Push Event의 모든 커밋에서 수정/추가/삭제된 파일을 체크합니다.
미리 등록된 MODULE_PATH와 일치하면 트리거가 동작합니다. Trigger는 미리 작성된Pipeline에 파라미터를 넘겨주며 실행시킵니다.
현재는 빌드 및 배포 대상이 되는 경로만 다르고 빌드 과정이 모두 같기 때문에,
같은 Pipeline을 이용하며 MODULE_PATH만 파라미터로 넘겨 대상을 결정합니다.
ArgoCD는 Kubernetes 환경에서의 지속적 배포 및 관리 자동화를 위한 도구입니다.
Kubernetes 클러스터 상에 배포될 애플리케이션의 매니페스트를 Git에서 선언적으로 관리하여,
GitOps의 구현을 가능하게 합니다.
ArgoCD는 Secret 리소스를 이용하여 Repository에 대한 커넥션을 설정합니다. 또한, Application CRD를 정의하여 배포 대상 매니페스트를
지정합니다.
Application의 Source로 명시된 매니페스트를 확인하며,
Destination로 지정된 클러스터에서 해당 리소스를 모니터링합니다.
두 상태의 차이가 관찰되면 Sync 작업을 진행하게 됩니다.
$ kubectl -k bootstrap/overlays/default기본 구성을 진행합니다. Tekton, ArgoCD 설치와 더불어 기본 CI/CD 파이프라인 워크플로가 구축됩니다.
$ kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "NodePort"}}'ArgoCD Server는 기본적으로
ClusterIP타입의 서비스로 구성되기 때문에, ALB를 이용하기 위하여NodePort타입으로 수정합니다.
# argocd-ingress.yaml
...
alb.ingress.kubernetes.io/listen-ports: '[{"HTTP":80}]'
...
name: argocd
namespace: argocd
...
backend:
service:
name: argocd-server
port:
number: 80기본적으로 HTTP를 이용하도록
Ingress가 구성되어 있습니다. tls를 적용하고 backend 포트를 443으로 설정하는 것이 권장됩니다.
Note
ArgoCD Server를 insecure 모드로 설정해야 HTTP를 이용할 수 있습니다.
ArgoCD CLI는 gRPC를 이용하기 때문에, HTTPS 설정이 필요합니다.
$ kubectl patch deploy -n argocd argocd-server --type json -p '[ { "op": "add", "path": "/spec/template/spec/containers/0/command/-", "value": "--insecure" } ]'이제 Web UI로 ArgoCD에 접근할 수 있습니다!
Tekton 트리거에서 MODULE_PATH는,
- 웹훅 페이로드에 명시된 변경된 파일 경로
- GitOps 레포지토리
manifests/하위의 매니페스트 경로
를 나타냅니다. (두 항목의 이름이 일치해야 합니다.)
현재 소스 레포지토리에서 배포 대상은 스프링 부트 애플리케이션뿐이기 때문에,
기존 스프링 빌드 파이프라인을 재사용하기 위해,
트리거의 MODULE_PATH만 Parameterize 하는 방식으로 진행됩니다.
소스 레포지토리에 user-service 애플리케이션이 추가된 시나리오를 가정하겠습니다.
기본 트리거를 템플릿처럼 사용하기 위해 kustomize를 사용합니다.
# manifests/tektonci/triggers/overlays/user/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: tektonci
resources:
- ../../base
patches:
- target:
group: triggers.tekton.dev
version: v1beta1
kind: Trigger
name: trigger
patch: |
- op: replace
path: /metadata/name
value: "user-trigger" # 1
- op: replace
path: /spec/interceptors/0/params/0/value/0/expression
value: "string('backend/user')" # 2단순히 기본 트리거의
1) name,2) MODULE_PATH만 변경하는 패치입니다.
# manifests/tektonci/triggers/overlays/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: tektonci
resources:
- demo
- user # Add new Trigger 모든 트리거를 한번에 배포하기 위해, overlays 디렉토리에서
user디렉토리를 추가해줍니다.
demo-trigger가 webhook-listener에 추가된 방식처럼,
user-trigger를 추가하도록 패치 파일도 편집합니다.
[
{
"op": "add",
"path": "/spec/triggers/-",
"value": {
"triggerRef": "demo-trigger"
}
},
{
"op": "add",
"path": "/spec/triggers/-",
"value": {
"triggerRef": "user-trigger"
}
}
]
manifests/tektonci/listeners/listener-patch.json
$ kubectl apply -k components/tektonci/listeners
$ describe el -n tektonci | grep "Trigger Ref"
> Trigger Ref: trigger
> Trigger Ref: demo-trigger
> Trigger Ref: user-trigger이제
webhook-listener는backend/dummy,backend/demo,backend/user에 대한 트리거를 참조하게 됩니다!
새로운 user-trigger는 MODULE_PATH를 CI/CD 파이프라인에게 파라미터로 넘깁니다.
파이프라인의 마지막은 현재 GitOps 레포지토리의 매니페스트를 업데이트하는 단계입니다.
업데이트할 backend/user의 매니페스트가 현재 레포지토리에 존재하지 않습니다.
manifests/backend/demo 디렉토리를 참조하여,
user-service의 Deployment, Service 등 매니페스트를 작성해주어야 합니다.
이제 마지막 단계입니다.
ArgoCD는 아직 새로 구성된 user-service 매니페스트에 대해 알지 못합니다.
Application 리소스를 작성하여, ArgoCD가 이를 모니터링하도록 합니다.
# apps/user-service/user-appset.yaml
...
project: default
source:
repoURL: git@github.com:2-cha/gitops-config.git
targetRevision: main
path: apps/backend/user/overlays/{{env}} # Here
...
demo-appset.yaml을 참고하여 나머지 부분도 적절하게 변경해줍니다.
# apps/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: argocd
resources:
- demo-service
- user-service한 번에 관리할 수 있도록 리소스를 추가합니다.
$ kubectl apply -k apps/이제 ArgoCD 는 manifests/backend/user/... 의 매니페스트를 쿠버네티스 클러스터와 레포지토리 상에서 모니터링합니다!
- apply CI to main branch
- complete README
- How to add new application
- apply autoscaling
- deploy prometheus, grafana
- deploy Elastic stack
- tekton GC
- inject configurations
- automate gradual promotion
- apply unit test, sonarqube