CI 도구로서의 젠킨스
젠킨스(Jenkins)
자바(Java)로 작성된 오픈 소스 자동화 서버
지속적 인도 프로세스를 구축하는데 널리 이용됨
- 장점: 유연성과 확장성
허드슨(Hudson)이라는 이름으로 공개된 바 있었으나, 오라클이 허드슨을 인수하고 독점 소프트웨어로 전환하기로 하자 이름을 젠킨스로 바꾸고 현재까지 오픈소스(MIT 라이선스) 솔루션으로 개발 지속 |
CI/CD시나리오
CI(Continuous Integration; 지속적 통합) 단계
- 일반적으로 개발자가 소스 코드를 커밋하고 푸시하는 것으로 시작
- 응용 소프트웨어를 자도응로 빌드, 통합
- (자동) 테스트를 통하여 배포할 수 있는 상태임을 확인
CD(Continuous Delivery/Deployment; 지속적 인도) 단계
- CI 단계에서 소프트웨어가 배포 가능한 상태임을 확인하는 것으로 시작
- 응용 소프트웨어를 컨테이너 이미지로 만들어 냄
- 포드, 디플로이먼트, 서비스 등 다양한 오브젝트 조건에 맞추어 (리미 설정한 파일을 통해) 배포
지속적 통합 파이프라인 (CI Pipeline)
리포지토리에 코드 커밋이 발생할 때마다 빌드, 단위 테스트, 정적 분석 등을 행함
쿠버네티스 클러스터에 구성한 젠킨스 CI
k8s클러스터 환경에 젠킨스에 의한 CI를 적용
젠킨스의 특징
❄️다양한 프로그래밍 언어 지원
플러그인을 통한 확장
- 사용자가 직접 플러그인을 작성해 젠킨스의 기능을 확장하는 것도 기능
❄️이식성
- 여러 종류의 컴퓨터에서뿐만 아니라 컨테이너 및 클러스터 환경에도 부드럽게 적용
❄️대부분의 소스 관리 시스템 지원
❄️분산 처리 지원
- 마스터/슬레이브 구조를 채택하여 여러 노드에서 작업 수행
❄️코드로 파이프라인 구성
- 프로세스 자동화에 적합
젠킨스 아키텍처
마스터-슬레이브 구조
- 슬리이브(slave)는 에이전트(agent)라고 부르기도 함
마스터
- 빌드 시작 트리거 포착 (예: 코드 커밋)
- 알림 (예: 빌드 실패를 사용자에게 전달)
- 클라이언트와 통신하며 HTTP 요청 처리
- 에이전트에서 실행 중인 작업의 우선순위 조정 등 빌드 환경 관리
에이전트
- 마스터에 의한 개시 후 모든 작업을 처리
수평적 확장
조직(개발팀, 테스트팀, 데브옵스팀)이 늘어날 때마다 마스터 인스턴스의 수를 늘려가는 방식
- 비교: 수직적 확장 - 마스터에 대한 부하가 증가함에 따라 마스터 시스템에 자원을 추가하는 방식
통합 자동화가 복잡해진다는 단점이 있으나, 다음과 같은 중요한 이점이 있음
- 마스터 역할을 하는 컴퓨터의 하드웨어 사양에 대한 부담이 감소 (특히, 조직이 많이 커진다면)
- 팀마다 각기 다른 설정이 가능
- 팀 전용 마스터 인스턴스가 있으므로 팀워크와 업무 효율이 높아짐
- 마스터 인스턴스 하나에 문제가 생겨도 다른 팀에 끼치는 영향이 최소화 됨
테스트 인스턴스와 프로덕션 인스턴스
중요! - 젠킨스 인스턴스는 항상 테스트용과 프로덕션용으로 분리 운용해야 함
- 개발팀보다는 운영팀에서 주의를 기울여야 하는 부분
다음과 같은 시스템 설정 변경이 일어날 때 프로덕션에 적용하기 이전 철저한 검증이 필요
- 젠킨스 소프트웨어의 업데이트
- 신규 플러그인 적용
- CI/CD 파이프라인의 변경 및 유지보수
k8s 클러스터에 젠킨스 설치
Helm
❄️대표적인 k8s용 패키지 매니저
❄️오브젝트 배포에 필요한 사양이 이미 정의된 차트(chart)를 이용하여
패키지를 검색하고 내려받아 설치
❄️공개되어 있는 소프트웨어 패키지를 k8s에 배포하는 것 외에도
❄️배포 효율화를 위해 많이 이용되는 방법
❄️(Linux의 예와 비교하자면)
- RedHat 계열의 rpm, yum 또는 Debian 계열의 apt와 비슷한 방식으로 동작
Helm의 기능
패키지 검색
- 설정한 저장소(리포지토리)에서 패키지를 검색할 수 있음 (저장소는 목적에 따라 추가 및 변경 가능)
패키지 관리
- 저장소에서 패키지 정보를 확인하고 사용자 시스템에 패키지 설치, 삭제, 업그레이드, 롤백 등을 지원
패키지 의존성 관리
- 패키지를 설치할 때 의존성 관계에 있는 소프트웨어를 같이 설치하고
- 패키지를 삭제할때 필요하지 않게 된 소프트웨어를 함께 삭제
패키지 보안 관리
- 디지털 인증서와 패키지 체크섬(checksum)을 이용하여
- 해당 패키지의 소프트웨어 또는 의존성 관계가 젼조되었는지 확인할 수 있음
- (악의적인 공격으로부터 보호)
Helm의 설치
Helm 프로젝트에서 소프트웨어를 얻어다가 설치
- 각자의 환경에 맞는 바이너리 릴리스를 찾아서 다운로드하고 설치하는 방법
- 설치 스크립트만 받아다가 이것을 실행함으로써
- 스크립트가 적절한 버전을 얻어다 설치하도록 하는 방법
패키지 매니저를 이용하여 설치
- Windows - Chocolatey와 Scoop 이용가능
- MacOS - Homebrew 이용가능
- Linux - apt/yum 등 이용가능
Ubunto apt를 이용하여 설치
GPG 키를 받아서 /usr/share/keyrings/helm.gpg로 저장
curl https://baltocdn.com/helm/signing.asc | gpg --dearmor | \
sudo tee /usr/share/keyrings/helm.gpg > /dev/null
apt-transport-https 패키지 설치
sudo apt install -y apt-transport-https
Helm을 받아오기 위한 apt repo 설정
echo "deb [arch=$(dpkg --print-architecture) \
signed-by=/usr/share/keyrings/helm.gpg] \
https://baltocdn.com/helm/stable/debian/ all main" \
sudo tee etc/apt/sources.list.d/helm-stable-debian.list
Helm 패키지 설치
sudo apt install -y helm
Helm을 이용한 Jenkins 설치
Helm 이용가능 확인, repo설정
helm repo add jenkins https://charts.jenkins.io
helm install jenkins jenkins/jenkins
Jenkins 설치 확인
kubectl logs sts/jenkins jenkins
먼저 포트 포워드(port forward)를 실행해서 k8s 클러스터 내에서 8080번 포트로 제공하고있는 jenkins 서비스에 로컬 컴퓨터의 포트를 연결해야함
- 로컬 컴퓨터의 포트 번호는 8080번이 아니어도 됨
kubectl port-forward svc/jenkins 8080:8080
Jenkins 관리자 비밀번호 알아내기
지금 설치된 Jenkins의 관리자 계정(admin)설정은 k8s의 secret 오브젝트로 관리됨
- 다음과 같은 방법으로 알아낼 수 있음 (초기 비밀번호 설정은 설치할 때마다 항상 같지 않음)
kubectl get secret jenkins \
-o jsonpath="{.data.jenkins-admin-password}" | base64 --decode && echo
Jenkins 관리자 비밀번호 변경
(주의) Jenkins 메뉴 (Users > Jenkins Admin > Configure)에서 변경한 사항은 포드가 새로 실행할 때 적용되지 않아 원래의 비밀번호로 되돌려짐
- k8s 오브젝트(secret)을 변경해서 admin(Jenkins Admin) 계정의 비밀번호를 적용해야 함
kubectl get secrets jenkins
kubectl edit secrets jenkins
data안에 있는 jenkins-admin-password, user는 Base64방식으로 인코딩되어 있음
원하는 문자열을 base64로 인코딩해서 k8s secret 설정 파일에 적용
echo "원하는 비밀번호" | base64
하면 base64로 인코딩된 문자열 값이 나오는데 이 결과를 edit의 password에 변경하면 된다.
이후 포드 jenkins-0을 삭제하여 k8s에 의해서 포드 재시작하고 나면
(STATUS = Ready 될 때까지 시간이 좀 걸림)
변경된 admin 비밀번호로 로그인 가능
Jenkins 기초 설정
언어 설정
- 사용자 인터페이스에 기본적으로 적용되는 언어 설정을 영어로 고정
- 메뉴명 등이 달라서 겪을 수 있는 혼란을 피하려는 목적
- 플러그인 "Locale"을 설치
- Manage Jenkins > System > Locale
시간대 설정
- 자신이 살고있는 지역의 시간대로 서버 시간대를 설정
- 빌드 시작 및 종료 시각 등의 기록을 해석하는데 혼란을 피하려는 목적
- People > [계정 선택] > Configure > User Defined Time Zone
젠킨스 기본 사용법
클러스터 내 에이전트 동작 관찰
k8s 클러스터에서 Jenkins는 에이전트를 동적으로 프로비저닝
- 이를 위해서 Kubernetes 플러그인이 설치되어 있어야 하며, 적절한 설정도 되어 있어야함
- 우리의 실습에서는 helm을 이용하여 Jenkins를 설치할 때 이러한 설정들도 (기본값으로)구성되어 있음
동적 에이전트 프로비저닝 테스트
- (인위적으로) 빌드 과정이 오래 걸리는 파이프라인을 구성
- 순차적으로 여러 차례의 빌드를 스케줄("Build Now" 버튼을 여러 번 눌러서)
- Jenkins의 동작과 k8s 클러스터의 상태를 관찰
젠킨스 프로젝트 설정
'공부 > 타입스크립트로 함께하는 웹 풀 사이클 개발(React, Node.js)' 카테고리의 다른 글
웹 개발 파이프라인 구축(5) (2) | 2024.12.06 |
---|---|
웹 개발 파이프라인 구축(4) (1) | 2024.12.05 |
웹 개발 파이프라인 구축(2) (0) | 2024.12.03 |
웹 개발 파이프라인 구축(1) (1) | 2024.12.02 |
Code contributor: 오픈소스 프로젝트 활용(5) (4) | 2024.11.29 |