Spinnaker Architecture
Overview
By the end of this chapter, you should be able to explain:
Visual understanding of the Spinnaker components at a high level
Each component and how it's used within Spinnaker
How does the Spinnaker architecture work?
We must first understand the components of the Spinnaker architecture to understand how it works. Spinnaker is a collection of microservices bound by the single responsibility principle (SRP).
SRP is a principle that states that each module or component of an application is responsible to perform a specific functionality allocated by the application. The component's ownership is entirely contained within the module or component. It allows faster iteration of individual components and more pluggable architecture for custom components.
In other words, each Spinnaker microservice is responsible for completing a specific task and then communicating it to the next microservice to continue the process after completion.
Spinnaker is a collection of eleven such services. Let’s take a look at them.
Deck: This microservice is responsible for visualizing the current state of cloud resources through a browser-based User Interface. It is Spinnaker's front-end service. Deck is the connection to the Gate microservice.
Gate: Gate as the name suggests, is the API gateway that connects all of the other services. Gate is responsible for all communications from the User Interface to other back end services. It handles the authentication and authorization for sub-service APIs and resources with Spinnaker. It is also responsible for the Spinnaker API calls.
Orca: This service is the coordination engine of Spinnaker. The service is responsible for managing ad hoc operations such as the pipeline stages and tasks, and coordinating with the other services. It ensures that the sub-services' executions and states are passed along smoothly and correctly. The most granular unit within Orca is a task. Pipelines are composed of stages and stages are a collection of tasks.
CloudDriver: This is responsible for communicating and interacting with various cloud providers, such as AWS, Kubernetes, and others. It also keeps all of the resources deployed in the cloud caching/indexing.
Front50: This service is responsible for keeping track of all the metadata for projects, applications, pipelines and notifications.
Rosco: This service is basically the bakery responsible for producing persistent VM images for cloud providers that will be deployed. Its main function is to create machine images (for example GCE images, AWS AMIs, Azure VM images).
Igor: This service connects to Spinnaker and triggers pipelines for continuous integration platforms such as Jenkins, Travis, and others. It is responsible for starting jobs and then reporting the current state of running or completing jobs.
Echo: This service is responsible for all events, such as sending notifications (via email, Slack, etc.) and controlling all incoming webhooks to Spinnaker. It's also known as Spinnaker's Event bus.
Fiat: This service is Spinnaker’s authorization service. It is responsible for the user’s access to accounts, service accounts and applications.
Kayenta: Early detection of problems while deploying a new version is critical in any application release management. This warning system for detecting problems is known as Canary analysis. This service is responsible for automating the canary analysis for Spinnaker.
Halyard: This service is the configuration engine of Spinnaker. It manages the lifecycle of all the above services. It only communicates with these services while installing, configuring, and updating Spinnaker.
The figure below depicts the visual architecture of Spinnaker and how each of the services communicates with each other.
System Dependencies
Refer to the table to see how each microservice is dependent on each other. A grey-colored cell in this table indicates that the column header is dependent on the service listed in that row. For example, the Deck cell in the first column is greyed out and filled with grey, indicating that it is dependent on Gate. Similarly, API Caller is dependent on Gate.
A simple use case: To understand the Spinnaker architecture better, let’s go through a simple example that explains the stages of the deployment process and the services affecting the stages.
In the above process diagram the different stages of deployment and the respective services responsible for specific tasks are shown. The stages are:
Spinnaker UI: The Deck is in control of Spinnaker's user interface. Here you log in, create a pipeline, and start the deployment process.
API Gateway: Once you request to start the deployment process, the Gate service is activated and communicates with Orca.
Orca: Orca is the coordination engine of Spinnaker. Orca creates an orchestration ID and sends it to Deck via the API Gateway after receiving the deploy request. This service's primary responsibility is to coordinate with other services and manage ad-hoc operations such as pipeline stages and tasks. It makes sure that the executions and states of the sub-services are passed along smoothly and correctly.
CloudDriver: The CloudDriver services work as the communication medium between Orca and the cloud platforms. So Once the pipeline is executed and ready for deployment, Orca requests the CloudDriver to deploy in the cloud environment platform.
Redis: Redis is responsible for caching information from Orca and CloudDirver.
Last updated
Was this helpful?