Install Operator and Deploy Armory Continuous Deployment Quickstart
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 thanspinnaker-operator
, you need to edit the namespace indeploy/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 bespinnaker-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 withkubectl
v1.19.x. and standalone Kustomize v2 and v3. You may see apanic
error if you use thespinnaker-kustomize-patches
repo with Kustomize v4.0+ orkubectl
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.
Feedback
Was this page helpful?
Thank you for letting us know!
Sorry to hear that. Please tell us how we can improve.
Last modified September 5, 2023: (17d76bcd)