10.2 Jenkins 정보¶

젠킨스는 사용자가 개발하는 소프트웨어를 빌드하고 빌드된 결과를 사용자가 원하는 클라우드에 배포하는 기능을 제공합니다.

젠킨스에서 사용자가 개발한 코드를 빌드하기 위해서는 사용자의 소스 코드 저장소에 저장된 코드를 불러와서 코드의 성격에 따라서 필요한 실행 파일을 생성하는 빌드 단계를 거치게 되며, 이를 통해서 최종적으로 만들어진 도커 이미지를 쿠버네티스 기반의 클라우드에 무중단 배포(Rolling Update)를 통해서 배포하게 됩니다.

아래의 과정을 통해서 이러한 절차가 이루어지게 됩니다.

소스 코드 저장소 인증 정보 등록
소스 유형별 빌드 절차 등록 및 실행
빌드 결과물(도커 이미지)의 서비스 배포

10.2.1 소스 코드 저장소 인증 정보 등록¶

전역 인증 정보는 모든 사용자가 사용할 수 있는 인증정보 입니다.

세렝게티에서 제공하는 소스 코드 저장소인 Gitlab은 API Token 기반의 인증 기능과 Username with password 기반의 인증을 제공하고 있으며 2가지 인증을 모두 생성해야 합니다.

API Token 기반 인증

API Token 기반 인증은 Gitlab에서 발행된 Token 정보를 등록하여 인증하는 방식으로 연동해야 하는 Gitlab 시스템 정보를 등록할 때 활용됩니다.

생성된 Token 정보는 아래와 같은 형태입니다.
```
-xd4N4Cxpyy4i5z_rfys
```
- API Token 등록/변경 방법
  - 기본 화면(Dashboard) > Manage Jenkins > Credentials > System
- 기본 화면
- 기본 화면(Dashboard) > Manage Jenkins
- 기본 화면(Dashboard) > Manage Jenkins > Credentials
- 인증 정보 등록/변경 방법
  
  ![인증 정보 등록/변경 화면 이미지../../../_static/images/plugins/jenkins/credential-update.png)
  - “Update” 링크를 선택해서 변경 화면으로 이동
  - “Change Password” 버튼을 눌러서 인증 정보 창 활성화
  - “API Token” 입력 창에 Gitlab의 API Token 정보 입력
  - “ID” 입력 창에 API Token을 발행한 Gitlab 사용자 Id(일반적으로 root) 입력
  - “Save” 버튼으로 변경된 정보 등록

Username with password 기반 인증

이 인증 방식은 사용자의 소스 코드를 Gitlab의 개별 사용자 계정에서 빌드하기 위해 가져오기 위해서 사용이 되며, System 인증 정보 화면의 “Add Credentials” 버튼을 선택해서 등록할 수 있습니다.

새로운 Credential 등록 화면에서 “종류(Kind)”를 “Username with password”를 선택해서 등록하면 되며, 등록할 각각의 필드에 대한 설명은 화면 아래와 같습니다.
- Scope : Global로 설정
- Username: Gitlab에서 연동할 계정의 id 정보를 입력
- Treat username as secret : 체크(true)
- Password : Gitlab에 연동할 계정의 암호를 입력
- ID : 외부에 노출할 Credential의 구분 이름을 입력
- Description: Credential에 대한 설명을 입력(옵션)

10.2.2 소스 유형별 빌드 절차 등록 및 실행¶

신규 작업 생성 소스 코드에 대한 빌드를 수행하기 위해서는 개발 환경에 맞추어서 작업을 생성해야 합니다.

새로운 작업을 생성하기 위해서는 젠킨스 초기 화면에서 “New Item” 링크를 선택해서 새로운 작업을 생성하도록 합니다.
기존 작업 설정 등록에 필요한 작업 이름을 등록하고 적용하고자 하는 작업 타입을 선택합니다.

기존에 생성된 작업에 대해서는 등록된 작업 목록에서 작업을 선택한 후, “Configuration” 링크를 통해서 등록 과정에서 등록한 내용을 변경합니다.
- General
  
  작업에 대한 일반적인 설정을 합니다.
  
  주로 지정하는 작업에 대한 설명은 아래와 같습니다.
  - Discard old builds
    
    빌드된 이력 관리를 설정합니다.
    
    최대로 보관되는 이력 갯수를 설정할 수 있고 기본적으로 5개로 설정합니다.
  - Gitlab Connection
    
    소스 저장소로 사용되는 Gitlab의 연결 정보를 설정합니다.
  - JDK/Ant
    
    Java 버전을 설정할 수 있습니다.
    
    젠킨스 툴(Tools)에서 설정한 Java 버전별 이름을 선택합니다. 선택된 Java 버전으로 빌드 과정에서 사용이 됩니다.
  - This project is parameterized
    
    작업 실행 시, 활용될 수 있는 환경 변수를 설정합니다.
    
    설정된 환경 변수는 각각의 작업 유형에 따라서 다르게 활용될 수 있으면 실행되는 작업 유형에 따라서 추가로 환경 변수를 설정할 수 있습니다.
    
    대표적으로 도커 이미지 생성을 위한 Tag 정보로 사용되는 BUILD_NUMBER를 설정할 수 있습니다.
  - Advanced
    
    실행 작업에 대한 식별 가능한 이름(한글 포함)을 지정합니다.
- Source Code Management
  
  소스 코드를 불러오기 위한 소스 코드 저장소 정보를 설정합니다.
  
  대부분의 프로젝트에서 소스 코드 연동을 위해서 사용이 되며, 등록할 각각의 정보는 아래와 같습니다.
  - Repository URL
    
    Gitlab에서 복사한 소스코드 URL 정보를 등록합니다.
    
    Gitlab의 프로젝트를 선택해서 출력된 File 목록에서 “Clone” 버튼을 선택해서 출력된 정보를 복사하여 붙여넣기 합니다.
  - Credentials
    
    소스 코드 연동을 위해서 등록한 인증서 중에서 Username with password 항목을 선택하여 등록합니다.
  - Branches to build
    
    소스 코드가 저장된 Branch 정보를 등록합니다.
    
    /로 시작되는 Branch 이름을 지정하시면 됩니다.
- Build Triggers
  
  이전에 실행된 프로젝트의 상태에 따라서 현재 프로젝트를 자동으로 실행합니다.
  
  이전 빌드가 정상적으로 종료가 된 경우에만 실행이 될 수 있도록 “Trigger only if build is stable” 항목에 체크를 합니다.

10.2.2.1 Java Gradle 작업¶

빌드 단계에서 Gradle 기반의 작업을 실행합니다.

빌드 단계 작업 설정

Use Gradle Wrapper 설정
- Make gradlew executable 체크
- Wrapper location 을 “${workspace}” 로 지정

Tasks

아래 설정 정보로 설정

clean build --refresh-dependencies --debug

Advanced

고급 환경 설정에서 아래 화면과 같이 Switches 환경 설정
```
--scan -s
```

10.2.2.2 Java Maven 작업¶

Maven으로 구성된 Java Project에 대한 빌드 환경 정보를 제공합니다.

Java Maven 빌드 환경 설정

설정되는 정보는 아래와 같습니다.

Root POM

SCM을 통해서 maven에서 참조하는 pom.xml 파일의 경로를 지정합니다.
```
pom.xml
```
Goals and options

IDE 프로그램에서 실행할 때 사용하는 Maven 명령어를 설정합니다.
```
clean install -DskipTests
```

10.2.3 빌드 결과물(도커 이미지)로 배포¶

도커 이미지 빌드를 위해서 사용하는 젠킨스 파이프라인을 설정합니다.

자동 실행을 위해서는 “Build Triggers” 항목의 “Build after other projects are built” 항목에 Trigger 설정을 위한 프로젝트 이름을 지정합니다.

설정 스크립트 내역은 아래와 같습니다.

node {
  stage('========== Clone repository ==========') {
    checkout scm
  }
  stage('========== Copy build ==========') {
    sh 'rm -rf ./target'
    sh 'cp -R ../PROJECT_US_OP/build/libs ./target'
  }
  stage('========== Build image ==========') {
    app = docker.build("serengeti-user/administrator/ulsan_us_op")
  }
  stage('========== Push image ==========') {
    docker.withRegistry('https://serengeti.registry:30443', '') {
      app.push("${env.BUILD_NUMBER}")
      app.push("latest")
    }
  }
}

Clone repository
```
checkout scm
```
명령어를 통해서 SCM에 설정된 정보로 빌드에 사용되는 script를 다운로드 합니다.
Copy build
```
sh 'rm -rf ./target'
sh 'cp -R ../${workspace}/build/libs ./target'
```
프로젝트의 상태에 따라서 ${workspace} 정보를 프로젝트 정보로 맞추어서 변경합니다.
Build image
```
app = docker.build("serengeti-user/administrator/ulsan_us_op")
```
빌드되는 도커 이미지의 경로 정보를 설정합니다.
Push image
```
docker.withRegistry('https://serengeti.registry:30443', '') {
  app.push("${env.BUILD_NUMBER}")
  app.push("latest")
}  
```
이미지 Push를 위해서 사용되는 내부 저장소는 serengeti.registry 를 사용하며 세렝게티 내부 시스템입니다. 빌드된 이미지는 젠킨스의 파라미터 환경변수로 전달되는 BUILD_NUMBER 값을 통해서 지정된 이미지 Tag와 latest 로 이미지 저장소에 Push가 됩니다.

이미지를 빌드할 때 사용되는 Dockerfile은 Script Path에 지정된 Jenkinsfile과 동일한 경로에 위치되어야 합니다.

빌드를 위해서는 설정된 Dockerfile의 내용은 아래과 같습니다.

FROM openjdk:17-alpine

ARG JAR_FILE=target/us_op-0.0.1.jar
COPY ${JAR_FILE} app.jar
ENTRYPOINT ["java","-jar","/app.jar"]

Dockerfile의 구성 내용은 다음과 같습니다.

Base Image
```
FROM openjdk:17-alpine
```
개발된 코드가 사용하는 Java 버전에 맞추어서 openjdk 이미지를 사용합니다.
실행 Jar
```
ARG JAR_FILE=target/us_op-0.0.1.jar
COPY ${JAR_FILE} app.jar
```
Jenkinsfile의 “Copy build” 섹션에서 처리된 결과를 루트 경로(/)에 app.jar 로 복사하는 명령어입니다.
실행 명령어
```
ENTRYPOINT ["java","-jar","/app.jar"]
```
ENTRYPOINT에 지정된 명령어는 “java -jar /app.jar” 명령어를 실행하기 위한 실행문입니다. 추가적인 명령어 구성을 위해서는 ENTRYPOINT에 , 를 구분자로 옵션을 추가하면 됩니다.

설정 파일은 SCM의 프로젝트에 등록된 Jenkinsfile을 참조하고 있으며 해당하는 파일은 아래의 Script Path 정보에 해당하는 경로를 정확하게 명시해야 합니다.

ScriptPath 정보는 SCM 정보의 부가 정보로 설정할 수 있습니다.

파이프라인 실행을 위한 Jenkinsfile 파일 설정

10.2.4 빌드 결과물(도커 이미지)를 이용해서 서비스 업데이트¶

빌드된 이미지를 서비스에 반영하기 위해서는 세렝게티에서 제공하는 Rolling Update 기능을 이용합니다.

자동 실행을 위해서는 “Build Triggers” 항목의 “Build after other projects are built” 항목에 Trigger 설정을 위한 프로젝트 이름을 지정합니다.

Rolling Update 기능은 서비스 무중단을 통한 이미지 반영 기능을 제공합니다.

해당 기능을 위해서 빌드 단계에서 “HTTP Request” Plugin을 사용하여 설정합니다. HTTP Request 설정 화면

Plugin에서 호출하는 URL 정보는 다음과 같습니다.

URL
```
https://222.239.254.56:8090/api.template//catalog/v1/handle/instance/${ResourceCatalogInstanceId}/runtime/${ResourceCatalogRuntimeId}/rollingUpdate
```
Rolling Update URL에서 사용하는 정보는 세렝게티에서 생성된 Resource Catalog 정보를 기반으로 하고 있으면 사용되는 각각의 정보에 대한 설명은 아래와 같습니다.
- ResourceCatalogInstanceId
  
  리소스 카탈로그 화면에서 카탈로그 실행을 통해서 생성된 카탈로그 인스턴스의 Id
- ResourceCatalogRuntimeId
  
  리소스 카탈로그 인스턴스에서 카탈로그를 구성하는 Runtime의 Id
HTTP Mode(PATCH)
Ignore SSL Errors(YES)
Advanced
- General Headers
  - Content-Type: application/json
- Custom Headers
  - LoginId: administrator
  - AccessKey: ***
  - SecretKey: ***

10.2.5 외부 연동을 위한 API Token 관리¶

Jenkins를 Gitlab과 같은 외부 CI/CD 툴에서 호출하기 위해서 API Token을 활용할 수 있다.

API Token은 Jenkins의 사용자 단위로 설정할 수 있으며, 아래와 같이 사용자 Id 옆의 Dropdown 메뉴를 선택해서 나오는 Configure 기능을 통해서 생성할 수 있다.

사용자별 Configure 메뉴 선택

API Token을 생성하기 위해서는 아래 화면과 같이 Configure 영역의 API Token에서 “Add new Token” 기능으로 새로운 토큰을 생성할 수 있습니다.

사용자별 Token 관리

생성된 토큰은 생성 이후에 화면 이동 등을 통해서 토큰 값이 사라지면 다시 조회할 수 없기 때문에(목록 첫번쨰), 생성 이후에 활용을 위해서는 반드시 해당하는 값을 복사해서 별도로 보관해야 합니다.

Jenkins가 설치된 환경이 공인된 https를 사용하지 않는 경우에는 웹 브라우저의 보안 정책으로 화면에서 제공하는 복사 기능 링크가 정상적으로 동작하지 않기 때문에 화면에 표시된 토큰 값을 직접 선택해서 복사해야 합니다.

이렇게 생성된 토큰 값을 Gitlab의 Webhook에 사용할 수 있습니다.

10.2.6 Build Trigger¶

Jenkins에 등록된 작업을 자동으로 실행하기 위한 설정입니다.

Gitlab 요청에 따른 자동 실행

Build Trigger 항목에서 “Build when a change is pushed to GitLab. GitLab webhook URL” 항목을 선택하고 위에서와 같이 “Push Events” 항목에 대해서만 체크를 합니다.

기타 항목에 대한 설정은 Jenkins 메뉴얼을 통해서 확인할 수 있습니다.

상세 항목에 대한 설정을 마치고 저장 또는 Apply를 통해서 설정된 내역을 Item별로 저장해야 합니다.
이전 항목의 빌드 상태에 따른 자동 실행

이전에 실행된 빌드 항목 상태에 따라서 현재 프로젝트를 자동으로 실행합니다. 이전 항목의 지정을 위해서는 해당하는 항목의 등록된 이름(출력 이름이 아님)을 입력하면 자동 완성 기능으로 검색하여 가능한 항목을 출력하므로 출력된 항목에서 선택하여 설정합니다.

이전 빌드가 정상적으로 종료가 된 경우에만 실행이 될 수 있도록 “Trigger only if build is stable” 항목에 체크를 합니다.