Armory Docs – Install Armory Continuous Deployment for Spinnaker

Continuous-Deployment: System Requirements for Armory Continuous Deployment

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

The requirements described on this page are meant as a minimum starting point for installing Armory Continuous Deployment. You may need to increase the resources based on the number of applications, pipelines, and executions. Work with your IT organization to make sure that the requirements are met.

Installation targets

This section defines where you can run Armory Continuous Deployment, not where you can deploy your applications. For information about where you can deploy applications to, see the Product Compatibility Matrix.

Armory Continuous Deployment can be installed on any certified Kubernetes cluster that meets the following version requirements:

Minimum version: 1.20
Maximum version: 1.25

You install Armory Continuous Deployment using the Armory Operator (a Kubernetes operator), which has the following requirements:

You must be able to apply Kubernetes manifests and CRDs, either directly using kubectl commands from your machine or another method.
By default, the Operator pulls images from a public registry. If you cannot pull images from public registries, see Air-Gapped with the Armory Operator.

Note that Armory does not produce marketplace specific images that can be used by different certified Kubernetes offerings.

The Kubernetes cluster itself must meet the following requirements:

You have administrator rights to install the Custom Resource Definition (CRD) for the Armory Operator.
If you are managing your own Kubernetes cluster (not EKS), 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.

If you do not have a cluster already, consult guides for Amazon EKSor the equivalent for your Kubernetes provider.

Browsers

The UI for Armory Continuous Deployment works best on Firefox or Chromium-based browsers.

External storage

Armory Continuous Deployment requires external storage for storing metadata and history.

Bucket storage

You need an S3-compatible object store, such as an S3 bucket or Minio, for persisting your application settings and pipelines. The account you use to install and run Armory Continuous Deployment needs read/write access to the buckets.

RDBMS (SQL)

Depending on the service, Armory Continuous Deployment also uses either Redis, MySQL, or Postgres as a backing store. The following table lists the supported database and the service:

Database	DB version	Armory	Services	Note
Redis	All supported versions	All supported versions	All Armory Continuous Deployment services that require a backing store	The DB versions refer to external Redis instances. Supported only for services that still require Redis for a feature, such as Gate sessions. Redis is not supported as a core persistent storage engine. Although Armory Continuous Deployment deploys internal Redis instances, do not use these instances for production deployments. Armory recommends only using them for testing and proof-of-concept deployments. For AWS ElastiCache for Redis, the instance type should minimally be set to `cache.m5.large`.
MySQL	5.7; AWS Aurora	All supported versions	Clouddriver, Front50, Orca	For AWS RDS, the instance type should minimally be set to `db.r5`.
PostgreSQL	10+	2.24.0 or later	Clouddriver	For AWS RDS, the instance type should minimally be set to `db.r5`.

Armory recommends using MySQL or PostgreSQL as the backing store when possible for production instances of Armory Continuous Deployment. For other services, use an external Redis instance for production instances of Armory Continuous Deployment.

Hardware requirements

Armory recommends a minimum of 3 nodes that match the following profile:

CPUS: 8
Memory (GiB): 32

kubectl

To install and manage Armory Continuous Deployment, Armory recommends using the Armory Operator with Kustomize and tailoring the Kustomize files to meet the requirements of your instance and environment. This installation method supports the following versions of kubectl: 1.16 to 1.19.

It is possible to use the Operator to install Armory Continuous Deployment without the Kustomize repo. In that case, any actively maintained version of kubectl is supported.

Networking

Pods in your Kubernetes cluster must be able to communicate with each other without restrictions.

Additionally, the ports for the API gateway (the Gate service) and the UI (the Deck service) need to be exposed. All interactions with Armory Continuous Deployment go through these two services.

Gate ports

8084
8085 when secured by x509

Deck port

9000

Security

Armory Continuous Deployment needs to be able to assume roles in the accounts that it deploys applications to. For example, Armory Continuous Deployment needs the sts:AssumeRole permission for AWS. Elevated access (equivalent to the level of PowerUser access in AWS) is helpful so that Armory Continuous Deployment can cache data from deployment target accounts and deploy without errors.

In addition to the security requirements that Armory Continuous Deployment needs to run, Armory recommends securing your installation by using a secret store for sensitive values in your configs as well as configuring authentication and authorization.

Continuous-Deployment: Deploy Armory Continuous Deployment or Spinnaker Using Kubernetes Operators

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

Armory Continuous Deployment (Armory CD) requires a license. For more information, contact Armory.

Important

Armory Operator has been deprecated and will is considered EOL. Please migrate to the Kustomize method of deployment.

What are Kubernetes Operators for Spinnaker?

From the Kubernetes Operator pattern docs: “Operators are software extensions to Kubernetes that make use of custom resources to manage applications and their components.” In other words, an Operator is a Kubernetes controller that manages a specific application using a custom resource. Both the proprietary Armory Operator and the open source Spinnaker Operator for Kubernetes are custom Kubernetes Operators that you can install in your cluster.

The Armory Operator extends the Spinnaker Operator’s features by providing the ability to configure Armory Continuous Deployment’s features, such as Pipelines-as-Code and Policy Engine. The Armory Operator and Armory Continuous Deployment are closed source and not free to use.
The Spinnaker Operator is a Kubernetes controller for deploying and managing Spinnaker. The Spinnaker Operator and Spinnaker are both open source and free to use.

Advantages to using a Kubernetes Operator for Armory Continuous Deployment deployment

Use a Kubernetes manifest to deploy and manage Armory Continuous Deployment or Spinnaker.
Use kubectl to deploy, manage, and access Armory Continuous Deployment or Spinnaker like you would with any other app deployed on Kubernetes.
Store and reference configuration secrets in one of the supported secrets engines.
Store your configuration in git for an auditable and reversible GitOps workflow.

How the Armory Operator and the Spinnaker Operator work

The Operator is a custom controller of Kubernetes kind Deployment. The Operator works with a Kubernetes custom resource named SpinnakerService to deploy and manage Armory Continuous Deployment or Spinnaker in your cluster.

`SpinnakerService` Custom Resource Definition

The SpinnakerService CRD declares the resource’s names, the scope of the resource, and the structural schema of the spinnakerservice.yml Kubernetes manifest that contains your Spinnaker configuration:

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
 name: spinnakerservices.spinnaker.io
spec:
 group: spinnaker.io
 names:
 kind: SpinnakerService
 listKind: SpinnakerServiceList
 plural: spinnakerservices
 shortNames:
 - spinsvc
 singular: spinnakerservice
 scope: Namespaced

You can view the entire SpinnakerService CRD in the public spinnaker-operator repo.

Spinnnaker manifest

You have the following options for creating the Spinnaker manifest:

Create the manifest YAML file yourself using an example spinnakerservice.yml as a starting point.
Create a collection of patch files that Kustomize uses to overwrite sections of the spinnakerservice.yml manifest. Kustomize is part of kubectl.

Regardless of the option you use to configure Spinnaker, the spinnakerservice.yml manifest specifies that the Kubernetes kind is SpinnakerService:

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

You can view the rest of the basic file in the spinnaker-operator repo.

At the highest level, when you use kubectl to apply the manifest:

kubectl parses spinnakerservice.yml and sees that the kind is SpinnakerService.
kubectl delegates manifest validation and deployment to the Operator.
The Operator validates the manifest and uses Halyard to deploy Spinnaker.

The Armory Operator’s SpinnakerService CRD and Armory Continuous Deployment SpinnakerService.yml are slightly different than their open source counterparts so that kubectl knows to delegate to the Armory Operator.

Comparison of the Spinnaker Operator and the Armory Operator

Use the Armory Operator if you want to deploy Armory Continuous Deployment and use its proprietary features.

	Armory Operator	Spinnaker Operator
Deploy open source Spinnaker	❌	✅
Deploy Armory Continuous Deployment for Spinnaker	✅	❌
Use `kubectl` to manage deployment	✅	✅
Validate your configuration before deployment	✅	✅
Use a single `spinnakerservice.yml` configuration file	✅	✅
Use Kustomize patches instead of a single configuration file	✅	✅
Store Spinnaker secrets in Kubernetes secrets	✅	✅
Store your configuration in `git` for an easy GitOps workflow	✅	✅
Define Kubernetes accounts in `SpinnakerAccount` objects and store `kubeconfig` inline, in Kubernetes secrets, in s3, or GCS	✅	✅
Expose via `LoadBalancer` or `Ingress`	✅	❌
Deploy in an Istio-controlled cluster	✅	❌
Configure diagnostics	✅	❌
Configure Pipelines-as-Code	✅	❌
Configure Policy Engine	✅	❌
Configure Terraform integration	✅	❌
Configure Vault secrets	✅	❌
Configure artifacts	✅	✅
Configure canary	✅	✅
Configure continuous integration providers	✅	✅
Configure deployment environment	✅	✅
Configure features	✅	✅
Configure metric stores	✅	✅
Configure notifications	✅	✅
Configure persistent storage	✅	✅
Configure plugins	✅	✅
Configure pub sub	✅	✅
Configure repository artifactory	✅	✅
Configure security	✅	✅
Configure stats	✅	✅
Configure webhooks	✅	✅

What’s next

Continuous-Deployment: Install Spinnaker on Lightweight Kubernetes using Minnaker

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

Install Spinnaker in 10 minutes using Minnaker

Armory Minnaker is an easy to use installation script that leverages the power of Kubernetes with the simplicity of a Virtual Machine. Minnaker makes it easy to install Spinnaker and lets you scale your deployment into a medium to large deployment down the road.

The Kubernetes environment that gets installed on your behalf is based on Rancher’s K3s. You do not need to know how to set up Kubernetes. Minnaker takes care of the hard parts for you, allowing you to get Spinnaker up and running in under 10 minutes.

Watch Spinnaker in 10 minutes or less with Project Minnaker for a demo of using Minnaker to install Spinnaker on cloud platforms as well as VMWare Fusion running locally.

Prerequisites for running Minnaker

Your VM should have 4 vCPUs, 16G of memory and 30G of HDD space.

Getting started

Check out the GitHub project for more information. After you install Minnaker, use the AWS Quick Start to learn how to configure Armory to deploy to AWS.

Continuous-Deployment: Guides for Installing Armory Continuous Deployment for Spinnaker

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

Once installed, Armory Continuous Deployment can deploy to supported providers through Clouddriver regardless of where it is installed.

See Install Armory Continuous Deployment for Spinnaker in Air-Gapped Environments for additional steps you have to take if you have an air-gapped environment.

Continuous-Deployment: Instance Registration

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

Register your instance

Navigate to the URL provided by Armory and follow the instructions to create an account.
Make note of the following information:
- Instance ID
- Client ID
- Secret
This is the only time you are shown the secret value. Store it somewhere safe.

Apply the registration information

In your Operator manifest, configure the following parameters:

spec.spinnakerConfig.profiles.spinnaker.armory.cloud.iam.tokenIssueUrl: set this value to https://auth.cloud.armory.io/oauth/token.
spec.spinnakerConfig.profiles.spinnaker.armory.cloud.iam.clientID: set this value to Client ID that you received from Register your instance.
spec.spinnakerConfig.profiles.spinnaker.”armory.cloud”.iam.clientSecret: set this value to the Secret that you received from Register your instance.

Once you apply the registration information to your instance, your Armory Continuous Deployment instance is registered with Armory.

spec:
 spinnakerConfig:
 profiles:
 gate:
 armory.cloud:
 enabled: true
 iam:
 tokenIssuerUrl: https://auth.cloud.armory.io/oauth/token
 clientId: <clientId>
 clientSecret: <clientSecret>
 api:
 baseUrl: https://api.cloud.armory.io

Save the file and apply the manifest. This redeploys Armory Continuous Deployment.

Troubleshooting

Registration fails

This issue can occur if Operator failed to generate a UUID for your Armory Continuous Deployment instance. You can resolve this issue with one of the following actions:

Deploy Armory Continuous Deployment with a supported Operator version that corresponds to your Armory Continuous Deployment version.
Manually apply a registration ID.

To manually apply a registration ID, perform the following steps:

In your Operator manifest (spinnakerservice.yml by default), check if there is a value for spec.spinnakerConfig.config.armory.diagnostics.uuid.

If there is a value, use that value for the next step.

If there is no value, generate a UUID and add it to spec.spinnakerConfig.config.armory.diagnostics.uuid field.
Add the UUID to the spec.spinnakerConfig.profiles.spinnaker.armory.registrationId field.
Save the file and deploy Armory Continuous Deployment.

If you generated your own UUID, contact Armory Support and provide your UUID so that it can be associated with your organization. This helps with troubleshooting when you contact Support.

Armory Docs – Install Armory Continuous Deployment for Spinnaker

Continuous-Deployment: System Requirements for Armory Continuous Deployment

Installation targets

Browsers

External storage

Bucket storage

RDBMS (SQL)

Hardware requirements

kubectl

Networking

Security

Continuous-Deployment: Deploy Armory Continuous Deployment or Spinnaker Using Kubernetes Operators

Important

What are Kubernetes Operators for Spinnaker?

Advantages to using a Kubernetes Operator for Armory Continuous Deployment deployment

How the Armory Operator and the Spinnaker Operator work

SpinnakerService Custom Resource Definition

Spinnnaker manifest

Comparison of the Spinnaker Operator and the Armory Operator

What’s next

Continuous-Deployment: Install Spinnaker on Lightweight Kubernetes using Minnaker

Install Spinnaker in 10 minutes using Minnaker

Prerequisites for running Minnaker

Getting started

Continuous-Deployment: Guides for Installing Armory Continuous Deployment for Spinnaker

Continuous-Deployment: Instance Registration

Register your instance

Apply the registration information

Troubleshooting

Registration fails

`SpinnakerService` Custom Resource Definition