전체 글 77

Jenkins - Approval Stage 구현

빌드 및 테스트 완료 후, Production 환경에 업데이트 된 버전을 배포하기 전에 사용자의 별도의 승인을 요청하는 케이스를 생각할 수 있다. 우선 승인 요청이 발생했다는 사실을 Email, Slack, Jira 등으로 사용자에게 전달한 뒤, 파이프라인을 일시중지한 상태에서 진행/중단 입력을 기다리는게 이 동작의 핵심이다. 이번 시간엔 이메일을 보내고 사용자의 승인을 기다리는 시나리오로 진행해보자. Email Extension 우선 이메일을 보내기 위해 Email Extension 플러그인이 필요하다. 아직 설치하지 않은 경우, Jenkins Plugin Manager를 통해 쉽게 추가할 수 있다. 설치가 완료됐다면, 해당 플러그인의 SMTP 서버를 세팅해야 한다. 'Jenkins 관리' > '시스템..

CI-CD 2021.03.05

Jenkins - Container 기반 Agent

Intro Static Agent Jenkins를 오래전부터 사용했다면 대부분 Baremetal 또는 VM 기반의 Remote Agent를 마스터에 추가해 본 경험이 있을 것이다. 관리자가 직접 패키지, 컴파일러, 환경변수 등의 빌드 환경을 Agent로 사용할 장비에 미리 세팅해놓고, JNLP 또는 SSH를 통해 연결하는 방식이다. Job의 갯수나 관리할 Agent가 많지 않다면 큰 어려움이 없겠지만, 점점 규모가 커질 수록 아래와 같은 문제를 겪을 수 밖에 없다. Agent가 장애 등의 원인으로 Offline 상태가 될 경우 Agent 하나에 여러 Job을 빌드하기 위해 구성한 환경이 서로 충돌하는 경우 짧은 시간 동안 많은 빌드 요청이 발생하는 경우 On-demand Agent Jenkins Kube..

CI-CD 2021.03.03

Jenkins Pipeline

What is Jenkins Pipeline Jenkins에서 새로운 Job을 생성하거나 기존 설정을 변경하기 위해서, 대부분은 Web UI에서 매뉴얼 방식으로 작업한 경험이 있을 것이다. Job이 몇개 없고 설정도 단순하다면 큰 문제가 되지 않지만, 점차 구성이 복잡해지고 관리해야 할 Job이 늘어날 수록 이 방식은 적합하지 않다.. 예를 들어, 진행중인 프로젝트에 CI/CD 파이프라인을 적용한다고 하자. 동일한 소스 코드에 대해 빌드/테스트/배포 Job이 서로 분리되어 있으므로 설정도 따로 해야하고, 각 단계가 어떻게 진행되었는지 직관적인 파악이 어려운 경우가 있다. Jenkins Pipeline은 프로젝트의 전체 파이프라인을 개발자가 직접 정의한 코드 형태(Pipeline as Code)로 받아 하..

CI-CD 2021.03.01

kustomize를 활용한 Manifest 관리

Manifest의 재사용성 이 글을 읽고 있는 대부분의 사람은 Kubernetes에서 App 배포를 위해 Manifest 파일을 작성한 경험이 있을 것이다. 예를 들어 Nginx로 구성한 Frontend의 Deployment, Service, Persistent Volume, PVC, ConfigMap 등을 정의하고 "kubectl apply -f" 명령어로 적용하는 것이다. 현재 App을 배포한 Namespace를 dev라고 하고 테스트를 완료한 상태에서 production에 배포하려고 한다. spec이 동일하지 않고 일부 필드를 추가해야 하거나 환경변수 값이 다른 경우도 있다고 가정하자. 가장 단순한 해결책으로 기존에 작성한 Manifest 파일을 복사해서 production 환경에 맞게 수정하는 작..

CI-CD 2021.02.24

CD를 위한 Jenkins, Argo CD 연계

이전 포스트에서 Jenkins, GitHub, Docker Hub를 파이프라인으로 구성하여, 컨테이너 이미지 빌드를 자동화하였다. 이번 시간엔 Argo CD를 연계하여 배포까지 자동화된 CI/CD Pipeline을 만들어 볼 차례다. 우선 기존 구성에서 추가되는 내용은 다음과 같다. 1. Jenkins에서 Image 빌드 및 Push 후, 배포 전용 Repository에 새로운 이미지 태그 반영 2. Argo CD는 해당 Repository로부터 Auto Sync 수행 3. AutoSync를 통해 업데이트된 Manifest를 사용하여 리소스 재생성 참고로 GitHub와 Argo CD의 연결은 일반적으로 GitHub Webhook 방식을 사용하나, 현재 테스트 환경은 외부에서 Argo CD에 접근할 수 없..

CI-CD 2021.02.21

CI를 위한 Jenkins, GitHub, Docker Hub 연계

본격적인 CI 구성을 위해 Jenkins와 GitHub 그리고 Docker Hub를 연계하는 방법에 대해 설명한다. k8s 위에 Jenkins를 배포하는 방법에 대해선 이전 포스트를 참고한다. 실습 환경에서 CI는 다음과 같은 일련의 순서로 이루어진다고 가정하자. 1. 개발자가 자신이 작업한 코드를 GitHub Repository에 반영 2. Jenkins는 해당 Repository를 Checkout하여 Docker Image로 빌드 3. 빌드 완료 후 Docker Hub로 Image를 Push 실제 CI 과정에선 코드 리뷰나 테스트 등의 과정이 포함되어야 하나 이번 실습에선 생략하도록 한다. 우선은 Jenkihns가 GitHub에서 Code를 가져올 수 있도록 Credential을 추가하자. GitHu..

CI-CD 2021.02.20

Kubernetes 위에 Jenkins 설치하기

이번엔 Kubernetes 위에 Jenkins를 설치해보자. 가장 먼저 아래와 같이 Manifest 파일을 작성한다. [jenkins-master.yaml] apiVersion: apps/v1 kind: StatefulSet metadata: name: jenkins spec: serviceName: jenkins replicas: 1 selector: matchLabels: app: jenkins template: metadata: labels: app: jenkins spec: serviceAccountName: jenkins containers: - name: jenkins image: jenkins/jenkins:lts ports: - name: http-port containerPort: 808..

CI-CD 2021.02.19

ArgoCD: Kubernetes에 GitOps 적용하기

What is GitOps? 개발자의 코드가 실제 서비스로 반영되기까지 많은 과정을 거쳐야 한다. Repository에 Push 후 CI를 통해 Docker Image로 빌드되고, Container Registry(ex: DockerHub)로 업로드하면 CI 과정은 끝나며 이후부턴 Kubernetes에 어떻게 배포할지 고민이 필요하다. 처음엔 Manifest 파일을 작성하고 이를 kubectl 명령어를 통해 서비스를 배포하다가, 서비스마다 일일이 Manifest 파일을 작성하기 번거롭기 때문에 Helm, kustomize 등을 활용하고, 이후 자동화를 위해 Jenkins나 Ansible 등의 툴이나 API 호출같은 방식을 택하게 된다. 문제는 사람마다 선호하는 배포 방식이 제각각이고 여러 소스(원천)로부..

CI-CD 2021.02.17

Calico Components

이번엔 Calico를 구성하는 Component들에 대해 알아보자. 아래 그림은 Calico component와 관계를 설명하는 다이어그램이다. Felix Calico Datastore로부터 가져온 설정 정보에 맞게 Host의 인터페이스, 라우팅 테이블, iptables(kube-proxy 모드에 따라 IPVS가 될 수 있음)를 관리하여 패킷이 지정된 Pod에 정확히 전달될 수 있게 한다. 클러스터의 Network Policy를 위반한 패킷이 전송되지 않게 차단하는 ACL 기능도 제공한다. BIRD BGP Client 역할을 담당하는 Component다. Felix가 Route 정보를 Linux Kernel FIB(Forwarding Information Base)에 추가할 때, 이를 다른 Node에 공..

하이퍼바이저(Hypervisor)

하이퍼바이저(Hypervisor)는 하나의 물리적인 컴퓨터(Host Machine) 위에 여러개의 Guest(VM; Virtual Machine)를 동시에 실행할 수 있게 가상화하는 플랫폼을 의미한다. CPU(core), 메모리, 기타 물리적 자원(ex: Network, Storage)에 대한 가상화 레이어(Virtualization Layer)를 제공하며, 이를 통해 각 Virtual Machine에 필요한 만큼의 리소스를 할당할 수 있다. VM 입장에선 물리적 환경과 가상화 환경에 차이가 없다. 마찬가지로 하이퍼바이저의 존재와 다른 VM과 Computing Power를 공유하고 있다는 사실 역시 알 수 없다. 현존하는 하이퍼바이저는 대부분 다음 두가지 타입으로 구분할 수 있다. Types of Hyp..

Cloud 2021.02.06