devops

템플릿과 Role 🔧 Ansible 실습 시리즈 - Chap1. Ansible 실습 환경 구성과 첫 Playbook - Chap2. 변수와 조건문 - Chap3. 반복문과 핸들러 - Chap4. 템플릿과 Role 이전 포스팅에서 모듈로 고정된 설정 파일을 배포하고, handler로 변경 시에만 reload하는 패턴을 실습했습니다. 이번에는 Jinja2 템플릿으로 노드별 맞춤 설정을 생성하고, Role로 playbook을 구조화하는 방법을 다룹니다. 템플릿 (Jinja2 + template 모듈) Chap 3에서 모듈로 nginx 설정을 배포했습니다. 그런데 을 각 노드의 호스트명으로 다르게 설정하고 싶다면? 같은 파일을 3개 만들 수는 없습니다. copy vs template Helm의 디렉토리에서 으로 값을 주입하는 것과 동일한 개념입니다. 다만 Helm은 Go template이고, Ansible은 Jinja2(Python)라는 차이가 있습니다. 문법이 비슷해서 혼동할

반복문과 핸들러 🔧 Ansible 실습 시리즈 - Chap1. Ansible 실습 환경 구성과 첫 Playbook - Chap2. 변수와 조건문 - Chap3. 반복문과 핸들러 - Chap4. 템플릿과 Role 이전 포스팅에서 변수와 조건문으로 playbook을 유연하게 만들었습니다. 이번에는 반복문(loop)으로 여러 패키지를 한 번에 처리하고, 핸들러(handler)로 설정 변경 시에만 서비스를 reload하는 패턴을 실습합니다. 반복문 (loop) Chap 2에서 작성한 은 패키지를 하나만 설치합니다. 여러 패키지를 설치하려면 어떻게 해야 할까요? loop 없이 하면 패키지마다 task를 복사해야 합니다. 쿠버네티스에서 동일 구조의 Pod을 여러 개 만들기 위해 Deployment의 를 쓰듯, Ansible에서는 으로 해결합니다. loop 사용 - — 리스트를 순회 - — 현재 반복 요소를 참조하는 예약 변수 💡 예약 변수 은 사용자가 정의하는 변수가 아니라, Ans

변수와 조건문 🔧 Ansible 실습 시리즈 - Chap1. Ansible 실습 환경 구성과 첫 Playbook - Chap2. 변수와 조건문 이전 포스팅에서 nginx를 설치하는 playbook을 작성했습니다. 이번에는 패키지명을 하드코딩하지 않고 변수(vars)로 관리하고, 조건문(when)으로 상황에 따라 task 실행을 분기하는 방법을 실습합니다. 변수 (vars) Chap 1에서 작성한 을 다시 보겠습니다. 라는 패키지명이 여러 곳에 하드코딩되어 있습니다. 다른 패키지를 설치하려면 playbook 전체를 수정해야 합니다. 변수로 리팩토링 - — play 레벨에서 변수를 정의 - — Jinja2 문법으로 변수를 참조 ⚠️ 따옴표 필수 를 사용할 때는 반드시 따옴표로 감싸야 합니다. YAML 파서가 를 객체 시작으로 인식하여 문법 오류가 발생하기 때문입니다. 변수 정의 방법 변수를 정의하는 방법은 여러 가지입니다. Helm으로 비유하면 이렇습니다: 우선순위도 비슷합니다.

Ansible 실습 환경 구성과 첫 Playbook 🔧 Ansible 실습 시리즈 - Chap1. Ansible 실습 환경 구성과 첫 Playbook - Chap2. 변수와 조건문 Ansible은 에이전트 없이 SSH만으로 서버를 관리하는 자동화 도구입니다. 이번 포스팅에서는 Docker 기반 실습 환경을 구성하고, 인벤토리와 설정 파일의 역할을 이해한 뒤, 첫 Playbook으로 nginx를 설치해봅니다. 실습 환경 아키텍처 Docker Compose로 control 노드 1대 + managed 노드 3대를 구성합니다. Ansible은 에이전트리스(agentless) 구조입니다. managed 노드에 별도 소프트웨어를 설치하지 않고, control 노드에서 SSH로 접속하여 작업을 수행합니다. 쿠버네티스에서 kubelet이 각 노드에 설치되어야 하는 것과 달리, Ansible은 SSH 접속만 가능하면 됩니다. 4개 컨테이너는 브릿지 네트워크로 연결되며, control 노드에서

📦 Docker Hub 제한 탈출 — 온프레미스 Nexus Registry 구축기 Docker Hub의 Free 플랜에서는 Private Repository를 1개만 생성할 수 있다. 서비스가 하나일 때는 문제가 없지만, backend와 frontend처럼 이미지가 2개 이상 필요해지면 유료 플랜을 고려하거나, 자체 Registry를 운영해야 한다. 이 글에서는 온프레미스 Kubernetes 클러스터에 Nexus Repository Manager를 배포하고, 기존 Docker Hub 기반 CI/CD 파이프라인을 Nexus로 전환한 과정을 정리한다. 기존 구조와 문제점 기존에는 Jenkins(Kaniko)가 Docker Hub에 이미지를 push하고, 클러스터가 Docker Hub에서 pull하는 구조였다. 이 구조의 문제: - Private Repository 1개 제한 (Free 플랜): backend, frontend 두 이미지를 private으로 관리할 수 없음 - Pull

Kubernetes + Jenkins + ArgoCD로 검색엔진을 포함한 블로그 CI/CD 파이프라인 구축기 지금 이 글을 보고 있는 이 블로그는 온프레미스 Kubernetes 클러스터 위에서 돌아가고 있다. 사실 블로그 하나 띄우는 데 Kubernetes까지 필요하냐고 물으면, 솔직히 필요 없다. Vercel에 올리면 5분이면 끝난다. 근데 나는 이 블로그를 인프라 놀이터로 쓰고 싶었다. 코드를 push하면 이미지 빌드부터 배포, 검색 색인 갱신까지 자동으로 돌아가는 파이프라인을 직접 만들어보고 싶었고, 실제로 만들었다. 이 글에서는 이 파이프라인이 어떤 아키텍처로 구성되어 있고, 각 설계 결정에 어떤 이유가 있었는지를 실제 매니페스트와 함께 다뤄보려 한다. 전체 아키텍처 먼저 전체 그림을 보자. 핵심은 두 개의 Git 저장소가 역할을 분리한다는 것이다: - blog-new: 애플리케이션 소스코드. Next.js 앱, 마크다운 콘텐츠, Jenkinsfile, ES 색인 스크립트가

Kubernetes 에서 Jenkins로 Cacheable CI 파이프라인 구축하기 최근 Kubernetes 에서 Jenkins 멀티브랜치 파이프라인을 구축했습니다. DinD, DooD 의 태생적인 보안 문제 때문에, 빌드를 어떻게 진행할지 고민이 많았는데요, Kaniko 를 통해 도커데몬 없이 컨테이너 이미지를 빌드할 수 있다는것을 알게되었습니다. 본 포스트에서는 Kubernetes 환경에서 Jenkins의 agent pod을 통해 kaniko를 활용한 캐시재사용성이 있는 CI 파이프라인을 구축하는 방법에 대해 다뤄보겠습니다. Kubernetes에서의 Jenkins kubernetes 환경에 Helm 으로 Jenkins를 배포한 경우, Jenkins는 기본적으로 kubernetes api 를 호출할 수 있는 권한을 갖게 되고, 각종 플러그인도 미리 설치가 됩니다: - ServiceAccount Helm 차트는 기본적으로 jenkins라는 이름의 ServiceAc

ArgoCD 옵션을 통한 무한 리다이렉션 문제 해결기 ArgoCD를 사용하면서 Web UI 접속이 이상하게 계속 리다이렉션 되는 상황을 겪은 적이 있다. 기존 LoadBalancer 타입으로 배포된 argocd-server를 ClusterIP로 바꾸고, Gateway API에 노출하는 과정에서 발생한 일이었다. URL은 정확한데, 브라우저는 으로 계속 튕기고, 로그를 봐도 인증 자체는 성공한 듯 보이는데 진입하지 못했다. 상황 설명 - Gateway Controller: Istio - 인증서: cert-manager + Let's Encrypt - 외부 도메인: (dns01 wildcard 사용) - 서비스: 를 ClusterIP로 운영 - UI 접속을 위해 HTTPRoute로 외부에 노출 Gateway 및 HttpRoute 설정은 다음과 같이 구성했다: minseoky-gateway.yaml argocd-route.yaml 정확한 문제 상황 설명 이전에, 내 환경 이야기를

ArgoCD 사용시 K8s 리소스가 의도치 않은 네임스페이스에 생기는 경우 트러블슈팅 🧵 ReferenceGrant 네임스페이스 오버라이딩 문제 분석과 해결기 🐳ArgoCD 에서 Helm + Kustomize 를 함께 사용하여 관리하는 경우에 발생한 문제를 다룹니다. 쿠버네티스 Gateway API와 cert-manager를 함께 사용하는 경우, ReferenceGrant 리소스 설정은 TLS 인증서 발급 및 사용을 위해 꼭 필요하다. 복잡한 상황을 해소하고자 ReferenceGrant를 istio-system 어플리케이션에 몰아넣었는데, 문제가 발생했다. 여기에 문제 상황과 해결방법을 정리하고 공유하려 한다. 클러스터 상태 및 Gitops 이전 내 gitops 상황을 요약하면 아래와 같다. 크게 argocd, istio-system, jenkins, cert-manager 네 개의 어플리케이션을 관리하고 있다. Argocd + Helm + Kustomize 방식을 사용해서 관

CKA 합격 후기 2025년 6월, 올해 따기로 결심했던 자격증 중 하나인 CKA에 합격했다. 개정된 시험 포맷 이후 치른 시험이었고, DevOps, MSA 아키텍처, 인프라 자동화에 깊은 관심을 가져오던 나로서는 하나의 마일스톤이 되었다. 이 글에서는 내가 CKA에 합격하기까지 어떤 전략과 학습 경로를 거쳤는지, 어떤 부분에서 시간을 쏟았는지, 그리고 실전 시험에서 어떤 식으로 접근했는지를 공유하려한다. 왜 CKA인가? 나는 온프레미스 환경(Proxmox)에서 을 이용해 직접 Kubernetes 클러스터를 구축한 경험이 있다. 여기에 MetalLB, Calico CNI, Ingress, Istio, Helm 등을 직접 적용해보면서, Kubernetes는 나에게 단순한 관심사를 넘어 직접 다루고 싶은 도구가 되었다. 나는 백엔드 개발자이지만, 나 스스로를 단순히 "백엔드 개발자"로만 규정하고 싶지 않았다. 프론트엔드부터 인프라, 운영까지 전반적인 흐름을 이해하고 다룰 수 있는

🐳 DinD vs DooD: Docker 기반 Jenkins/Argo CI/CD 전략 분석 Docker 기반의 CI/CD 파이프라인을 구성할 때, Jenkins나 Argo 같은 자동화 도구에서 Docker를 어떻게 실행할지에 따라 DinD(Docker-in-Docker) 와 DooD(Docker-outside-of-Docker) 두 가지 방식 중 선택하게 된다. DinD (Docker-in-Docker) 컨테이너 내부에서 자체적으로 Docker 데몬을 실행하여, 완전한 격리 환경을 제공한다. 예를 들어, Jenkins Job이 실행되는 컨테이너 안에서 독립적인 Docker 데몬을 구동하여, 그 안에서 다시 컨테이너를 실행하는 구조이다. 이러한 방식은 테스트 환경을 완전히 분리하고자 할 때 유용하다. 그러나 --privileged 권한이 필요하며, 보안상 위험이 존재하고 리소스 사용량이 많을 수 있다. DooD (Docker-outside-of-Docker) 컨테이너에서 호스트의 D

Chap 17. Workflow 관리 Argo workflow 쿠버네티스 core API에는 일회성 배치 작업을 수행하는 Job 리소스가 존재한다. 간단한 retry정책이나 parallel 실행이 가능하지만 작업간 종속성 부여, 조건부 실행, 에러 핸들링 등 고급 워크플로우 관리 기능은 부재한다. 이를 해결하고자 Argo Project에서 Argo workflow를 개발했다. Argo workflow는 쿠버네티스 워크플로우 엔진으로 CNCF의 incubating 프로젝트로 등록되어 있다. 사용자가 원하는 Workflow를 직접 구성할 수 있으며 작업간 종속성을 만들어 순차적으로 실행할 수 있다. 또한 병렬실행이나 에러 핸들링 등과 같은 고급 워크플로우 관리 기능과 사용자를 위한 웹 UI도 제공한다. 사용자는 쿠버네티스 내장 리소스처럼 워크플로우를 생성, 삭제 및 관리할 수 있다. 동작 방법 Argo workflow도 다른 Operator와 마찬가지로 사용자 정의 리소스에 따라 사용자

Chap 16. 사용자 정의 리소스 사용자 정의 리소스란? Custom Resource 사용자 정의 리소스는 쿠버네티스 API를 사용자가 원하는대로 확장한 리소스를 말한다. 예를 들어, 쿠버네티스 코어 API에 Pod라는 리소스가 있지만 사용자가 원하는 특별한 기능을 더한 MyPod라는 리소스를 새롭게 정의할 수 있다. 쿠버네티스에는 사용자가 쉽게 API를 확장할 수 있도록 CustomResourceDefinition(CRD)라는 리소스를 제공한다. CRD는 바로 새로운 리소스를 정의하는 리소스이다. - kind: CustomResourceDefinition — 이 리소스가 CRD임을 나타냄. 쿠버네티스에서 새로운 리소스 타입을 정의할 때 사용함. - name: mypods.crd.example.com — CRD의 전체 이름. . 형식을 따르며, 이 이름으로 API 서버에 등록됨. - group: crd.example.com — 해당 CRD가 속한 API 그룹. 커스텀 리소스는 코어

Chap 14. 로킹과 모니터링 쿠버네티스는 기본적으로 내장하고 있는 로깅 및 모니터링 시스템이 없다. 대신 그 기능을 Cloud Native 생태계에 맡겼다. 이번 장에서는 로킹은 EFK 스택을 이용하여, 모니터링은 Prometheus, Grafana를 이용하여 시스템을 구축해보자. 로깅 시스템 구축 클러스터 레벨 로깅의 장점 kubectl logs 명령어를 사용하면 컨테이너의 로그를 바로 확인할 수 있다. 그렇다면 왜 따로 클러스터 레벨의 로깅 시스템이 필요할까? 1. 로그 히스토리 저장 pod가 실행 중인 경우에는 kubectl logs 를 통해 로그 메시지를 확인할 수 있지만 Pod가 죽게 되거나 1회성 배치 작업인 경우, Pod가 사라지게 되어 로그 기록도 같이 삭제된다. 클러스터 레벨의 로깅 시스템을 따로 구축하여 로그 기록을 저장하면 언제든지 과거의 로그 기록들을 확인할 수 있다. 2. 시스템 컴포넌트 로그 통합 쿠버네티스에는 컨테이너뿐만 아니라

Chap 13. 접근 제어 쿠버네티스에서는 사용자의 인증/인가를 통해 아래 3단계를 통과해야 시스템에 접근할 수 있다.. 1. Authentication(인증): 접속한 사람의 신분을 인증하는 단계(누가 접근하는가). 2. Authorization(인가): 어떤 권한을 가지고 어떤 자원에 어떤 행동을 할 수 있는지 확인하는 단계. 3. Admission Control: 요청한 내용이 적절한지 확인하는 단계이다 - LimitRange, ResourceQuota 기능이 Admission Control을 통해 Pod 요청이 적절한지 확인한 예시이다. 사용자 인증 쿠버네티스에는 크게 5가지 사용자 인증 방식이 존재한다. - HTTP Authentication: 토큰, 베이직 인증 사용 - X.509 Certificate: 인증서 기반 사용자 인증 - OpenID Connect: OAuth 기반 외부 인증 - Webhook 인증: 외부 서버에 인증 위임 - Proxy 인증: 프록시 서버