Install Operator and Deploy Armory Continuous Deployment Quickstart

Install the Operator, create a Kubernetes manifest for Armory Continuous Deployment or Spinnaker, and then deploy using the Operator.

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 Proprietary.

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.

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.

  1. 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'
    
  2. Install or update CRDs across the cluster:

    kubectl apply -f deploy/crds/
    
  3. 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
    
  4. Install the Operator:

    kubectl -n spinnaker-operator apply -f deploy/operator/cluster
    
  5. 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.

  1. Get the latest Operator release:

    Armory Operator for Armory CD Installation Proprietary

    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'
    
  2. Install or update CRDs across the cluster:

    kubectl apply -f deploy/crds/
    
  3. Create the namespace for the Operator:

    In basic mode, the namespace must be spinnaker-operator.

    kubectl create ns spinnaker-operator
    
  4. Install the Operator:

    kubectl -n spinnaker-operator apply -f deploy/operator/basic
    
  5. 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

Proprietary

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.

Proprietary

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
  1. 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.

  2. Deploy from the /spinnaker-operator/deploy/spinnaker/kustomize/ directory:

    kubectl create ns spinnaker
    kubectl -n spinnaker apply -k .
    
  3. You can watch the installation progress by executing:

    kubectl -n spinnaker get spinsvc spinnaker -w
    
  4. You can verify pod status by executing:

    kubectl -n spinnaker get pods
    

Help resources

What’s next


Last modified September 5, 2023: (17d76bcd)