Spinnaker – Concepts

Docs: Clusters

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

Spinnaker acts as a single pane of glass from which to manage your global deployments across multiple clouds. Here, we surface information related to health and status of running environments, and metadata around deployments and individual instances.

Also available are ad-hoc actions you can perform on the resources you see such as resize, clone, disable, and roll back. Together, the Clusters section acts as command and control base where we can increasingly layer on information relevant to deploying your applications.

On the left are filters for viewing your deployed services. You can search by string match, or narrow by specific attributes of your services, such as cloud platform, region, or your designated environments and stacks.
The main/center section lists the deployed services. Following the description in the Concepts page, you can see the grouping in action. Here, the green chiclets are individual instances (e.g. an EC2 VM instance, a Kubernetes Pod), grouped into Server Groups (a particular deployment), which are further grouped into Clusters.
The right section provides details for the item currently selected in the center section. For each item, Spinnaker provides details related to both application-level concerns (Jenkins job details) as well as infrastructure-level concerns (machine type, auto-scaling policies).

Docs: Pipelines

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

About pipelines

Pipelines are your way of managing deployments in a consistent, repeatable and safe way. A pipeline is a sequence of stages provided by Spinnaker, ranging from functions that manipulate infrastructure (deploy, resize, disable) as well as utility scaffolding functions (manual judgment, wait, run Jenkins job) that together precisely define your runbook for managing your deployments.

Define your sequence of stages at the top. Spinnaker supports parallel paths of stages, as well as the ability to specify whether multiple instances of a pipeline can be run at once.
Specify details for a given stage in the sections below.

You can view pipeline execution history, which serves as a means to introspect details of each deployment operation, as well as an effective audit log of enforced processes/policies on how you make changes to your deployed applications landscape.

Automation does not end with orchestrating only the high-level steps of your release process. Each of these operational steps often corresponds to a sequence of calls to the cloud platform, each of which needs to be remediated in failure scenarios. The Blue/Green Deploy stage is an example of how Spinnaker fully supports this notion:

The Blue/Green Deploy stage in Spinnaker actually entails a sequence of steps
Each given step is actually a set of tasks that need polling; remediation to ensure requisite state is reached prior to proceeding
A given task often entails multiple API calls to the specific cloud platform, cognizant of expected response codes and remediating actions in failure

Pipeline templates

Managed pipeline templates are a way to scalably manage pipelines across different teams.

Pipeline templates have two main components:

Template

A pipeline template defines a parameterized pipeline, with the set of variables for which your users will provide values.
Configuration

A concrete implementation of a template. Configurations can inject new stages into the final pipeline graph and inherit or override, or both, triggers, notifications, and parameters.

Terminology

Pipeline template

A parameterized pipeline, minus the pipeline configuration found on a pipeline instance. This template helps developers create pipelines that follow a pattern that you establish.

Pipeline configuration

The same as the configuration for a pipeline not created from a template , plus variable bindings and a reference to the template.

Pipeline

Whether it’s created from a template or not, an executable pipeline that can be visualized in the Deck UI, and can be run by Orca .

Pipeline template variable

A variable defined in a pipeline template, whose value is deteremined when a pipeline is instantiated based on the template. Contrast with pipeline variables, which vary per execution of the pipeline.

Docs: Providers

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

In Spinnaker, a Cloud Provider is an interface to a set of virtual resources that Spinnaker has control over. Typically, this is a IaaS provider, like AWS , or GCP , but it can also be a PaaS, like App Engine , or a container orchestrator, like Kubernetes .

The cloud provider is central to everything you do in Spinnaker. It’s where you deploy your Server Groups, the source of your deployable artifacts, and the subject of automation via Pipelines .

Accounts

In Spinnaker, an Account is a named credential Spinnaker uses to authenticate against a cloud provider. Each provider has slightly different requirements for what format credentials can be in, and what permissions they need to have afforded to them. The links under Supported Providers describe exactly how to create an account.

Keep in mind that every Provider can have as many accounts added as desired - this will allow you to keep your environments (e.g. staging vs. prod) separate, as well as restrict access to sets of resources using Spinnaker’s Authorization mechanisms.

Supported providers

These are the cloud providers currently supported by Spinnaker:

App Engine
Amazon Web Services
Azure
Cloud Foundry
Docker v2 Registry (Note: This only acts as a source of image tags/references, and does not include support for deploying Docker images)
Google Compute Engine
Kubernetes
Oracle

Setup instructions for providers are here

If you see a provider missing from this list that you feel Spinnaker should support, we gladly welcome your contributions. Please reach out to us on the #dev channel on Slack for help getting started, and check out the Contributing Guide for pointers and guidelines.

Docs: eBook: Continuous Delivery With Spinnaker

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

Download Free

PDF | Epub | Mobi

Ebook Description

Many companies are moving away from “big bang” software releases every six months or so to a continuous delivery (CD) model that enables IT to release updates frequently, even if that means several times a day. Using Netflix and its open source Spinnaker CD platform as examples, this practical ebook demonstrates how a new host of tools can help you deploy software changes to production quickly, safely, and automatically.

A team of experts from Netflix and Google show you how to automate deployments with Spinnaker across multiple cloud accounts, regions, and even across multiple cloud platforms into continuous deployment pipelines. You’ll learn how Spinnaker enables your company to design and automate a delivery process that not only fits your release cadence, but also the business criticality of your application.

Learn about the organizational and technical practices that enable continuous delivery
Understand the fundamental considerations you need to solve before successfully deploying software to the cloud
Manage cloud resources for consistency across accounts, regions, and cloud providers
Use Spinnaker’s pipelines to structure deployments from customizable pieces
Understand how CD pipelines to Kubernetes differ from pipelines to VM-based clouds
Examine how Spinnaker ensures safety across cluster deployments and pipeline executions
Learn how to integrate automated testing techniques such as chaos engineering or automated canary analysis into the delivery process