젠킨스 2 기본 개념

개요

• 젠킨스 2가 어떻게 pipelines-as-code를 지원하는지 이해하는데 필요한 기본 개념

 

 

문법 : 스크립트 방식의 파이프라인과 서술적 파이프라인

• 젠킨스 2는 파이프라인 생성에 사용되는 두 종류의 문법 사용 가능
• 스크립트 방식 파이프라인 (Scripted Pipelines)
  • 젠킨스에서 pipelines-as-code가 수행되는 초기의 방법
  • 명령적인 스타일의 로직에 기반
  • 그루비 언어와 명령어에 밀접하게 연관
  • 에러 확인과 예외 처리 부분에서 의존성이 강함
• 서술적 파이프라인 (Declarative Pipelines)
  • 주요 영역에서 필요한 상태와 결과를 나타내는 구역이 잘 나뉨
  • 로직 자체에 대한 집중은 적음
• 예시

// 스크립트 방식의 파이프라인
node('worker_node1') {
    stage('Source') {   // 코드 가져오기
        // 깃 저장소에서 코드 가져오기
        git 'git@diyvb2:/home/git/repositories/workshop.git'
    }
    stage('Compile') {  // 컴파일과 단위 테스트 수행
        // 컴파일과 단위 테스트를 위해 그레이들 실행
        sh "gradle clean compileJava test"
    }
}
  
// 서술적 파이프라인
pipeline {
    agent {label 'worker_node1'}
    stages {
        stage('Source') {   // 코드 가져오기
            steps {
                // 깃 저장소에서 코드 가져오기
                git 'git@diyvb2:/home/git/repositories/workshop.git'
            }
        }
        stage('Compile') {  // 컴파일과 단위 테스트 수행
            steps {
                // 컴파일과 단위 테스트를 위해 그레이들 실행
                sh "gradle clean compileJava test"
            }
        }
    }
}  

• 차이
  • 스크립트 방식 : 프로그램의 흐름과 로직을 실행하기 위해 일반적인 명령형 언어로 작성
  • 서술적 방식 : 전통적인 젠킨스 웹 폼에서 주요 정보를 특정 목적과 행동을 하는 미리 정의된 섹션에 입력하는 형태

 

 

스크립트 방식의 파이프라인과 서술적 파이프라인 중 선택

• 주어진 상황에 맞게 적절한 것을 선택
• 필요성, 구조, 구현의 흐름, 구현자의 배경 지식에 따라 더 잘 동작하는 방식이 있음
• 스크립트 방식 파이프라인
  • 장점
    • 대체로 더 적은 섹션과 설명이 필요하다.
    • 더 많은 절차형 코드를 사용 가능하다.
    • 프로그램을 작성하는 것과 유사하다.
    • 전통적인 pipeline-as-code 모델로서 더 익숙하고 하위 호환성이 좋다.
    • 필요시 맞춤화된 동작을 수행하기 쉽다.
    • 더 복잡한 흐름과 파이프라인을 설계할 수 있다.
  • 단점
    • 대체로 더 많은 프로그래밍이 필요하다.
    • 문법 검사가 그루비 언어와 환경에 국한된다.
    • 전통적 젠킨스 모델과 연관이 적다.
    • 서술적 파이프라인에서 같은 내용의 구현이 가능하다고 가정하면, 상대적으로 더 복잡하다.
    • 서술적보다 유연하여 숙련된 사용자가 이 구조를 이용해 더 많은 일 처리 가능
• 서술적 파이프라인
  • 장점
    • 더 구조화돼 전통적 젠킨스 웹 폼과 유사하다.
    • 필요한 것을 선언하는 것이 유연해 대체로 가독성이 좋다.
    • 블루 오션 화면의 인터페이스를 이용해 생성 가능하다.
    • 알림과 같이 기존 젠킨스 개념에 대응될 수 있는 섹션이 존재한다.
    • 문법 확인 및 에러 확인이 쉽다.
    • 파이프라인 사이의 일관성이 높다.
  • 단점
    • 반복되는 로직에 대한 지원이 적다. (프로그램적 요소가 적다)
    • 아직 발전 중이다. (기존 젠킨스에서 지원됐던 기능이 지원되지 않을 수 있다)
    • 유연성이 적은 구조다. (맞춤화된 파이프라인 코드 작성이 더 어렵다)
    • 현재 복잡한 파이프라인이나 워크플로우에 잘 적용되지 않는다.
• 새로운 파이프라인 사용자가 배우고 유지하기 더 쉬움
• 기존 젠킨스처럼 바로 사용 가능한 기능을 원하는 경우 유용
• 대신 제공되는 구조에서 벗어나는 일을 할 수 있는 유연성은 적음

 

 

시스템 : 마스터, 노드, 에이전트, 엑시큐터

• 모든 젠킨스 파이프라인은 코드를 실행하기 위해 하나 이상의 시스템 필요

 

 

마스터 (Master)

• 젠킨스 인스턴스 제어에 중심이 되는 역할
• 다른 시스템에 정의되지 않았다면 잡을 실행하는 기본 장소
• 무거운 작업은 다른 시스템에서 수행하는 것이 좋음
  • 마스터에서 수행되는 잡에는 모든 데이터, 환경 설정, 작업에 대해 마스터와 같은 접근 권한이 있는 보안 위협 때문
  • 마스터가 과부하로 인해 중단되면 안 되기 때문

 

 

노드 (Node)

• 젠킨스 잡을 실행할 수 있는 시스템
• 마스터 혹은 에이전트가 포함되며 도커와 같은 컨테이너를 의미할 때도 있음

 

 

에이전트 (Agent)

• 구 젠킨스의 슬레이브(slave), 전통적으로 마스터가 아닌 시스템을 의미
• 마스터에 의해 관리되고 필요에 의해 할당되어 각 잡의 수행을 담당
• 에이전트와 노드의 관계
  • 스크립트 방식 : 노드는 에이전트가 있는 시스템을 지칭
  • 서술적 : 특정 에이전트를 명시해 노드를 할당

 

 

엑시큐터 (Executor)

• 노드나 에이전트에서 잡을 실행시키는 장소
• 노드는 엑시큐터를 여러 개를 갖고 있을 수도 있고, 하나도 갖고 있지 않을 수도 있다

• 버전에 따라서 1개 이상 지정해야 하는 경우도 있음

 

※ 젠킨스 작업 수행에 연관된 시스템 종류

 

 

노드 생성

• 젠킨스에 신규 노드를 추가하는 경우의 방법
• 젠킨스에 로그인한 후 관리 페이지로 이동 후 노드 관리 링크 클릭

 

• 노드 관리 화면에서 새로운 노드(New Node) 선택

 

• 노드 명과 종류 선택

 

• 노드 사용을 위한 변수 입력

 

• 환경 변수(Environment variables)와 도구 위치(Tool Locations)는 해당 노드에서 사용할 특별한 변수와 도구 정의 가능

 

• 레이블 사용 목적
  • 고유 레이블을 통한 노드의 구분
  • 같은 레이블을 지정해 노드를 그룹화하는 용도
  • 작업에 필요한 노드의 특징을 알려주는 용도로 사용 (권장)

 

 

구조 : 젠킨스 DSL 사용하기

• 파이프라인의 기본 구조
• DSL(Domain-Specific Language) : 특정한 상황을 위한 프로그래밍 언어
• 젠킨스 DSL은 그루비(Groovy) 언어를 이용해 작성
  • 그루비가 제공하는 기능이 다른 언어보다 DSL을 생성하기 쉽게 만들었기 때문
  • 대신 그루비 문법에 심하게 의존하는 결과가 생김
• 아래는 스크립트 방식의 파이프라인 관점으로 기술

 // 젠킨스 DSL로 표현된 간단한 파이프라인 예시

 node ('worker1') {
    stage('Source') {   // 화면 표시 목적
        // 깃 저장소에서 코드 가져오기
        git 'https://github.com/brentlaster/gradle-greetings.git'
    }
}

 

 

노드 (node)

• 각 노드에는 젠킨스 에이전트가 설치되어 잡을 실행
• 젠킨스에게 어떤 노드에서 해당 파이프라인을 실행해야 하는지 알려줌
• 레이블에 해당하는 명칭을 변수로 넘겨 노드를 지정
• 레이블을 지정하지 않은 경우
  • master가 실행을 위한 기본 노드로 설정됐을 경우, 이 잡을 master에서 수행
  • 그 외의 경우 젠킨스가 여러 노드 중 가용한 첫 번째 엑시큐터를 이용해 수행
• 레이블에 or(||)나 and(&&) 사용 가능
  • 예 : node("linux && east") { ... }
• 그루비 클로저(closure)
  • {} 기호
  • 현재 노드에 연관되어 있는 코드 블록의 시작과 끝
  • 마지막 문장이 리턴 값이 된다

 

 

스테이지 (stage)

• 각각의 설정, DSL 명령어, 로직을 그룹으로 묶음
• 이름은 반드시 지정해야 하며 로그에 이름이 출력되어 어떤 스테이지가 진행 중인지 표시
• 하나의 스테이지에서 하는 일은 전통적인 파이프라인 하나가 담당하는 크기로 나누는 것을 권장

 

 

스텝 (steps)

• 스테이지 안의 실제 젠킨스 DSL 명령어
• DSL의 가장 최소 기능 단위
• 맵 형태의 매개 변수를 사용
  • [키: 값, 키: 값] 문법
  • 예시
    • git([branch: 'test', url: 'http://github.com/brentlaster/gradle-greetings.git'])
    • git branch: 'test', url: 'https://github.com/brentlaster/gradle-greetings.git' (위 예시에서 괄호 생략)
    • git 'https://github.com/brentlaster/gradle-greetings.git' (매개변수가 하나만 존재할 때)
• 기본 매개 변수는 script 객체
  • 예시
    • bat([script: 'echo hi'])
    • bat 'echo hi' (괄호와 변수명 생략)

 

※ 노드와 스테이지, 스텝의 관계

 

 

지원되는 환경 : 파이프라인 스크립트 개발

• 파이프라인 개발과 실행을 위해 젠킨스에서 제공되는 환경과 도구
• 파이프라인 스크립트는 파이프라인 잡 타입이나 Jenkinsfile(10장 참조)을 통해 생성

 

 

파이프라인 프로젝트 시작

• 새 파이프라인 프로젝트 생성을 위해 'New Item' 선택

 

• 프로젝트 이름 입력 후 pipeline 선택 후 OK 선택

 

• General, Build Triggers, Advanced Project Options 항목은 설정하거나 비우기 가능

 

• pipeline 탭의 Script 항목에서 파이프라인 스크립트 입력 가능

 

• 간단한 스크립트 입력 예시

 

 

편집기

• 문법 검사
  • 문제가 있는 라인에는 붉은 X 표시

• 의존성이나 방금 생성된 임포트(import)가 해결되지 않은 경우에도 뜰 수 있으나 이는 특수한 경우

• 확장된 에러 정보
  • X 표시 위에 마우스를 올려놓으면 자세한 정보 표시

 

• 자동 완성
  • 괄호 등에 대해 자동 완성 지원

 

 

스니펫 생성기 사용하기 (Snippet Generator)

• 파이프라인 문법 지원 도구
• 웹 폼을 통해 원하는 문법과 내용을 고를 수 있도록 지원
• 특정 소스 코드가 필요한 상황에서 'Pipeline Syntax' 선택

 

• Snippet Generator 항목으로 이동

 

• Sample Step에서 원하는 항목 선택

 

• 항목 선택 후 기본값이나 원하는 값을 설정

 

• Generate Pipeline Script를 선택하여 스크립트 생성

 

• 생성한 스크립트를 적용

 

 

파이프라인 실행

• 과거 버전 젠킨스에서
  • 각 분야를 프리스타일 잡으로 분리한 후 선후 관계를 지정하여 가장 먼저 실행하는 것이 일반적

 

• Build Pipeline 플러그인
  • 스테이지를 나타내는 잡의 흐름을 시각화

 

• 젠킨스 2에는 전체 파이프라인을 작성하는 파이프라인 프로젝트 타입 사용
  • 스크립트 작성

 

• 저장하면 'No data available. This Pipeline has not yet run'이라 아직 파이프라인을 실행하지 않았다고 표시

 

• Build Now를 선택하여 빌드를 실행하면 내용 표시

 

• 각 행은 프로젝트의 빌드, 열은 스테이지를 의미
• 각 타일의 색상은 상태를 의미

색상	의미
파란 줄무늬	실행 중
하얀색	아직 실행되지 않음
장미빛 줄무늬	스테이지 실패
초록	스테이지 성공
장미색	해당 스테이지는 성공했지만, 하위 스테이지가 실패

 

• 로그 확인
• 전통적인 젠킨스와 동일하게 로그를 확인하려면 Console output 선택

 

• 스테이지 뷰에서는 각 스테이지의 로그 확인 가능

 

• 에러가 발생한 스테이지 뷰
• 에러가 발생하면 장미색으로 표시

 

• 에러난 스테이지를 선택하면 자세한 내용 표시

 

 

리플레이

• 원본 코드의 변경 없이 변경 사항을 적용하여 다시 실행하는 메뉴
• 다시 시도하려는 빌드에서 Replay 선택

 

• 스크립트 편집 후 Run 선택하여 다시 실행

 

• 변경한 코드가 반영된 새 빌드 동작

 

• 설정 화면에서 원본 스크립트는 유지된 것을 확인

 

• 리플레이 빌드는 어떤 빌드에서 리플레이되었는지 표시

 

• 위 화면에서 diff를 선택하면 스크립트의 수정 사항 표시

 

 

 

요약

• 두 가지 문법 모델의 차이점
• 파이프라인이 실행될 수 있는 두 시스템 차이점 분류
• 스크립트 방식의 파이프라인에서 사용되는 코드의 구조
• 젠킨스가 파이프라인 개발자에게 제공하는 도구와 환경