Managed Delivery on Spinnaker

Managed Delivery Overview

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

What is Managed Delivery?

Managed Delivery is an initiative with two key goals.

Provide native means for Spinnaker users to declaratively manage software delivery.
- With a declarative model, users describe the desired end-state of a deployed application. Spinnaker continually calculates how this desired state maps to cloud resources. When desired state diverges from actual cloud state, Spinnaker figures out how to safely bring the deployed state in-line with the desired.

Getting Started

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

This means that we support only EC2 and Titus, and that we have limited feature and UI support. This guide walks through onboarding to Managed Delivery assuming that you are using EC2 or Titus.

Intro

To get started with Managed Delivery you’ll need an idea of what infrastructure you want to manage. You can pick a new piece of infrastructure that you want to create (a new load balancer, for example) or migrate an existing piece of infrastructure (an existing cluster, for example).

API

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

The endpoints for managed delivery are located in the managed-controller. The endpoints are easily accessible from the swagger api page of your Spinnaker instance.

This doc provides samples for how to use the endpoints.

Export an Existing Resource

The export endpoint (under the “managed-controller”) allows you to take an existing resource and export it to a yaml config.

GET /managed/resources/export/{cloudProvider}/{account}/{type}/{name}?serviceAccount=yourServiceAccount@company.com

These definitions can be stored in your git repo.

Validating yaml

The ad-hoc diff endpoint allows you to see if a resource config is valid, and to see the difference between config (desired state) and reality.

Managed Delivery Artifacts

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

Managed Delivery supports two types of delivery artifacts: debians and Docker images.

Delivery artifacts are meant to provide Spinnaker information about:

Where to locate the available versions of an artifact you care about
How to choose the latest version from a list of versions

Spinnaker needs this information to make decisions about when and how to roll out new versions as they become available. Artifacts are defined with name, type, and version strategy information.

Delivery Configs

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

Prerequisite: read and complete the Getting Started document!

What is a Delivery Config?

A delivery config allows you to group resources together in a single file (e.g. spinnaker.yml) and specify how these resources work together to promote an artifact between environments.

Artifacts

An artifact represents the package or docker image that you want to promote in your delivery flow. For example, if you develop the package keeldemo (which is built into a debian) and that is the only package that runs in your application, you’d have the following artifact section:

Environment Constraints

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

Prerequisite: understand the environment concept offered by Delivery Configs

What is an Environment Constraint?

Environment constraints control how an artifact version flows through environments. A constraint can be as simple as ensuring an artifact isn’t promoted into Environment B unless it has successfully deployed into Environment A. Constraints can also specify that an artifact needs to have a canary evaluated by Kayenta before it can be deployed into an environment, while also defining how the canary should be deployed and evaluated.

Git-Based Workflows

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

Spinnaker supports git-based workflows to create and update Managed Delivery configurations. This allows you to keep your Managed Delivery configuration in code and follow all the usual best practices like code review and approvals before a change is introduced to your managed resources, environments or deployments.

Git support is currently achieved via a pipeline configured with a trigger that can provide source repository information (such as a Git trigger) and containing a single Import Delivery Config stage. This stage will retrieve a Delivery Config manifest from the repository associated with your pipeline’s trigger, then save (or update) it in Spinnaker so it will automatically monitor and manage the resources, environments and deployments described in the manifest.

Mark an Artifact as Bad

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

You can mark a version of an artifact in an environment as bad to ensure that that version never gets deployed to the environment. If you mark an artifact as bad in the first in a series of environments (linked together by depends-on constraints) that version of the artifact will never be promoted into the later environments.

Marking via the API

To mark the artifact via the API you’ll need the application name, the name of the environment, the reference for your artifact (defined in your delivery config, defaulted to the artifact name), and the version that is bad. The request needs to have a body that contains this information . Here’s an example:

Pin an Environment

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

You can pin an environment to a specific artifact version to ensure that all resources in the environment stay on that version. Until the pin is removed, that environment won’t change to a new version of the artifact.

Pinning via the API

To create a pin via the API you’ll need the application name, the name of the environment you want to pin, the reference for your artifact (defined in your delivery config, defaulted to the artifact name), and the version you’d like to pin to. The request needs to have a body that contains this information . Here’s an example:

Resource Status

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

If you’re not sure what a managed resource is, check out our Overview of Managed Delivery first.

Overview

Managed resources always have a status, which describes the current state of the resource from Spinnaker’s perspective. A resource’s status can help you quickly answer questions like:

Is Spinnaker taking automatic action on this resource right now?
Does the actual state of this resource match the declarative configuration I gave to Spinnaker?
Is something wrong with this resource?

How to find a resource’s status

UI

On the Infrastructure views (Clusters, Load Balancers, Firewalls), you’ll see a color-coded “M” logo attached to any resources that are managed by Spinnaker. Hovering over the logo reveals additional context about the current status and what it means.

Managed Delivery FAQ

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

What is happening?

Spinnaker is managing this resource. That means that the state of this resource is controlled using a declarative config submitted to Spinnaker.

Can I make changes in the UI to this resource?

Nope. Well, you can, but they will be almost immediately stomped to return to the declared state.

Who is the source of truth for that declared state?

Spinnaker is.

Then why do I have code checked into a repo?

To help you keep your resources in a known good state. You must publish these resource configs to Spinnaker every time they change in order for that change to be reflected in Spinnaker.

CI Features

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

One of the goals of Managed Delivery is to show you the journey of your code, from commit to deployment, in an easy, consistent way. In order to enable this experience, we created an integration between Managed Delivery and the Continuous Integration (CI) provider, which is described below.

Note: in order to take advantage of this feature, your Spinnaker operator/administrator will have to configure a CI provider which matches your company’s setup. They can look for available open-source or commercial Spinnaker CI providers, or even develop their own. See the developer guide on CI integration .