Spinnaker – Spinnaker Architecture

Docs: Spinnaker Architecture Overview

Mon, 01 Jan 0001 00:00:00 +0000

Spinnaker microservices

Spinnaker is composed of a number of independent microservices:

Deck is the browser-based UI.
Gate is the API gateway.

The Spinnaker UI and all api callers communicate with Spinnaker via Gate.
Orca is the orchestration engine. It handles all ad-hoc operations and pipelines. Read more on the Orca Service Overview .
Clouddriver is responsible for all mutating calls to the cloud providers and for indexing/caching all deployed resources.
Front50 is used to persist the metadata of applications, pipelines, projects and notifications.
Rosco is the bakery. It produces immutable VM images (or image templates) for various cloud providers.

It is used to produce machine images (for example GCE images , AWS AMIs , Azure VM images ). It currently wraps packer , but also supports helm, kustomize and helmfile bakes for kubernetes manifests.
Igor is used to trigger pipelines via continuous integration jobs in systems like Jenkins and Travis CI, and it allows Jenkins/Travis stages to be used in pipelines.
Echo is Spinnaker’s eventing bus.

It supports sending notifications (e.g. Slack, email, SMS), and acts on incoming webhooks from services like Github.
Fiat is Spinnaker’s authorization service.

It is used to query a user’s access permissions for accounts, applications and service accounts.
Kayenta provides automated canary analysis for Spinnaker.
Keel powers Managed Delivery .

System dependencies

This diagram shows which microservices depend on each other. The green boxes represent “external” components, including the Deck UI, a single-page JavaScript application that runs in your browser.

graph TB deck(Deck) --> gate; api(Custom Script/API Caller) --> gate(Gate); gate --> kayenta(Kayenta); gate --> orca(Orca); gate --> clouddriver(Clouddriver); orca --> clouddriver; gate --> rosco(Rosco); orca --> front50; orca --> rosco; gate --> front50(Front50); gate --> fiat(Fiat); orca --> kayenta; clouddriver --> fiat; orca --> fiat; front50 --> fiat; echo(Echo) --> orca; echo --> front50; gate --> echo; gate --> igor(Igor); igor(Igor) --> echo; keel(Keel) --> clouddriver; keel --> orca; keel --> front50; keel --> fiat; keel --> echo; keel --> igor; gate --> keel; classDef default fill:#d8e8ec,stroke:#39546a; linkStyle default stroke:#39546a,stroke-width:1px,fill:none; classDef external fill:#c0d89d,stroke:#39546a; class deck,api external;

In the table below, A filled cell indicates that the system listed in the heading of that column has a dependency on the system listed in the heading of that row. As all Spinnaker services can be run in their own server group, it is typical for services to resolve their dependencies via load balancers or discovery systems (for example Eureka or Consul ).

Port mappings

By default Spinnaker binds ports according to the following table

Service	Port
Clouddriver	7002
Deck	9000
Echo	8089
Fiat	7003
Front50	8080
Gate	8084
Igor	8088
Kayenta	8090
Orca	8083
Rosco	8087
Keel	7010

Docs: Authentication & Authorization

Mon, 01 Jan 0001 00:00:00 +0000

This is a high-level explanation of how authentication and authorization work within Spinnaker itself.

Redis stores computed roles, default permissions, and roles from external systems
Clouddriver gets known accounts
Front50 gets known apps

Setup & Configuration

For more information on actual use of this see Setup Authentication and Authorization .

Docs: Life of a Bake

Mon, 01 Jan 0001 00:00:00 +0000

sequenceDiagram Title: Life of a Bake participant Igor participant Jenkins participant ArtifactRepo participant Echo participant Front50 participant Orca participant Rosco participant Packer participant Redis participant Cloud Echo->>Front50: Build cache of pipeline triggers Jenkins->>ArtifactRepo: Publish newly-produced deployable asset (e.g. .deb/.rpm/.jar) Note right of Jenkins: Archive artifacts Igor->>Jenkins: Poll Jenkins for completed builds Igor->>Echo: Publish completed build info to eventing bus Echo->>+Orca: Initiate pipeline execution based on matched trigger Orca->>Redis: Persist new execution Note right of Orca: Orca uses the artifact details from the trigger to decorate the package name with version information Orca->>-Rosco: Request bake, passing package with exact version to install Rosco->>Redis: Persist new bake Rosco->>Packer: Initiate bake job, passing repo address (from config) and package/version Packer->>ArtifactRepo: Pull deployable asset from repo Packer->>Cloud: Publish machine image Loop In background thread Rosco->>Packer: Poll until job completion Rosco->>Redis: Mark bake completed end Loop In worker thread Orca->>Rosco: Poll until task completion Rosco->>Redis: Query bake status Orca->>Redis: Update execution state end

Docs: Life of a Deployment

Mon, 01 Jan 0001 00:00:00 +0000

sequenceDiagram Title: Life of a deployment participant Deck participant Gate participant Orca participant Clouddriver participant Redis participant Cloud Deck->>+Gate: Initiate Deploy orchestration Gate->>+Orca: Initiate Deploy orchestration Orca->>Redis: Persist new execution Orca-->>-Gate: Reply with orchestration id Gate-->>-Deck: Reply with orchestration id Note right of Orca: In worker thread Orca->>+Clouddriver: Initiate Deploy operation Clouddriver->>Redis: Persist new task Clouddriver-->>-Orca: Reply with task id Clouddriver-xCloud: Mutating calls activate Clouddriver Clouddriver->>Redis: Mark task completed deactivate Clouddriver Loop In worker thread Orca->>Clouddriver: Poll until task completion Clouddriver->>Redis: Query task status Orca->>Redis: Update execution state end Loop In worker thread Orca->>Clouddriver: Poll until instances are up Clouddriver->>Redis: Query server group/instance state from cache Orca->>Redis: Mark execution completed end Loop In background thread Deck->>Gate: Poll until orchestration completion Gate->>Orca: Query orchestration status Orca->>Redis: Query execution status end