ArgoCD에서 여러 클러스터에 배포를 관리할 수 있는 패턴인 ApplicationSet에 대해서 알아보겠습니다.
실습을 위해 Quick Install을 수행합니다.
Quick Install
mgmt, dev, prod 3 개의 클러스터를 배포하고 mgmt 클러스터에 argocd를 설치하는 형태로 구성을 진행합니다.
docker-desktop으로 진행하기에 별도의 추가설정도 같이 진행합니다.
OrbStack과 Docker Desktop 의 Network 차이
kind로 멀티 클러스터 구성 시 docker network를 확인해보면 아래와 같이 별도의 네트워크 대역대로 구성되어 있습니다.
docker network inspect kind | grep -E 'Name|IPv4Address'
...
"Name": "kind",
"Name": "prd-control-plane",
"IPv4Address": "172.18.0.4/16",
"Name": "dev-control-plane",
"IPv4Address": "172.18.0.3/16",
"Name": "mgmt-control-plane",
"IPv4Address": "172.18.0.2/16",
...
orbstack의 경우 네이티브와 통합되어 host에서 호출이 가능하지만 docker desktop의 경우 분리되어 있어 host에서 호출이 불가능합니다. 별도의 설정이 필요합니다.
# orbstack
┌──────────────────────────────────────────────────────────────┐
│ macOS (호스트) │
│ │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ OrbStack (네이티브 통합) │ │
│ │ │ │
│ │ ┌──────────────────────────────────────────────┐ │ │
│ │ │ Docker Network │ │ │
│ │ │ 172.18.0.0/16 │ │ │
│ │ │ ← macOS 네트워크 스택과 직접 통합 │ │ │
│ │ └──────────────────────────────────────────────┘ │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
│ ✔ macOS → 172.18.0.3 직접 접근 가능! │
└──────────────────────────────────────────────────────────────┘
# docker desktop
╭──────────────────────────────────────────────────────────────╮
│ macOS (Host) │
│ │
│ ╭────────────────────────────────────────────────────────╮ │
│ │ Docker Desktop VM (격리 환경) │ │
│ │ │ │
│ │ ╭────────────────────────────────────────────────╮ │ │
│ │ │ Docker Network │ │ │
│ │ │ 172.18.0.0/16 │ │ │
│ │ │ (VM 내부에서만 접근 가능한 네트워크) │ │ │
│ │ ╰────────────────────────────────────────────────╯ │ │
│ ╰────────────────────────────────────────────────────────╯ │
│ │
│ ✘ macOS → 172.18.0.3 직접 접근 불가 │
╰──────────────────────────────────────────────────────────────╯
Cluster
docker container 네트워크 대역대와 호스트 네트워크 대역대가 다르기에 argocd와 호스트에서 동일하게 kube apiserver 접근을 위해 호스트 IP로 kube apiserver 접근 설정이 필요합니다.
kubeadm에서 호스트 IP로 호출하기 위해 certSANs에 호스트 IP를 입력해줍니다. 그러면 docker container 내부에서 호스트 IP는 라우팅이 되기 때문에 호스트 IP로 kube apiserver를 접근 할 수 있습니다.
이번 실습에서는 ClusterIP로 분리하지 않고 클러스터별로 Port를 분리하여 진행하겠습니다.(OrbStack 사용 시 ClusterIP로 분리가능)
mgmt: 6443. dev:6444, prd: 6445로 구분합니다.
certSANs 를 설정안하고 생성 시 호스트 IP로 kube apiserver 호출 시 인증서 에러가 발생합니다.
# 모든 kind cluster 삭제
kind get clusters | xargs -I {} kind delete cluster --name {}
docker system prune --force
HOSTIP=192.168.1.66
# mgmt cluster
kind create cluster --name mgmt --image kindest/node:v1.32.8 --config - <<EOF
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
labels:
ingress-ready: true
extraPortMappings:
- containerPort: 80
hostPort: 80
protocol: TCP
- containerPort: 443
hostPort: 443
protocol: TCP
- containerPort: 30000
hostPort: 30000
- containerPort: 6443
hostPort: 6443
protocol: TCP
kubeadmConfigPatches:
- |
kind: ClusterConfiguration
apiServer:
ExtraArgs:
bind-address: 0.0.0.0
certSANs:
- "$HOSTIP"
- "127.0.0.1"
EOF
# dev cluster
kind create cluster --name dev --image kindest/node:v1.32.8 --config - <<EOF
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
extraPortMappings:
- containerPort: 31000
hostPort: 31000
- containerPort: 6443
hostPort: 6444
protocol: TCP
kubeadmConfigPatches:
- |
kind: ClusterConfiguration
apiServer:
ExtraArgs:
bind-address: 0.0.0.0
certSANs:
- "$HOSTIP"
- "127.0.0.1"
EOF
# prod cluster
kind create cluster --name prd --image kindest/node:v1.32.8 --config - <<EOF
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
extraPortMappings:
- containerPort: 32000
hostPort: 32000
- containerPort: 6443
hostPort: 6445
protocol: TCP
kubeadmConfigPatches:
- |
kind: ClusterConfiguration
apiServer:
ExtraArgs:
bind-address: 0.0.0.0
certSANs:
- "$HOSTIP"
- "127.0.0.1"
EOF
# kubeconfig에서 호스트 ip주소로 변경
kubectl config set-cluster kind-mgmt --server=https://$HOSTIP:6443
kubectl config set-cluster kind-dev --server=https://$HOSTIP:6444
kubectl config set-cluster kind-prd --server=https://$HOSTIP:6445
# alias 설정
alias k8s1='kubectl --context kind-mgmt'
alias k8s2='kubectl --context kind-dev'
alias k8s3='kubectl --context kind-prd'
# 확인
k8s1 get node
k8s2 get node
k8s3 get node
# 모든 클러스터의 node가 Ready 임을 확인하기
NAME STATUS ROLES AGE VERSION
mgmt-control-plane Ready control-plane 95s v1.32.8
NAME STATUS ROLES AGE VERSION
dev-control-plane Ready control-plane 85s v1.32.8
NAME STATUS ROLES AGE VERSION
prd-control-plane Ready control-plane 76s v1.32.8Ingress 설치 및 인증서
# 배포
kubectl --context kind-mgmt apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/kind/deploy.yaml
# ingress 설정
kubectl --context kind-mgmt patch deployment ingress-nginx-controller -n ingress-nginx \
--type='json' \
-p='[
{"op": "add", "path": "/spec/template/spec/containers/0/args/-", "value": "--publish-status-address=localhost"},
{"op": "add", "path": "/spec/template/spec/containers/0/args/-", "value": "--enable-ssl-passthrough"}
]'
# 인증서 생성
openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
-keyout argocd.example.com.key \
-out argocd.example.com.crt \
-subj "/CN=argocd.example.com/O=argocd"
# 인증서 반영
kubectl --context kind-mgmt create ns argocd
# tls 시크릿 생성
kubectl --context kind-mgmt -n argocd create secret tls argocd-server-tls \
--cert=argocd.example.com.crt \
--key=argocd.example.com.key
# 도메인 등록
echo "127.0.0.1 argocd.example.com" | sudo tee -a /etc/hostsArgoCD
helm repo add argo https://argoproj.github.io/argo-helm
helm repo update
helm --kube-context kind-mgmt install argocd argo/argo-cd \
--version 9.0.5 \
--namespace argocd \
--set global.domain=argocd.example.com \
--set server.ingress.enabled=true \
--set server.ingress.ingressClassName=nginx \
--set server.ingress.annotations."nginx.ingress.kubernetes.io/force-ssl-redirect"="true" \
--set server.ingress.annotations."nginx.ingress.kubernetes.io/ssl-passthrough"="true" \
--set server.ingress.tls=true접근
# 접속 확인
curl -vk https://argocd.example.com/
# 최초 접속 암호 확인
ARGOPW=$(kubectl --context kind-mgmt -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d ;echo)
# argocd 서버 cli 로그인
argocd --kube-context kind-mgmt login argocd.example.com --insecure --username admin --password $ARGOPW
# admin 계정 암호 변경 : qwe12345
argocd --kube-context kind-mgmt account update-password --current-password $ARGOPW --new-password qwe12345
# Argo CD 웹 접속 주소 확인 : admin 계정 / qwe12345
open "http://argocd.example.com"
open "https://argocd.example.com"실습을 하기 위한 설정이 모두 완료되었습니다.
지금부터 멀티 클러스터를 구성하고 ArgoCD ApplicationSet을 활용하여 애플리케이션 배포를 관리해보겠니다.
ArgoCD에 멀티 클러스터 등록하기
현재 mgmt 클러스터에 argocd를 설치했기 때문에 mgmt 클러스터만 등록되어있습니다. dev, prd 클러스터 등록을 진행하겠습니다.
명령어는 아래와 같습니다.
argocd cluster add kind-dev --name dev-k8s
명령어를 살펴보면
kind-dev 는 현재 로컬 환경의 kubeconfig에 있는 context 명칭이며 argocd cluster add를 하기 위해서는 argocd 내부와 로컬에서 동일하게 kube apiserver 호출이 가능해야합니다.
현재 호스트 IP를 kube apiserver로 지정했기에 아래와 같이 호스트 IP로 등록됩니다.
dev, prd 클러스터를 등록해줍니다.
argocd cluster add kind-dev --name dev-k8s --yes
{"level":"info","msg":"ServiceAccount \\"argocd-manager\\" created in namespace \\"kube-system\\"","time":"2025-11-22T21:52:29+09:00"}
{"level":"info","msg":"ClusterRole \\"argocd-manager-role\\" created","time":"2025-11-22T21:52:29+09:00"}
{"level":"info","msg":"ClusterRoleBinding \\"argocd-manager-role-binding\\" created","time":"2025-11-22T21:52:29+09:00"}
{"level":"info","msg":"Created bearer token secret \\"argocd-manager-long-lived-token\\" for ServiceAccount \\"argocd-manager\\"","time":"2025-11-22T21:52:29+09:00"}
Cluster '' added
argocd cluster add kind-prd --name prd-k8s --yes
Cluster '' added
argocd cluster list
SERVER NAME VERSION STATUS MESSAGE
dev-k8s Unknown Cluster has no applications and is not being monitored.
prd-k8s Unknown Cluster has no applications and is not being monitored.
<https://kubernetes.default.svc> in-cluster Unknown Cluster has no applications and is not being monitored.
등록 과정을 살펴보면 아래의 순서대로 클러스터 연동 설정을 진행합니다.
- kind-dev 클러스터내에 ServiceAccount 를 생성하고 ClusterRole을 생성하고 ClusterRolebinding을 생성합니다.
k8s2 get sa -n kube-system argocd-manager
NAME SECRETS AGE
argocd-manager 0 13m
k8s2 get clusterrole -n kube-system argocd-manager-role
NAME CREATED AT
argocd-manager-role 2025-11-22T12:52:29Z
k8s2 get clusterrolebinding -n kube-system argocd-manager-role-binding
NAME ROLE AGE
argocd-manager-role-binding ClusterRole/argocd-manager-role 18m
- kind-dev 클러스터의 ServiceAccount의 rolesum을 확인해보면 * 권한으로 kind-dev 클러스터의 모든 리소스를 접근할 수 있도록 설정되어 있습니다.
kubectl rolesum -n kube-system argocd-manager --context kind-dev
ServiceAccount: kube-system/argocd-manager
Secrets:
Policies:
• [CRB] */argocd-manager-role-binding ⟶ [CR] */argocd-manager-role
Resource Name Exclude Verbs G L W C U P D DC
*.* [*] [-] [-] ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
- kind-dev 클러스터의 자격증명은 kind-mgmt 클러스터 내에 secret으로 저장하여 kind-dev 클러스터를 argocd에서 제어할 수 있습니다.
k8s1 get secret -n argocd -l argocd.argoproj.io/secret-type=cluster
# argocd.argoproj.io/secret-type=cluster 라벨 필요
NAME TYPE DATA AGE
cluster-192.168.1.66-525208354 Opaque 3 19m
멀티 클러스터에 Nginx 배포하기
mgmt, dev, prd 클러스터에 각각 nginx를 배포합니다.
# 자격증명 변경
kubectl config use-context kind-mgmt
HOSTIP=192.168.1.66
cat https://github.com/hanship0530/Learning
targetRevision: HEAD
syncPolicy:
automated:
prune: true
syncOptions:
- CreateNamespace=true
destination:
namespace: mgmt-nginx
server: https://kubernetes.default.svc
EOF
cat https://github.com/hanship0530/Learning
targetRevision: HEAD
syncPolicy:
automated:
prune: true
syncOptions:
- CreateNamespace=true
destination:
namespace: dev-nginx
server:
EOF
cat https://github.com/hanship0530/Learning
targetRevision: HEAD
syncPolicy:
automated:
prune: true
syncOptions:
- CreateNamespace=true
destination:
namespace: prd-nginx
server:
EOF각 리소스가 잘 생성되었는 지 확인해보겠습니다.
argocd app list
NAME CLUSTER NAMESPACE PROJECT STATUS HEALTH SYNCPOLICY CONDITIONS REPO PATH TARGET
argocd/dev-nginx dev-nginx default Synced Healthy Auto-Prune <https://github.com/gasida/cicd-study> nginx-chart HEAD
argocd/mgmt-nginx <https://kubernetes.default.svc> mgmt-nginx default Synced Healthy Auto-Prune <https://github.com/gasida/cicd-study> nginx-chart HEAD
argocd/prd-nginx prd-nginx default Synced Progressing Auto-Prune <https://github.com/gasida/cicd-study> nginx-chart HEAD
kubectl get applications -n argocd
NAME SYNC STATUS HEALTH STATUS
dev-nginx Synced Healthy
mgmt-nginx Synced Healthy
prd-nginx Synced Healthy
# mgmt
kubectl get pod,svc,ep,cm -n mgmt-nginx
curl -s
# dev
kubectl get pod,svc,ep,cm -n dev-nginx --context kind-dev
curl -s
# prd
kubectl get pod,svc,ep,cm -n prd-nginx --context kind-prd
curl -s
다음 실습을 위해 애플리케이션을 삭제해줍니다.
kubectl delete applications -n argocd mgmt-nginx dev-nginx prd-nginx
App of Apps 패턴
app of apps 패턴은 부모 애플리케이션과 자식 애플리케이션 집합을 논리적으로 그룹화할 수 있는 기능을 제공합니다.
아래 실습을 통해 app of apps를 구현해보겠습니다.
# Root Application 하나에 여러 Application manifest를 넣어 관리
argocd app create apps \
--dest-namespace argocd \
--dest-server https://kubernetes.default.svc \
--repo https://github.com/hanship0530/Learning.git \
--path ci-cd-cookbook/6w/apps
# Root Application을 sync하면 하위 앱들이 자동 생성됨
argocd app sync appshttps://github.com/gasida/cicd-study/blob/main/apps/templates/applications.yaml 코드를 살펴보면
{{- range .Values.applications }}
{{- $config := $.Values.config -}}
Values 의 applications를 돌면서 Application 을 정의합니다.
spec:
destination:
namespace: {{ .namespace | default .name | quote }}
server: {{ $config.spec.destination.server | quote }}
destination에는 namespace와 배포할 server를 Values로 부터 받아옵니다. server는 config 값에서 공통으로 정의합니다.
spec:
project: default
project는 default 를 사용합니다.
spec:
source:
path: {{ .path | quote }}
repoURL: {{ $config.spec.source.repoURL }}
targetRevision: {{ $config.spec.source.targetRevision }}
{{- with .tool }}
{{- . | toYaml | nindent 4 }}
{{- end }}source에서는 Values.applications[].name 을 가져와서 path 로 지정합니다. 실제 github 을 보면 application 이름과 path 명이 일치합니다.
repoURL은 Values.config.source.repoURL에 정의되어 있습니다.
targetRevision은 Values.config.source.targetRevision에 브런치명이 정의되어 있습니다.
https://github.com/gasida/cicd-study/blob/main/apps/values.yaml values를 살펴보면 아래와 같이 구성되어 있습니다.
config:
spec:
destination:
server: https://kubernetes.default.svc
source:
repoURL: https://github.com/hanship0530/Learning
targetRevision: main
applications:
- name: helm-guestbook
path: ci-cd-cookbook/6w/helm-guestbook
tool:
helm:
releaseName: helm-guestbook
- name: kustomize-guestbook
path: ci-cd-cookbook/6w/kustomize-guestbook
- name: sync-waves
path: ci-cd-cookbook/6w/sync-wavesargocd를 확인해보면 아래와 같이 단일 application에서 여러개의 application을 관리하는 것을 볼 수 있습니다.
이와 같이 app of apps 패턴을 사용하면 여러개의 application을 단일 application으로 관리할 수 있습니다.
다음 실습을 위해 부모 app을 삭제해주면 전체 app이 다 삭제됩니다.
argocd app delete argocd/apps --yes
ApplicationSet
ApplicationSet Controller란?
- ApplicationSet Controller는 CustomResourceDefinition(CRD)을 기반으로 동작하는 Kubernetes 컨트롤러로,
- Argo CD 애플리케이션을 대규모·자동화 방식으로 관리할 수 있게 해준다.
- 다수의 클러스터 또는 모노레포 환경에서 애플리케이션 생성·관리·배포를 자동화하는 역할을 한다.
🚀주요 기능
1. 하나의 매니페스트로 여러 클러스터에 배포
- 단일 ApplicationSet 매니페스트를 사용해
- 여러 Kubernetes 클러스터에 Argo CD 애플리케이션을 자동 생성·배포한다.
2. 여러 Git 저장소 또는 다수의 애플리케이션을 한 번에 관리
- 하나의 매니페스트로
- 여러 Git repo 또는 동일 repo 내 여러 애플리케이션을 자동 생성할 수 있다.
3. 모노레포(monorepo) 지원 강화
- 단일 Git 저장소에 여러 애플리케이션이 존재하는 구조에서도
- 경로(Path)별로 개별 Argo CD 애플리케이션을 자동 관리해준다.
4. 멀티 테넌트 환경 지원
- 다중 테넌트 클러스터에서 각 테넌트가 직접 애플리케이션을 배포할 수 있도록 지원.
- 테넌트가 대상 클러스터/네임스페이스를 활성화하는 데
- 클러스터 관리자 개입이 최소화된다.
목록 List 제너레이터
ApplicationSet 의 기본 구성 요소는 제너레이터이고 ApplicationSet 에서 사용되는 매개변수 생성을 담당합니다.
목록 List 제너레이터는 고정된 클러스터 목록에 Argo CD 애플리케이션을 지정할 수 있습니다.
아래 예제를 통해 테스트 해보겠습니다.
HOSTIP=192.168.1.66
# argocd app 배포
cat <
- cluster: prd-k8s
url:
template:
metadata:
name: '{{.cluster}}-guestbook'
labels:
environment: '{{.cluster}}'
managed-by: applicationset
spec:
project: default
source:
repoURL: https://github.com/hanship0530/Learning.git
targetRevision: HEAD
path: ci-cd-cookbook/6w/appset/list/{{.cluster}}
destination:
server: '{{.url}}'
namespace: guestbook
syncPolicy:
syncOptions:
- CreateNamespace=true
EOF
# Sync
argocd app sync -l managed-by=applicationset배포 Yaml을 살펴보면
spec:
generators:
- list:
elements:
- cluster: dev-k8s
url: https://$HOSTIP:6444
- cluster: prd-k8s
url: https://$HOSTIP:6445generators 에 배포할 클러스터를 지정하는 것을 볼 수 있습니다. Port로 클러스터를 분리했기때문에 HOSTIP:<PORT> 로 클러스터가 구분되어 있습니다.
배포된 리소스를 아래 명령어를 통해 확인해봅니다.
kubectl get applicationsets -n argocd guestbook -o yaml
kubectl get applicationsets -n argocd guestbook -o yaml | k neat | yq
kubectl get applicationsets -n argocd
argocd appset list
argocd app list
argocd app list -l managed-by=applicationset
kubectl get applications -n argocd
kubectl get applications -n argocd --show-labels
# 각 k8s 에 배포된 파드 정보 확인
k8s2 get pod -n guestbook
NAME READY STATUS RESTARTS AGE
guestbook-ui-7cf4fd7cb9-jk78d 1/1 Running 0 39s
k8s3 get pod -n guestbook
k8s3 get pod -n guestbook
NAME READY STATUS RESTARTS AGE
guestbook-ui-7cf4fd7cb9-vplqv 1/1 Running 0 42s
guestbook-ui-7cf4fd7cb9-xgglp 1/1 Running 0 42s
위 와같이 동일한 application을 각 클러스터에 별도의 argocd 구성없이 동일하게 배포를 할 수 있습니다.
삭제는 아래와 같이 할 수 있습니다.
argocd appset delete guestbook --yes
클러스터 제너레이터
지정된 클러스터에만 배포하는 목록 제너레이터와 달리 클러스터 제너레이터는 Argo CD에서 사용 가능한 모든 쿠버네티스 클러스터를 대상으로 배포합니다.
아래 예제를 통해 실습을 해봅니다.
클러스터를 지정할 필요가 없기에 별도의 클러스터 지정옵션은 사용하지 않습니다.
cat https://github.com/hanship0530/Learning
targetRevision: HEAD
path: ci-cd-cookbook/6w/guestbook
destination:
server: '{{.server}}'
namespace: guestbook
syncPolicy:
syncOptions:
- CreateNamespace=true
EOF
# sync
argocd app sync -l managed-by=applicationset목록 제너레이터와 template, metadata 설정은 비슷하지만 아래 설정만 다른것을 볼 수 있습니다.
spec:
generators:
- clusters: {}
generators 에서 cluster가 {} 으로 표기되어 있습니다.
아래 명령어로 확인을 해보면 dev,prd 뿐만 아니라 mgmt 클러스터에도 배포된 것을 확인 할 수 있습니다.
# 생성된 application yaml 확인
kubectl get applications -n argocd in-cluster-guestbook -o yaml | k neat | yq
kubectl get applications -n argocd dev-k8s-guestbook -o yaml | k neat | yq
kubectl get applications -n argocd prd-k8s-guestbook -o yaml | k neat | yq
# 각 k8s 에 배포된 파드 정보 확인
k8s1 get pod -n guestbook
k8s2 get pod -n guestbook
k8s3 get pod -n guestbook
삭제도 동일하게 아래 명령어로 해줍니다.
argocd appset delete guestbook --yes
클러스터 제너레이터에서도 일부 클러스터만 선택해서 배포를 진행할 수 있습니다.
argocd에서 클러스터 설정 시 설정된 클러스터에 대한 자격증명에 Label을 지정하여 배포 시 선택하는 설정을 통해 배포할 수 있습니다.
아래 예제를 통해 테스트를 해봅니다.
kubectl get secret -n argocd -l argocd.argoproj.io/secret-type=cluster
NAME TYPE DATA AGE
cluster-192.168.1.66-525208354 Opaque 3 88m -> dev
cluster-192.168.1.66-541985973 Opaque 3 75m -> prd
DEVK8S=cluster-192.168.1.66-525208354
kubectl label secrets $DEVK8S -n argocd env=stg
kubectl get secret -n argocd -l env=stg
NAME TYPE DATA AGE
cluster-192.168.1.66-525208354 Opaque 3 90m
위와 같이 지정하고 클러스터 제너레이터 Yaml에서 spec.generators 만 설정해서 배포합니다.
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: guestbook
namespace: argocd
spec:
goTemplate: true
goTemplateOptions: ["missingkey=error"]
generators:
- clusters:
selector:
matchLabels:
env: "stg"
dev 클러스터에만 배포된 것을 확인할 수 있습니다.
k8s2 get pod -n guestbook
NAME READY STATUS RESTARTS AGE
guestbook-ui-85db984648-hrwxh 1/1 Running 0 26s
ArgoCD ApplicationSet을 활용하여 멀티클러스터 환경에서 중복적인 설정없이 통합설정으로 애플리케이션을 배포하고 관리 할 수 있습니다.
실습 완료 후 클러스터를 삭제합니다
kind get clusters | xargs -I {} kind delete cluster --name {}
docker system prune --force
'스터디 > [gasida] ci-cd 스터디 1기' 카테고리의 다른 글
| Vault (0) | 2025.11.26 |
|---|---|
| OpenLDAP + KeyCloak + Argo CD + Jenkins (0) | 2025.11.23 |
| Arocd Rollout (0) | 2025.11.16 |
| ArgoCD + Ingress + Self Managed (0) | 2025.11.16 |
| 4주차: Argo (0) | 2025.11.09 |