설치는 매우 간단하다.
Getting_started만 따라해도 서비스가 간단하게 뜨는 것을 확인할 수 있다.
https://argo-cd.readthedocs.io/en/release-2.0/getting_started
HA for production
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/ha/install.yaml
https://argo-cd.readthedocs.io/en/stable/operator-manual/high_availability/
Argo CD is largely stateless. All data is persisted as Kubernetes objects, which in turn is stored in Kubernetes' etcd. Redis is only used as a throw-away cache and can be lost. When lost, it will be rebuilt without loss of service.
A set of HA manifests are provided for users who wish to run Argo CD in a highly available manner. This runs more containers, and runs Redis in HA mode.
Stable
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
Argo CD is implemented as a kubernetes controller which continuously monitors running applications and compares the current, live state against the desired target state (as specified in the Git repo). A deployed application whose live state deviates from the target state is considered OutOfSync.
Argo CD reports & visualizes the differences, while providing facilities to automatically or manually sync the live state back to the desired target state.
Any modifications made to the desired target state in the Git repo can be automatically applied and reflected in the specified target environments.
Git 리포지토리에서 원하는 대상 상태에 대한 모든 수정 사항은 지정된 대상 환경에 자동으로 적용되고 반영될 수 있다고 한다. 지속적으로 모니터링하고 라이브 상태를 원하는 Git 리포지같은 상태와 계속 비교하는 컨트롤러로 구현되어 있다고 한다.
자세한 건 문서를 더 찾아보도록 하자.
https://argo-cd.readthedocs.io/en/release-2.0/
콘솔에 접근하기 위한 초기 비밀번호를 확인하고 재설정한다. 초기 계정은 admin이다.
argocd-server에 접근하여 비밀번호를 변경하도록 하자. argocd cli를 설치하여 호스트에서 사용하는 방법도 있지만 필자는 비밀번호만 변경하기에는 해당 방법이 가장 편리하였다. argocd cli 설치도 남겼다.
# 초기 비밀번호 확인
kubectl get secret -n argocd argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d
# argocd-server 접근
kubectl exec -it -n argocd deployment/argocd-server -- /bin/bash
argocd login localhost:8080
# 비밀번호 변경 ( arogocd cli 명령도구를 호스트에 설치하여 사용하는 방법도 있음)
argocd account update-password
## 추가 argocd cli 설치
wget https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64
cp argocd-linux-amd64 /usr/local/bin/argocd
chomd +x /usr/local/bin/argocd
argocd version
svc 타입 변경 (외부 노출)
외부 노출을 위해 NodePort로 svc타입을 변경해준다. 하지만 바로 밑에 ingress로 노출하는 방법도 기록하니 참고하도록 하자.
kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "NodePort"}}'
ingress 생성
일반적으로 만든 ingress로는 접근이 안되어서 ingress 방법을 기록해두었다.
aws alb controller를 사용하는 경우 grpc 때문에 따로 추가해야되는 것이 있었다.
아래와 같이 추가해주면 된다.
- 인터넷으로 들어올때 https로 들어옴
- CLI로 접속할때 gprc로 들어옴
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
namespace: argocd
name: argocd-ingress
annotations:
kubernetes.io/ingress.class: alb
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS":443}]'
alb.ingress.kubernetes.io/load-balaner-name: argo-alb
alb.ingress.kubernetes.io/conditions.argogrpc: |
[{"field":"http-header","httpHeaderConfig":{"httpHeaderName": "Content-Type", "values":["application/grpc"]}}]
alb.ingress.kubernetes.io/backend-protocol: HTTPS
alb.ingress.kubernetes.io/target-type: instance
alb.ingress.kubernetes.io/ssl-redirect: '443'
alb.ingress.kubernetes.io/tags: app=argo
alb.ingress.kubernetes.io/certificate-arn: acm arn
spec:
rules:
- host: argocd.XXX.XXX #만약에 서티 안쓰고 싶으면 그냥 이부분 빈칸으로 주면됨.
http:
paths:
- path: /
backend:
service:
name: argogrpc
port:
number: 443
pathType: Prefix
- path: /*
backend:
service:
name: argocd-server
port:
number: 443
pathType: ImplementationSpecific
tls:
- hosts:
- argocd.XXX.XXX
grpc 서비스 만들기
apiVersion: v1
kind: Service
metadata:
annotations:
alb.ingress.kubernetes.io/backend-protocol-version: GRPC
labels:
app: argogrpc
name: argogrpc
namespace: argocd
spec:
ports:
- name: "443"
port: 443
protocol: TCP
targetPort: 8080
selector:
app.kubernetes.io/name: argocd-server
sessionAffinity: None
type: NodePort
argoCD를 통해 배포 할 애플리케이션 등록이 필요하다.
왼쪽 메뉴바 Settings -> Repository -> Connect Repo를 통해 레파지토리를 등록한다.
정상적으로 등록이 완료되었으면 Connection Status가 다음과 같이 활성화 된다.
Settings에 Project를 만들어 논리적 구분도 가능하며 Account 관리도 가능하니 필요 시 참고하도록 하며,
바로 Application 등록을 진행해보자.
왼쪽 메뉴바 Application -> +New APP
Sync Policy는 수동(Manual), 자동(Auto)을 선택할 수 있다. Sync할 Source 주소와 배포할 Destination을 지정하였으면 3분을 주기로 Sync를 맞춘다. Application에는 크게 source와 destination이 저장되어있는데 source에는 Git 레포지토리 또는 Helm chart 정보가 들어있고, destination에는 동기화시킬 쿠버네티스 클러스터 정보가 들어있다.
ArgoCD는 쿠버네티스 환경에서의 GitOps 기반의 CD(Continuously Delivery) 도구이다. 주요 역할은 Git에 저장된 매니페스트를 쿠버네티스 클러스터로 동기화한다. git과 클러스터 현재 상태가 같으면 Synced(초록색), 상태가 다르면 Out Of Sync(주황색)을 나타낸다.
ArgoCD Application은 매니페스트가 저장된 Git 또는 Helm 차트와 동기화시킬 쿠버네티스 클러스터 정보를 저장하는 ArgoCD만의 CR(Custom Resource)이다.
automated : Auto sync와 Manual sync로 선택할 수 있는 설정
prune
동기화 된 상태에서 git에서 리소스 파일 삭제 또는 변경하고 쿠버네티스에서 삭제할지 유지할지 결정하는 옵션이다.
예를들어 Auto sync상태에서 deployment파일을 깃에서 지웠을때 확인하면 다음과 같다.
아래처럼 health status는 계속 healthy로 application에 문제는 없고 sync status는 out of sync로 동기화에 문제가 있다라는 상태로 변환된다.
self heal
반대로 self heal은 git이 아닌 쿠버네티스에서 리소스를 변경 해도 결과 값은 git에 있는 파일로 유지되는것이다.
Ignore Difference
특정 리소스를 sync 대상에서 제외시키는 기능으로 만약 hpa를 통해 파드가 증가할때 git에 따라 자동 동기화 되기 때문에 파드는 지속적으로 증가하지 못하는데 이러한 상황에서 Ignore Difference를 사용한다.
현재 WEB UI에서는 제공하지 않으며 생성한 applicationd의 CRD 또는 argocd configmap에서 설정할 수 있다.
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: external-secrets-operator
...
spec:
project: default
source:
...
destination:
...
syncPolicy:
...
ignoreDifferences: # 해당부분에 명시
...
ArgoCD Notification Configuration
1. ArgoCD Notification 관련 패키지를 설치한다. ArgoCD는 Kubernetes 클러스터에 배포된 상태이다. 따라서 ArgoCD Notification 패키지도 Kubernetes에 배포해야 한다. (단, ArgoCD를 배포한 네임스페이스에 함께 배포해야함)
$ kubectl apply -f https://raw.githubusercontent.com/argoproj-labs/argocd-notifications/release-1.0/manifests/install.yaml
2. ArgoCD Trigger 설정을 설치한다. ArgoCD에서 관리하는 애플리케이션이 어떤 상황에서 어떤 메시지를 보내야 하는지를 정의하는 설정다. 마찬가지로 다음 명령어를 실행한다( 네임스페이스 동일하게)
$ kubectl apply -f https://raw.githubusercontent.com/argoproj-labs/argocd-notifications/release-1.0/catalog/install.yaml
3. Slack 설정 과정에서 만든 토큰을 ArgoCD Notification 컴포넌트에 알려주어야 한다. 다음의 내용을 파일로 생성한다.
# argocd-notifications-secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: argocd-notifications-secret
stringData:
slack-token: <여기에 토큰을 입력합니다>
$ kubectl apply -f argocd-notifications-secret.yaml
4. argocd-notifications-cm을 토큰을 넣어주는 작업을 한다.
$ kubectl edit cm argocd-notifications-cm
apiVersion: v1
kind: ConfigMap
metadata:
name: argocd-notifications-cm
data:
service.slack: | token: <여기에 토큰을 입력합니다> ...
5. 애플리케이션에 Notification Trigger를 설정
- Sync가 성공했을 때 알림
$ kubectl patch app $APP\_NAME -n $NAMESPACE -p '{"metadata": {"annotations": {"notifications.argoproj.io/subscribe.on-sync-succeeded.slack":"$SLACK\_CHANNEL\_NAME"}}}' --type merge
- Sync가 실패했을 때 알림
$ kubectl patch app $APP_NAME -n $NAMESPACE -p '{"metadata": {"annotations": {"notifications.argoproj.io/subscribe.on-sync-failed.slack":"$SLACK_CHANNEL_NAME"}}}' --type merge
- Sync가 진행중일 때 알림
$ kubectl patch app $APP_NAME -n $NAMESPACE -p '{"metadata": {"annotations": {"notifications.argoproj.io/subscribe.on-sync-running.slack":"$SLACK_CHANNEL_NAME"}}}' --type merge
- Sync 상태가 Unknown일 때 알림
$ kubectl patch app $APP_NAME -n $NAMESPACE -p '{"metadata": {"annotations": {"notifications.argoproj.io/subscribe.on-sync-status-unknown.slack":"$SLACK_CHANNEL_NAME"}}}' --type merge
- Health가 Degrade 되었을 때 알림
$ kubectl patch app $APP_NAME -n $NAMESPACE -p '{"metadata": {"annotations": {"notifications.argoproj.io/subscribe.on-health-degraded.slack":"$SLACK_CHANNEL_NAME"}}}' --type merge
- Deploy 되었을 때 알림
$ kubectl patch app $APP_NAME -n $NAMESPACE -p '{"metadata": {"annotations": {"notifications.argoproj.io/subscribe.on-deployed.slack":"$SLACK_CHANNEL_NAME"}}}' --type merge
아주 간단하게 argocd 설치하고 AWS ALB를 통해 외부에 노출하였으며 Slack 설정까지 기록하였다.
중간중간 빼먹은 부분이 있겠지만 생각나는데로 중요한 부분은 기록하려고 노력하였다. 금방 기억이 나지 않아서 구축하면 기록하는 습관을 꼭 가져야겠드아....
구축하는 과정은 getting started부터 많은 친절한 엔지니어분들 덕에 금방할 수 있는 것 같다.
중요한 건 운영 노하우라고 요즘 느끼는 것 같다.
'IT' 카테고리의 다른 글
EKS worker node SSM 접속 (0) | 2024.10.09 |
---|---|
쿠버네티스[EKS] argo rollout을 이용한 Blue/Green, Canary 배포 (3) | 2024.10.09 |
쿠버네티스[EKS] EFK (Elastic, Fluent-bit, Kibana) helm 설치 (1) | 2024.10.09 |
쿠버네티스[EKS] 프로메테우스, 그라파나 helm 설치 (0) | 2024.10.08 |
Helm, Helm chart (0) | 2024.08.26 |