Spinnaker Architecture Overview

Spinnaker microservices, system dependencies, and port mappings

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 will be expanded to support additional mechanisms for producing images.

• 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 .

• Halyard is Spinnaker’s configuration service.

  Halyard manages the lifecycle of each of the above services. It only interacts with these services during Spinnaker startup, updates, and rollbacks.

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. The gold boxes represent Halyard components which are only ran when configuring Spinnaker.

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; hal(Halyard CLI) —> halyard(Halyard Daemon); classDef default fill:#d8e8ec,stroke:#39546a; linkStyle default stroke:#39546a,stroke-width:1px,fill:none; classDef halStyle fill:#eebb3c,stroke:#39546a; class halyard,hal halStyle; 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

Last modified January 3, 2022: docs(fix): fix link to Orca from microservices-overview.md (#171) (5e96f37)