Spinnaker 개요

Spinnaker란?

(https://spinnaker.io/docs/)

 멀티클라우드 환경에 지속적 배포(Continuous Delivery)를 할수있도록 해주는 오픈소스 플랫폼입니다. 크게 Application 배포, 관리 기능을 제공합니다.

 

Application 관리

서비스를 나타내는 주요 개념: Applications, clusters, server groups

서비스 노출을 나타내는 주요 개념: Load balancers, firewalls

• Applications: 배포하려는 서비스를 나타낸다. clusters, server groups의 집합이며, Load balancers, firewalls를 모두 포함하는 개념이다.
• clusters: server groups의 논리적 그룹이다. (Kubernetes cluster와는 다른 개념이다.)
• server groups: 배포 가능한 artifact(VM image, Docker image, source location), 기본 configuration settings(instances 개수, autoscaling 정책, metadata 등)를 나타내며, Load Balancer, Firewall과도 선택적으로 연결이 된다. 배포가 되고나면 Server group은 운영되고 있는 software의 인스턴스 집합체라고 볼 수 있다.
• Load balancers: ingress protocol과 port 범위와 연관된다. Server groups 내의 인스턴스들 사이 트래픽을 조정한다.
• firewalls: 네트워크 트래픽 접근을 정의하는 방화벽. 

Application 배포

Pipeline

• Pipeline: 배포 관리 구조로 stage들로 이루어져있다.
• Stage: 연속적인 Task들의 집합체로 pipeline에서 다양하게 구성될 수 있다.
• Task: 수행할 automatic function
• Account: Cloud Provider에 인증하기위해 사용하는 Account name
• Provider: AWS, GCP, Azure, kubernetes와 같은 Cloud Provider
• Deployment strategies: Red/black, Rolling red/black, Canary 전략 제공
  • None(Dark): 새로운 replicaSets를 생성하고, 기존의 ReplicaSets는 그대로 유지한다.
  • Red/black(Blue/green): 새로운 replicaSets이 준비되면 이전의 ReplicaSets은 disable한다.
  • Highlander: Red/black과 동일하나, 하나의 load balancer를 두고 한개의 cluster가 존재 할 때 해당된다.

 

 

 

---

Spinnaker 구조

Spinnaker는 기본적으로 MSA구조로 되어있다.

Spinnaker 구조

Spinnaker를 어떻게 설정하느냐에 따라 일부 서비스가 배포될 수 있고, 안될 수 있다. 예를 들어, CI 시스템 trigger를 사용하지 않을 경우 Igor서비스는 배포되지 않는다.

• Deck: UI
• Gate: API gateway. UI나 기타 callers들과 통신들은 모두 gate를 지나게된다.
• Orac: orchestration engine으로 불리며, pipeline, task, stages 관리를 하고, Spinnaker 서비스들을 관리한다.
• Clouddriver: cloud providers관련 모든 호출과 배포된 리소스들의 indexing/caching을 담당한다.
• Front50: application, piplines등의 meatadata를 저장한다.
• Rosco: bakery. 다양한 cloud provider를 위한 immutable vm images를 생성한다. 배포하기전 Rosco를 통해 image를 bakering하는 작업이 필요하다.
• Igor: CI 시스템들을 통해 pipeline을 trigger한다.
• Echo: 외부 통신을 위한 eventing bus로, 이슈 발생 시 Slack, email, SMS등으로 notifications을 보낸다.
• Fiat: Auth service
• Kayenta: automated canary analysis를 제공. 배포 시 canary 분석을 통과하면 운영에 배포하는 방식을 제공
• Halyard: Spinnaker configuration service로 이를 통해 spinnaker를 배포 및 관리한다.

---

왜 Spinnaker를 사용할까?

Spinnaker를 사용하는 이유는 다양하겠지만, 직접 사용하면서 느꼈던 것을 위주로 정리해보았다.

• 멀티 클라우드 환경에 Application 배포 및 관리가 편리하다.
• 기존에 사용하던 CI/CD 툴과 통합이 쉽다.
• 다양한 배포전략, helm values override, Notification 등 배포에 필요한 다양한 기능을 제공한다.
• pipeline 형식으로 배포 프로세스를 다양하게 구성 가능하다.
• 배포 후 적용된 yaml 파일이나 artifact, service를 화면에서 바로 확인 가능하다.
• rollback, replicas 조정 등 운영에 필요한 기능들을 제공한다.
• CI를 Jenkins에서 수행하고, CD를 Spinnaker에서 수행하게 하여 분리가 가능하다.