전체 글419

• DevOps 신뢰성 설계의 모든 것: SLO부터 MTTR까지 (via Datadog) 완벽한 시스템은 존재하지 않는다.좋은 DevOps는 장애를 피하려 하지 않고, 장애를 예측하고 학습하는 구조를 만든다.그래서 SLO, RTO 같은 지표는 단순한 숫자가 아니라,‘신뢰할 수 있는 시스템을 설계하는 철학’의 표현이다.1. SLO / SLA / SLI 개념과 설계 방법1) 기본 개념SLI (Service Level Indicator)서비스 품질을 수치로 표현하는 측정 지표다.예: 성공한 요청 수 / 전체 요청 수, 평균 응답 시간, 가용 시간 비율.SLO (Service Level Objective)SLI에 기반해 조직이 달성하고자 하는 목표치를 명시한다.예: “한 달 동안 API 성공률 99.9% 유지”.SLA (Service Level Agreement)서비스 제공자와 고객 간의 계약 수준.. 프로그래밍공부(Programming Study)/DevOps-Cloud Native 2025. 11. 9.

• 

  예제로 배우는 Argo CD 3장: Argo CD 운영 고가용성과 실전 운영 전략1·2장에서 GitOps의 개념과 Argo CD의 기본 원리를 다뤘다면, 이번 장에서는 실제 운영 환경에서 Argo CD를 안정적이고 효율적으로 운용하는 방법을 살펴본다.운영 환경에서는 단일 인스턴스로는 충분하지 않으며, 고가용성(HA) 구성, 모니터링, 자동 동기화 제어, 재해 복구(Disaster Recovery) 전략이 필수적이다.1. 고가용성(HA) 구성의 필요성Argo CD는 단일 Pod로도 실행 가능하지만, 프로덕션 환경에서는 장애 복원력 확보가 필수다.특히 Application Controller와 Repo Server는 지속적으로 Git과 클러스터를 비교하기 때문에, 단일 장애로도 배포 전체가 중단될 수 있다.HA 모드의 핵심 개념Controller / Repo-s.. 스터디(Study)/CI·CD Study 2025. 11. 8.

• 

  예제로 배우는 Argo CD 2장: Argo CD 시작하기 GitOps의 실질적 구현1장에서 GitOps의 개념을 이해했다면, 이제 그 철학을 실제로 구현할 수 있는 대표적인 도구인 Argo CD를 살펴볼 차례다.Argo CD는 깃 리포지터리에 정의된 애플리케이션 상태를 쿠버네티스 클러스터와 자동으로 동기화하는 GitOps 기반 CD(Continuous Delivery) 도구다.이번 장에서는 Argo CD의 구성 요소, 설치 및 초기 설정, 깃 리포지터리와 클러스터 연결 방법을 정리한다.1. Argo CD란 무엇인가1.1 개념 정리Argo CD는 쿠버네티스 환경에서 GitOps 원칙을 실제로 구현한 도구다.즉, 깃 리포지터리의 선언적 매니페스트를 읽어, 해당 리소스들이 클러스터에서 동일한 상태로 유지되도록 지속적으로 동기화한다.Argo CD는 명시적 배포 명령이.. 스터디(Study)/CI·CD Study 2025. 11. 8.

• 

  예제로 배우는 Argo CD 1장: 깃옵스와 쿠버네티스 선언적 운영의 시작쿠버네티스 환경에서 배포 자동화를 구축하려면 단순한 스크립트 실행 이상의 접근이 필요하다.GitOps는 그런 문제를 해결하기 위해 등장한, 선언적 구성 관리와 자동 동기화를 기반으로 하는 새로운 운영 방식이다.이번 장에서는 깃옵스의 개념, 쿠버네티스가 이를 자연스럽게 받아들일 수 있었던 이유, 그리고 kind 클러스터를 활용한 기본 실습까지 살펴본다.1. 깃옵스란 무엇인가?1.1 개념GitOps는 Git + Operations의 합성어로,모든 인프라와 애플리케이션 배포 상태를 Git 리포지터리에 선언적으로 저장하고,그 리포지터리를 “단일 진리의 원천(Source of Truth)”으로 삼아 시스템을 운영하는 접근 방식이다.2017년 Weaveworks의 Flux 개발팀이 처음 제시했으며.. 스터디(Study)/CI·CD Study 2025. 11. 8.

• 

  20251013 여박총피법을 읽고난 후 수많은 정보가 넘쳐나는 시대다. 그러나 모든 정보가 가치 있는 것은 아니다. 우리가 해야 할 일은 그 정보가 삶을 더 가치 있게 만드는가를 기준으로 판단하는 것이다. 삶을 가치 있게 한다는 것은, 매일의 행동과 선택 속에서 떳떳한 윤리를 분별하고 실천하는 과정에서 비로소 드러난다. 즉, 머리로 아는 것이 아니라, 마음으로 분별하고 몸으로 검증해야만 알 수 있다. 어떤 주제나 핵심 개념에 몰두했다면, 그 주제에 맞는 본질적인 문제를 스스로 도출해야 한다. 그리고 그 문제를 중심으로 자료를 탐색하며, 서로의 관계를 맞추고 연결해야 한다. 이때 중요한 것은 자료의 양이나 속도가 아니라, 자료와 내가 융화되는 깊이다. 꼼꼼히 정리하는 것보다 더 중요한 것은, 얻은 자료를 따져보고 헤아려 그 속에서 깨달음을 길어.. 독서(Reading)/다산선생의 지식경영법 2025. 11. 1.

• 로컬 환경에서 Jenkins + Gogs + Kind(K8s) 기반 CI/CD 파이프라인 구축하기 가시다님께서 진행하시는 ci/cd 스터디 3주차 주제인 jenkins와 argocd 실습 내용을 기반으로 작성하였다.이번 글에서는 로컬 환경에서 CI/CD 전체 파이프라인을 직접 구축하는 과정을 단계별로 기록했다.Kind(Kubernetes in Docker), Jenkins, Gogs(Git 서버), 그리고 DockerHub를 활용하며,DevOps 파이프라인을 실제로 자동화하는 과정을 실습 중심으로 다룬다. 1. CI/CD 개념 정리소프트웨어 개발 프로세스는 일반적으로 다음 단계를 자동화한다.최신 코드 가져오기단위 테스트 작성 및 실행코드 개발테스트 재실행코드 푸시 및 병합코드 병합 후 컴파일통합 테스트빌드된 아티팩트 배포E2E 테스트 실행 (예: Selenium)이 과정을 Jenkins 파이프라인으로.. 스터디(Study)/CI·CD Study 2025. 11. 1.

• 

  GitOps Cookbook 8장: 고급 주제 8.0 들어가며GitOps의 기본 구조는 “Git 선언 → 자동 동기화 → 상태 유지”지만, 실제 운영환경에서는 보안, 멀티클러스터, 승인 흐름, 점진적 배포 등 복잡한 요구가 생긴다.이 장에서는 Argo CD를 중심으로 이런 고급 주제를 다룬다.8.1 민감한 데이터 암호화 (복원된 시크릿)GitOps의 핵심 원칙은 “모든 설정을 Git에 저장한다”지만, 문제는 시크릿(Secret)이다.비밀번호, 토큰, 인증서 등을 그대로 Git에 넣을 수는 없다. 이를 안전하게 관리하기 위해 다음 세 가지 접근법이 사용된다.Sealed Secrets (Bitnami)쿠버네티스 Secret을 암호화된 형태로 Git에 저장.Sealed Secrets Controller가 클러스터에서 자동 복호화.Git에는 복호화 불가능한.. 스터디(Study)/CI·CD Study 2025. 11. 1.

• 

  GitOps Cookbook 7장: Argo CD 7.0 들어가며쿠버네티스에서의 배포(Delivery)는 이제 수동 kubectl apply나 “사람이 파이프라인 마지막 단계에서 승인 → 배포” 같은 절차형 모델에서 벗어나고 있다.대신, 원하는 상태(Desired State)를 Git에 선언하고, 클러스터가 그 선언을 지속적으로 따라가도록 자동으로 유지시키는 방식이 보편화되고 있다. 이 방식을 GitOps라고 부른다.Argo CD는 GitOps 기반 쿠버네티스 전용 CD(Continuous Delivery) 컨트롤러다.Git 리포지토리를 단일 진실 공급원(SSOT)으로 삼는다.Git에 선언된 상태(Desired State)와 실제 클러스터 상태(Live State)를 비교한다.차이가 있으면 OutOfSync로 감지하고, 필요하면 자동으로 클러스터를 Gi.. 스터디(Study)/CI·CD Study 2025. 11. 1.

• 

  GitOps Cookbook 6장: 클라우드 네이티브 CI/CD 6.0 들어가며쿠버네티스 시대의 CI/CD는 더 이상 외부의 빌드 서버(Jenkins 등)에 작업을 던져놓고 결과물을 받아오는 방식만으로 끝나지 않는다.빌드, 테스트, 이미지 생성, 보안 스캔, 매니페스트 렌더링, 실제 배포(쿠버네티스 apply/upgrade), 심지어 Git에 결과를 기록하고 PR을 만드는 것까지 전부 클러스터 내부에서 일어날 수 있다.이 장은 그 전체 체인을 Tekton(텍톤), Kustomize, Helm, 그리고 GitHub Actions까지 연결해서 보여준다:텍톤 설치 → Task → Pipeline → Trigger빌드/패키징/이미지 푸시쿠버네티스 배포변경 내용을 Git에도 반영 (GitOps 스타일 업데이트)마지막으로 GitHub Actions로 비교/연계6.1 텍톤 설치텍.. 스터디(Study)/CI·CD Study 2025. 10. 25.

• 

  GitOps Cookbook 5장: 헬름 5.0 들어가며Helm은 쿠버네티스 애플리케이션을 “차트(chart)”라는 단위로 패키징하고, 템플릿 렌더링, 배포, 업그레이드, 롤백을 일관되게 다룰 수 있게 해주는 도구다. Helm은 kustomize처럼 매니페스트를 조합/변경할 수 있지만, 동시에 apt/yum 같은 패키지 관리자처럼 버전 있는 배포 아티팩트로 다룬다는 점이 다르다.운영 환경 기준에서 Helm 차트는 단순한 YAML 묶음이 아니라 배포 단위, 롤백 단위, 그리고 조직 표준(보안 컨텍스트, 라벨 정책 등)을 코드화해 강제하는 수단이다. Helm을 잘 설계하면 애플리케이션 팀과 플랫폼/보안 팀의 경계를 명확하게 만들 수 있다.5.1 헬름 프로젝트 생성Helm 차트란 무엇인가Helm 차트는 애플리케이션을 배포하는 데 필요한 쿠버네티스 리.. 스터디(Study)/CI·CD Study 2025. 10. 25.

• 

  GitOps Cookbook 4장: 커스터마이즈 4. 커스터마이즈 (Kustomize)4.0 들어가며KustomizeHomeDocsIntroExtending쿠버네티스 리소스를 YAML로 정의하고 배포하는 과정은 단순하지만, 운영 단계에선 환경별 차이로 인해 복잡해진다.이를 해결하기 위해 등장한 도구가 Kustomize다.템플릿이 아닌 패치(Patch) 기반 선언적 구성 방식을 사용하며,GitOps 및 CI/CD 파이프라인에 자연스럽게 통합된다.4.1 커스터마이즈 개념 및 배경4.1.1 목적과 특징Base: 공통 리소스 정의 (Deployment, Service 등)Overlay: 환경별 패치 정의 (dev, staging, prod 등)중복을 제거하고 YAML을 재사용할 수 있다.Git 저장소와 결합하면 변경 이력을 추적하며 인프라를 코드로 관리할 수.. 스터디(Study)/CI·CD Study 2025. 10. 18.

• 

  GitOps Cookbook 3장: 컨테이너 본 정리는 macOS(Apple Silicon/Intel 공통)에서 Docker Desktop + kind 환경을 기반으로, 컨테이너 이미지를 빌드/검증/배포하는 방법을 한 번에 따라 할 수 있도록 요약한 실습 가이드다. 예시의 모든 레지스트리 경로는 docker.io/chaany로 통일했다.3.0 들어가며컨테이너는 앱·런타임·라이브러리를 계층(layer) 구조로 패키징한 표준 포맷이며, OCI(https://opencontainers.org/) 표준을 따른다.개방형 표준(OCI) 덕분에 Docker, Jib, Buildah/Podman, Buildpacks, Shipwright(BuildKit) 등 다양한 도구로 이미지를 만들고 상호운용 가능하다.이하 절에서는 Dockerfile, Jib(자바), Bu.. 스터디(Study)/CI·CD Study 2025. 10. 18.