Spinnaker Stage Deploy (Manifest)
External
- https://spinnaker.io/docs/guides/user/kubernetes-v2/deploy-helm/
- https://spinnaker.io/docs/guides/user/kubernetes-v2/traffic-management/
- https://spinnaker.io/docs/guides/user/kubernetes-v2/rollout-strategies/
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:
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
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:
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:
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
Execution Options
Notifications
Produced Artifacts
Running a Script with Deploy (Manifest)
Organizatorium
Timeout
WaitForManifestStableTask set by default to 30 min.