DevOps Story

ApplicationSet이 왜 필요할까? K8s를 사용하는 조직이라면, 클러스터를 목적에 따라 여러개로 구분하여 활용하는 곳이 대부분일 것이다. 환경별(Dev, Staging, Prod 등) 클러스터를 따로 구성하거나, 규모가 큰 기업은 프로젝트, 팀 또는 계열사마다 따로 클러스터를 사용하는 경우를 예로 들 수 있다. 이제 Argo CD와 연결된 여러 개의 클러스터에 동일한 Application을 배포하는 경우에 대해 생각해보자. 예를 들어, Dev, Staging, Prod 클러스터에 Prometheus를 배포한다면, Argo CD에 이름만 다르고 내용은 같은 Application 3개를 추가해야 한다. 클러스터와 애플리케이션이 많아질 수록 이런 단순 반복 작업(Toil)이 늘어나기 때문에, 자동화가..

Retry Strategy 실제 서비스 운영시, DB 연결시 Timeout 등의 문제로 프로세스를 재시작해야 하는 경우가 발생할 수 있다. Argo Workflows에서도 Task에서 에러 발생시, task를 다시 생성하여 재시도하는 기능을 제공한다. 다음은 일부러 Python 스크립트 에러를 발생시켜 지정된 횟수만큼 retry를 하는 워크플로우 예시이다. apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: generateName: wf-retrystrategy- spec: entrypoint: dag-template arguments: parameters: - name: messageA value: A templates: - name: dag-temp..

Secret Template 정의시, 미리 생성해 놓은 K8s Secret 또는 ConfigMap 리소스를 사용할 수 있다. 우선 다음 명령어로 Secret 'test-secret'을 생성한다. kubectl -n argo create secret generic test-secret --from-literal test-password="Password123" 그리고 wf-artifact 워크플로우를 아래와 같이 수정하여, secret을 환경변수로 사용하는 'wf-secret-env'를 정의하였다. apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: name: wf-secret-env spec: entrypoint: dag-template argument..

Parameters Workflow를 정의할 때, template에서 사용할 변수를 정의하고 해당 template 호출시 값을 전달해 줄 수 있는 이를 Parameter라고 한다. Argo Workflows에는 Input과 Output 두가지 타입의 Parameter가 존재한다. Input Input Parameter의 값을 달리 하여, Template 실행시 다른 동작을 하도록 구성할 수 있다. 이전에 작성했던 wf-dag-template.yaml을 수정하여, 다음과 같은 Workflow manifest를 작성해보자. apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: name: wf-input-parameter-templates spec: entry..

Core Concepts 이번 시간엔 Argo Workflows의 기본 개념과 Workflow에 대해서 알아보자. 가장 먼저 Argo Workflows 공식 홈페이지에서 제공하는 간단한 'Hello world' 예제부터 시작한다. 'Hello world' Workflow 아래와 같이 'wf-hello-world.yaml'을 작성한다. apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: generateName: hello-world- # Name of this Workflow spec: entrypoint: whalesay # Defines "whalesay" as the "main" template templates: - name: whalesay # ..

Argo Workflows Workflow 엔진의 필요성 Kubernetes가 웹서버 형태로 동작하는 마이크로서비스를 배포하기에 최적화된 플랫폼인 것은 부정할 수 없는 사실이다. 다만 현실 세계에서 부딪힐 수 있는 문제 중엔 단순 Batch 또는 Machine Learning, ETL(Extract, Transform, Load)과 같이 일회성의 프로세스들이 일련의 흐름으로 묶인 작업을 처리할 경우가 있다. K8s에선 이를 위해 Job, CronJob 등의 Workload를 제공하나, 이것만으로 여러 컨테이너가 유기적으로 연결되도록 구성하기엔 많은 어려움이 있다. 현재 시장엔 K8s의 기능을 확장시켜 복잡한 Workflow를 생성, 실행할 수 있는 다양한 솔루션이 존재하며, 이를 Workflow Engi..

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

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

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

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