Spinnaker를 활용한 Kubernetes CD 구성하기

서론

Spinnaker는 넷플릭스에서 개발한 오픈소스 Continuous Delivery 플랫폼이다. AWS, Azure, Google Cloud 등 Public Cloud는 물론, Native Kubernetes, OpenStack 등의 Private Cloud 기반에도 적용할 수 있다.

Spinnaker 역시 Jenkins와 같이 Pipeline으로 여러 Stage를 하나의 동작으로 묶어 관리할 수 있으며, UI에 강점이 있어 보다 운영 편의성을 제공한다.

Spinnaker는 Jenkins 등 CI 툴에서 생성한 Base Image를 기반으로 CD를 수행하는 오픈소스 플랫폼이다. Spinnaker를 적용할 경우 Jenkins의 두 스텝 중 Base Image, Custom Image 설계/빌드가 완료되면, 이를 Nexus3로부터 불러와 Deployment & Delivery를 수행한다.

본문

1. Spinnaker 구성

Spinnaker는 Infra Server에서 구성한다. 기동을 위해서는 kubenetes 설정이 필요하므로 master 서버에 있는 ~/.kube폴더를 infra 서버의 root경로로 복사한다.

 

1) Spinnaker Docker Container 기동

Spinnaker를 설치하기 위해서 Spinnaker의 배포를 관장하는 tool인 halyard를 이용한다.

Halyad를 설치하는 방안으로는 여러가지가 있다.

그 중 Halyard를 VM에 직접 구성하는 방법과 Docker Container로 기동하는 방법에 대해 알아보자.

먼저 VM에 직접 구성하는 방법이다.

[root@ciserver ~]# curl -O https://raw.githubusercontent.com/spinnaker/halyard/master/install/debian/InstallHalyard.sh
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  9188  100  9188    0     0  15829      0 --:--:-- --:--:-- --:--:-- 15841
[root@ciserver ~]# bash InstallHalyard.sh
~~~
~~~
[root@ciserver ~]# 

다음으로 Docker Container로 기동하는 방법이다.

[root@kubemaster ~]# docker run –p 8084:8084 –p 9000:9000 --name halyard --rm –network=host –v ~/.hal:/home/spinnaker/hal –v ~/.kube:/home/spinnaker/.kube –it -d gcr.io/spinnaker-marketplace/halyard:stable
WARNING: Published ports are discarded when using host network mode
8590e150abcd48b04de33989c30d528f35fdf0ce95f6393893cce067294d0e7f

Spinnakers는 ui와 api 가 각각 8084, 9000 포트를 이용하므로 위와 같이 입력하여 호스트OS를 통해 접근할 수 있도록 한다. docker-proxy로 인터넷이 되지 않는 경우에 한하여 --network=host를 입력하여 host의 인터넷을 사용할 수 있도록 한다. Halyard config와 Kubernetes config를 이용하므로 해당하는 폴더를 /home/spinnaker에 mapping 시킨다. 백그라운드 기동을 위하여 –d 옵션을 추가시켜준다.

기동이 완료되면 다음과 같이 halyard 버전을 확인할 수 있다.

[root@ciserver ~]# hal -v
1.38.0-20200727213212
[root@ciserver ~]# 

 

2) 컨테이너 접속

다음으로 기동된 컨테이너에 접근한다.

다음과 같이 입력하여 halyard docker container에 접속한다.

[root@kubemaster ~]# docker exec –it halyard bash
bash-5.0$

 

3) Provider 지정

접속이 완료되면 다음으로 공급자를 선택한다. 여기서 kubernetes를 선택하도록 한다. 사전에 아래 두가지 사항이 필요하다.

-kubeconfig : Kubernetes 설정을 담당한다. Spinnaker가 사용하는 리소스에 대한 읽기/쓰기 권한을 제어할 수 있다.

-kubectl : Spinnaker는 kubectl을 이용하여 모든 API 액세스를 관리한다.

사전 준비가 되었다면 계정 추가를 한다. 다음과 같이 입력하여 공급자가 활성화 되어 있는지 확인한다.

bash-5.0$ hal config provider kubernetes enable
+ Get current deployment
  Success
+ Edit the kubernetes provider
  Success
Validation in default:
- WARNING You have not yet selected a version of Spinnaker to
  deploy.
? Options include:
  - 1.16.6
  - 1.17.6
  - 1.18.4
Validation in default.provider.kubernetes:
- WARNING Provider kubernetes is enabled, but no accounts have been
  configured.
+ Successfully enabled kubernetes

 

4) 계정 추가

공급자가 활성화 되었다면 다음을 입력하여 계정을 추가한다.

bash-5.0$ hal config provider kubernetes account add my-k8s-account --provider-version v2 --context $(kubectl config current-context)
+ Get current deployment
  Success
+ Add the my-k8s-account account
  Success
+ Successfully added account my-k8s-account for provider
  kubernetes.
bash-5.0$ hal config features edit --artifacts true
+ Get current deployment
  Success
+ Get features
  Success
+ Edit features
  Success
Validation in default:
- WARNING You have not yet selected a version of Spinnaker to
  deploy.
? Options include:
  - 1.16.6
  - 1.17.6
  - 1.18.4
+ Successfully updated features.          

계정을 추가하면 설치 환경을 설치한다. 운영환경으로 적합한 분산 설치를 한다. 다음 명령으로 분산 설치를 지정할 수 있다.

bash-5.0$ hal config deploy edit --type distributed --account-name $ACCOUNT
+ Get current deployment
  Success
+ Get the deployment environment
  Success
_ Edit the deployment environment
+ Edit the deployment environment
  Success
Validation in default:
- WARNING You have not yet selected a version of Spinnaker to
  deploy.
? Options include:
  - 1.16.6
  - 1.17.6
  - 1.18.4
+ Successfully updated your deployment environment.

$ACCOUNT는 위에서 공급자를 추가할 때 만든 계정이다.

 

5) 스토리지 추가

다음으로 스토리지를 설정한다. Spinnaker는 외부 저장소에서 어플리케이션 설정 및 파이프라인 설정을 유지한다. 클라우드 환경을 사용하지 않을 때, Self-hosting 할 수 있는 s3 호환 스토리지인 Minio를 사용할 것을 권장한다.

Minio는 원격객체로 사용하기 위해 쿠버네티스 클러스터에 포함되어 있는 노드를 제외한 별도의 노드를 사용하는 것이 좋다.

Minio는 버전 객체를 권장하지 않으므로 Spinnaker에서 버전 객체를 비활성화한다.

bash-5.0$ vi ~/.hal/default/profiles/front50-local.yml
spinnaker.s3.versioning : false

인프라 서버에 minio를 설치한다. Minio는 단일 실행 파일을 제공하므로 wget으로 다운로드 받아 바로 실행할 수 있다.

[root@kubeinfra ~]# wget https://dl.min.io/server/minio/release/linux-amd64/minio
[root@kubeinfra ~]# chmod +x minio

다음으로 minio 파일을 9001 포트로 실행한다.

[root@kubeinfra ~]# minio server –address “:9001” --config-dir /data/minio-config /data/minio
Endpoint:  http://192.168.56.101:9001  http://172.17.0.1:9001  http://192.168.122.1:9001  http://127.0.0.1:9001
AccessKey: minioadmin
SecretKey: minioadmin
 
Browser Access:
   http://192.168.56.101:9001  http://172.17.0.1:9001  http://192.168.122.1:9001  http://127.0.0.1:9001
 
Command-line Access: https://docs.min.io/docs/minio-client-quickstart-guide
   $ mc config host add myminio http://192.168.56.101:9001 minioadmin minioadmin
 
Object API (Amazon S3 compatible):q
   Go:         https://docs.min.io/docs/golang-client-quickstart-guide
   Java:       https://docs.min.io/docs/java-client-quickstart-guide
   Python:     https://docs.min.io/docs/python-client-quickstart-guide
   JavaScript: https://docs.min.io/docs/javascript-client-quickstart-guide
   .NET:       https://docs.min.io/docs/dotnet-client-quickstart-guide

마스터 서버로 돌아와서 halyard 설정에 minio를 추가한다. Minio를 사용할 경우 저장소 유형을 s3으로 선택한다. Endpoint는 위에서 제시된 endpoint를 입력하고 access key와 secret key도 위에서 제시된대로 입력한다.

Bash-5.0$ hal config storage s3 edit –-endpoint http://192.168.56.101:9001 --access-key-id minioadmin  --secret-access-key minioadmin
 
+ Get current deployment
  Success
+ Get persistent store
  Success
Generated bucket name: spin-1e419e32-e088-4fe5-92a2-f172d18afeda
+ Edit persistent store
  Success
Validation in default.persistentStorage:
- WARNING Your deployment will most likely fail until you configure
  and enable a persistent store.
 
Validation in default:
- WARNING You have not yet selected a version of Spinnaker to
  deploy.
? Options include:
  - 1.16.6
  - 1.17.6
  - 1.18.4
 
+ Successfully edited persistent store "s3".
bash-5.0$  hal config storage edit --type s3
+ Get current deployment
  Success
+ Get persistent storage settings
  Success
+ Edit persistent storage settings
  Success
Validation in default:
- WARNING You have not yet selected a version of Spinnaker to
  deploy.
? Options include:
  - 1.16.6
  - 1.17.6
  - 1.18.4
 
+ Successfully edited persistent storage.

또는 in-memory DB인 Redis Cache를 연동할 수도 있다.

[root@ciserver ~]# hal config storage edit --type redis
+ Get current deployment
  Success
+ Get persistent storage settings
  Success
- No changes supplied.
[root@ciserver ~]#

 

6) Spinnaker 설치

다음으로 설치 가능한 버전을 조회한다.

bash-5.0$ hal version list
+ Get current deployment
  Success
+ Get Spinnaker version
  Success
+ Get released versions
  Success
+ You are on version "1.16.6", and the following are available:
 - 1.16.6 (SecretObsession):
   Changelog: https://gist.github.com/spinnaker-release/b200688131077600c458b07e0ae88052
   Published: Tue Dec 03 15:37:45 GMT 2019
   (Requires Halyard >= 1.17)
 - 1.17.6 (LlamaLlama):
   Changelog: https://gist.github.com/spinnaker-release/3c23bfdc3493cca22664ba9b7771bc9d
   Published: Tue Jan 14 14:19:44 GMT 2020
   (Requires Halyard >= 1.17)
 - 1.18.4 (Longmire):
   Changelog: https://gist.github.com/spinnaker-release/a7b148c63b4b8b0f6dc632ef3b9001cc
   Published: Thu Feb 27 21:59:02 GMT 2020
   (Requires Halyard >= 1.29)

원하는 버전을 선택한다.

bash-5.0$ hal config version edit --version 1.16.6

버전 설정이 완료되면 배포를 진행한다.

bash-5.0$ hal deploy apply
 
+ Get current deployment
   Success
+ Prep deployment
Success
 
. . . . . . . .
  
 
+ Apply deployment
  Success
+ Deploy spin-redis
  Success
+ Deploy spin-clouddriver
  Success
+ Deploy spin-front50
  Success
+ Deploy spin-orca
  Success
+ Deploy spin-deck
  Success
+ Deploy spin-echo
  Success
+ Deploy spin-gate
  Success
+ Deploy spin-rosco
  Success

 

7) Spinnaker 대시보드 구성

배포가 완료되면 Spinnaker 대시보드에 접속하기 위하여 아래 명령어를 실행한다.

설치 진행 방법대로 따라가다 보면 마스터 서버에서만 localhost로 접속이 가능함을 알 수 있다. 외부 ip로 접속이 가능하도록 kubenetes의 서비스들을 수정해주어야 한다. 다음 명령어로 spin-deck 서비스를 수정한다.

bash-5.0$ kubectl edit service spin-deck --namespace spinnaker
selector:
    app: spin
    cluster: spin-deck
  sessionAffinity: None
  type: NodePort     

Spec 카테고리에서 ClusterIp로 설정되어 있는 type을 NodePort로 수정한다. 저장하고 vim을 종료하면 spin-deck의 type이 NodePort로 설정됨과 동시에 NodePort를 부여받을 것이다.

마찬가지의 방법으로 spin-gate의 type도 NodePort로 바꾸어준다.

-      spin-deck은 UI에 접근하기 위한 NodePort

-      spin-gate는 API에 접근하기 위한 Node Port

그리고 사용 용이성을 위하여 인위적으로 port를 맞춰 주기를 권장한다. 마찬가지로 kubectl edit로 다음과 같이 바꿀 수 있다.

bash-5.0$ kubectl edit service spin-deck --namespace spinnaker
ports:
  - nodePort: 30101
    port: 9000
    protocol: TCP
    targetPort: 9000      

다음 명령어로 Service들을 조회하면 spin-gate와 spin-deck의 Node port 설정이 제대로 되었는지 확인할 수 있다.

bash-5.0$ kubectl get services --namespace spinnaker
NAME               TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
spin-clouddriver   ClusterIP   10.233.28.28    <none>        7002/TCP         6h4m
spin-deck          NodePort    10.233.11.139   <none>        9000:30101/TCP   6h4m
spin-echo          ClusterIP   10.233.55.3     <none>        8089/TCP         6h4m
spin-front50       ClusterIP   10.233.10.253   <none>        8080/TCP         6h4m
spin-gate          NodePort    10.233.8.154    <none>        8084:30102/TCP   6h4m
spin-igor          ClusterIP   10.233.7.137    <none>        8088/TCP         5h30m
spin-orca          ClusterIP   10.233.29.135   <none>        8083/TCP         6h4m
spin-redis         ClusterIP   10.233.23.80    <none>        6379/TCP         6h4m
spin-rosco         ClusterIP   10.233.37.125   <none>        8087/TCP         6h4m

 

8) spin-deck, spin-gate 연동

NodePort를 설정해 주었다면, 브라우저 내에서 deck과 gate가 통신할 수 있도록 base url을 override해주어야 한다. Override하지 않는다면 대시보드에서 api를 fetching 하지 못해 UI접속시 Application 생성화면을 불러오지 못하고 Fetching Error 메시지가 출력될 것이다. 다음 명령어로 UI와 API의 baseurl을 override한다. Ui의 url은 http://(Public Ip):(spin-deck의 node port), api의 url은

http://(Public Ip):(spin-gate의 node port)이 된다.

bash-5.0$ hal config security ui edit --override-base-url http://192.168.56.101:30101
bash-5.0$ hal config security api edit --override-base-url http:://192.168.56.101:30102           

다음과 같이 설정이 완료되면 배포 적용을 하고 connect를 한다.. 백그라운드 사용을 위하여 &을 붙여서 백그라운드 적용을 권장한다.

bash-5.0$ hal deploy apply
bash-5.0$ hal deploy connect &

 

9) Spinnaker 대시보드 접속

이제 http://ClusterNodeIp:(spin-deck_nodePort)로 접속할 경우 다음과 같이 Spinnaker 대시보드를 확인할 수 있다.

2. Spinnaker 배포

Spinnaker는 배포 자동화 툴로서 CD(Continuous Delievery)를  지원한다.  Docker registry에 있는 Docker Image를 Kubernetes Pods 의 형태로 배포한다.  배포 진행 과정은 다음과 같다. 우선적으로 Spinnaker는 application 단위로 job을 구동하므로 application을 생성해주어야 한다. Application은 다음과 같이 생성할 수 있다.

 

Jenkins에서 CI가 진행된 방식처럼 Spinnaker에서도 파이프라인 형태로 배포를 진행한다. 파이프라인에 스테이지를 올려서 배포를 단계별로 진행하는 방식이다. Application내에서 구동할 파이프라인을 생성할 수 있다. Pipeline의 생성 방식은 다음과 같다. 우선 Application내 Pipeline 메뉴를 클릭한다. 아직 pipeline이 구성되어 있지 않으므로 pipeline이 존재하지 않다고 나오며 pipeline을 생성할 수 있는 버튼이 나온다. 클릭하면 pipeline의 이름을 넣어서 간단하게 Pipeline을 만들 수 있다.

 

Pipeline은 다음과 같이 진행된다. Nexus3로 구성된 Docker Registry에 새로운 Docker Image가 push될 때마다 pipeline에서는 Docker Image를 pull하고 이를 Kubernetes Pod으로 배포한다. 이 과정은 세가지로 나눌 수 있다.

1)    Docker Image가 push될 때마다 pipeline이 작동되게 끔하는 Build Trigger

2)    Kubenetes manifest를 Helm Chart로 작성하기 위한 Bake Stage

3)    Build Trigger가 발생하면 Docker Registry로부터 Image를 Pull받아 Kubernetes Pods로 배포하는Deploy Stage

 

1) Build Trigger

Build Trigger Stage의 과정은 다음과 같이 구성할 수 있다. 먼저 spinnaker내에  docker registry를 추가해 주어야 한다.  Halyard bash에서 다음과 같이 입력하여 docker-registry를 추가할 수 있다.

bash-5.0$ hal config provider docker-registry enable
 
+ Get current deployment
  Success
+ Edit the dockerRegistry provider
  Success
Validation in default.provider.dockerRegistry:
- WARNING Provider dockerRegistry is enabled, but no accounts have
  been configured.
 
+ Successfully enabled dockerRegistr
bash-5.0$ hal config provider docker-registry account add my-docker-registry --address $ADDRESS --username $USERNAME --password $PASSWORD
 
bash-5.0$ hal config provider docker-registry account add my-docker-registry --address http://192.168.56.101:5000 --username admin --password 1234qwer
+ Get current deployment
  Success
* Add the my-docker-registry account
+ Add the my-docker-registry account
  Success
 
+ Successfully added account my-docker-registry for provider
  dockerRegistry.
bash-5.0$ hal deploy apply            

 Docker-registry 등록이 완료되었으면 다시 spinnaker에 접속한다.

위에서 만든 Application과 pipeline에 접속하면 왼쪽 탭에 다음과 같이 Automated Triggers 메뉴가 보이는 데 다음을 클릭하고 Docker Registry 설정을 해준다. Trigger하고자하는 image를 선택하고 저장한다.

위와 같이 작성하면 Docker Registry에 Image가 Push될 때 마다 Pipeline이 진행되게 된다.

Tag 명을 지정하지 않으면 latest가 default로 지정된다.

 

2) Bake Stage

Bake Stage 에서 Helm Chart 패키지를 artifact로 참조하기 위해선 Helm Chart가 Git Repository에 존재해야 한다. 따라서 프로젝트 repository를 Git pull하여 Helm Chart를 그 안에 패키징한 후 다시 Push 하도록한다. Git pull과 Helm Chart 생성은 다음과 같이 할 수 있다.

[root@kubemaster ~]# git clone http://192.168.56.101:80/root/source.git
Cloning into 'source'...
Username for 'http://192.168.56.101:81': root
Password for 'http://root@192.168.56.101:81':
remote: Enumerating objects: 255, done.
remote: Counting objects: 100% (255/255), done.
remote: Compressing objects: 100% (150/150), done.
remote: Total 255 (delta 89), reused 241 (delta 75), pack-reused 0
Receiving objects: 100% (255/255), 25.09 MiB | 39.19 MiB/s, done.
Resolving deltas: 100% (89/89), done.
[root@kubemaster ~]# cd source
[root@kubemaster source]# helm create helm-chart
Creating helm-chart

 위와 같이 입력하면 Helm Chart가 구성된다. Helm Chart는 Kubernetes Pods으로 배포하기 위한 yaml으로 구성된다. Container에 구성될 Docker Image는 templates/deployment.yaml에 {values.image.repository}:{chart.appversion}으로 되어 있다. 따라서 참조하는 values.yaml과 chart.yaml을 수정하여 pull할 image를 mapping 하도록한다.

[root@kubemaster source]# cd helm-chart/
[root@kubemaster helm-chart]# vim values.yaml
 
. . . . . . .
replicaCount: 1
 
image:
  repository: 192.168.56.101:5000/tec_repo/customimage
  pullPolicy: IfNotPresent
 
imagePullSecrets: []
nameOverride: ""
fullnameOverride: ""
 
. . . . . . . .
 
 
[root@kubemaster helm-chart]# vim chart.yaml
 
. . . . . . . .
appVersion: 20200306

 위와 같이 수정하면 Kubernetes Pod으로 배포하기 위한 기본 설정은 끝난다. Helm chart를 packaging하고 Git repository로 Push한다.

[root@kubemaster source]# helm package helm-chart
Successfully packaged chart and saved it to: /root/source/helm-chart-0.1.0.tgz
[root@kubemaster source]# git add .
[root@kubemaster source]# git commit –m “helm chart add”
[root@kubemaster source]# git push origin master
Counting objects: 14, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (8/8), 3.99 KiB | 0 bytes/s, done.
Total 8 (delta 5), reused 0 (delta 0)
To http://192.168.56.101:81/root/source.git
   6963dd8..dcf24ae  master -> master

위와 같이 작업하면 배포를 위한 helm 기본 환경 구성이 완료된다

위의 2)는 4.1.7 Helm 파트에서 구성한 Helm Chart Package를 artifact로 사용하여야 한다. Helm Chart Package가 Gitlab에 적재되어 있으므로 GIt 접근 권한을 spinnaker에 제공하여야 한다. Spinnaker에 GIt 접근 권한을 추가하는 것은 다음과 같이 진행할 수 있다.

우선적으로 GItlab에 접속하여 User Setting에서 Personal Access Token을 얻는다.

Personal Access Token 을 획득하였다면 halyard bash로 접속하여 spinnaker에 gitlab access를 추가해준다.

bash-5.0$ cd~
bash-5.0$ echo “9a-Em8W3gdCyC2BAz8yy” > ./hal/gitlab_root_token
bash-5.0$
bash-5.0$ ARTIFACT_ACCOUNT_NAME=”gitlab-root-access”
bash-5.0$ hal config features edit --artifacts true
 
+ Get current deployment
  Success
+ Get features
  Success
+ Edit features
  Success
+ Successfully updated features.
bash-5.0$ hal config artifact gitlab enable
+ Get current deployment
  Success
+ Edit the gitlab provider
  Success
+ Successfully enabled gitlab
bash-5.0$ hal config artifact gitlab account add $ARTIFACT_ACCOUNT_NAME --token-file /home/spinnaker/hal/gitlab_root_token
+ Get current deployment
  Success
+ Add the test artifact account
  Success
+ Successfully added artifact account test for artifact provider
  gitlab.
bash-5.0$ hal deploy apply

 위와 같이 입력하면 Spinnaker에 Gitlab root 접근 권한 추가가 완료된다. Pipeline에서 Expected Artifact 로 GItlab에 있는 helm chart package 파일을 추가해주어야 한다. 다음과 같이 추가할 수 있다.

Bake stage는 다음과 같이 구성된다., 먼저, 배포시 생성될 pod의 이름과 namespace를 지정한다. 그리고 Template Artifact로 expected artifact에서 구성하였던 helm chart artifact를 입력한다. Produces artifacts는 bake stage에서 생성할 artifact로서 deploy stage에서 쓰일 kubernetes artifacts가 된다.  artifact로서 kubernetes manifest로 쓰이게 된다.

 

3) Deploy Trigger

마지막으로 배포 단계만 남았다. Add Stage를 하고 deploy를 선택한다. account 는 spinnaker 설치시 공급자 계정으로 추가했던 계정을 선택한다. Manifest는 artfiact로 bake stage에서 만드는 artifact를 설정한다. 아래와 같이 하면 deploy stage 기본 설정이 완료된다.

이제 배포를 위한 설정은 완료되었고 파이프라인을 구동시키면 Kubernetes pod이 생성된다.

위와 같이 정상적으로 완료되면 Kubernetes에 Pod 상태를 확인한다.

[root@kubemaster source]# kubectl get pods -v
NAMESPACE  NAME                                READY    STATUS    RESTARTS   AGE
default     test-helm-chart-68d58bf6cb-ktmmq       1/1     Running   0          133m

위와 같이 test-helm-chart가 Running 상태로 기동된 것을 확인할 수 있다.

3.  Jenkins와 Spinnaker 비교

본 절에서는 Jenkins pipeline을 통한 배포와 Spinnaker를 통한 배포를 비교해보고 각각의 장단점을 분석하였다.

Jenkins 는 CI 도구이고 Spinnaker는 Cloud Api를 직접 호출하기 때문에 스크립트가 필요없다. Jenkins는 범용성을 지원하다보니 필요한 기능은 플러그인을 개발해서 사용해야 하고 이미 있는 플러그인을 설치하더라도 복잡한 설정을 일일이 수작업으로 진행해야 한다. 결정적으로 Jenkins는 클라우드 환경에서 안정적으로 배포하기 위한 오케스트레이션 플러그인이나 자체 엔진을 제공하지 않는다. 다시 말하면 배포를 하기 위해 직접 스크립트를 작성해야 하고 그 스크립트를 검증하고 버전관리하는 수고를 해야한다는 뜻이다.

Spinnaker의 경우 Orca서비스가 존재하며 Orca는 모든 컴포넌트들을 오케스트레이션하여 파이프라인을 관리한다. 그리고 Bake 과정을 통하여 스크립트없이 배포를 위한 Manifest를 UI로 만들어서 진행할 수 있다. 따라서 위에서 보는 것처럼 UI로 배포 과정을 용이하게 진행할 수 있다는 것이 Spinnaker의 큰 장점이라고 볼 수 있다.

그러나 Spinnaker의 경우 CI를 지원하지 않으므로 CI 파이프라인은 다른 툴에서 진행해야 한다. Docker Image를 build하고 Docker Registry에 Push하는 CI 파이프라인은 Jenkins에서 실행하고 Spinnaker는 Jenkins와 연동하여 CD 파이프라인을 수행한다.