기본 사용법

함수 호출시 파라미터 전달

Jenkins pipeline은 groovy 를 사용하기 때문에 java 와 문법이 유사하다. 그러나 java 의 method 호출 방식은 method 의 signature 를 엄격하게 지켜야 한다. method 에서 정의한 모든 파라미터의 type 과 순서를 맞게 입력해야 해당 메소드를 호출할 수 있다. 사용하지 않는 파라미터라도 null 을 입력해서 method 의 signature 에 맞아야만 호출이 가능하기 때문에, 파라미터가 많고 필수로 입력할 필요가 없을 경우에는 매우 불편하다.

Retort 에서는 이런 불편함을 해소하고자 Groovy 의 특성을 활용한 2가지 파라미터 전달 방식을 사용한다.

• Map type parameter

  parameter 를 key, value 형태인 map 으로 전달한다. 

  // map 변수를 생성해서 전달
  def param = [:]
  // groovy style 변수 추가
  param.pom = './somePom.xml'
  // java style 변수 추가
  param.put('profile', 'dev')
  mavenBuild param
  
  
  // 함수에 직접 전달
  mavenBuild pom:'./somePom.xml', profile:'dev'

  key 와 value 는 Colon(:) 으로 구분하고 여러 파라미터를 넘길 경우 Comma(,) 로 구분한다.

• Closure type parameter

  Closure 를 이용해 파라미터를 전달 가능하다.

  mavenBuild {
  	pom = './somePom.xml'
  	profile = 'dev'
  }

  파라미터 명을 string 으로 지정한게 아니라 이미 지정되어 있는 일반 변수처럼 사용하고, 해당 변수에 전달하고자 하는 값을 입력한다. 블록 안에서 파라미터 생성을 위한 로직을 추가할 수도 있다.

mavenBuild

maven build 와 관련된 동작을 수행한다. 

Parameters

Return

N/A

실행하는 Maven Goal 에 따라 workspace 내부에 결과물이 생성된다.

사용 예제

• Kubernetes 에서 기본적인 maven 빌드

  mavenBuild goal:'clean package'
  
  // 실제 수행되는 명령어
  // mvn clean package

• profile 지정

  mavenBuild goal:'clean package', profile:'dev'
  // 실제 수행되는 명령어
  // mvn clean package -Pdev
  
  
  // String 으로 두 개의 profile 지정
  mavenBuild goal:'clean package', profile:'stg, prd'
  
  // 배열로 두 개의 profile 지정
  mavenBuild goal:'clean package', profile:['stg', 'prd']
  
  // 실제 수행되는 명령어
  // mvn clean package -Pdev,prd

• 다른 경로의 pom 파일 사용

  mavenBuild goal:'clean package', pom:'./dev/pom.xml'
  
  // 실제 수행되는 명령어
  // mvn clean package -f ./dev/pom.xml

• 테스트 생략하기

  mavenBuild goal:'clean package', systemProperties:['maven.test.skip':'true']
  
  // 실제 수행되는 명령어
  // mvn clean package -Dmaven.test.skip=true

• settings 파일 적용하기

  사전에 settings 파일을 미리 등록해두어야 한다.

  Jenkins 관리 > Managed files > Add a new Config 메뉴 클릭.

  Maven settings.xml 선택한다. ID 는 자동입력된 값을 사용해도 되지만, 사용자가 인식하기 편하도록 의미있는 값을 입력하기를 권장한다. (Pipeline 에서는 Name 이 아닌 ID 를 사용하기 때문)

  mavenBuild goal:'clean package deploy', settingsID:'mySettings'
  
  // 실제 수행되는 명령어
  // mvn clean package deploy -s ${임시경로}/config1662438358361787735tmp

mavenBuild.updateVersion

maven pom 파일의 버전을 업데이트 한다.

예를 들어, 아래와 같은 pom 파일이 있을 때

<?xml version="1.0" encoding="UTF-8"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.sk.tbd</groupId>
  <artifactId>bluegreen</artifactId>
  <version>0.0.1</version>
  <name>bluegreen</name>
  <description>Demo project for Spring Boot</description>
  <dependencies>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-web</artifactId>


  ...
</project>

project - version Tag 의 값을 변경하고자 할 때 사용한다.

version 값을 변경하면 빌드 시 생성되는 Artifact 파일명이 변경될 수 있으므로 주의해야 한다.

parameters

Return

N/A

지정한 pom 파일의 version 값이 바뀐다. 파일 내용을 변경하고 저장할 때 Formatting 을 새로 하기 때문에 xml 의 모양이 변경될 수 있다.

사용 예제

• version 을 0.0.2 로 업데이트

  mavenBuild.updateVersion pom:'./pom.xml', version: '0.0.2'

dockerCmd

docker 명령어를 수행한다. 

dockerCmd.build

docker build 명령어를 수행한다.

parameters

Return

N/A

사용 예제

• 기본적인 docker 빌드

  dockerCmd.build tag:'my/app:0.0.1'
  
  // 실제 수행되는 명령어
  // docker build -t my/app:0.0.1 .

  source root 의 Dockerfile 을 이용해 빌드한다.

• 여러 개의 tag 생성

  dockerCmd.build tag:['my/app:0.0.1', 'my/app:latest']
  
  // 실제 수행되는 명령어
  // docker build -t my/app:0.0.1 -t my/app:latest .

• 다른 경로에 있는 특정 Dockerfile 을 이용해서 빌드

  dockerCmd.build tag:'my/app:0.0.1', path: 'docker', 'file': 'Dockerfile-dev'
  
  // 실제 수행되는 명령어
  // docker build -f Dockerfile-dev -t my/app:0.0.1 docker

  source root 하위의 ./docker/Dockerfile-dev 를 이용해서 빌드한다.

• buildArgs 전달

  dockerCmd.build tag:'my/app:0.0.1', buildArgs: [file: "target/myApp-0.0.1.jar"]
  
  // 실제 수행되는 명령어
  // docker build -t my/app:0.0.1 --build-arg file=target/myApp-0.0.1.jar .

  아래처럼 Dockerfile 안에서 특정 값을 파라미터로 받을 필요가 있는 경우 buildArgs 를 사용한다. 

  FROM openjdk:8-jdk-alpine
  ARG file
  ADD ${file} app.jar
  ENTRYPOINT exec java -jar /app.jar

dockerCmd.tag

docker image 에 새로운 tag 를 생성한다.

Parameters

Return

N/A

사용 예제

• dockerCmd.tag source:'my/app:0.0.1', target:'my/app:latest'
  
  // 실제 수행되는 명령어
  // docker tag my/app:0.0.1 my/app:latest

dockerCmd.push

local 에 존재하는 docker image 를 remote registry 에 push한다.

Parameters

Return

N/A

사용 예제

• docker hub 에 이미지 올리기

  Credential 은 미리 생성해두어야 한다.

  dockerCmd.push imageName: 'my/app', imageVersion: '1.0.0', credentialsId: 'myCredentialsId'
  
  // 실제 수행되는 명령어
  // docker login -u XXXX -p XXXX
  // docker push my/app:1.0.1
  // docker logout

• Private Repository 에 이미지 올리기

  dockerCmd.push registry:'https://my.private.registry', imageName: 'my/app', imageVersion: '1.0.0', credentialsId: 'myCredentialsId'
  
  // 실제 수행되는 명령어
  // docker login https://my.private.registry -u XXXX -p XXXX
  // docker push my/app:1.0.1
  // docker logout

kubeCmd

kubectl 관련 명령어를 수행한다.

kubeCmd.apply

kubectl apply 를 실행하고, 이후의 관련 오류 처리를 수행한다.

Parameters

조회 유형 & 적용 우선순위 (위에서부터 순서대로)

1. file
2. folder

사용 예제

• 폴더 하위의 모든 file 적용

  kubeCmd.apply folder: 'k8s'

  현재 사용중인 kubeConfig 에 설정되어 있는 namespace 에 k8s 폴더 하위의 모든 파일을 apply 한다.
  folder 를 대상으로 apply 하는 경우 wait, recoverOnFail, recoverFile 옵션은 무시된다.

• deployment 를 dev namespace 에 apply 하기

  kubeCmd.apply file: 'k8s/deploy.yaml', namespace: 'dev'

  ./k8s/deploy.yaml 파일을 dev namespace 에 apply 한다. 

  wait 값을 지정하지 않았으므로 해당 Deployment 에 의해 생성되는 Pod 들이 완전히 기동 될때까지 최대 300초를 기다린다.

  300초가 지나도 모든 Pod 이 완전히 기동되지 않으면 실패로 판단한다. 실패 시 kubectl describe 로 해당 Pod 들의 event 를 로그에 출력하고, Exception 을 발생시킨다.

• deployment 를 dev namespace 에 apply 하고 1분 안에 Pod 기동 실패 시 이전 상태로 복구하기.

  kubeCmd.apply file: 'k8s/deploy.yaml', namespace: 'dev', wait: '60', recoverOnFail: true

  ./k8s/deploy.yaml 파일을 dev namespace 에 apply 한다.

  wait 값이 60 이므로 해당 Deployment 에 의해 생성되는 Pod 들이 완전히 기동 될때까지 최대 60초를 기다린다.

  60초가 지나도 모든 Pod 이 완전히 기동되지 않으면 실패로 판단하고, describe 로 Pod 들의 event 를 로그에 출력한다.

  apply 실행 시 동일한 이름의 Deployment 가 존재했으면 실패했을 때 Rollout undo 로 이전 Deployment 의 상태로 되돌린다.

  동일한 이름의 Deployment 가 존재하지 않았으면 delete 로 기동 실패한 Deployment 를 삭제한다.

• service 를 apply 하고 실패 시 이전 상태로 복구하기.

  // 복구를 위한 원본 파일을 복사해둔다.
  sh 'cp k8s/service.yaml k8s/service_old.yaml'
  
  
  // service 파일 내용을 변경하는 예시.
  yaml.bluegreenServiceUpdate file: 'k8s/service.yaml'
  
  
  // 변경한 service 파일을 apply 하고 실패 시 원본 파일 상태로 되돌린다.
  kubeCmd.apply file: 'k8s/service.yaml', namespace: 'dev', recoverOnFail: true, recoverFile: 'k8s/service_old.yaml'

  ./k8s/service.yaml 파일을 dev namespace 에 apply 한다.

  리소스가 service 타입이므로 wait 를 설정해도 대기하지 않는다.

  recoverOnFail 옵션이 true 이므로 apply 시 에러가 발생하면 복구를 시도한다.

  recoverFile 을 설정했으므로 service_old.yaml 파일을 다시 apply 하여 이전 상태로 복구한다. 만일 recoverFile 를 설정하지 않았으면 그냥 종료된다.

kubeCmd.describe

kubectl describe 를 실행한 내용을 log 에 출력한다.

Parameters

조회 유형 & 적용 우선순위

1. type + name
2. type + label
3. file

사용 예제

• deployment 의 name 으로 describe 출력

  kubeCmd.describe type: 'deployment', name: 'myapp'

• deployment 의 label 로 describe 출력

  kubeCmd.describe type: 'deployment', label: ['app' : 'myapp']

• yaml 파일로 describe 출력

  kubeCmd.describe file: 'k8s/myapp.yaml'

• 조회 실패 시 error 발생시키기

  kubeCmd.describe type: 'deployment', name: 'myapp', throwException: true

  myapp 이란 deployment 가 존재하지 않을 경우 exception 이 발생한다.
  
  

kubeCmd.resourceExists

해당 리소스가 해당 namespace 에 이미 존재하는지 확인한다.

Parameters

return

boolean - 해당 resource 존재 여부

조회 유형 & 적용 우선순위

1. type + name
2. type + label
3. file

사용 예제

• deployment 가 namespace 에 존재하는지 확인하기

  def exists = kubeCmd.resourceExsits type: 'deployment', name: 'myapp', namespace: 'dev' 

  myapp 이란 deployment 가 dev namespace에 이미 존재할 경우 true 를 return 하고, 존재하지 않을 경우 false 를 return 한다.

• deployment 의 label 로 해당 deployment 가 존재하는지 확인

  def exists = kubeCmd.resourceExsits type: 'deployment', label: ['app':'myapp']

• yaml 파일로 해당 리소스가 존재하는지 확인

  def exists = kubeCmd.resourceExists file: 'k8s/myservice.yaml'

kubeCmd.getValue

json path 를 이용해 해당 리소스의 특정 값을 추출한다.

Parameters

return

String - 추출한 jsonpath 값.

조회 유형 & 적용 우선순위

1. type + name
2. file

kubeCmd.rolloutStatus

특정 resource를 apply 한 후 readiness 가 성공할 때까지 대기한다.

deploy, daemonset, statefullset 만 지원한다.

Parameters

조회 유형 & 적용 우선순위

1. type + name
2. file

kubeCmd.rolloutUndo

특정 resource 를 rollout history 의 이전 상태로 롤백시킨다. 

deploy, daemonset, statefullset 만 지원한다.

Parameters

조회 유형 & 적용 우선순위

1. type + name
2. file

kubeCmd.delete

resource 를 삭제한다.

Parameters

조회 유형 & 적용 우선순위

1. type + name
2. file

kubeCmd.scale

해당 resource 의 instance 수(Pod 갯수)를 조정한다.

deploy, daemonset, statefullset 만 지원한다.

Parameters

조회 유형 & 적용 우선순위

1. type + name
2. file

yaml

yaml 파일 관련 기능 제공

yaml.update

yaml 파일의 특정 값을 업데이트 한다.

Parameters

yaml.bluegreenDeployUpdate

bluegreen 에서 기본으로 사용되는 형태의 deployment.yaml 파일을 업데이트 한다.

.metadata.name

.metadata.labels.version

.spec.selector.matchLabels.version

.spec.template.metadata.labels.version

.spec.template.spec.containers[0].image

Parameters

yaml.bluegreenServiceUpdate

bluegreen 에서 기본으로 사용되는 형태의 service.yaml 파일을 업데이트 한다.

.spec.selector.version

Parameters

gitCmd

git 과 관련 된 명령어를 수행한다.

gitCmd.checkout

git 에서 checkout 을 받는다.

Parameters

gitCmd.commit

변경한 파일을 commit 한다.

Parameters

gitCmd.push

commit 한 파일을 원격 저장소에 push 한다.

Parameters

gitCmd.tag

local repository 에 tag 를 생성하고 remote repository 에 push 한다.

Parameters