Spinnaker?
•Spinnaker는 에서 Netflix에서 구축 된 클라우드 배포 모범 사례를 염두에 두고 구축
•Spinnaker의 목적은 응용 프로그램을 안정적으로 배포하기 위해 기본 클라우드 플랫폼의 전문가의 도움없이 배포를 안정적으로 하는 것
•대신 그들은 실제 문제 영역에 더 집중할 수 있고 롤아웃의 복잡성에 덜 집중
•엔지니어링 팀은 일관된 개념적 모델을 사용하여 지속적으로 전용 운영 팀에 참여하지 않고도 다양한 클라우드 플랫폼에 배포
•적은 노력으로 Netflix와 Google에서 정의한 모범 사례를 기반으로 배포
Application-centric Control Plane
•Spinnaker는 가상 머신 및 컨테이너에서 로드밸런서 및 보안 그룹에 이르는 모든 애플리케이션 리소스에 대한 통합된 UI를 제공 한다.
Spinnaker Features
•CI Integrations
Jenkins, Gitlab등 다양한 CI툴과 통합이 용이
•CLI for Setup and Admin
halyard 명령을 통한 CLI관리
•Monitoring Integrations
상태를 polling하여 감시
•VM Bakery
VM과 Container 동시에 라이프사이클 통합관리 가능
•Notifications
Email, Slack, Hipchat등
•Role-based Access Control
•White-listed Execution Windows
•Manual Judgments
승인기능이 매우 손쉽게 가능
•Chaos Monkey Integration
Spinnaker Concepts (논리적 계층 구조)
논리적으로 아래 그림과 같이 Project를 통하여 여러 Application을 관리 한다. 하위에는 Cluster Service에서 서로 다른 환경의 Cluster 환경에 배포할 수 있도록 구성 되어 있으며, LoadBalancer를 통하여 트래픽을 관리 하여 다양한 형태의 Roll Out/Back 전략을 구축할 수 있다.
Spinnaker Concepts vs Kubernetes
Kubernetes의 각 객체와 비교 하면 아래 그림과 같은 형태를 보일 수 있다. 또한, 일반적인 Manifest배포 환경에서 Deployment를 통하여 다 수의 ReplicaSet을 관리 한다면, Spinnaker는 Deployment가 아닌 Spinnaker자체적으로 ReplicaSet을 관리 한다.
Spinnaker Architecture
Spinnaker의 구조는 그림과 같이 다양한 컴포넌트로 구성되어 있다. 복잡한 컴포넌트로 구성되어 있기 때문에
Spinnaker Deck
•Deck 컴포넌트는 Spinnaker의 UI 컴포넌트로 node로 구성되어 있다.
Spinnaker Gate
•Gate 컴포넌트는 API Gateway역할을 하는 Spinnaker의 컴포넌트이다. Spinnaker는 MSA 구조로, 모든 기능을 API 로 Expose한다.
•Spinnaker RESTAPI를 제공하여 스크립팅 클라이언트와 Deck의 모든 작업을 지원한다.
Spinnaker Igor
•Spinnaker는 다양한CI(ContinuousIntegration)및 SCM(SourceControlManagement)서비스와 연동이 되는데, 외부 CI Tool에서 작업이 끝나거나 SCM의 변경사항이 있으면 Spinnaker Pipeline을 Invoke 할때 사용 한다.
•외부 리소스에서 항목 목록을 주기적으로 가져와서 해당 목록과 항목의 지속적인 캐시를 비교하며(차이를 delta size라고 함) 변경사항이 있을 경우 Pipeline에 invoke하고 새로운 목록을 캐시 한다.
Spinnaker Echo
•Echo는 Spinnaker 의 Eventing Service로 역할은 두가지로 구분 된다.외부 통신을 위한 Event Bus로, 장애가 발생하거나 특정 이벤트가 발생했을때, SMS, Email 등으로 notification을 보내기 위한 Connector의 역할
•Igor에서 delta size 가 발생하여 해당 이벤트를 echo로 전송 하면 Orca를 통하여 Pipeline/orchestration을 실행 한다.
Spinnaker Rosco
•Rosco는 Baking 컴포넌트로, Spinnaker는 VM또는 Docker 이미지 형태로 생성하기 위하여 Packer를 기반으로 Build를 담당하는 컴포넌트이다.
•Alibaba Cloud 이미지, Google Compute Engine 이미지, Huawei Cloud 이미지, AWS Amis 및 Azure 이미지 생성 그리고 Docker Container를 지원 한다.
Spinnaker Front50
• 파이프라인이나 기타 메타 정보를 저장하는 스토리지 컴포넌트이다.
•모든 메타데이터는 메모리 내 캐쉬에서 지속적으로 저장되고 제공된다.
Spinnaker Orca
• Oraca는 이 모든 컴포넌트를 오케스트레이션하여, 파이프라인을 관리해주는 역할을 한다.
•실행 정의를 취하고 단계와 작업을 관리하고 다른 Spinnaker 서비스를 조정한다. 기본 Redis를 백엔드로 사용하고 있다.
Spinnaker CloudDriver
•다양한 형태의 클라우드 플랫폼에 명령(Read/Write)을 내리기 위한 아답터 역할을 한다.
•지원하는 CloudDriver
• App Engine
•Amazon Web Services
•Azure
•Cloud Foundry
•DC/OS
•Google Compute Engine
•Kubernetes V2 (manifest based)
•Oracle
Kubernetes V2 (manifest based) Cloud Provider
•각 artifacts 혹은 Spinnaker 에 저장되어 있는 매니페스트를 이용하여 "kubectl" 백그라운드로 사용하여 대상 클러스터에 적용된다.
•Available manifest based stages
•Deploy Manifest
•kubectl apply를 사용하여 매니페스트를 Deploy
•Delete Manifests
•다양한 유형과 레이블을 기반으로 Kubernetes에서 해당 매니페스트를 제거
•Scale Manifests
•ReplicaSet의 지정된 정적 크기로 조정
•Rollback Manifest
•지정된 버전으로 특정 Kubernetes 아티팩트를 롤백 배포 실패 또는 수동 QA 실패시 도움
Spinnaker Rollout/Rollback Strategy
Dark Rollouts
•Dark Rollouts을 사용하여 기존 버전과 함께 새 버전의 응용 프로그램을 배포하지만 트래픽을 새 버전으로 즉시 라우팅하지 않는다.
•추가적인 Stage를 Enable (Manifest) 및 Disable (Manifest) 단계를 추가하여 새 버전으로 트래픽 전송을 시작하고 이전 버전으로 트래픽 전송을 중지해야 한다.
•아래와 같이 기존 버전이 Service를 통하여 Version00이 라우팅 되어 트래픽이 처리 된다.
•Dark Deploy할경우 아래와 같이 새로운 버전만 Deploy하며, 트래픽을 전송 하지 않는다. 추가적인 Stage를 통하여 트래픽을 조정 하거나, 옵션을 추가하여 트래픽을 관리 해야 한다.
Red/Black Rollouts
•Red/Black 롤아웃을 사용하여 기존 버전과 함께 새 버전의 응용 프로그램을 배포하고 클라이언트 트래픽을 새 버전으로 보낸 다음 클러스터에서 기존 버전을 비활성한다.
•선택적으로 후속 Destroy (Manifest) 단계를 추가하여 클러스터에서 원치 않는 워크로드를 정리할 수 있다.
•또는 활성화 (Manifest) 단계를 구성하거나 클러스터 탭에서 임시 활성화 조작을 사용하여 이전 버전으로 쉽게 롤백 할 수 있다
참고 사이트
https://www.tothenew.com/blog/introduction-to-spinnaker-global-continuous-delivery/
'CNCF > Spinnaker' 카테고리의 다른 글
| Spinnaker 를 통한 Kubernetes환경의 Application 배포(2)-CI/SCM연동 (0) | 2020.01.01 |
|---|
