spinnaker CD 연동해 보기 (4) - pipeline template 사용해 보기

전체 글타래

2022.12.18 - [Study/CI&CD] - 로컬 kubernetes에 Spinnaker 설치해 보기

2022.12.22 - [Study/CI&CD] - spinnaker CD 연동해 보기 - jenkins, kubernetes 연동, pipeline 사용

2022.12.26 - [Study/CI&CD] - spinnaker CD 연동해 보기 (2) - deploy manifest artifact 사용, SpEL 사용

2023.01.01 - [Study/CI&CD] - spinnaker CD 연동해 보기 (3) - jenkins parameter 사용, kubernetes livenessProbe, readinessProbe 설정

2023.01.10 - [Study/CI&CD] - spinnaker CD 연동해 보기 (4) - pipeline template 사용해 보기

이번 목표

이전 글을 통해 CD를 어느 정도 구축하였다.

하지만 api 추가가 늘어나면서 수정 사항이 생길 때마다 N개만큼 pipeline을 수정하는 것이 부담이 커지게 되었다.
pipeline template을  `spinnaker CD 연동해 보기 (2)`에서 잠깐 언급한 적이 있다.
pipeline template을 사용해서 이런 부담을 줄일 수 있는지 알아본다.

jenkins build.properties로 pipeline paramter 설정 값 옮기기

https://spinnaker.io/docs/guides/user/pipeline/triggers/jenkins/

artifact가 deploy에 대한 설정을 공통화하는 것이라면 pipeline template은 pipeline을 템플릿화 해서 재사용을 하기 위한 기능이다.

다만 이렇게 재사용을 하기 위해서는 각 pipeline의 parameter의 default값을 개별로 설정하지 않고 jenkins에서 전달받아 쓰도록 공통화를 해야 한다.
(pipeline에선 동일하게 설정해야 함)

내 경우 maven의 properties-maven-plugin을 사용하여 build.properties를 만들고 build.version을 사용할 수 있게 하였었다.
여기에 기존 pipeline의 parameters에서 설정하던 몇 가지 값을 추가하려고 한다.

jenkins의 기존 빌드 단계에 `Add post-build step`으로 Execute shell에 다음과 같은 값을 build.properties에 추가하도록 하였다.

# 빌드 관련 정보 추가
echo "build.imageHost=localhost:8083" >> bluesky-parent/build.properties 
echo "build.bluesky-web-swagger-ui.artifactId=bluesky-web-swagger-ui" >> bluesky-parent/build.properties 
echo "build.bluesky-web-swagger-ui.springProfilesActive=k8sdev" >> bluesky-parent/build.properties 
echo "build.bluesky-web-swagger-ui.port=30120" >> bluesky-parent/build.properties 
echo "build.bluesky-web-swagger-ui.nodePort=30120" >> bluesky-parent/build.properties 
echo "build.bluesky-web-default.artifactId=bluesky-web-default" >> bluesky-parent/build.properties 
echo "build.bluesky-web-default.springProfilesActive=k8sdev" >> bluesky-parent/build.properties 
echo "build.bluesky-web-default.port=30121" >> bluesky-parent/build.properties 
echo "build.bluesky-web-default.nodePort=30121" >> bluesky-parent/build.properties 
echo "build.bluesky-api-bookkeeping.artifactId=bluesky-api-bookkeeping" >> bluesky-parent/build.properties 
echo "build.bluesky-api-bookkeeping.springProfilesActive=k8sdev" >> bluesky-parent/build.properties 
echo "build.bluesky-api-bookkeeping.port=30130" >> bluesky-parent/build.properties 
echo "build.bluesky-api-bookkeeping.nodePort=30130" >> bluesky-parent/build.properties 
echo "build.bluesky-api-user.artifactId=bluesky-api-user" >> bluesky-parent/build.properties 
echo "build.bluesky-api-user.springProfilesActive=k8sdev" >> bluesky-parent/build.properties 
echo "build.bluesky-api-user.port=30131" >> bluesky-parent/build.properties 
echo "build.bluesky-api-user.nodePort=30131" >> bluesky-parent/build.properties 
echo "build.bluesky-api-gate.artifactId=bluesky-api-gate" >> bluesky-parent/build.properties 
echo "build.bluesky-api-gate.springProfilesActive=k8sdev" >> bluesky-parent/build.properties 
echo "build.bluesky-api-gate.port=30132" >> bluesky-parent/build.properties 
echo "build.bluesky-api-gate.nodePort=30132" >> bluesky-parent/build.properties

Evaluate Variables Type으로 jenkins build.properties의 값을 설정하기

설정한 내용을 보면 spinnaker application 별로 다르게 설정하던 값들을 jenkins에서 build.properties에 `build.[applicationName].[key]` 형태로 설정하였다.

application 별로 설정된 값을 가져다 쓰면 되는데 각 application의 이름은 `${execution.application}` 으로 구할 수 있다.

따라서 SpEL의 구문을 사용하여 각 application별 값을 사용하려면 다음처럼 호출하면 된다.

${trigger.properties['build.' + execution.application + '.artifactId']}

하지만 spinnaker의 parameters의 경우 위와 같은 형태의 중첩 SpEL을 사용할 수 없다.

https://spinnaker.io/docs/guides/user/pipeline/expressions/

기존에 다음과 같은 형태로 parameters에 설정되어 있던 값을

다음처럼 바꿔도 올바르게 동작하지 않는다.

하지만 테스트해보니 Evaluate Variables Type stage의 변수 선언에선 중첩 SpEL이 사용이 된다. (최초 parameters의 설정만 중첩 SpEL을 사용할 수 없고 이후엔 사용이 가능해 보인다.)

따라서 기존의 parameter를 모두 지우고 Deploy Manifest 전에 Evaluate Variables Type stage를 추가하여 다음과 같이 설정하였다.

이 값을 사용하도록 기존의 deploy manifest를 수정하면 된다.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: '${name}'
  name: '${name}-deployment'
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: '${name}'
  template:
    metadata:
      labels:
        app: '${name}'
    spec:
      containers:
        - args:
            - '--spring.profiles.active=${springProfilesActive}'
          image: '${imageHost}/luversof/${artifactId}:${buildVersion}.${buildNumber}'
          livenessProbe:
            httpGet:
              path: /actuator/health/liveness
              port: '${port}'
            initialDelaySeconds: 20
            periodSeconds: 10
          name: spring
          ports:
            - containerPort: '${port}'
          readinessProbe:
            httpGet:
              path: /actuator/health/readiness
              port: '${port}'
            initialDelaySeconds: 20
            periodSeconds: 10
      imagePullSecrets:
        - name: regcred
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: '${name}'
    spring-boot: 'true'
  name: '${name}-service'
  namespace: default
spec:
  ports:
    - nodePort: '${nodePort}'
      port: '${port}'
      protocol: TCP
      targetPort: '${port}'
  selector:
    app: '${name}'
  type: NodePort

여기까지 설정하고 jenkins build의 값을 가져와 동작하는지 확인하면 정상적으로 동작을 한다.

Pipeline Template 생성하기

이제 이 pipeline은 공통으로 사용할 수 있도록 별도의 값을 설정하지 않은 상태이다.

이 pipeline을 기준으로 pipeline template을 생성한다.

내 경우 spin을 사용하지 않고 ui로 만들어보았다.

`Export as Pipeline Template`을 선택한 후

적당한 pipeline template name을 입력하고 save를 누르면

pipeline template이 생성된 것을 확인할 수 있다.

Pipeline Template 사용하기

똑같은 설정을 사용하는 기존의 다른 pipeline을 제거하고 pipeline template의 Create Pipeline으로 생성을 하면 된다.

pipeline template에서 가져올 수 있는 항목은 Notifiactions, Parameters, Triggers가 있다.

이 3가지 항목에 대해 개별설정을 하고자 하는 경우 체크를 해제하면 된다.

이렇게 pipeline template으로 생성된 pipeline은 다음과 같이 격자 모양으로 표시된다.

해당 pipeline은 가져오도록 체크하지 않은 항목에 대해서만 수정이 가능하고 수정이 불가능한 항목은 설정에서 모두 비활성화된다.

이제 새로운 application이 추가될 때마다 pipeline을 매번 세부 설정을 하지 않아도 만들어진 pipeline template을 사용하여 설정을 공통화할 수 있게 되었다

---

1.

생성된 pipeline template의 설정을 이후 변경해도 pipeline template에 바로 반영되지 않았다.

또한 다시 export 하더라도 기존 pipeline template 히스토리에 추가가 되지 않고 동일한 이름으로 새로운 pipeline template이 생성되었다.

이런 부분은 ui를 통해 생성해서 그런 것인지 spin을 사용하면 갱신이 되는 것인지는 확인하지 않았다.
(문서상엔 spin의 save 명령으로 update도 실행되는 것처럼 설명이 되어 있었다.)

https://spinnaker.io/docs/guides/spin/pipeline-templates/#create-and-update-pipeline-templates-with-save

2.

pipeline template을 만들고 해당 template을 사용하여 일부 항목을 재설정한 새로운 pipeline template을 만들면 두 template은 상속관계인 것처럼 보인다.

하지만 상속된 pipeline template을 사용하려고 하면 올바르게 template이 설정되지 않았다.

이 부분을 좀 더 자세하게 알아보지는 않았다.