2024년 12월 4일

*여기서 내가 명심해야할 것

• 빌드(Build) = 컴파일 + 그 외의 Task(작업)을 포함하는 개념
• 컴파일(Complie) = 소스코드를 기계어로 번역하는 작업, 빌드 과정 중 하나
  참고글: https://jay-so.tistory.com/73

✏️ CI 도구로서의 젠킨스

• 젠킨스 관련 글 : https://www.elancer.co.kr/blog/detail/741

• 젠킨스(Jenkins)

  • 자바(Java)로 작성된 오픈 소스 자동화 서버
  • 지속적 인도 프로세스를 구축하는데 널리 이용됨
  • 장점 : 유연성과 확장성
  • 허드슨 이라는 이름으로 공개된 바 있었으나, 오라클이 허드슨을 인수하고 독점 소프트웨어로 전환하기로 하자 이름을 젠킨스로 바꾸고 현재까지 오픈소스 (MIT 라이선스) 솔루션으로 개발 지속

• CI / CD 시나리오

  • CI(Continuous Integration; 지속적 통합) 단계

    • 일반적으로 개발자가 소스 코드를 커밋하고 푸시하는 것으로 시작
    • 응용 소프트웨어를 자동으로 빌드, 통합
    • (자동) 테스트를 통하여 배포할 수 있는 상태임을 확인

  • CD(Continuous Delivery / Deployment; 지속적 인도) 단계

    • CI 단계에서 소프트웨어가 배포 가능한 상태임을 확인하는 것으로 시작
    • 응용 소프트웨어를 컨테이너 이미지로 만들어 냄
    • 포드, 디플로이먼트, 서비스 등 다양한 오브젝트 조건에 맞추어 (미리 설정한 파일을 통해) 배포

• 지속적 통합 파이프라인(CI Pipeline)

  • 리포지토리에 코드 커밋이 발생할 때마다 빌드, 단위 테스트, 정적 분석 등을 행함
    

• 쿠버네티스 클러스터에 구성한 젠킨스 CI

  • k8s 클러스터 환경에 젠킨스에 의한 CI를 적용
    

• 젠킨스의 특징

  • 다양한 프로그래밍 언어 지원

  • 플러그인을 통한 확장

    • 사용자가 직접 플러그인을 작성해 켄킨스의 기능을 확장하는 것도 가능

  • 이식성

    • 여러 종류의 컴퓨터에서뿐만 아니라 컨테이너 및 클러스터 환경에도 부드럽게 적용

  • 대부분의 소스 관리 시스템 지원

  • 분산 처리 지원

    • 마스터 / 슬레이브 구조를 채택하여 여러 노드에서 작업 수행

  • 코드로 파이프라인 구성

    • 프로세스 자동화에 적합

  • 젠킨스 아키텍처
    

    • 마스터-슬레이브 구조

      • 슬레이블(slave)는 에이전트 (agent)라고 부르기도 함

    • 마스터

      • 빌드 시작 트리거 포착 (e.g. 코드 커밋)
      • 알림 (예 : 빌드 실패를 사용자에게 전달)
      • 클라이언트와 통신하며 HTTP 요청 처리
      • 에이전트에서 실행 중인 작업의 우선순위 조정 등 빌드 환경 관리

    • 에이전트

      • 마스터에 의한 개시 후 모든 작업을 처리

  • 수평적 확장

    • 조직(개발팀, 테스트팀, 데브옵스팀)이 늘어날때마다 마스터 인스턴스의 수를 늘려 가는 방식

      • 비교: 수직적 확장 - 마스터에 대한 부하가 증가함에 따라 마스터 시스템에 자원을 추가하는 방식

    • 통합 자동화가 복잡해진다는 단점이 있으나, 아래와 같은 중요한 이점 있음

      • 마스터 역할을 하는 컴퓨터의 하드웨어 사양에 대한 부담 감소 (특히, 조직이 많이 커진다면?)
      • 팀마다 각기 다른 설정 가능
      • 팀 전용 마스터 인스턴스가 있으므로 팀워크와 업무 효율이 높아짐
      • 마스터 인스턴스 하나에 문제가 생겨도 다른 팀에 끼치는 영향이 최소화됨

  • 테스트 인스턴스와 프로덕션 인스턴스

    • 중요! - 젠킨스 인스턴스는 항상 테스트용과 프로덕션용으로 분리 운용해야함
      • 개발팀보다는 운영팀에서 주의를 기울여야 하는 부분
    • 다음과 같은 시스템 설정 변경이 일어날 때 프로덕션에 적용하기 이전 철저한 검증이 필요
      • 젠킨스 소프트웨어의 업데이트
      • 신규 플러그인 적용
      • CI/CD 파이프라인의 변경 및 유지보수

✏️ k8s 클러스터에 젠킨스 설치

• Helm

  • 대표적인 k8s용 패키지 매니저 → 이걸 이용해서 젠킨스를 설치할 예정임
  • 오브젝트 배포에 필요한 사양이 이미 정의된 차트(chart)를 이용하여 패키지를 검색하고 내려받아 설치
  • 공개되어 있는 소프트웨어 패키지를 k8s에 배포하는 것 외에도 배포 효율화를 위해 많이 이용되는 방법
  • (Linux 의 예와 비교하자면)
    • RedHat 계열의 rpm, ym 또는 Debian 계열의 apt와 비슷한 방식으로 동작

• helm 설치

  • 참고 글 : https://tech.ktcloud.com/51 (나의 경우 brew 업데이트하는데 시간이 많이 걸려서 스크립트로 설치함)
    
    

• helm을 통해 jenkins 설치 (여기서부턴 강의 따라함)

  • Helm 이용 가능 확인, repo 설정
    
    

  • Helm을 이용한 Jenkins 설치
    
    

  • jenkins 설치 확인
    
    

  • 포트 포워드를 실행해 k8s 클러스터 내에서 8080번 포트로 제공하고 있는 jenkins 서비스에 로컬 컴퓨터의 포트 연결
    
    

  • localhost:8080 접속하면 아래와 같은 화면 확인
    
    

  • jenkins 관리자 비밀번호 알아내기

    • 지금 설치된 jenkins의 관리자 계정 (admin) 설정은 k8s의 secret 오브젝트로 관리됨

    • 알아낼 수 있는 방법 (초기 비밀번호 설정은 설치할때마다 항상 같지 않음)

      • kubectl get secret jenkins \ -o jsonpath=”{.data.jenkins-admin-password}” | base64 —decode && echo gnck1PSU7JYQUnmitznrfR

    • 비밀 번호가 어려우니깐 바꿔줘야함

      • kubectl get secrets jenkins
      • kubectl edit secrets jenkins
      • 아래의 파일의 내용 확인 할 수 있음
        
        
      • 원하는 비밀번호 인코딩해서 붙여넣고, 포드 삭제 후 다시 재시작하고 amin, 변경된 비밀번호로 로그인
        
        
        
        

• jenkins 기초 설정
  

  • 언어 설정
    • manage jenkins > plugins > available plugins > locale plugin 설치
      
      
    • manage jenkins > system > locale > en_US (나의 경우에는 원래 영어로 되어있어서 그런지 아무리 찾아도 locale이 없었음..)
  • 시간 설정
    • manage jenkins > users > account > timezone > asia/seoul
      
      

✏️ 젠킨스 기본 사용법

• 단순한 예제로 파이프라인 맛보기
  

  • dash board > new item > title : hello world + pipeline 선택 + 아래처럼 입력
    
    
  • build now 클릭 → 빌드 완료 되면 빌드 번호 누르면 → console output에서 아래의 내용 확인 할 수 있음
    
    

• 클러스터 내 에이전트 동작 관찰 (할 일이 있을 때 시키는 것)
  

  • dashboard > hello world > configure > advanced project options > sleep 300 입력 (5분 동안 빌드 대기시킴)
    
    
  • build now 5번 클릭하고 터미널에 kubectl get pods 입력하면 5개 포드들 확인 가능(이 포드들에서는 이미 설정되어있는 어떤 이미지로 만들어진 컨테이너가 돌고 있음)
    
    

• 내용 요약

  • Jenkins는 “Item” 단위로 프로젝트를 관리

    • 웹사용자 인터페이스를 이용해서 설정할 수 있고 상태를 열람할 수 있도록 되어 있음

  • 파이프라인에 빌드 절차를 기술할 수 있음

    • 앞에서는 매우 간단한 (echo ‘Hello, world!’) 동작을 시험 삼아 기술해 보았음

  • 빌드는 어떤 이벤트에 의하여 시작

    • “Build Now”를 클릭함으로써 수동으로 빌드 개시했음
    • 보통은 SCM (예: git) repository에 발생하는 이벤트 (예: push)에 의하여 트리거됨

  • k8s 클러스터에 운용되는 jenkins는 동적으로 에이전트 프로비저닝

    • 이와 관련한 설정은 이미 helm을 이용해 Jenkins를 설치할 때 이루어져 있었음

• dash board > manage jenkins > clouds > kubernetes > default > pod template settings

  • 여기서 포드가 만들어지는 것을 확인 할 수 있음

    • 포드가 생성되는데 컨테이너가 한 개 들어가고, 컨테이너 이름과 컨테이너를 만들 때 가져다 쓴 이미지를 확인할 수 있음
      

✏️ 젠킨스 프로젝트 설정

• 첫번째 실습
  

  • 준비
    
    

  • 깃허브 리포지토리 생성 + 파일들 업로드

  • Jenkins plugin docker pipline, kubernetes cli plugin 설치

  • 젠킨스 재시작

  • new item 추가 → name : simple-echo-1 + freestyle project → 아이템 생성

    • general → source code management : git 체크 + repository url 입력

    • build steps : execute shell 클릭 → command 에 아래 내용 입력

      docker build -t hongbiko/simple-echo .

      docker push hongbiko/simple-echo
      

    • save

  • build now 클릭 → build 되고 있는 #1 console-output 클릭 → failed됨

    • failed된 이유 : 도커 이미지에 도커 cli(command line interface)가 설치되어 있지 않기 때문

      • 따라서 도커 cli가 설치되어있는 에이전트 이미지를 가져다가 빌드 해야함
      • custom 에어전트를 등록하고 프로젝트에 에이전트를 이용하도록 함
        • manage jenkins > clouds > kubernetes > pd templates > add a pod template > 아래 내용 처럼 작성
          
          
        • 컨테이너 스펙을 작성해서 포드 템플릿의 설정 완성
          
          
        • containers > add container > container template (2개 넣을 것임)
          • jnlp 컨테이너 설정
            
            
          • demon 컨테이너 설정
            
            
          • create

  • dashboard → simple-echo-1 클릭 → general → restrict where this project can be run 체크 (이 아이템을 빌드하는데 있어서는 특정한 템플릿에 의한 포드만 이용하라는 의미) → jenkins-sample-agent(포드 지정) → save

  • build now → failed 함

    • failed 이유는 ?
      • access to the resources is denied → docker push를 하려면 도커 허브 레지스트리에 권한(인증)정보를 있어야 하는데 어디에도 지정 하지 않아서임
      • 설정 추가 필요 (jekins credential 추가 할 것임)
        • manage jenkins > credentials > globals 클릭 → add credentails → 아래처럼 입력 > create(여기서는 도커허브 아이디, 비밀번호 입력 도커 로그 아웃 해야함)
          

  • 프로젝트로 다시 돌아와서 : dashboard > simple-echo1 클릭 > configuraton > build environment 클릭 > use secret text(s) or file(s) 체크 > add > username and password (separated) > 아래처럼 입력 > save
    
    

  • configuration > build steps > 아래처럼 입력 > save
    

  • build now 클릭 → console output → sucess

  • 쿠버네티스 배포

    • configuration > build steps > 아래처럼 입력 > save
      

  • build now 클릭 → console oupt → failed함

    • failed 이유는 ?

      • error when retrieving current configuration → 현재 디플로이먼트 상태를 가져오는게 허용되어 있지 않았음 → 이 크러스터에 리소스를 생성하거나 조회할 권한이 주어지지 않았음 → credentails 설정해줘야함

        • 쿠버네티스 클러스터 접근 권한 설정
          
        • credentail 등록
          
          
        • credentail 설정 → dashboard > simple-echo-1 > configuration > build environment > 아래 내용 클릭 > save
          
          

  • build now 클릭 → success

  • 쿠버네티스에 잘 설치되어있는지 확인

    • kubectl get deployment
      
    • kubectl get svc
      
    • curl localhost:30000

✏️ 간단한 젠킨스 파이프라인

• 파이프 라인 만들기
  

  • 아이템 만들기
    
    
  • pipeline 입력
    
    
  • build now → console output → failed
  • pipeline > agent 수정
    
    
  • build now → console output → success

• 깃허브에서 파이프 스크립트 가져오기

  • pipeline 내용 복사 → Jenkinsfile이라는 파일 하나 만들어서(아래내용 처럼 고쳐야함) 한 군데 고쳐서 붙여넣고, 깃허브 레포지토리에 올리기
    
  • pipeline 아래처럼 수정 후 save
    
  • build now → success

✏️ CI 파이프라인 기초 (1)

• CI 파이프라인

  • 파이프라인 추상적 수준에서 정의
    
  • CI 파이프라인에 대한 상세 수준에서의 정의
    • Jenkins를 통해 자동화한 빌드 단계와 그 절차
      
      

• 간단한 파이프라인 구축 실습
  

  • 깃허브 리포지토리 생성 (private repo)
    

  • 깃허브 접근용 SSH Key 생성
    

  • SSH KEY 만들기

    • https://git-scm.com/book/ko/v2/Git-서버-SSH-공개키-만들기 참고해서 SSH Key를 만들고
    • 등록한 키로 ssh 프로토콜로 github 접속 가능한지 확인 후, git clone 명령으로 리모트 리포지토리 복제
      

  • spring boot 프로젝트 생성 → calcultor.zip 파일 생성됨
    
    
    

  • 로컬에서 빌드

    • 로컬 컴퓨터에 JDK (버전까지 맞추면 좋음) 가 설치 되어있어야 함

      https://www.oracle.com/kr/java/technologies/downloads/#java17

      

      설치 compressed → mac interchip
      

    • 다운받은 calculator 파일들 깃 레포지토리에 넣고

      • cd calculator
      • git pull (파일들 땡겨와서)
      • ls -l (reademe.md 파일 확인가능)
      • ./gradlew build (빌드를 로컬에서 성공하는지 확인) → build successful

  • 젠킨스 설정

    • plugins > stage view 설치
    • manage jenkins > credentials > github ssh key 등록
      
      
    • jdek installations 설정 : tools > add jdk > 아래 내용 입력하고 save
      
      

  • 빌드해보기

    • 아이템 생성
      
      
    • build now → stage view를 보면 →declative, checkout, compile 시간들을 볼 수 있음
      

  • 빌드 에이전트의 개선
    

    • 커스텀 에이전트 구성
      
      
    • 빌드 에이전트 설정
      
      
    • 빌드 결과
      
    • 빌드에 관련한 설정을 빌드 절차 안에 넣어 자동화시킴

✏️ CI 파이프라인 - 단위 테스트

• 단위 테스트

  • 단위 테스트의 중요성

    • 코드(를 포함해서, 복잡한 구조를 가지는 구현물)의 개발에 있어서는 “잠재적 결함을 일찍 (앞선 단계에서) 발견할 수 있을수록” 효율(및 안정성)이 높아짐
    • 쓰여진 모든 코드는 테스트되어야함 - 테스트 커버리지와 연관

  • 단위 테스트는 개발자의 몫

    • 직접 코드를 구현하는 개발자만큼 해당 코드의 어떤 측면을 어떻게 테스트해야 하는지를 잘 이해할 수 있는 다른 사람이란 없음
    • 이것은 통합 테스트 및 인수 테스트와는 구별 되어야 하는 것으로써, 테스트 케이스를 명확히 정의하고 이것을 테스트 케이스로 구현하는 것은 코드 개발자가 담당
      • 이것을 조금 더 깊이 고려하면 TDD(Test-Driven Development) 방법으로 연결 할수도있음

✏️ CI 파이프라인 - 코드 품질 확보

• 코드의 품질이란?

  • 기능성 - 의도한(요구된) 기능을 모두 올바르게 수행하는가
  • 올바른 코드 말고, 좋은 코드란 어떤것인가?
    • 대충 얘기하면, 읽기 좋은 코드, 또는 바꾸어 말하면 엔지니어링 관점에서 재활용성이 높은 코드

• 실행 시점이 아닌, 그보다 이전에 정의할 수 있는 코드의 품질은 어떤 것들이 있을까?

  • 단위 테스트가 잘 마련되어 있는 코드 - 테스트 커버리지 로 측정
  • 규칙에 따라 잘 쓰여진 코드 - 컨벤션 (스타일 가이드라인) 준수 정도로 측정