Jenkins X v3 란 무엇인가? - 1

목차

• 들어가기 전에
• GitOps란?
• Jenkins X란?
  • jx-git-operator namespace
  • jx namespace
    • Lighthouse
  • Secret이란?
  • Secret-infra
• 마무리하며
• Reference

들어가기 전에

GitOps에 대한 간단한 설명과 최근에 베타 버전이 릴리즈 된 Jenkins X version 3에 대한 구조 및 개념에 대해 알아보도록 하겠습니다.

Minikube 환경에서 실습도 같이 진행하려고 준비해보았으나 베타 버전이라 그런지 참고자료가 많지않아 어려움을 겪고 있어 다음 편에서 실습 할 수 있는 환경을 구축해보도록 하겠습니다.

GitOps란?

GitOps란 Weaveworks라는 회사에서 처음 쓰기 시작하였고 Ci/CD 파이프라인 중 특별히 Delivery 초점을 가지고 탄생한 개념입니다.

"Single source of truth"(SSOT), 단일 진실의 원천; 어떠한 진실(결과)의 원인이 오직 단일한 원천(이유)에서 나왔다는 것을 의미합니다.

 

쉽게 예를 들자면, 어떤 아이가 울고 있으면(결과) 그것은 오직 아이스크림을 땅바닥에 떨어뜨렸기 때문(이유)이라고 가정해봅시다. 넘어져서 우는 것도 아니고 혼나서 우는 것도 아니라 오직 아이스크림을 땅바닥에 떨어뜨렸기 때문에 우는 것 입니다. 반대로 아이스크림을 제대로 들고 있으면 항상 웃고 그 아이가 웃는다면 이유는 칭찬을 받아서도 아니고 과자를 먹어서도 아니고 오직 아이스크림을 떨어뜨리지 않았기 때문입니다. 이것이 단일 진실의 원천입니다. 오직 그 진실(결과)이 오직 한가지의 원천(이유)에서 비롯된다는 것입니다.

 

쿠버네티스에 애플리케이션을 배포하는 방법은 여러가지가 있습니다. 가장 간단한 방법으로는 사람이 직접 kubectl를 실행해서 매니페스트(yaml)를 클러스터에 적용하는 것 입니다.

$ kubectl apply -f updated-deployments.yaml

물론 사람이 실행하기 때문에 번거롭게, 실수가 쉽게 발생한다는 문제가 있습니다. 이전 프로젝트에서 Git Action으로 CI/CD를 구현하였을 때 이 부분이 가장 실수가 많이 발생하는 부분이였고, 이 부분을 해결하기 위해서 Helm deploy Action도 사용해보았으나 EKS 클러스터 인증 문제가 까다로워 사용하지 못하였습니다. 그래서 보통은 자동화 도구를 사용합니다. Spinnaker, Jenkins X, Tekton, Argo CD와 같은 도구들을 사용해서 배포 작업을 자동화하는 것 입니다. 정리해보자면 GitOps란 Git저장소에 있는 내용을 쿠버네티스 클러스터에 그대로 반영해주는 것 입니다. Git 저장소에 있는 것을 쿠버네티스 클러스터에 동기화 합니다.

일반적으로 많이 사용하는 CI/CD 방법은 개발자가 소스 코드를 작성하고, Git 저장소에 올립니다. 그러면 Jenkins, CircleCI 같은 CI 툴에 의해서 테스트와 빌드 같은 작업이 실행된 후, 생성한 컨테이너 이미지를 컨테이너 저장소에 업로드 합니다. 그런 다음 CI/CD 툴에서 업로드된 컨테이너 이미지의 정보를 참조하여, 대상 서버에 배포하는 것 입니다. GitOps는 이러한 파이프라인의 배포 부분에서 약간 다르게 작동합니다. 컨테이너 이미지를 컨테이너 저장소에 업로드 한 후, 매니페스트가 저장되어 있는 Git 저장소를 가져옵니다. 그리고 매니페스트의 특정 부분(예를 들면 이미지 태그)을 업데이트 한 후, Git 저장소에 올리고 작업을 종료하게 됩니다.

 

오늘 알아볼 Jenkins X는 앞서 말한 CI/CD 방법과는 다르게 Git Operator가 Git 저장소를 조사(Polling)하여 변경 사항을 찾고, 각 변경 사항에 대해 Kubernetes Job을 실행하는 방식으로 동작합니다.

Jenkins X란?

흔히 Jenkins, Circle CI, Travis 와 같은 CI/CD 툴 들을 많이 들어보셨을 겁니다. Jenkins X도 개념은 크게 다르지 않습니다.

현재 클라우드 시대가 도래하면서 컨테이너 환경의 사용이 많아졌기 때문에 기존에 사용하던 Jenkins로는 따라갈 수 없었습니다.

아래와 같은 문제들도 있었다고 하네요.

• 장애가 나서 서비스가 내려갔을 경우 그동안의 git webhook 이벤트를 받을 수 없다.
• Disk 공간을 사람이 직접 비워주고 관리를 해주어야 한다.
• Plugin 버전이 맞지 않는 경우 장애가 발생한다.
• Branch가 여러개일 경우 속도가 느려진다.
• JVM으로 인해 사용중이지 않을 경우에도 메모리를 잡아먹으며 클라우드 환경에서는 불필요한 비용이 발생한다.

위와 같은 문제들로 인하여 Jenkins에서는 쿠버네티스 환경에 맞춘 새로운 CI/CD 툴인 Jenkins X를 개발하게 되었습니다.

Jenkins X는 컨테이너 환경에서 돌아가므로 Jenkins 만의 별다른 서버가 존재하지 않으며 참고한 문서에서는 웹 UI를 공식문서에서 제안한 대로 설정하여 사용할 수 있다고 하였는데 version 3에서는 octant로 웹 UI를 확인할 수 있습니다.

Jenkins X 3 Beta 버전이기 때문에 흐름만 이해

Jenkins X는 네임스페이스 별로 다음과 같은 마이크로서비스를 사용합니다.

• jx-git-operator
• jx
• secret-infra

jx-git-operator namespace

Git Operator 및 관려 부팅 작업을 포함합니다. 여기서 부팅 작업이라 함은 Jenkins X를 부팅하는 작업을 의미합니다.

jx namespace

주요 개발에 필요한 서비스들이 포함되어 있습니다.

• jx-build-controller PipelineRun 리소스를 감시하고 jx get build log(Application이 빌드 된 로그들), octant(UI 시각화) 및 파이프라인 시각화 도구에서 사용하는 관련 PipelineActivity 리소스를 생성/업데이트합니다.
• jx-pipelines-visualizer 빌드로그를 시각화
• jx-preview-gc-jobs Preview 가비지 컬렉션, Preview는 PullRequest가 생성되고 Merge가 안되어 있는 상태에서 생성되는 환경
• jxboot-helmfile-resources-gcactivities 오래되고 완료된 PipelineActivity resource를 가비지 컬렉션 합니다.
• jxboot-helmfile-resources-gcpods 오래되고 완료 된 파드들을 가비지 컬렉션 합니다.
• jx-kh-check 

lighthouse

lighthouse는 tekton 파이프라인을 생성하고, Pull Requests에 ChatOps를 트리거합니다.

Jenkins X 2 흐름도

흐름도에서 Prow가 하는 역할을 버전이 업그레이드 됨에 따라 lighthouse로 변경되었다고 생각하시면 됩니다.

먼저 개발자가 Git Repository로 소스를 푸시한다. 특정 branch (master, develop, staging)에 푸시될 경우 Lighthouse에서 이벤트를 받아 파이프라인을 처리한다. 그 후 Tekton에서 실질적인 파이프라인을 수행하는데 그 전에 Jenkins X가 사전 작업을 수행 후 넘겨주며 Application이 배포가 된다.

• lighthouse-webhooks git 공급자의 webhooks를 LighthouseJob 사용자 지정 리소스로 변환
• lighthouse-tektoncontroller LighthouseJob 사용자 지정 리소스를 tektonPipelineRun 리소스로 변환
• lighthouse-foghorn Lighthouse에서 트리거된 PipelineRun 리소스의 실행을 관찰하고, Pipeline Status ingiting을 업데이트하여 Pipeline이 Pull Request의 각 컨텍스트에 있는 파이프라인 시각화 도구와 함께 시작, 완료 또는 실패하는 것을 볼 수 있도록 합니다.
• lighthouse-keeper 자동으로 병합할 수 있는 Green Pipeline 및 필요한 승인 레이블을 사용하여 Pull Request를 엽니다.
• lighthouse-gc-jobs 가비지 컬렉션 입니다.

앞서 언급한 Preview, Lighthouse-keeper 관련 Pull Request

Secret이란?

Jenkins X 3에서는 Kubernetes External Secrets를 사용하여 다음과 같은 기본 비밀 저장소에서 수집된 비밀을 관리합니다.

• Alibaba Cloud KMS Secret Manager
• Amazon Secret Manager
• Azure Key Vault
• Hashicorp Vault
• GCP Secret Manager

이를 통해 간편하고 강력한 GitOps를 위해 다른 Kubernetes Resource 및 사용자 정의 Resource 정의를 Git에서 체크인 할 수 있습니다. 그런 다음 Git과 독립적으로 쉽게 비밀을 전환(교대)할 수 있습니다.

secret-infra namespace

• kubernetes-external-secrets ExternalSecrets을 위한 external-secrets/kubernetes-external-secrets이 포함되어 있습니다.
• pusher-wave Vault 또는 클라우드 Provider의 Secret resource를 사용하는 모든 마이크로 서비스의 롤링 업그레이드를 수행하기 위한 pusher/wave 서비스와 기본 저장소의 비밀 변경 기능이 포함되어 있습니다.

다음은 클라우드 Provider native secret manager를 사용하지 않을 경우 옵션 추가 사항입니다. Ex) minikube

• vault-operator Vault resource를 HashiCorp Vault 인스턴스로 변환하는 Vault Operator를 포함합니다.
• vault-instance default Vault resource를 생성하는 vault instance가 포함되어 있습니다.

마무리하며

Jenkins X v3가 베타 버전이라 처음에 실습환경 하기 전부터 레퍼런스가 많이 없을 걸 예상하기는 했지만 막상 막히는 부분이 생기고, 참고 할 문서가 없어 많은 시간을 할애하다 글또 마감일이 다가오니 급하게 개념정리 글로 주제를 변경하였네요. 그래서 그런지 의도와 다르게 독자분들에게 설명하는 식의 방향보다는 공부한 것을 정리하는 느낌이 많이 묻어 나오는 것 같습니다. 앞으로는 주제 선정전에 자세히 조사를해서 내가 커버할 수 있는 정도인지 생각하고 주제를 선정해야겠습니다.

Reference

- [Jenkins X 개념]

- [Jenkins X 공식문서]

- [GitOps 개념설명]