Spinnaker Stage Deploy (Manifest)

From NovaOrdis Knowledge Base
Jump to navigation Jump to search

External

Internal

Overview

Deploy a Kubernetes manifest yaml/json file. This section refers to deploying a Helm chart rendered by a previous Bake (Manifest) stage.

Configuration

Add stage → Type: Deploy (Manifest)

Stage Name: Deploy Helm Chart

Deploy (Manifest) Configuration

Basic Settings

Account

A Spinnaker account corresponds to a physical Kubernetes cluster. Must be previously configured.

Override Namespace

Also see:

Bake (Manifest) → Helm Options → Namespace
Override Namespace Selected

If "Override Namespace" is selected, Spinnaker forcibly overwrites the value of:

metadata:
  namespace: [...]

in all manifests of the deployments.

Even if no .metadata.namespace is present in the manifest, a synthetic:

metadata:
  namespace: <override-namespace-value>

is injected in the manifest.

Override Namespace NOT Selected

If no .metadata.namespace is present in the manifest, then the following is injected:

metadata:
  namespace: default

and the manifest is deployed in the "default" namespace.

If .metadata.namespace is present in the manifest, it is left unchanged.

Namespace

The namespace should be chosen from a dropdown box and there is some time between creating one in the cluster and seeing it in the dropdown.

Manifest Configuration

Manifest Source

Artifact

Manifest Artifact

The display name of the manifest rendered at the Bake (Manifest) stage. If not explicitly configured, it will be generated to something similar to "tender-seahorse-98".

Expression Evaluation

Skip SpEL expression evaluation.

Select "no"

Skip SpEL expression evaluation of the manifest artifact in this stage. Can be paired with the "Evaluate SpEL expressions in overrides at bake time" option in the Bake Manifest stage when baking a third-party manifest artifact with expressions not meant for Spinnaker to evaluate as SpEL.

Required Artifacts to Bind

These artifacts must be present in the context for this stage to successfully complete. Artifacts specified will be bound to the deployed manifest. TO PROCESS: https://spinnaker.io/docs/reference/artifacts-legacy/in-kubernetes-v2/#binding-artifacts-in-manifests.

Don't select an artifact here.

Rollout Strategy Options

https://spinnaker.io/docs/guides/user/kubernetes-v2/rollout-strategies/

The implementation behind the rollout strategies allows you to associate a new version of a workload with one or more services, decide whether the workload should receive traffic, and determine how Spinnaker should handle the previous version the workload currently being deployed in the same cluster and namespace. Because the implementation is based on the existing traffic management strategy, it is only valid for ReplicaSets workloads.

Also see:

Deployment Strategies with Spinnaker

Enable

Allow Spinnaker to associate each ReplicaSet deployed in this stage with one or more Services and manage traffic based on your selected rollout strategy options.

Service(s) Namespace

Select the namespace containing the service(s) to be associated with the workload.

Service(s)

Select one or more services to be associated with the workload.

Services are usually manually created and labeled "stage" or "prod", as described here:

Blue-Green Deployments with Spinnaker | Create the Ingresses and Services

If this is a stage deployment, select "stage". Select "prod" otherwise.

Note that more than one service can be enabled at this step (for example "stage", "stage-auth", if present).

Traffic

Send client requests to new pods

Strategy

The rollout strategy tells Spinnaker what to do with the previous version(s) of the ReplicaSet in the cluster.

For Stage, set the "Highlander" strategy. This will automatically enable Traffic: "Send client requests to new pods"

For Prod, set the "Red/Black" strategy.

Examples

Rollout Strategy Options Configuration Example for Blue-Green Deployment

Execution Options

Notifications

Produced Artifacts

Running a Script with Deploy (Manifest)

Running a Script with Deploy (Manifest)

Organizatorium

Timeout

WaitForManifestStableTask set by default to 30 min.