Spinnaker에서 Judgement stage를 활용하여 Rollback을 수행했던 내용에 대하여 알아보도록 하겠습니다. 우선 기존 deploy 방식에 대하여 간단히 알아보겠습니다.

Application 배포는 다음과 같은 Deploy(Manifest) stage 구성으로 진행됩니다.

배포 전략은 Red/Black 방식을 사용하여 새로운 Replicaset이 배포되면 기존 Replicaset은 disable 되도록 하였습니다.

위 배포가 진행된 이후 Rollback과 Rollout 선택을 통해 배포를 그대로 진행할지 결정하도록 하였고 그에 따라 Rollback 후 delete가 될지

Rollout 그대로 진행후 오래된 ReplicaSet을 disable 할지 결정하게 됩니다.

Judgement stage 를 사용하여 분기시키기

앞서 설명하였던 “Manual Judgement” stage를 사용한 분기 방식에 대하여 알아보도록 하겠습니다.

먼저 Manual Judgement stage를 아래와 같이 Approval 이라는 이름과 함께 Option에 “rollout”, “rollback”을 추가합니다.

이후 다음 Enable(Manifest) Stage로 선택하여 아래와 같은 Execution Options을 추가합니다.

실제 조건은 다음과 같습니다.

${ #judgement( 'Approval' } == 'rollback' }

이후 Delete (Manifest) Stage를 선택하여 아래와 같은 Execution Options을 추가합니다.

실제 조건은 다음과 같습니다.

${ #judgement( 'Approval' } == 'rollout' }

여기까지는 설정방법이고 실제 동작결과에 대하여 알아보도록 하겠습니다.

Rollback

위 설정에 기반한 Rollback 에 대하여 실제 적용한 결과를 확인해보면 deploy가 실행되고 실제 Application은 다음과 같은 배포가 이루어집니다.

배포가 되면서 기존 Replicaset은 disable 되고 새로운 Replicaset이 동작하게 됩니다.

Judgement 에서 rollback 을 선택하면

아래와 같이 Delete(Manifest)는 제외된 상태로 진행이 됩니다.

Cluster를 확인해보면 다음과 같이 새로운 Replicaset이 아닌 기존 동작중이던 Replicaset으로 rollback 되었음을 확인할 수 있습니다.

Normal Rollout

이번에는 정상적으로 Rollout 된 상황에 대하여 알아보도록 하겠습니다.

deploy가 실행되면 실제 Replicaset은 다음과 같이 배포가 이루어집니다.

Judgement 에서 rollout을 선택하면

아래와 같이 Delete(Manifest)만 실행되고 나머지는 제외된 상태로 진행이 됩니다.

Cluster를 확인해보면 다음과 같이 새로운 Replicaset이 동작중이고 가장 오래된 Replicaset이 삭제되었음을 확인할 수 있습니다.

참고사이트

• https://www.spinnaker.io/guides/user/pipeline/expressions/#use-preconditions-to-choose-pipeline-paths
• https://www.spinnaker.io/guides/user/kubernetes-v2/automated-rollbacks/#parameterized-rollbacks
• https://www.spinnaker.io/guides/user/kubernetes-v2/automated-rollbacks/#configure-automated-rollbacks-in-the-kubernetes-provider-v2