Argo CD 설치 및 Autotrade app 자동배포 파이프 만들기 - Gitops 형상관리

 개요

Git 리포지토리에 저장된 Kubernetes 매니페스트를 클러스터와 연동하여, 변경 사항을 자동으로 감지·반영하거나 필요 시 수동으로 동기화하는 GitOps 기반 배포 자동화 도구입니다. 이를 통해 애플리케이션 배포 과정을 코드로 관리하여 일관성과 안정성을 높이고, 배포 파이프라인의 투명한 변경 이력 관리를 가능하게 합니다.


설치

helm install argocd oci://ghcr.io/argoproj/argo-helm/argo-cd \

  --namespace argocd \

  --create-namespace \

  --set configs.params."server\.insecure"=true \

  --set server.ingress.enabled=true \

  --set server.ingress.hostname="argocd.apps.lab3.dslee.lab"


암호확인

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d

암호 수정

argocd login localhost:8080 
argocd account update-password

깃허브 리포지토리 추가 예시

argocd repo add https://gitlab.cicd.local/pj1/pilot-app-1.git \
 --username admin@example.com \
 --password ...-rzfqbCiMr97Pbc- \
 --insecure-skip-server-verification

깃러브 Manifests (deployment 와 kustomization 파일을 생성 합니다.)
https://github.com/dslee1371/gitops/tree/main/autotrade-binance

애플리케이션 생성





생성되며, Sync 하고, 정상 상태가 확인 됩니다.(Healthy, Synced)




수동으로 새로운 버전으로 배포하기: 

GitOps 기반 배포 도구(예: Argo CD)에서는 애플리케이션을 자동 동기화(Auto‑Sync) 또는 수동 동기화(Manual Sync) 방식으로 배포할 수 있습니다. 이 절차에서는 수동 동기화를 통해 새 버전을 배포하는 과정을 단계별로 설명합니다.


1. 새 버전 감지

  • 애플리케이션의 Git 리포지토리에 코드 변경(커밋·푸시)이나 새로운 태그가 올라가면, UI 상에서 해당 애플리케이션의 상태가 OutOfSync로 표시됩니다.

  • 이는 “내부(클러스터)에 반영된 버전”과 “Git상의 최신 버전”이 일치하지 않음을 의미합니다.

2. OutOfSync 상태 확인

  1. 대시보드의 애플리케이션 리스트에서 OutOfSync 뱃지가 붙은 항목을 찾습니다.

  2. 혹은 애플리케이션 상세 페이지로 들어가서 상단 상태 표시줄에서 OutOfSync를 확인할 수 있습니다.

3. Sync 버튼 클릭

  • OutOfSync 상태인 애플리케이션의 상세 페이지 우측 상단에 있는 Sync 버튼을 클릭합니다.

4. 동기화 옵션 설정 (선택사항)

Sync 창이 뜨면 다음 옵션을 필요에 따라 활성화할 수 있습니다:

  • Prune Resources: Git에서 제거된 리소스를 클러스터에서도 함께 삭제

  • Dry Run: 실제로 적용하지 않고 시뮬레이션만 수행

  • Force Apply: 충돌이 있더라도 강제로 덮어쓰기

옵션을 선택한 뒤 Synchronize(또는 Sync) 버튼을 눌러 배포를 시작합니다.

5. 배포 진행 및 결과 확인

  • 동기화 로그가 실시간으로 출력되며, 각 Kubernetes 리소스가 업데이트되는 과정을 볼 수 있습니다.

  • 완료되면 상태가 Synced로 바뀌고, Health 상태(Healthy 등)를 통해 정상 여부를 최종 확인합니다.

Tip.
매번 수동으로 배포하는 번거로움을 줄이려면, 애플리케이션 설정에서 자동 동기화(Auto‑Sync) 기능을 켜두세요. Git 리포지토리가 변경될 때마다 자동으로 동기화가 수행됩니다.




댓글

댓글 쓰기

이 블로그의 인기 게시물

금융권 망분리 환경에서 클로드 코드 도입할 때 실제로 걸리는 5가지 — 보안팀 질문과 대응 설정

이미지
카드사·신용평가사 대형 SI와 멀티클라우드·Kubernetes 운영을 20년 가까이 해 왔고, 최근에는 사내 AI 코딩 도구 도입과 거버넌스(가드레일) 설계를 다루고 있습니다. 이 글은 금융권처럼 망분리·보안 심사가 있는 환경에서 클로드 코드(Claude Code)를 도입할 때 실제로 어디에서 막히고, 무엇을 준비하면 통과하는지를 정리한 것입니다. 도입이 막히는 지점은 기술이 아니라 "질문"입니다 클로드 코드는 파일을 읽고 쓰고, 셸 명령을 실행하고, MCP로 외부 도구까지 부르는 에이전트입니다. 개발자 입장에서는 강력하지만, 정보보호팀 입장에서는 "우리 소스코드와 데이터를 외부로 내보내고, 운영 환경에 명령을 내릴 수 있는 프로그램"입니다. 그래서 심사에서 나오는 질문은 늘 비슷합니다. 이 질문에 설정 파일과 증적으로 답할 수 있으면 통과하고, 말로만 답하면 막힙니다. 보안팀이 반드시 묻는 5가지와 대응 1. 소스코드가 외부로 나가는가? 나갑니다. 이걸 부정하려고 하면 신뢰를 잃습니다. 대신 두 가지를 준비합니다. 첫째, 벤더의 데이터 보존 정책(학습 미사용, 보존 기간) 을 계약 문서·DPA로 확보합니다. 둘째, 나가면 안 되는 파일은 아예 읽지 못하게 설정으로 막습니다. .claude/settings.json 의 permissions.deny 에 .env* , *.pem , *.jks , 운영 프로파일 설정을 넣으면 클로드가 그 파일을 열 수 없습니다. 1번에서 막히면 나머지는 의미가 없으니 계약 확인부터 하세요. 2. 어떤 경로로 나가는가? 망분리 환경에서는 "직접 호출 경로가 막혀 있다"는 것을 증적으로 보여야 합니다. 구성 패턴은 세 가지입니다. 프록시 화이트리스트 : 개발망에서 벤더 API 도메인만 프록시로 허용. 가장 단순하고 빠릅니다. HTTPS_PROXY 환경변수로 클로드 코드가 프록시를 타게 합니다. 사내 LLM 게이트웨이 : 모든 호출을 사내 게이트웨이로 보내고 게이트웨이가 벤...
자세한 내용 보기

맥 스튜디오 M5 Ultra 512GB, 3,000만원을 어떻게 결제할까 — 카드 한도 상향·18개월 무이자·잔존가치 금융리스 총정리

이미지
맥 스튜디오 M5 Ultra 512GB 는 10월 말 국내 출시가 예고된, 개인이 살 수 있는 사실상 가장 강력한 AI 워크스테이션입니다. 문제는 가격입니다. 512GB 메모리에 대용량 SSD까지 얹은 풀옵션은 3,000만원 안팎까지 갈 수 있는 금액이라, 이 정도면 "무이자 할부 몇 개월"로 해결되는 영역을 벗어납니다. 이 글은 카드 한도 상향과 무이자 할부 , 금융리스·운용리스와 잔존가치 , 신용대출·마이너스 통장 , 사업자 비용 처리 까지, 3,000만원짜리 맥 스튜디오를 현실적으로 들이는 금융 상품 조합을 정리한 구매 전 체크리스트입니다. ▲ 3,000만원 결제 로드맵: 한도 확보 → 무이자 할부 → (사업자) 잔존가치 금융리스 1. 맥 스튜디오 M5 Ultra 512GB, 지금 알려진 것과 가격 전망 애플은 2026년 8월 25일 M5 Max / M5 Ultra 칩을 탑재한 신형 Mac Studio를 발표했고, 기본 모델은 9월 22일부터 배송이 시작됐습니다. 국내 출고가는 M5 Max 모델 4,290,000원, M5 Ultra 모델(30코어 CPU, 64코어 GPU, 96GB 메모리, 1TB) 9,490,000원부터입니다. 핵심인 512GB 통합 메모리 구성 은 별도로 10월 말 출시 예정입니다. M5 Ultra는 최대 36코어 CPU, 80코어 GPU, 1.2TB/s 메모리 대역폭을 갖춘 쿼드 다이 구조로, 512GB 메모리를 얹으면 GPU 서버 없이도 수천억 파라미터급 LLM을 로컬에서 돌릴 수 있는 사양이 됩니다. 미국 매체들은 512GB 구성의 시작가를 1만 달러 이상, 저장 장치를 최대 옵션(16TB)으로 채우면 2만 달러를 넘길 것으로 내다봅니다. 국내 원화로 환산하면 512GB 기본 구성이 대략 1,500만~2,000만원대, 512GB + 대용량 SSD 풀옵션은 3,000만원 안팎 이 될 가능성이 큽니다. 국내 가격은 10월 말 공개 전까지 확정되지 않았으므로, 이 글에서는 실제로 사고 싶어지는 구성인 풀...
자세한 내용 보기

Kubernetes Pod Pending 해결법: FailedScheduling 원인별 실전 점검 가이드

이미지
Kubernetes를 운영하다 보면 Deployment를 배포했는데 Pod가 Pending 상태에서 움직이지 않는 경우가 있습니다. 재시작부터 해보거나 무작정 노드를 증설하기 전에, 스케줄러가 남긴 이벤트를 읽으면 대부분의 원인을 빠르게 찾을 수 있습니다. 이 글에서는 실무에서 자주 만나는 FailedScheduling 메시지를 기준으로 CPU·메모리 부족, taint, nodeSelector, PVC, Pod 수 제한 문제를 순서대로 점검하는 방법을 정리합니다. 1. Pending은 장애 원인이 아니라 현재 상태다 Pending은 Pod 객체가 생성됐지만 아직 실행할 노드가 결정되지 않았거나, 컨테이너 실행에 필요한 준비가 끝나지 않았다는 뜻입니다. 따라서 kubectl get pods 결과만 보고는 원인을 알 수 없습니다. kubectl get pods -A --field-selector=status.phase=Pending 문제가 발생한 Pod를 찾았다면 가장 먼저 상세 정보와 이벤트를 확인합니다. kubectl describe pod <pod-name> -n <namespace> kubectl events -n <namespace> --for pod/<pod-name> describe 출력의 맨 아래 Events 영역에 있는 Reason과 Message가 핵심입니다. 여러 메시지가 반복된다면 가장 최근의 Warning / FailedScheduling 부터 읽습니다. 2. 가장 흔한 원인: CPU 또는 메모리 부족 다음과 같은 메시지가 보인다면 Pod가 요청한 리소스를 수용할 노드가 없다는 뜻입니다. 0/3 nodes are available: 3 Insufficient cpu. 0/3 nodes are available: 2 Insufficient memory. Kubernetes 스케줄러는 현재 사용률이 아니라 Pod에 설정된 resources.requests 의 합계를 기준으로...
자세한 내용 보기