You are viewing version 2.25 of the documentation, which is no longer maintained. For up-to-date documentation, see the latest version.

Install Operator and Deploy Armory Enterprise Quickstart

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

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

Before you begin

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

Ensure you meet the following 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.

  • Your Kubernetes environment meets the following:

    • Minimum version: 1.13; kubectl 1.13.
    • Maximum version: 1.19; kubectl 1.19.4.

    If you do not have a cluster already, consult guides for Amazon EKS.

  • You have administrator rights to install the Custom Resource Definition (CRD) for Operator.

  • If you are managing your own Kubernetes cluster (not EKS or OpenShift), be sure:

    • You have enabled admission controllers in Kubernetes (-enable-admission-plugins).
    • You have ValidatingAdmissionWebhook enabled in kube-apiserver. Alternatively, you can pass the --disable-admission-controller parameter to the to the deployment.yaml file that deploys the Operator.
  • You have created a persistent storage source for Armory Enterprise to use to store app settings and configured pipelines.

    • You can find a list of supported external storage providers for Armory Enterprise in the in the Compatibility Matrix’s External storage section.
    • You can find a list of supported external storage providers for Spinnaker in the open source Spinnaker About External Storage documentation.

Operator installation options

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

Basic Mode Cluster Mode
Must deploy Armory Enterprise in the same namespace as the Operator;
permissions scoped to single namespace; suitable for a Proof of Concept (POC)
Can deploy Armory Enterprise to multiple namespaces
(requires Kubernetes ClusterRole)
Configure Armory Enterprise using a single manifest file
Configure Armory Enterpris eusing 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 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 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

    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/kustomize/role_binding.yaml.

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

    kubectl -n spinnaker-operator apply -f deploy/operator/kustomize
    
  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 Enterprise to the same namespace as the Operator.

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

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

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 Enterprise 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 Enterprise to deploy
      persistentStorage:
        persistentStoreType: s3
        s3:
          bucket: <change-me> # Armory Enterprise stores application and pipeline definitions here. Create an S3 bucket and provide the name here.
          rootFolder: front50
  # spec.expose - This section defines how Armory Enterprise 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 uses Halyard to deploy Armory Enterprise. See Custom Halyard Configuration if you need to modify Halyard so you can use Armory Enterprise features.

Deploy using kubectl:

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

You can watch the installation progress by executing:

kubectl -n spinnaker-operator get spinsvc spinnaker -w

You can verify pod status by executing:

 kubectl -n spinnaker-operator get pods

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

Kustomize patches option

This example assumes you deploy Armory Enterprise 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 Enterprise 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 Enterprise, 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 Enterprise Using Kustomize guide for details.

Proprietary

You can see the list of Armory Enterprise 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 Enterprise to be deployed
      persistentStorage:
        persistentStoreType: s3
        s3:
          bucket: mybucket
          rootFolder: front50

The Armory Operator uses Halyard to deploy Armory Enterprise. See Custom Halyard Configuration if you need to modify Halyard so you can use Armory Enterprise features.

You can see the list of Spinnaker versions on the Spinnaker 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:

    kubctl -n spinnaker-operator apply -k .
    
  3. You can watch the installation progress by executing:

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

    kubectl -n spinnaker-operator get pods
    

Help resources

What’s next

Last modified May 7, 2021: (066ebea)