Armory Docs – Deploy Armory Continuous Deployment or Spinnaker Using Kubernetes Operators

Continuous-Deployment: Install Operator and Deploy Armory Continuous Deployment Quickstart

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

This guide is for both the Armory Operator and the Spinnaker Operator. Armory Continuous Deployment and Spinnaker configuration is the same except for features only in Armory Continuous Deployment. Those features are marked .

Before you begin

The goal of this guide is to deploy Armory Continuous Deployment with bare minimum configuration. The What’s next section contains links to advanced configuration guides.

You are familiar with Kubernetes Operators, which use custom resources to manage applications and their components.
You understand the concept of managing Kubernetes resources using manifests.
You have reviewed and met the Armory Continuous Deployment system requirements.

If you are using Armory Continuous Deployment, be sure to choose the Armory Operator version that is compatible with your Armory CD and Kubernetes versions. Likewise, if you are using open source Spinnaker, choose the Spinnaker Operator that is compatible with your Spinnaker and Kubernetes versions.

Kubernetes Version	Armory Operator Version	Armory CD Version
< 1.21	<= 1.6.x	<= 2.28.0
>= 1.21	>= 1.7.x	All supported versions

Kubernetes Version	Spinnaker Operator Version	Spinnaker Version
< 1.21	<= 1.2.5	>= 1.27.3
>= 1.21	>= 1.3.x	>= 1.27.3

Consult the Manage Operator guide for how to upgrade your Operator version.

Depending on your Kubernetes version, you may need to adjust the following instructions to use a supported Operator version.

Operator installation options

The Operator has basic and cluster installation modes. The option you use depends on which namespace you want to deploy Armory Continuous Deployment or open source Spinnaker to.

Most users choose Cluster Mode.

	Basic Mode	Cluster Mode
Must deploy Armory Continuous Deployment or open source Spinnaker in the same namespace as the Operator; permissions scoped to single namespace; suitable for a Proof of Concept (POC)	✅	❌
Can deploy Armory Continuous Deployment or open source Spinnaker to multiple namespaces (requires Kubernetes ClusterRole)	❌	✅
Configure Armory Continuous Deployment or open source Spinnaker using a single manifest file	✅	✅
Configure Armory Continuous Deployment or open source Spinnaker using Kustomize patches	✅	✅
Perform pre-flight checks to prevent misconfiguration	❌	✅

Install the Operator

You need Kubernetes ClusterRole authority to install the Operator in cluster mode. You should use Cluster mode to do one of the following:

Install a single Spinnaker Operator to manage an entire Kubernetes cluster of Spinnaker installations
Install a single Armory Operator to manage an entire Kubernetes cluster of Armory CD installations

You can find the Operator’s deployment configuration in spinnaker-operator/deploy/operator/cluster after you download and unpack the archive. You don’t need to update any configuration values.

Get the latest Operator release:

Armory Operator for Armory CD Installation

mkdir -p spinnaker-operator && cd spinnaker-operator
bash -c 'curl -L https://github.com/armory-io/spinnaker-operator/releases/latest/download/manifests.tgz | tar -xz'

Spinnaker Operator for Open Source Spinnaker Installation

mkdir -p spinnaker-operator && cd spinnaker-operator
bash -c 'curl -L https://github.com/armory/spinnaker-operator/releases/latest/download/manifests.tgz | tar -xz'

Install or update CRDs across the cluster:
```
kubectl apply -f deploy/crds/
```
Create the namespace for the Operator:

In cluster mode, if you want to use a namespace other than spinnaker-operator, you need to edit the namespace in deploy/operator/cluster/role_binding.yaml.
```
kubectl create ns spinnaker-operator
```

Install the Operator:

kubectl -n spinnaker-operator apply -f deploy/operator/cluster

Verify that the Operator is running:

kubectl -n spinnaker-operator get pods

The command returns output similar to the following if the pod for the Operator is running:

NAMESPACE READY STATUS RESTARTS AGE
spinnaker-operator-7cd659654b-4vktl 2/2 Running 0 6s

Operator in basic mode has permissions scoped to a single namespace, so the Operator can’t see anything in other namespaces. You must deploy Armory Continuous Deployment or open source Spinnaker to the same namespace as the Operator, in a 1:1 correlation (one Armory Operator per Armory CD; one Spinnaker Operator per open source Spinnaker install).

You can find the Operator’s deployment configuration in spinnaker-operator/deploy/operator/basic after you download and unpack the archive. You don’t need to update any configuration values.

Get the latest Operator release:

Armory Operator for Armory CD Installation

mkdir -p spinnaker-operator && cd spinnaker-operator
bash -c 'curl -L https://github.com/armory-io/spinnaker-operator/releases/latest/download/manifests.tgz | tar -xz'

Spinnaker Operator for Open Source Spinnaker Installation

mkdir -p spinnaker-operator && cd spinnaker-operator
bash -c 'curl -L https://github.com/armory/spinnaker-operator/releases/latest/download/manifests.tgz | tar -xz'

Install or update CRDs across the cluster:
```
kubectl apply -f deploy/crds/
```
Create the namespace for the Operator:

In basic mode, the namespace must be spinnaker-operator.
```
kubectl create ns spinnaker-operator
```

Install the Operator:

kubectl -n spinnaker-operator apply -f deploy/operator/basic

Verify that the Operator is running:

kubectl -n spinnaker-operator get pods

The command returns output similar to the following if the pod for the Operator is running:

NAMESPACE READY STATUS RESTARTS AGE
spinnaker-operator-7cd659654b-4vktl 2/2 Running 0 6s

Deploy an Armory Continuous Deployment instance

Single manifest file option

You can find the SpinnakerService.yml manifest file in /spinnaker-operator/deploy/spinnaker/basic/. You need to specify persistent storage details and the version to deploy before you can use the manifest to deploy Armory Continuous Deployment.

The following example uses an AWS S3 bucket. You can find configuration for other storage types in the Persistent Storage reference.

You can see the list of Armory Continuous Deployment versions on the Release Notes page.

apiVersion: spinnaker.armory.io/v1alpha2
kind: SpinnakerService
metadata:
 name: spinnaker
spec:
 spinnakerConfig:
 config:
 version: <version> # the version of Armory Continuous Deployment to deploy
 persistentStorage:
 persistentStoreType: s3
 s3:
 bucket: <change-me> # Armory Continuous Deployment stores application and pipeline definitions here. Create an S3 bucket and provide the name here.
 rootFolder: front50
 # spec.expose - This section defines how Armory Continuous Deployment should be publicly exposed
 expose:
 type: service # Kubernetes LoadBalancer type (service/ingress), note: only "service" is supported for now
 service:
 type: LoadBalancer

The Armory Operator contains Halyard to manage a portion of your Armory Continuous Deployment installation. See Advanced Operator Configuration if you need to override the default settings for the Halyard container for some advanced features.

Deploy using kubectl:

kubectl create ns spinnaker
kubectl -n spinnaker apply -f deploy/spinnaker/basic/SpinnakerService.yml

You can find the basic spinnakerservice.yml manifest file in /spinnaker-operator/deploy/spinnaker/basic/.

You need to specify persistent storage details and the version to deploy before you can use the manifest to deploy Spinnaker. The following example uses an AWS S3 bucket. You can find configuration for other storage types in the Persistent Storage reference.

You can see the list of Spinnaker versions on the Spinnaker Versions page.

apiVersion: spinnaker.io/v1alpha2
kind: SpinnakerService
metadata:
 name: spinnaker
spec:
 spinnakerConfig:
 config:
 version: <version> # the version of Spinnaker to deploy
 persistentStorage:
 persistentStoreType: s3
 s3:
 bucket: <change-me> # Spinnaker stores application and pipeline definitions here. Create an S3 bucket and provide the name here.
 rootFolder: front50
 # spec.expose - This section defines how Spinnaker should be publicly exposed
 expose:
 type: service # Kubernetes LoadBalancer type (service/ingress), note: only "service" is supported for now
 service:
 type: LoadBalancer

Deploy using kubectl:

kubectl create ns spinnaker
kubectl -n spinnaker apply -f deploy/spinnaker/basic/spinnakerservice.yml

You can watch the installation progress by executing:

kubectl -n spinnaker get spinsvc spinnaker -w

You can verify pod status by executing:

 kubectl -n spinnaker get pods

The included manifest file is only for a very basic installation. Configure Armory Continuous Deployment Using a Manifest File contains detailed manifest configuration options.

Kustomize patches option

This example assumes you deploy Armory Continuous Deployment to the spinnaker-operator namespace.

Kustomize uses patch files to build a deployment file by overwriting sections of the spinnakerservice.yml manifest file. You declare your patch files in a kustomization.yml file, which kubectl and Kustomize and use to build the Armory Continuous Deployment or Spinnaker manifest file.

You can put each manifest config section in its own file. For example, if you create a profiles-patch.yml patch with configuration for various services, you are telling Kustomize to overwrite the profiles section of the spinnakerservice.yml manifest with the contents of profiles-patch.yml. Kustomize is flexible, though, so you could instead create a separate patch file for each service (profiles-clouddriver-patch.yml, profiles-gate-patch.yml, profiles-deck-patch.yml, etc.), and then declare those patches in the kustomization.yml file.

Kustomize is part of kubectl, so you do not need to install Kustomize locally to build and verify your manifest file. You can run kubectl kustomize <path-to-kustomization.yml>. This prints out the contents of the manifest file that Kustomize builds using your kustomization.yml file.

kubectl versions up to and including v1.20 come bundled with Kustomize v2.0.3. kubectl 1.21 comes bundled with Kustomize v4.0.5. Using Kustomize patches has been tested with kubectl v1.19.x. and standalone Kustomize v2 and v3. You may see a panic error if you use the spinnaker-kustomize-patches repo with Kustomize v4.0+ or kubectl v1.21+.

For this quickstart, you can find bare minimum patches in /spinnaker-operator/deploy/spinnaker/kustomize. Before you deploy Armory Continuous Deployment, you need to update the version and persistentStorage values in config-patch.yml.

The following example uses an AWS S3 bucket. You can find configuration for other storage types in the Persistent Storage reference.

This quickstart example is suitable for a proof of concept. For production environments, you should use a robust set of Kustomize patches. See the Configure Armory Continuous Deployment Using Kustomize guide for details.

You can see the list of Armory Continuous Deployment versions on the Release Notes page.

apiVersion: spinnaker.armory.io/v1alpha2
kind: SpinnakerService
metadata:
 name: spinnaker
spec:
 # spec.spinnakerConfig - This section is how to specify configuration spinnaker
 spinnakerConfig:
 # spec.spinnakerConfig.config - This section contains the contents of a deployment found in a halconfig .deploymentConfigurations[0]
 config:
 version: <version> # the version of Armory Continuous Deployment to be deployed
 persistentStorage:
 persistentStoreType: s3
 s3:
 bucket: mybucket
 rootFolder: front50

The Armory Operator contains Halyard to manage a portion of the deployment Armory Continuous Deployment. See Advanced Operator Configuration if you need to override the default settings for the Halyard Container for some advanced features.

You can see the list of open source Spinnaker versions on the Spinnaker website’s Versions page.

apiVersion: spinnaker.io/v1alpha2
kind: SpinnakerService
metadata:
 name: spinnaker
spec:
 # spec.spinnakerConfig - This section is how to specify configuration Spinnaker
 spinnakerConfig:
 # spec.spinnakerConfig.config - This section contains the contents of a deployment found in a halconfig .deploymentConfigurations[0]
 config:
 version: <version> # the version of Spinnaker to be deployed
 persistentStorage:
 persistentStoreType: s3
 s3:
 bucket: mybucket
 rootFolder: front50

If you want to verify the contents of the manifest file, execute from the /spinnaker-operator/deploy/spinnaker/kustomize/ directory:
```
kubectl kustomize .
```
This prints out the contents of the manifest file that Kustomize built based on your kustomization.yml file.
Deploy from the /spinnaker-operator/deploy/spinnaker/kustomize/ directory:
```
kubectl create ns spinnaker
kubectl -n spinnaker apply -k .
```
You can watch the installation progress by executing:
```
kubectl -n spinnaker get spinsvc spinnaker -w
```
You can verify pod status by executing:
```
kubectl -n spinnaker get pods
```

Help resources

Armory Operator and Armory Continuous Deployment: contact Armory Support or use the Spinnaker Slack #armory channel.
Spinnaker Operator and Spinnaker: Spinnaker Slack #kubernetes-operator channel.

What’s next

Register your Armory Continuous Deployment instance.
Learn how to Manage Armory Continuous Deployment using the Operator.
See advanced manifest configuration in the Configure Armory Continuous Deployment Using a Manifest File guide.
See advanced configuration using Kustomize in the Configure Armory Continuous Deployment Using Kustomize guide.
See the Errors and Troubleshooting guide if you encounter issues.
If you are deploying Armory Continuous Deployment, you may need to override the default settings for the Halyard container for some advanced features. See the Advanced Operator Configuration guide.
Learn how to Manage Operator.

Continuous-Deployment: Configure Armory Continuous Deployment Using Kustomize

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

This guide is for both the Armory Operator and the Spinnaker Operator. Armory Continuous Deployment and Spinnaker configuration is the same except for features only in Armory Continuous Deployment. Those features are marked .

Why use Kustomize patches for Spinnaker configuration

Even though you can configure Armory Continuous Deployment or Spinnaker in a single manifest file, the advantage of using Kustomize patch files is readability, consistency across environments, and maintainability.

How Kustomize works

kubectl versions up to and including v1.20 come bundled with Kustomize v2.0.3. kubectl 1.21 comes bundled with Kustomize v4.0.5. Using Kustomize patches has been tested with kubectl v1.19.x. and standalone Kustomize v2 and v3. You may see a panic error if you use the spinnaker-kustomize-patches repo with Kustomize v4.0+ or kubectl v1.21+.

Kustomize resources

You should familiarize yourself with Kustomize before you create patch files to configure Armory Continuous Deployment.

Kubernetes requirements

You are familiar with Kubernetes Operators, which use custom resources to manage applications and their components.
You understand the concept of managing Kubernetes resources using manifests.
You have reviewed and met the Armory Continuous Deployment system requirements.

Spinnaker Kustomize patches repo

Armory maintains the spinnakaker-kustomize-patches repo, which contains common configuration options for Armory Continuous Deployment or Spinnaker as well as helper scripts. The patches in this repo give you a reliable starting point when adding and removing features.

Configuration in this repository is meant for Armory Continuous Delivery. To make it compatible with Spinnaker instead, apply the utilities/switch-to-oss.yml patch.

To start, create your own copy of the spinnaker-kustomize-patches repository by clicking the Use this template button:

If you intend to update your copy from upstream, use Fork instead. See Creating a repository from a template for the difference between Use this template and Fork.

Once created, clone this repository to your local machine.

Configure Armory Continuous Deployment

Follow these steps to configure Armory Continuous Deployment:

Choose a kustomization.yml file.
(Optional) If you are deploying open source Spinnaker, change the apiVersion in each patch file.
Set the Armory Continuous Deployment (or Spinnaker) version.
Verify the content of each resource file.
Verify the configuration contents of each patch file.

Choose a `kustomization` file

Before you begin configuring Armory Continuous Deployment, you need to choose or create a kustomization.yml file. The kustomization.yml specifies the namespace for Armory Continuous Deployment, a list of Kubernetes resources, and a list of patch files to merge into the spinnakerservice.yml manifest file. For example, the recipes/kustomization-minimum.yml file contains the following:

#-----------------------------------------------------------------------------------------------------------------------
# Minimum Starting Point recipe
#
# Self contained Spinnaker installation with no external dependencies and no additional configuration needed.
# This is intended as a starting point for any kubernetes cluster.
# Not for production use.
#
# Features:
# - One Kubernetes account (Spinnaker's own cluster) for deployment targets
# - Spinnaker authentication disabled
# - Self hosted minio as a persistent storage
# - Self hosted redis backend for caching and temporal storage of services
#-----------------------------------------------------------------------------------------------------------------------
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

namespace: spinnaker

components:
 - core/base
 - core/persistence/in-cluster
 - targets/kubernetes/default

patchesStrategicMerge:
 - core/patches/version.yml

transformers:
 - utilities/unique-service-account.yml

The components section contains paths to directories that define collections of Kubernetes resources, such as: in-cluster Spinnaker persistence with Minio, Kubernetes Service Account and patches to enable the cluster in Spinnaker.
The patchesStrategicMerge section contains links to files that contain partial resource definitions. Kustomize uses these patch files to overwrite sections of components or resources, such as the SpinnakerService definition.

spinnaker-kustomize-patches/kustomization.yml is a symlink that points to spinnaker-kustomize-patches/recipes/kustomization-all.yml. There are multiple kustomization examples in the recipes directory. Choose the one that most closely resembles your use case and link to it. Alternately, you can delete the symlink, move your desired Kustomization file from recipes to the top-level directory, and rename the file to kustomization.yml.

Warning

If you are in an air-gapped environment and are using MinIO to host the Armory Continuous Deployment BOM, remove core/persistence/in-cluster/minio.yml from the list of resources to prevent the accidental deletion of the bucket when calling kubectl delete -k ..

Choose Open Source Spinnaker

This step is required only if you are deploying open source Spinnaker.

Add the following patch to your kustomization.yml file:

patches:
 - target:
 kind: SpinnakerService
 path: utilities/switch-to-oss.yml

Set the Armory Continuous Deployment version

In spinnaker-kustomize-patches/core/patches/version.yml, set the Armory CD version or Spinnaker version that you want to deploy, such as 2.34 (Armory Continuous Deployment) or 1.25.3 (Spinnaker).

1
2
3
4
5
6
7


kind: SpinnakerService
metadata:
 name: spinnaker
spec:
 spinnakerConfig:
 config:
 version: 2.34

Verify resources

Read each file linked to from your chosen kustomization.yml file section to make sure that the Kubernetes resource as configured works with your environment.

Verify patches

Read each file linked to in the patchesStrategicMerge section. You may need to update each patch configuration with values specific to you and your environment. For example, the kustomization-quickstart.yml file described in the Choose a kustomization file section links to accounts/docker/patch-dockerhub.yml. You need to update that patch file with your own DockerHub credentials.

Explore the patches in various folders to see if there are any that you want to use. Remember to list additional patches in the patchesStrategicMerge section of your kustomization.yml file.

Secrets

If you want to store Spinnaker secrets in Kubernetes, we recommend using Kustomize generators.

Deploy Armory Continuous Deployment

Once you have configured your patch files, you can deploy Armory Continuous Deployment.

Create the spinnaker namespace:
```
kubectl create ns spinnaker
```
If you want to use a different namespace, you must update the namespace value in your kustomization.yml file.
(Optional) Verify the Kustomize build output:
```
kubectl kustomize <path-to-kustomization.yml>
```
This prints out the contents of the manifest file that Kustomize built based on your kustomization.yml file.

Apply the manifest:

kubectl apply -k <path-to-kustomization.yml>

Watch the install progress and see the pods being created:
```
kubectl -n spinnaker get spinsvc spinnaker -w
```

Help resources

Armory Operator and Armory Continuous Deployment: contact Armory Support or use the Spinnaker Slack #armory channel.
Spinnaker Operator and Spinnaker: Spinnaker Slack #kubernetes-operator channel.

What’s next

See the Manifest Reference for configuration options by section.
Learn how to manage your Spinnaker instance.
See the Errors and Troubleshooting guide if you encounter issues.

Continuous-Deployment: Configure Armory Continuous Deployment Using a Manifest File

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

This guide is for both the Armory Operator and the Spinnaker Operator. Armory Continuous Deployment and Spinnaker configuration is the same except for features only in Armory Continuous Deployment. Those features are marked .

Before you begin

This guide assumes you want to expand the manifest file used in the Quickstart.
You know how to deploy Armory Continuous Deployment using a Kubernetes manifest file. See the Quickstart’s Single manifest file section.

Kubernetes manifest file

The structure of the manifest file is the same whether you are using the Armory Operator or the Spinnaker Operator. The value of certain keys, though, depends on whether you are deploying Armory Continuous Deployment or Spinnaker. The following snippet is the first several lines from a spinnakerservice.yml manifest that deploys Armory Continuous Deployment.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


apiVersion: spinnaker.armory.io/v1alpha2
kind: SpinnakerService
metadata:
 name: spinnaker
spec:
 spinnakerConfig:
 config:
 version: <version>
 persistentStorage:
 persistentStoreType: s3
 s3:
 bucket: <s3-bucket-name>
 rootFolder: front50

Line 1: apiVersion is the CRD version of the SpinnakerService custom resource.
- If you are deploying Armory Continuous Deployment, the value is spinnaker.armory.io/v1alpha2; if you change this value, the Armory Operator won’t process the manifest file.
- If you are deploying Spinnaker, the value is spinnaker.io/v1alpha2; if you change this value, the Spinnaker Operator won’t process the manifest file.
Line 8: spec.spinnakerConfig.config.version
- If you are using the Armory Operator, this is the version of Armory Continuous Deployment you want to deploy; for example, 2.34.
- If you are using the Spinnaker Operator, this is the version of Spinnaker you want to deploy; for example, 1.25.

Expand to see a skeleton manifest file

This file is from the public armory/spinnaker-operator repo. You use this file to configure and deploy Spinnaker. Note that the apiVersion is the SpinnakerService CRD used by the Spinnaker Operator.

apiVersion: spinnaker.io/v1alpha2
kind: SpinnakerService
metadata:
 name: spinnaker
spec:
 # spec.spinnakerConfig - This section is how to specify configuration spinnaker
 spinnakerConfig:
 # spec.spinnakerConfig.config - This section contains the contents of a deployment found in a halconfig .deploymentConfigurations[0]
 config:
 version: 1.28.1 # the version of Spinnaker to be deployed
 persistentStorage:
 persistentStoreType: s3
 s3:
 bucket: <change-me> # Change to a unique name. Spinnaker stores application and pipeline definitions here
 rootFolder: front50

 # spec.spinnakerConfig.profiles - This section contains the YAML of each service's profile
 profiles:
 clouddriver: {} # is the contents of ~/.hal/default/profiles/clouddriver.yml
 # deck has a special key "settings-local.js" for the contents of settings-local.js
 deck:
 # settings-local.js - contents of ~/.hal/default/profiles/settings-local.js
 # Use the | YAML symbol to indicate a block-style multiline string
 settings-local.js: |
  window.spinnakerSettings.feature.kustomizeEnabled = true;
 echo: {} # is the contents of ~/.hal/default/profiles/echo.yml
 fiat: {} # is the contents of ~/.hal/default/profiles/fiat.yml
 front50: {} # is the contents of ~/.hal/default/profiles/front50.yml
 gate: {} # is the contents of ~/.hal/default/profiles/gate.yml
 igor: {} # is the contents of ~/.hal/default/profiles/igor.yml
 kayenta: {} # is the contents of ~/.hal/default/profiles/kayenta.yml
 orca: {} # is the contents of ~/.hal/default/profiles/orca.yml
 rosco: {} # is the contents of ~/.hal/default/profiles/rosco.yml

 # spec.spinnakerConfig.service-settings - This section contains the YAML of the service's service-setting
 # see https://www.spinnaker.io/reference/halyard/custom/#tweakable-service-settings for available settings
 service-settings:
 clouddriver: {}
 deck: {}
 echo: {}
 fiat: {}
 front50: {}
 gate: {}
 igor: {}
 kayenta: {}
 orca: {}
 rosco: {}

 # spec.spinnakerConfig.files - This section allows you to include any other raw string files not handle above.
 # The KEY is the filepath and filename of where it should be placed
 # - Files here will be placed into ~/.hal/default/ on halyard
 # - __ is used in place of / for the path separator
 # The VALUE is the contents of the file.
 # - Use the | YAML symbol to indicate a block-style multiline string
 # - We currently only support string files
 # - NOTE: Kubernetes has a manifest size limitation of 1MB
 files: {}
 # profiles__rosco__packer__example-packer-config.json: |
 # {
 # "packerSetting": "someValue"
 # }
 # profiles__rosco__packer__my_custom_script.sh: |
 # #!/bin/bash -e
 # echo "hello world!"

 # spec.expose - This section defines how Spinnaker should be publicly exposed
 expose:
 type: service # Kubernetes LoadBalancer type (service/ingress), note: only "service" is supported for now
 service:
 type: LoadBalancer

 # annotations to be set on Kubernetes LoadBalancer type
 # they will only apply to spin-gate, spin-gate-x509, or spin-deck
 annotations:
 service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
 # uncomment the line below to provide an AWS SSL certificate to terminate SSL at the LoadBalancer
 #service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:us-west-2:9999999:certificate/abc-123-abc

 # provide an override to the exposing KubernetesService
 overrides: {}
 # Provided below is the example config for the Gate-X509 configuration
# deck:
# annotations:
# service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:us-west-2:9999999:certificate/abc-123-abc
# service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
# gate:
# annotations:
# service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:us-west-2:9999999:certificate/abc-123-abc
# service.beta.kubernetes.io/aws-load-balancer-backend-protocol: https # X509 requires https from LoadBalancer -> Gate
# gate-x509:
# annotations:
# service.beta.kubernetes.io/aws-load-balancer-backend-protocol: tcp
# service.beta.kubernetes.io/aws-load-balancer-ssl-cert: null
# publicPort: 443

 validation: {}

 # Patching of generated service or deployment by Spinnaker service.
 # Like in Kustomize, several patch types are supported. See
 # https://github.com/armory/spinnaker-operator/blob/master/doc/options.md#speckustomize
 kustomize: {}
 # An example to change Gate's image name using a strategic merge patch
# gate:
# deployment:
# patchesStrategicMerge:
# - |
# spec:
# template:
# spec:
# containers:
# - name: gate
# image: gate:1.0.0

Manifest sections

metadata.name

apiVersion: apiVersion: spinnaker.armory.io/v1alpha2
kind: SpinnakerService
metadata:
 name: spinnaker

metadata.name is the name of your Armory Continuous Deployment service. Use this name to view, edit, or delete Armory Continuous Deployment. The following example uses the name prod:

$ kubectl get spinsvc prod

Note that you can use spinsvc for brevity. You can also use spinnakerservices.spinnaker.armory.io (Armory Continuous Deployment) or spinnakerservices.spinnaker.io (Spinnaker).

spec.spinnakerConfig

Contains the same information as the deploymentConfigurations entry in a Halyard configuration.

For example, given the following ~/.hal/config file:

currentDeployment: default
deploymentConfigurations:
- name: default
 version: 2.17.1
 persistentStorage:
 persistentStoreType: s3
 s3:
 bucket: mybucket
 rootFolder: front50

The equivalent of that Halyard configuration is the following spec.spinnakerConfig:

apiVersion: apiVersion: spinnaker.armory.io/v1alpha2
kind: SpinnakerService
metadata:
 name: spinnaker
spec:
 spinnakerConfig:
 config:
 version: 2.17.1
 persistentStorage:
 persistentStoreType: s3
 s3:
 bucket: mybucket
 rootFolder: front50

spec.spinnakerConfig.config contains the following sections:

spec.spinnakerConfig.profiles

Configuration for each service profile. This is the equivalent of ~/.hal/default/profiles/<service>-local.yml. For example the following profile is for Gate:

spec:
 spinnakerConfig:
 config:
 ...
 profiles:
 gate:
 default:
 apiPort: 8085

Note that for Deck, the profile is a string under the key settings-local.js:

spec:
 spinnakerConfig:
 config:
 ...
 profiles:
 deck:
 settings-local.js: |
  window.spinnakerSettings.feature.artifactsRewrite = true;

spec.spinnakerConfig.service-settings

Settings for each service. This is the equivalent of ~/.hal/default/service-settings/<service>.yml. For example the following settings are for Clouddriver:

spec:
 spinnakerConfig:
 config:
 ...
 service-settings:
 clouddriver:
 kubernetes:
 serviceAccountName: spin-sa

spec.spinnakerConfig.files

Contents of any local files that should be added to the services. For example to reference the contents of a kubeconfig file:

spec:
 spinnakerConfig:
 config:
 providers:
 kubernetes:
 enabled: true
 accounts:
 - name: cluster-1
 kubeconfigFile: cluster1-kubeconfig
 ...
 files:
 cluster1-kubeconfig: |
  <FILE CONTENTS HERE>

A double underscore (__) in the file name is translated to a path separator (/). For example to add custom packer templates:

 files: {}
 profiles__rosco__packer__example-packer-config.json: |
 {
 "packerSetting": "someValue"
 }
 profiles__rosco__packer__my_custom_script.sh: |
 #!/bin/bash -e
 echo "hello world!"

spec.expose

Optional. Controls how Armory Continuous Deploymentgets exposed. If you omit it, no load balancer gets created. If this section gets removed, the Load Balancer does not get deleted.

Use the following configurations:

spec.expose.type: How Armory Continuous Deploymentgets exposed. Currently, only service is supported, which uses Kubernetes services to expose Spinnaker.
spec.expose.service: Service configuration
spec.expose.service.type: Should match a valid Kubernetes service type (i.e. LoadBalancer, NodePort, or ClusterIP).
spec.expose.service.annotations: Map containing annotations to be added to Gate (API) and Deck (UI) services.
spec.expose.service.overrides: Map with key for overriding the service type and specifying extra annotations: Armory Continuous Deploymentservice name (Gate or Deck) and value. By default, all services receive the same annotations. You can override annotations for a Deck (UI) or Gate (API) services.

spec.validation

Currently these configurations are experimental. By default, the Operator always validates Kubernetes accounts when applying a SpinnakerService manifest.

Validation options that apply to all validations that Operator performs:

spec.validation.failOnError: Boolean. Defaults to true. If false, the validation runs and the results are logged, but the service is always considered valid.
spec.validation.failFast: Boolean. Defaults to false. If true, validation stops at the first error.
spec.validation.frequencySeconds: Optional. Integer. Define a grace period before a validation runs again. For example, if you specify a value of 120 and edit the SpinnakerService without changing an account within a 120 second window, the validation on that account does not run again.

Additionally, the following settings are specific to Kubernetes, Docker, AWS, AWS S3, CI tools, metric stores, persistent storage, or notification systems:

spec.validation.providers.kubernetes
spec.validation.providers.docker
spec.validation.providers.aws
spec.validation.providers.s3
spec.validation.providers.ci
spec.validation.providers.metricStores
spec.validation.providers.persistentStorage
spec.validation.providers.notifications

Supported settings are enabled (set to false to turn off validations), failOnError, and frequencySeconds.

The following example disables all Kubernetes account validations:

spec:
 validation:
 providers:
 kubernetes:
 enabled: false

spec.accounts

Support for SpinnakerAccount CRD (Experimental):

spec.accounts.enabled: Boolean. Defaults to false. If true, the SpinnakerService uses all SpinnakerAccount objects enabled.
spec.accounts.dynamic (experimental): Boolean. Defaults to false. If true, SpinnakerAccount objects are available to Armory Continuous Deployment as the account is applied (without redeploying any service).

Example Manifests for exposing Armory Continuous Deployment

Load balancer Services

spec:
 expose:
 type: service
 service:
 type: LoadBalancer
 annotations:
 "service.beta.kubernetes.io/aws-load-balancer-backend-protocol": "http"
 "service.beta.kubernetes.io/aws-load-balancer-ssl-ports": "80,443"
 "service.beta.kubernetes.io/aws-load-balancer-ssl-cert": "arn:aws:acm:us-west-2:xxxxxxxxxxxx:certificate/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

The preceding manifest generates these two services:

spin-deck

apiVersion: v1
kind: Service
metadata:
 annotations:
 service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
 service.beta.kubernetes.io/aws-load-balancer-ssl-ports: 80,443
 service.beta.kubernetes.io/aws-load-balancer-ssl-cert": arn:aws:acm:us-west-2:xxxxxxxxxxxx:certificate/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 labels:
 app: spin
 cluster: spin-deck
 name: spin-deck
spec:
 ports:
 - name: deck-tcp
 nodePort: xxxxx
 port: 9000
 protocol: TCP
 targetPort: 9000
 selector:
 app: spin
 cluster: spin-deck
 sessionAffinity: None
 type: LoadBalancer

spin-gate

apiVersion: v1
kind: Service
metadata:
 annotations:
 service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
 service.beta.kubernetes.io/aws-load-balancer-ssl-ports: 80,443
 service.beta.kubernetes.io/aws-load-balancer-ssl-cert": arn:aws:acm:us-west-2:xxxxxxxxxxxx:certificate/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 labels:
 app: spin
 cluster: spin-gate
 name: spin-gate
spec:
 ports:
 - name: gate-tcp
 nodePort: xxxxx
 port: 8084
 protocol: TCP
 targetPort: 8084
 selector:
 app: spin
 cluster: spin-gate
 sessionAffinity: None
 type: LoadBalancer

Different service types for Deck (UI) and Gate (API)

spec:
 expose:
 type: service
 service:
 type: LoadBalancer
 annotations:
 "service.beta.kubernetes.io/aws-load-balancer-backend-protocol": "http"
 "service.beta.kubernetes.io/aws-load-balancer-ssl-ports": "80,443"
 "service.beta.kubernetes.io/aws-load-balancer-ssl-cert": "arn:aws:acm:us-west-2:xxxxxxxxxxxx:certificate/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
 overrides:
 gate:
 type: NodePort

The preceding manifest generates these two services:

spin-deck

apiVersion: v1
kind: Service
metadata:
 annotations:
 service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
 service.beta.kubernetes.io/aws-load-balancer-ssl-ports: 80,443
 service.beta.kubernetes.io/aws-load-balancer-ssl-cert": arn:aws:acm:us-west-2:xxxxxxxxxxxx:certificate/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 labels:
 app: spin
 cluster: spin-deck
 name: spin-deck
 spec:
 ports:
 - name: deck-tcp
 nodePort: xxxxx
 port: 9000
 protocol: TCP
 targetPort: 9000
 selector:
 app: spin
 cluster: spin-deck
 sessionAffinity: None
 type: LoadBalancer

spin-gate

apiVersion: v1
kind: Service
metadata:
 annotations:
 service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
 service.beta.kubernetes.io/aws-load-balancer-ssl-ports: 80,443
 service.beta.kubernetes.io/aws-load-balancer-ssl-cert": arn:aws:acm:us-west-2:xxxxxxxxxxxx:certificate/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 labels:
 app: spin
 cluster: spin-gate
 name: spin-gate
spec:
 ports:
 - name: gate-tcp
 nodePort: xxxxx
 port: 8084
 protocol: TCP
 targetPort: 8084
 selector:
 app: spin
 cluster: spin-gate
 sessionAffinity: None
 type: NodePort

Different annotations for Deck (UI) and Gate (API)

spec:
 expose:
 type: service
 service:
 type: LoadBalancer
 annotations:
 "service.beta.kubernetes.io/aws-load-balancer-backend-protocol": "http"
 "service.beta.kubernetes.io/aws-load-balancer-ssl-ports": "80,443"
 "service.beta.kubernetes.io/aws-load-balancer-ssl-cert": "arn:aws:acm:us-west-2:xxxxxxxxxxxx:certificate/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
 overrides:
 gate:
 annotations:
 "service.beta.kubernetes.io/aws-load-balancer-internal": "true"

The preceding manifest file generates these two services:

spin-deck

apiVersion: v1
kind: Service
metadata:
 annotations:
 service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
 service.beta.kubernetes.io/aws-load-balancer-ssl-ports: 80,443
 service.beta.kubernetes.io/aws-load-balancer-ssl-cert": arn:aws:acm:us-west-2:xxxxxxxxxxxx:certificate/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 labels:
 app: spin
 cluster: spin-deck
 name: spin-deck
spec:
 ports:
 - name: deck-tcp
 nodePort: xxxxx
 port: 9000
 protocol: TCP
 targetPort: 9000
 selector:
 app: spin
 cluster: spin-deck
 sessionAffinity: None
 type: LoadBalancer

spin-gate

apiVersion: v1
kind: Service
metadata:
 annotations:
 service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
 service.beta.kubernetes.io/aws-load-balancer-ssl-ports: 80,443
 service.beta.kubernetes.io/aws-load-balancer-ssl-cert": arn:aws:acm:us-west-2:xxxxxxxxxxxx:certificate/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 service.beta.kubernetes.io/aws-load-balancer-internal: true
 labels:
 app: spin
 cluster: spin-gate
 name: spin-gate
spec:
 ports:
 - name: gate-tcp
 nodePort: xxxxx
 port: 8084
 protocol: TCP
 targetPort: 8084
 selector:
 app: spin
 cluster: spin-gate
 sessionAffinity: None
 type: Loadbalancer

X509

spec:
 config:
 profiles:
 gate:
 default:
 apiPort: 8085
 expose:
 type: service
 service:
 type: LoadBalancer

 annotations:
 service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http

 overrides:
 # Provided below is the example config for the Gate-X509 configuration
 deck:
 annotations:
 service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:us-west-2:9999999:certificate/abc-123-abc
 service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
 gate:
 annotations:
 service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:us-west-2:9999999:certificate/abc-123-abc
 service.beta.kubernetes.io/aws-load-balancer-backend-protocol: https # X509 requires https from LoadBalancer -> Gate
 gate-x509:
 annotations:
 service.beta.kubernetes.io/aws-load-balancer-backend-protocol: tcp
 service.beta.kubernetes.io/aws-load-balancer-ssl-cert: null
 publicPort: 443

Help resources

Armory Operator and Armory Continuous Deployment: contact Armory Support or use the Spinnaker Slack #armory channel.
Spinnaker Operator and Spinnaker: Spinnaker Slack #kubernetes-operator channel.

What’s next

See the Manifest Reference for configuration options by section.
Configure Kubernetes accounts using the Spinnaker Accounts CRD (Experimental)
See advanced configuration using Kustomize in the Configure Armory Continuous Deployment Using Kustomize guide.

Continuous-Deployment: Manage Armory Continuous Deployment using the Operator

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

This guide is for both the Armory Operator and the Spinnaker Operator. Armory Continuous Deployment and Spinnaker configuration is the same except for features only in Armory Continuous Deployment. Those features are marked .

Kubernetes tools

You use kubectl to manage the Armory Continuous Deployment or Spinnaker lifecycle like you do with other applications deployed to Kubernetes. For example:

List instances

kubectl get spinnakerservice --all-namespaces

Describe instances

You can use spinsvc instead of spinnakerservice:

kubectl -n <namespace> describe spinsvc spinnaker

Consult the kubectl docs for a list of commands.

Deploy Armory Continuous Deployment

kubectl -n <namespace> apply -f <path-to-manifest-file>

kubctl -n <namespace> apply -k <path-to-kustomize-directory>

You can watch the installation progress by executing:

kubectl -n <namespace> get spinsvc spinnaker -w

You can verify pod status by executing:

 kubectl -n <namespace> get pods

Upgrade Armory Continuous Deployment

Change the version field in your manifest file to the target version for the upgrade:

kind: SpinnakerService
metadata:
 name: spinnaker
spec:
 spinnakerConfig:
 config:
 version: <version>

Apply the updated manifest:

kubectl -n <namespace> apply -f <path-to-manifest-file>

Change the version field in your Kustomize patch to the target version for the upgrade.

Apply the update:

kubctl -n <namespace> apply -k <path-to-kustomize-directory>

You can view the upgraded services starting up by executing describe:

kubectl -n <namespace> describe spinsvc spinnaker

Verify the upgraded version of Spinnaker:

kubectl -n <namespace> get spinsvc

The command returns information similar to the following:

NAME VERSION
spinnaker 2.20.2

VERSION should reflect the target version for your upgrade.

Rollback Armory Continuous Deployment

Change the version field in your manifest file to the target version for the rollback:

kind: SpinnakerService
metadata:
 name: spinnaker
spec:
 spinnakerConfig:
 config:
 version: <version>

Apply the updated manifest:

kubectl -n <namespace> apply -f <path-to-manifest-file>

Change the version field in your Kustomize patch to the target version for the rollback.

Apply the update:

kubctl -n <namespace> apply -k <path-to-kustomize-directory>

You can view the rolled back services starting up by executing describe:

kubectl -n <namespace> describe spinsvc spinnaker

Verify the rolled back version of Spinnaker:

kubectl -n <namespace> get spinsvc

The command returns information similar to the following:

NAME VERSION
spinnaker 2.27.2

VERSION should reflect the target version for your rollback.

Delete Armory Continuous Deployment

kubectl -n <namespace> delete spinnakerservice spinnaker

Help resources

Armory Operator and Armory Continuous Deployment: contact Armory Support or use the Spinnaker Slack #armory channel.
Spinnaker Operator and Spinnaker: Spinnaker Slack #kubernetes-operator channel.

What’s next

See the Errors and Troubleshooting guide if you encounter issues.

Continuous-Deployment: Migrate from Halyard to the Operator

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

This guide is for both the Armory Operator and the Spinnaker Operator. Armory Continuous Deployment and Spinnaker configuration is the same except for features only in Armory Continuous Deployment. Those features are marked .

Before you begin

You need to decide if you want to overwrite the current Halyard deployment of Armory Continuous Deployment or create a test instance.

If you choose to overwrite your current instance, you need to take downtime to clean up the namespace that the Halyard-deployed Armory Continuous Deployment is in so Operator can deploy Armory Continuous Deployment without collision.

Alternately, you can use Operator to deploy Armory Continuous Deployment to a different namespace to test out the migration. You need to create a separate data store as well as separate Gate and Deck URLs for your test instance of Armory Continuous Deployment. Once you’ve verified that Operator has deployed your test configuration as you expected, decommission the Halyard-deployed instance of Armory Continuous Deployment. Change the data store config and URLs in the manifest that Operator used to deploy your test instance to match what your decommissioned instance used. Then redeploy.

The second method is preferred as it allows you to test everything before decommissioning Armory Continuous Deployment that you deployed using Halyard.

Migrate to Operator

This guide assumes you want to deploy Armory Continuous Deployment using a single SpinnakerSerivce.yml manifest file rather than Kustomize patches.

The migration process from Halyard to Operator can be completed in 7 steps:

Install the Operator.
Export configuration.

Copy the desired profile’s content from the config file

For example, if you want to migrate the default hal profile, use the following SpinnakerService manifest structure:
```
currentDeployment: default
deploymentConfigurations:
- name: default
 <CONTENT>
```
Add <CONTENT> in the spec.spinnakerConfig.config section in the SpinnakerService manifest as follows:
```
spec:
 spinnakerConfig:
 config:
 <<CONTENT>>
```
Note: config is under ~/.hal

You can see more details in spec.spinnakerConfig.config.
Export Armory Continuous Deployment profiles.

If you have configured Armory Continuous Deployment profiles, you need to migrate these profiles to the SpinnakerService manifest.

First, identify the current profiles under ~/.hal/default/profiles.

For each file, create an entry under spec.spinnakerConfig.profiles.

For example, you have the following profile:
```
$ ls -a ~/.hal/default/profiles | sort
echo-local.yml
```
Create a new entry with the name of the file without -local.yaml as follows:
```
spec:
 spinnakerConfig:
 profiles:
 echo:
 <CONTENT>
```
You can see more details in spec.spinnakerConfig.profiles.
Export Armory Continuous Deployment settings.

If you configured Armory settings, you need to migrate these settings to the SpinnakerService manifest also.

First, identify the current settings under ~/.hal/default/service-settings.

For each file, create an entry under spec.spinnakerConfig.service-settings.

For example, you have the following settings:
```
$ ls -a ~/.hal/default/service-settings | sort
echo.yml
```
Create a new entry with the name of the file without .yaml as follows:
```
spec:
 spinnakerConfig:
 service-settings:
 echo:
 <CONTENT>
```
You can see more details in spec.spinnakerConfig.service-settings.

Export local file references.

If you have references to local files in any part of the config, like kubeconfigFile, service account JSON files or others, you need to migrate these files to the SpinnakerService manifest.

For each file, create an entry under spec.spinnakerConfig.files.

For example, you have a Kubernetes account configured like this:

kubernetes:
 enabled: true
 accounts:
 - name: prod
 requiredGroupMembership: []
 providerVersion: V2
 permissions: {}
 dockerRegistries: []
 configureImagePullSecrets: true
 cacheThreads: 1
 namespaces: []
 omitNamespaces: []
 kinds: []
 omitKinds: []
 customResources: []
 cachingPolicies: []
 oAuthScopes: []
 onlySpinnakerManaged: false
 kubeconfigFile: /home/spinnaker/.hal/secrets/kubeconfig-prod
 primaryAccount: prod

The kubeconfigFile field is a reference to a physical file on the machine running Halyard. You need to create a new entry in files section like this:

spec:
 spinnakerConfig:
 files:
 kubeconfig-prod: |
  <CONTENT>

Then replace the path in the config to match the key in the files section:

kubernetes:
 enabled: true
 accounts:
 - name: prod
 requiredGroupMembership: []
 providerVersion: V2
 permissions: {}
 dockerRegistries: []
 configureImagePullSecrets: true
 cacheThreads: 1
 namespaces: []
 omitNamespaces: []
 kinds: []
 omitKinds: []
 customResources: []
 cachingPolicies: []
 oAuthScopes: []
 onlySpinnakerManaged: false
 kubeconfigFile: kubeconfig-prod # File name must match "files" key
 primaryAccount: prod

You can see more details in spec.spinnakerConfig.files.

Export Packer template files (if used).

If you are using custom Packer templates for baking images, you need to migrate these files to the SpinnakerService manifest.

First, identify the current templates under ~/.hal/default/profiles/rosco/packer.

For each file, create an entry under spec.spinnakerConfig.files.

For example, you have the following example-packer-config file:
```
$ tree -v ~/.hal/default/profiles
├── echo-local.yml
└── rosco
 └── packer
 └── example-packer-config.json

2 directories, 2 files
```
You need to create a new entry with the name of the file following these instructions:
- For each file, list the folder name starting with profiles, followed by double underscores (__) and at the very end the name of the file.
```
spec:
 spinnakerConfig:
 files:
 profiles__rosco__packer__example-packer-config.json: |
  <CONTENT>
```
You can see more details in spec.spinnakerConfig.files.
Validate your Armory configuration if you plan to run the Operator in cluster mode:
```
kubectl -n <namespace> apply -f <spinnaker service manifest> --dry-run=server
```
The validation service throws an error when something is wrong with your manifest.

Apply your SpinnakerService:

kubectl -n <namespace> apply -f <spinnaker service>

Help resources

Armory Operator and Armory Continuous Deployment: contact Armory Support or use the Spinnaker Slack #armory channel.
Spinnaker Operator and Spinnaker: Spinnaker Slack #kubernetes-operator channel.

Continuous-Deployment: Manage Operator

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

This guide is for both the Armory Operator and the Spinnaker Operator. Armory Continuous Deployment and Spinnaker configuration is the same except for features only in Armory Continuous Deployment. Those features are marked .

Upgrade the Operator

Do not manually change Docker image tags in your existing manifest files. Operator computes the compatible Halyard version, so manually updating image tags is an unsupported upgrade method and may cause issues.

Use the kubectl replace command to replace your Operator deployment. See the kubectl replace docs for an explanation of this command.

Download the Operator version you want to upgrade to:

Armory Operator

In the following command, replace <version> with the specific version or “latest” for the most recent version.
```
bash -c 'curl -L https://github.com/armory-io/spinnaker-operator/releases/download/<version>/manifests.tgz | tar -xz'
```
Spinnaker Operator

In the following command, replace <version> with the specific version or “latest” for the most recent version.
```
bash -c 'curl -L https://github.com/armory/spinnaker-operator/releases/download/<version>/manifests.tgz | tar -xz'
```
Update CRDs across the cluster:
```
kubectl replace -f deploy/crds/
```

Update the Operator:

kubectl -n spinnaker-operator replace -f deploy/operator/cluster

Uninstall the Operator

Uninstalling the Operator involves deleting its deployment and SpinnakerService CRD. When you delete the Operator CRD, Kubernetes deletes any installation created by Operator. This occurs because the CRD is set as the owner of the resources, so they get garbage collected.

You can remove this ownership relationship so that Armory Continuous Deployment is not deleted when deleting the Operator by removing Operator ownership of resources.

Remove Operator ownership of Armory Continuous Deployment resources

Run the following script to remove ownership of Armory resources, where NAMESPACE is the namespace where Armory Continuous Deployment is installed:

#! /usr/bin/env bash
NAMESPACE=
for rtype in deployment service
do
 for r in $(kubectl -n $NAMESPACE get $rtype --selector=app=spin -o jsonpath='{.items[*].metadata.name}')
 do
 kubectl -n $NAMESPACE patch $rtype $r --type json -p='[{"op": "remove", "path": "/metadata/ownerReferences"}]'
 done
done

After the script completes, delete the Operator and its CRDs from the Kubernetes cluster:

kubectl delete -n <namespace> -f deploy/operator/<installation type>
kubectl delete -f deploy/crds/

Help resources

Armory Operator and Armory Continuous Deployment: contact Armory Support or use the Spinnaker Slack #armory channel.
Spinnaker Operator and Spinnaker: Spinnaker Slack #kubernetes-operator channel.

Continuous-Deployment: Spinnaker Accounts CRD

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

Experimental

The information below is written for an experimental feature. Reach out to Armory if you are interested in using this! Your feedback will help shape the development of this feature.

Do not use this experimental feature in a production instance of Armory Continuous Deployment.

`SpinnakerAcount` Custom Resource Definition overview

The Operator comes with a SpinnakerAccount Custom Resource for managing Kubernetes accounts that you want to use with Spinnaker. This SpinnakerAccount resource enables defining and managing Kubernetes accounts outside of Spinnaker’s manifest file. You create a separate manifest for each Kubernetes account and kubectl apply each manifest. kubectl delegates to the Operator, which then processes the manifest into the requisite configuration and adds the account to Armory Continuous Deployment or Spinnaker.

For example, you have a pipeline that provisions a Kubernetes cluster with Terraform. If you want that new cluster to be available, you can create a SpinnakerAccount of type Kubernetes in Spinnaker’s namespace.

Format

apiVersion: spinnaker.io/v1alpha2
kind: SpinnakerAccount
metadata:
 name: account-inline
spec:
 type: <Account type>
 enabled: true
 permissions: {} # List of permissions - see below
 settings: {} # Settings see below

`metadata.name`

This is the name of the SpinnakerAccount. It needs to be unique across all accounts - not just type of account as in Spinnaker.

`spec.type`

Account type. See below for current support:

Account type	Status	Notes
`Kubernetes`	alpha	Only the Spinnaker Kubernetes V2 provider is supported

`spec.enabled`

Determines if the account is enabled. If not enabled, SpinnakerService doesn’t use it.

`spec.permissions`

Map of authorizations similar to most accounts in Spinnaker.

spec:
 permissions:
 READ: ['role1', 'role2']
 WRITE: ['role1', 'role3']

`spec.settings`

Map of settings that are supported by Halyard. For instance:

spec:
 type: Kubernetes
 settings:
 cacheThreads: 2
 omitKinds:
 - podPreset

`spec.kubernetes`

Auth options for Kubernetes account type. Pick only one of the options below:

`spec.kubernetes.kubeconfigFile`

References a file loaded either out of band to Clouddriver or (more likely) stored in a secret.

`spec.kubernetes.kubeconfigSecret`

Reference to a Kubernetes secret in the same namespace that contains the kubeconfig file:

spec:
 type: Kubernetes
 kubernetes:
 kubeconfigSecret:
 name: my-secret
 key: account1-kubeconfig

`spec.kubernetes.kubeconfig`

You can also inline the kubeconfig file if it does not contain secrets:

spec:
 type: Kubernetes
 kubernetes:
 kubeconfig:
 apiVersion: v1
 kind: Config
 clusters:
 - cluster:
 certificate-authority-data: LS0t...
 server: https://mycluster.url
 name: my-cluster
 contexts:
 - context:
 cluster: my-cluster
 user: my-user
 name: my-context
 current-context: my-context
 preferences: {}
 users:
 - name: my-user
 user:
 exec:
 apiVersion: client.authentication.k8s.io/v1alpha1
 args:
 - token
 - -i
 - my-eks-cluster
 command: aws-iam-authenticator

Help resources

Armory Operator and Armory Continuous Deployment: contact Armory Support or use the Spinnaker Slack #armory channel.
Spinnaker Operator and Spinnaker: Spinnaker Slack #kubernetes-operator channel.

Continuous-Deployment: Advanced Operator Configuration

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

This guide is for both the Armory Operator and the Spinnaker Operator. Armory Continuous Deployment and Spinnaker configuration is the same except for features only in Armory Continuous Deployment. Those features are marked .

Custom Halyard configuration

To override Halyard’s configuration, create a Kubernetes ConfigMap with the configuration changes you need. For example, if you’re using secrets management with Vault(), Halyard and Operator containers need your Vault configuration:

apiVersion: v1
kind: ConfigMap
metadata:
 name: halyard-custom-config
data:
 halyard-local.yml: |
 secrets:
 vault:
 enabled: true
 url: <URL of vault server>
 path: <cluster path>
 role: <k8s role>
 authMethod: KUBERNETES

Then, you can mount it in the Operator deployment and make it available to the Halyard and Operator containers:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
 name: spinnaker-operator
 ...
spec:
 template:
 spec:
 containers:
 - name: spinnaker-operator
 ...
 volumeMounts:
 - mountPath: /opt/spinnaker/config/halyard.yml
 name: halconfig-volume
 subPath: halyard-local.yml
 - name: halyard
 ...
 volumeMounts:
 - mountPath: /opt/spinnaker/config/halyard-local.yml
 name: halconfig-volume
 subPath: halyard-local.yml
 volumes:
 - configMap:
 defaultMode: 420
 name: halyard-custom-config
 name: halconfig-volume

Patching Runtime Resources with Kustomize

Your Kubernetes cluster may require additional sidecars or configuration present when managing Spinnaker resources. In these situations, the Armory Operator provides the ability to patch resources during reconciliation. These patches are executed via an embedded Kustomize instance in the Operator, and requires no additional installation on the user’s part. You can apply Kustomize patches at two levels of specificity:

Spinnaker as a whole
Individual services within Spinnaker

Additionally, you may make changes to the following resources generated by the Operator:

Deployment manifests
Service manifests

For example, to ensure that a ConfigMap is present on all Spinnaker services, you would add the following configuration block to your SpinnakerService config:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


apiVersion: spinnaker.armory.io/v1alpha2
kind: SpinnakerService
metadata:
 name: spinnaker
spec:
 kustomize:
 spinnaker:
 deployment:
 patchesJson6902: |
 - op: add
 path: /spec/template/spec/volumes/-
 value:
 name: custom-volume
 configMap:
 name: custom-volume
 - op: add
 path: /spec/template/spec/containers/0/volumeMounts/-
 value:
 mountPath: /opt/spinnaker/config/foo
 type: configMap
 name: custom-volume 

The previous configuration sample indicates how to specify patches in the patchesJson6902 format, that mounts a ConfigMap called custom-volume into the /opt/spinnaker/config/foo namespace.

When you no longer need the patches, you can remove them from the Operator config and they will be removed on next reconciliation for your cluster.

Help resources

Armory Operator and Armory Continuous Deployment: contact Armory Support or use the Spinnaker Slack #armory channel.
Spinnaker Operator and Spinnaker: Spinnaker Slack #kubernetes-operator channel.

Continuous-Deployment: Errors and Troubleshooting

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

Reconciler error

You may see this error even though Operator successfully applies your manifest. This error may be normal depending on the frequency of the error. Controllers work with a local cache that can be out of sync. The issue should resolve itself via repeated synchronization. One error may be fine since it’s in the design of the reconciler. Too many means something is wrong.

{
 "level": "error",
 "ts": 1592879777.6785922,
 "logger": "controller-runtime.controller",
 "msg": "Reconciler error",
 "controller": "spinnakerservice-controller",
 "request": "spinnaker-migration/spinnaker",
 "error": "Operation cannot be fulfilled on spinnakerservices.spinnaker.armory.io
 \"spinnaker\": the object has been modified; please apply your changes to the latest version and try again",
 "stacktrace": "github.com/go-logr/zapr.(*zapLogger).Error
 /opt/spinnaker-operator/build/vendor/github.com/go-logr/zapr/zapr.go:128
 sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler
 /opt/spinnaker-operator/build/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:218
 sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem
 /opt/spinnaker-operator/build/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:192
 sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).worker
 /opt/spinnaker-operator/build/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:171
 k8s.io/apimachinery/pkg/util/wait.JitterUntil.func1
 /opt/spinnaker-operator/build/vendor/k8s.io/apimachinery/pkg/util/wait/wait.go:152
 k8s.io/apimachinery/pkg/util/wait.JitterUntil
 /opt/spinnaker-operator/build/vendor/k8s.io/apimachinery/pkg/util/wait/wait.go:153
 k8s.io/apimachinery/pkg/util/wait.Until
 /opt/spinnaker-operator/build/vendor/k8s.io/apimachinery/pkg/util/wait/wait.go:88"
}

Kustomize `panic` error

If you installed Kustomize standalone, Kustomize v4.0+ kustomize build throws a panic error when it tries to parse and build using the patch files in the spinnaker-kustomize-patches repo. For example:

panic: runtime error: index out of range [145] with length 145 [recovered]
 panic: runtime error: index out of range [145] with length 145

Starting with kubectl v1.21 , the bundled Kustomize version is v4.0.5, so if you execute kubectl kustomize ., you also see this error.

Solution:

Downgrade standalone Kustomize to v3.8.10.
Downgrade to kubectl v1.19.

Help resources

Armory Operator: contact Armory Support or use the Spinnaker Slack #armory channel.
Spinnaker Operator: Spinnaker Slack #kubernetes-operator channel.

Continuous-Deployment: Armory Continuous Deployment Manifest Configuration Reference

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

Armory Docs – Deploy Armory Continuous Deployment or Spinnaker Using Kubernetes Operators

Continuous-Deployment: Install Operator and Deploy Armory Continuous Deployment Quickstart

Before you begin

Operator installation options

Install the Operator

Deploy an Armory Continuous Deployment instance

Single manifest file option

Kustomize patches option

Help resources

What’s next

Continuous-Deployment: Configure Armory Continuous Deployment Using Kustomize

Why use Kustomize patches for Spinnaker configuration

How Kustomize works

Kustomize resources

Kubernetes requirements

Spinnaker Kustomize patches repo

Configure Armory Continuous Deployment

Choose a kustomization file

Warning

Choose Open Source Spinnaker

Set the Armory Continuous Deployment version

Verify resources

Verify patches

Secrets

Deploy Armory Continuous Deployment

Help resources

What’s next

Continuous-Deployment: Configure Armory Continuous Deployment Using a Manifest File

Before you begin

Kubernetes manifest file

Manifest sections

metadata.name

spec.spinnakerConfig

spec.spinnakerConfig.profiles

spec.spinnakerConfig.service-settings

spec.spinnakerConfig.files

spec.expose

spec.validation

spec.accounts

Example Manifests for exposing Armory Continuous Deployment

Load balancer Services

Different service types for Deck (UI) and Gate (API)

Different annotations for Deck (UI) and Gate (API)

X509

Help resources

What’s next

Continuous-Deployment: Manage Armory Continuous Deployment using the Operator

Kubernetes tools

Deploy Armory Continuous Deployment

Upgrade Armory Continuous Deployment

Rollback Armory Continuous Deployment

Delete Armory Continuous Deployment

Help resources

What’s next

Continuous-Deployment: Migrate from Halyard to the Operator

Before you begin

Migrate to Operator

Help resources

Continuous-Deployment: Manage Operator

Upgrade the Operator

Uninstall the Operator

Remove Operator ownership of Armory Continuous Deployment resources

Help resources

Continuous-Deployment: Spinnaker Accounts CRD

Experimental

SpinnakerAcount Custom Resource Definition overview

Format

metadata.name

spec.type

spec.enabled

spec.permissions

spec.settings

spec.kubernetes

spec.kubernetes.kubeconfigFile

spec.kubernetes.kubeconfigSecret

spec.kubernetes.kubeconfig

Help resources

Continuous-Deployment: Advanced Operator Configuration

Custom Halyard configuration

Patching Runtime Resources with Kustomize

Choose a `kustomization` file

`SpinnakerAcount` Custom Resource Definition overview

`metadata.name`

`spec.type`

`spec.enabled`

`spec.permissions`

`spec.settings`

`spec.kubernetes`

`spec.kubernetes.kubeconfigFile`

`spec.kubernetes.kubeconfigSecret`

`spec.kubernetes.kubeconfig`

Kustomize `panic` error