Armory Docs – Guides for Installing Armory Continuous Deployment for Spinnaker

Continuous-Deployment: Install Armory Continuous Deployment for Spinnaker in Air-Gapped Environments

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

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

Overview of air-gapped environments

An air-gapped deployment environment is one where any combination of the following conditions is true:

Your deployment environment, such as a Kubernetes cluster, doesn’t have internet access AWS S3 bucket and docker.io.

If your deployment environment is air-gapped, you need to host the Armory Continuous Deployment Bill of Materials (BOM) and Docker images in a location that your deployment environment can access. To set this up, you need public internet access so you can get the BOM and images, authority to create or access internal storage and image hosting, and permissions to move the Armory Continuous Deployment materials to your internal systems.

The first step is to familiarize yourself with the Armory Continuous Deployment Bill of Materials.

Before you begin

You have access to public AWS S3 buckets and docker.io.
You have installed the AWS CLI.

Inspect the Armory Continuous Deployment Bill of Materials

Armory Continuous Deployment’s Bill of Materials (BOM) is stored in the public S3 bucket halconfig. You can see the contents of this bucket using the AWS CLI:

aws s3 ls s3://halconfig

There are bom and profiles directories as well as four files: versions-edge.yml, versions-ossedge.yml, version-rc.yml, and versions.yml.

You can view the content of s3://halconfig/versions.yml by executing:

aws s3 cp s3://halconfig/versions.yml -

Output is similar to:

latestHalyard: 1.10.1
latestSpinnaker: 2.25.0
versions:
 - version: 2.25.0
 alias: Spinnaker Release 1.25.3
 changelog: https://docs.armory.io/docs/release-notes/rn-armory-spinnaker/armoryspinnaker_v2-25-0/
 minimumHalyardVersion: 1.10.1
 lastUpdate: "1616710502000"

The bom folder contains files for each release. To see the BOM for a specific release, you can run:

 aws s3 ls s3://halconfig/bom/<release-number>.yml

Then you can inspect the file’s contents. For example, to see the BOM for release 2.25.0:

aws s3 cp s3://halconfig/bom/2.25.0.yml -

Output is similar to:

version: 2.25.0
timestamp: "2021-03-25 09:28:32"
services:
 clouddriver:
 commit: de3aa3f0
 version: 2.25.3
 deck:
 commit: 516bcf0a
 version: 2.25.3
 dinghy:
 commit: 522e67e5
 version: 2.25.1
 echo:
 commit: 3a098acc
 version: 2.25.2
 fiat:
 commit: ca75f0d0
 version: 2.25.3
 front50:
 commit: 502b753e
 version: 2.25.2
 gate:
 commit: "47352833"
 version: 2.25.5
 igor:
 commit: 252dbd5c
 version: 2.25.2
 kayenta:
 commit: "72616529"
 version: 2.25.2
 monitoring-daemon:
 version: 2.25.0
 monitoring-third-party:
 version: 2.25.0
 orca:
 commit: 53f48823
 version: 2.25.2
 rosco:
 commit: 272f4f82
 version: 2.25.2
 terraformer:
 commit: 5dcae243
 version: 2.25.0
dependencies:
 redis:
 version: 2:2.8.4-2
artifactSources:
 dockerRegistry: docker.io/armory

What’s next

Follow the instructions for your deployment method: Air-Gapped with the Armory Operator.

Continuous-Deployment: Install Armory Continuous Deployment from the AWS Container Marketplace

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

Note

This document is intended for users who have purchased Armory’s AWS Container Marketplace offering. It will not work if you have not subscribed to the Armory Container Marketplace offering.

Please contact Armory if you’re interested in an AWS Marketplace Private Offer.

Overview of the Armory Operator

The Armory Operator is a Kubernetes Operator for Spinnaker^TM that makes it easier to install, deploy, and upgrade Spinnaker or Armory. The AWS Container Marketplace offering for Armory installs a version of the Armory Operator in an EKS cluster. After that, Armory can be installed in any namespace in your EKS cluster; this document assumes that Armory will be installed in the spinnaker namespace.

AWS Resources

Before you install Armory on AWS, it is essential that you familiarize yourself with relevant AWS services.

Prerequisites for using the Armory Operator

To use the Marketplace’s Armory offering, make sure you meet the following requirements:

You have reviewed and met the Armory Continuous Deployment system requirements.
You have access to an EKS cluster configured with IAM roles for service accounts.
You have an ingress controller for your EKS cluster. This document assumes the EKS cluster is using the NGINX Ingress Controller.
You have cluster-admin access on the EKS cluster.
You have An AWS S3 bucket to store Armory application and pipeline configuration.

Installation summary

This document covers the following high-level steps:

Creating and configuring the necessary AWS IAM roles for your Kubernetes cluster
Installing the Armory Operator Custom Resource Definitions (CRDs) for Armory into your Kubernetes cluster
Installing the Armory Operator
Creating a SpinnakerService Custom Resource
Exposing your Armory instance

Create an AWS bucket

If you do not already have an AWS S3 bucket, create one with these settings:

Versioning turned on (“Keep all versions of an object in the same bucket”)
Default encryption turned on
All public access blocked

Create and configure the AWS IAM roles for your Kubernetes cluster

AWS IAM permissions are granted to Armory through the use of AWS’s IAM roles for Kubernetes Service Accounts. This feature must be enabled at a cluster level. You need to create three IAM roles:

An IAM role for the Armory Operator (spinnaker-operator ServiceAccount in spinnaker-operator namespace) that has these permissions:
- aws-marketplace:RegisterUsage
- s3:* on your AWS Bucket
An IAM role for the Front50 service (front50 ServiceAccount in the spinnaker namespace), that has these permissions:
- s3:* on your AWS Bucket
An IAM role for the Clouddriver service (clouddriver ServiceAccount in the spinnaker namespace). This IAM role does not require any explicit permissions. If you want Armory to deploy AWS resources (AWS EC2, AWS ECS, AWS Lambda, or other AWS EKS clusters), you can add these permissions later.
- AWS permissions are not needed to deploy to the EKS cluster where Spinnaker is installed.

Upon completion of this section, you should have these three IAM roles:

arn:aws:iam::AWS_ACCOUNT_ID:role/eks-spinnaker-operator granted to the Kubernetes Service Account system:serviceaccount:spinnaker-operator:spinnaker-operator
arn:aws:iam::AWS_ACCOUNT_ID:role/eks-spinnaker-front50 granted to the Kubernetes Service Account system:serviceaccount:spinnaker:front50
arn:aws:iam::AWS_ACCOUNT_ID:role/eks-spinnaker-clouddriver granted to the Kubernetes Service Account system:serviceaccount:spinnaker:clouddriver

IAM role for Armory Operator Pod

Create an IAM role for the Armory Operator pod (call it eks-spinnaker-operator) and configure it for use by EC2. You will replace the trust relationship later.

Grant the role the AWS managed policy AWSMarketplaceMeteringRegisterUsage.

Grant the role an inline policy granting permissions on your S3 bucket (replace BUCKET_NAME with the name of your bucket):

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": "s3:*",
 "Resource": [
 "arn:aws:s3:::BUCKET_NAME",
 "arn:aws:s3:::BUCKET_NAME/*"
 ]
 }
 ]
}

For example:

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": "s3:*",
 "Resource": [
 "arn:aws:s3:::my-spinnaker-bucket",
 "arn:aws:s3:::my-spinnaker-bucket/*"
 ]
 }
 ]
}

Create this trust relationship on the IAM role, with these fields replaced:

replace AWS_ACCOUNT_ID with your AWS account ID
replace OIDC_PROVIDER with the “OpenID Connect provider URL” for your Kubernetes cluster (with the https:// removed)

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Principal": {
 "Federated": "arn:aws:iam::AWS_ACCOUNT_ID:oidc-provider/OIDC_PROVIDER"
 },
 "Action": "sts:AssumeRoleWithWebIdentity",
 "Condition": {
 "StringEquals": {
 "OIDC_PROVIDER:sub": "system:serviceaccount:spinnaker-operator:spinnaker-operator"
 }
 }
 }
 ]
}

For example:

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Principal": {
 "Federated": "arn:aws:iam::111222333444:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/AAAABBBBCCCCDDDDEEEEFFFF00001111"
 },
 "Action": "sts:AssumeRoleWithWebIdentity",
 "Condition": {
 "StringEquals": {
 "oidc.eks.us-east-1.amazonaws.com/id/AAAABBBBCCCCDDDDEEEEFFFF00001111:sub": "system:serviceaccount:spinnaker-operator:spinnaker-operator"
 }
 }
 }
 ]
}

IAM role for Front50 Pod

Create an IAM role for the Armory Operator pod (call it eks-spinnaker-front50) and configure it for use by EC2. You will replace the trust relationship later.

Grant the role an inline policy granting permissions on your S3 bucket (replace BUCKET_NAME with the name of your bucket):

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": "s3:*",
 "Resource": [
 "arn:aws:s3:::BUCKET_NAME",
 "arn:aws:s3:::BUCKET_NAME/*"
 ]
 }
 ]
}

For example:

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": "s3:*",
 "Resource": [
 "arn:aws:s3:::my-spinnaker-bucket",
 "arn:aws:s3:::my-spinnaker-bucket/*"
 ]
 }
 ]
}

Create this trust relationship on the IAM role, with these fields replaced:

Replace AWS_ACCOUNT_ID with your AWS account ID
Replace OIDC_PROVIDER with the “OpenID Connect provider URL” for your Kubernetes cluster (with the https:// removed)

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Principal": {
 "Federated": "arn:aws:iam::AWS_ACCOUNT_ID:oidc-provider/OIDC_PROVIDER"
 },
 "Action": "sts:AssumeRoleWithWebIdentity",
 "Condition": {
 "StringEquals": {
 "OIDC_PROVIDER:sub": "system:serviceaccount:spinnaker:front50"
 }
 }
 }
 ]
}

For example:

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Principal": {
 "Federated": "arn:aws:iam::111222333444:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/AAAABBBBCCCCDDDDEEEEFFFF00001111"
 },
 "Action": "sts:AssumeRoleWithWebIdentity",
 "Condition": {
 "StringEquals": {
 "oidc.eks.us-east-1.amazonaws.com/id/AAAABBBBCCCCDDDDEEEEFFFF00001111:sub": "system:serviceaccount:spinnaker:front50"
 }
 }
 }
 ]
}

IAM role for Clouddriver pod

Create an IAM role for the Armory Operator pod (call it eks-spinnaker-clouddriver) and configure it for use by EC2. You will replace the trust relationship later. It does not need explicit AWS permissions.

Create this trust relationship on the IAM role, with these fields replaced:

Replace AWS_ACCOUNT_ID with your AWS account ID
Replace OIDC_PROVIDER with the “OpenID Connect provider URL” for your Kubernetes cluster (with the https:// removed)

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Principal": {
 "Federated": "arn:aws:iam::AWS_ACCOUNT_ID:oidc-provider/OIDC_PROVIDER"
 },
 "Action": "sts:AssumeRoleWithWebIdentity",
 "Condition": {
 "StringEquals": {
 "OIDC_PROVIDER:sub": "system:serviceaccount:spinnaker:clouddriver"
 }
 }
 }
 ]
}

For example:

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Principal": {
 "Federated": "arn:aws:iam::111222333444:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/AAAABBBBCCCCDDDDEEEEFFFF00001111"
 },
 "Action": "sts:AssumeRoleWithWebIdentity",
 "Condition": {
 "StringEquals": {
 "oidc.eks.us-east-1.amazonaws.com/id/AAAABBBBCCCCDDDDEEEEFFFF00001111:sub": "system:serviceaccount:spinnaker:clouddriver"
 }
 }
 }
 ]
}

Install the Armory Operator Custom Resource Definitions (CRDs)

Download the Kubernetes manifest for Armory Operator and install it into your Kubernetes cluster:

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

# Install or update CRDs cluster wide
kubectl apply -f manifests/crds/

Install the Armory Operator

Update the manifest for the Armory Operator with your AWS Account ID:

You must update AWS_ACCOUNT_ID (in the ServiceAccount annotation) with your account ID, so the ServiceAccount can access your AWS IAM roles.

export AWS_ACCOUNT_ID=111122223333

sed -i.bak "s|AWS_ACCOUNT_ID|${AWS_ACCOUNT_ID}|g" manifests/operator/ServiceAccount.yaml
rm manifests/operator/ServiceAccount.yaml.bak

# Install the armory operator
kubectl apply -f manifests/operator

Deploying the Armory Operator may take a little bit of time. You can monitor its status by running this command:

kubectl -n spinnaker-operator get pod -owide

You’re looking for the deployment to be completely up (READY of 2/2 and STATUS of Running).

Creating a SpinnakerService Custom Resource

Update the manifest for the SpinnakerService object with these:

AWS_ACCOUNT_ID (in both ServiceAccount annotations) - your account ID, so the ServiceAccount can access your AWS IAM roles
BUCKET_NAME (in the SpinnakerService) - the name of your AWS S3 Bucket

export AWS_ACCOUNT_ID=111122223333
export BUCKET_NAME=my-spinnaker-bucket

sed -i.bak "s|AWS_ACCOUNT_ID|${AWS_ACCOUNT_ID}|g" manifests/spinnaker/ServiceAccount-clouddriver.yaml
sed -i.bak "s|AWS_ACCOUNT_ID|${AWS_ACCOUNT_ID}|g" manifests/spinnaker/ServiceAccount-front50.yaml
rm manifests/spinnaker/ServiceAccount-clouddriver.yaml.bak
rm manifests/spinnaker/ServiceAccount-front50.yaml.bak

sed -i.bak "s|BUCKET_NAME|${BUCKET_NAME}|g" manifests/spinnaker/SpinnakerService.yaml
rm manifests/spinnaker/SpinnakerService.yaml.bak

# Install the operator
kubectl apply -f manifests/spinnaker

If everything is configured properly, the Armory Operator should see the SpinnakerService custom resource, and start creating Kubernetes Deployments, ServiceAccounts, and Secrets in the spinnaker Namespace. You can monitor this with the following:

kubectl -n spinnaker get all -owide

Exposing your Armory instance

Once your Armory instance is running, you need to configure it so that it is accessible. There are two main parts to this:

Expose the spin-deck and spin-gate services so that they can be reached by your end users (and client services)
Configure Armory so that it knows about the endpoints it is exposed on

Given a domain name (or IP address) (such as spinnaker.domain.com or 55.55.55.55), you should be able to:

Reach the spin-deck service at the root of the domain (http://spinnaker.domain.com or http://55.55.55.55)
Reach the spin-gate service at the root of the domain (http://spinnaker.domain.com/api/v1 or http://55.55.55.55/api/v1)

You can use either http or https, as long as you use the same for both. Additionally, you have to configure Armory to be aware of its endpoints.

This section assumes the following:

You have installed the NGINX Ingress Controller in the EKS cluster
You can set up a DNS CNAME Record pointing at the AWS Load Balancer in front of your NGINX Ingress Controller

Set up an Ingress for `spin-deck` and `spin-gate`

First, determine a DNS name that you can use for Armory, and set up a CNAME pointing that DNS name at your AWS Load Balancer. For example:

NGINX Ingress Controller has created an NLB at abcd1234abcd1234abcd1234abcd1234-1234567812345678.elb.us-east-1.amazonaws.com
Desired domain name for Armory is spinnaker.domain.com
Create a CNAME DNS Record pointing spinnaker.domain.com at abcd1234abcd1234abcd1234abcd1234-1234567812345678.elb.us-east-1.amazonaws.com (you may also use an ALIAS Record in Route 53)

Then, create a Kubernetes Ingress to expose spin-deck and spin-gate. Create a file called spin-ingress.yml with the following content:

---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
 name: spin-ingress
 namespace: spinnaker
 labels:
 app: spin
 cluster: spin-ingress
 annotations:
 kubernetes.io/ingress.class: "nginx"
spec:
 rules:
 -
 host: spinnaker.domain.com # Make sure to update this field
 http:
 paths:
 - backend:
 serviceName: spin-deck
 servicePort: 9000
 path: /
 - backend:
 serviceName: spin-gate
 servicePort: 8084
 path: /api/v1

Make sure the host field is updated with the correct DNS record.

Apply the ingress file you just created:

kubectl -n spinnaker apply -f spin-ingress.yml

Configure Armory to be aware of its endpoints

Update the spec.spinnakerConfig.config.security section of manifests/spinnaker/SpinnakerService.yaml:

spec:
 spinnakerConfig:
 config:
 # ... more configuration
 security:
 uiSecurity:
 overrideBaseUrl: http://spinnaker.domain.com # Replace this with the IP address or DNS that points to our nginx ingress instance
 apiSecurity:
 overrideBaseUrl: http://spinnaker.domain.com/api/v1 # Replace this with the IP address or DNS that points to our nginx ingress instance
 # ... more configuration

Make sure to specify http or https according to your environment

Apply the changes:

kubectl apply -f manifests/spinnaker/SpinnakerService.yaml

If you encounter an error, delete and recreate the SpinnakerService.

Configure TLS certificates

Configuring TLS certificates for ingresses is environment-specific. In general, you want to do the following:

Add certificate(s) so that our ingress controller can use them
Configure the ingress(es) so that NGINX (or the load balancer in front of NGINX, or your alternative ingress controller) terminates TLS using the certificate(s)
Update Spinnaker to be aware of the new TLS endpoints, by replacing http by https to override the base URLs in the previous section.

Next steps

Now that Armory is running, here are potential next steps:

Configure certificates to secure our cluster (see this section for notes on this)
Configure authentication/authorization (see the Open Source Spinnaker documentation)
Add external Kubernetes accounts to deploy applications to (see Creating and Adding a Kubernetes Account to Spinnaker (Deployment Target))
Add AWS accounts to deploy applications to (see the Open Source Spinnaker documentation)

Continuous-Deployment: Install Armory Continuous Deployment in Amazon Web Services (AWS)

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

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

Overview of installing Armory in AWS

A running AWS EKS cluster.
An Amazon S3 (Simple Storage Service) bucket. You can use an existing one or create a new one.
An NGINX Ingress controller in your EKS cluster.

This document currently does not fully cover the following (see Next Steps for some links to achieve these)

TLS Encryption
Authentication/Authorization
Add K8s accounts to deploy to
Add cloud accounts to deploy to

AWS Resources

Before you install Armory on AWS, it is essential that you familiarize yourself with relevant AWS services.

Before you begin

You have reviewed and met the Armory Continuous Deployment system requirements.
You have a running EKS and can access the Kubernetes API. Either your user/role created the EKS cluster or your user/role has been added to the aws-auth configmap in the EKS cluster. See the AWS documentation for more details.
You have access to an S3 bucket or access to create an S3 bucket.
You have access to an IAM role or user with access to the S3 bucket or can create an IAM role or user with access to the S3 bucket.

This document is written with the following workflow in mind:

You have a machine (referred to as the workstation machine in this document) configured to use the aws CLI tool and a recent version of kubectl tool
You have a machine (referred to as the Halyard machine in this document) with the Docker daemon installed, and can run Docker containers on it
You can transfer files created on the workstation machine to the Halyard machine (to a directory mounted on a running Docker container)
These two machines can be the same machine

Furthermore:

On the Halyard machine:

Halyard (the tool used to install and manage Armory) is run in a Docker container on the Halyard machine
The Halyard container on the Halyard machine will be configured with the following volume mounts, which should be persisted or preserved to manage your Armory cluster
- .hal directory (mounted to /home/spinnaker/.hal) - stores all Halyard Armory configurations in a .hal/config YAML file and assorted subdirectories
- .secret directory (mounted to /home/spinnaker/.secret) stores all external secret keys and files used by Halyard
- resources directory (mounted to /home/spinnaker/resources) stores all Kubernetes manifests and other resources that help create Kubernetes resources
You will create kubeconfig files that will be added to the .secret directory

Note: If you are not using the Halyard Docker container, but sure to install kubectl before you install Halyard. Otherwise you will have to restart the Halyard daemon in order for hal to find kubectl in your $PATH. Execute hal shutdown and then any hal command to start the daemon.

On the workstation machine:

If using EKS, you can use the aws CLI tool to interact with the AWS API and configure/communicate with the following:
- EKS clusters (or, alternately, have a EKS cluster already built)
- S3 buckets (or, alternately, have an S3 bucket already built)
You have the kubectl (Kubernetes CLI tool) installed and are able to use it to interact with your Kubernetes cluster
You have a persistent working directory in which to work in. One option here is ~/aws-spinnaker
You will create AWS resources, such as service accounts, that will be permanently associated with your Armory cluster

Installation summary

In order to install Armory, this document covers the following:

Generating a kubeconfig file, which is a Kubernetes credential file that Halyard and Armory will use to communicate with the Kubernetes cluster where Armory will be installed
Creating an S3 bucket for Armory to store persistent configuration in
Creating an IAM user that Armory will use to access the S3 bucket
Running the Halyard daemon in a Docker container
- Persistent configuration directories from the workstation/host will be mounted into the container
Running the hal client interactively in the same Docker container, to:
- Build out the halconfig YAML file (.hal/config)
- Configure Armory/Halyard to use kubeconfig to install Armory
- Configure Armory with the IAM credentials and bucket information
- Turn on other recommended settings (artifacts and http artifact provider)
- Install Armory
- Expose Armory

Connect to the Kubernetes cluster

Armory needs a credential to talk to Kubernetes, so you must create a service account in your Kubernetes cluster.

Connecting to an EKS cluster

If you’re using an EKS cluster, you must be able to connect to the EKS cluster. This assumes you have already configured the aws CLI with credentials and a default region / availability zone (see installation directions here and configuration directions here)

Create the local working directory on your workstation. For the purposes of this document, we will be using ~/aws-spinnaker, but this can be any persistent directory on any Linux or OSX machine.
```
mkdir ~/aws-spinnaker
cd ~/aws-spinnaker
```
If you have access to the role that created the EKS cluster, you can create a kubeconfig with access to your Kubernetes cluster with this command:
```
aws eks update-kubeconfig --name <EKS_CLUSTER_NAME> --kubeconfig kubeconfig-aws
```
From here, you can validate access to the cluster with this command:
```
kubectl --kubeconfig kubeconfig-aws get namespaces
```

Connecting to other Kubernetes clusters

If you’ve stood up Kubernetes on AWS with KOPS or another Kubernetes tool, ensure that you can communicate with your Kubernetes cluster with kubectl.

Then, copy your kubeconfig file (this is typically located in ~/.kube/config) to your working directory:

cp ~/.kube/config ~/aws-spinnaker/kubeconfig-aws

Create a `kubeconfig` file for Halyard/Armory

Armory will be installed in its own namespace in your EKS or AWS-hosted Kubernetes cluster. For the purposes of this document, we will be installing Armory in the spinnaker-system namespace; you’re welcome to use a different namespace for this.

We’re going to create the following:

A namespace called spinnaker-system to install Armory in
A service account for that namespace
A role and rolebinding in that namespace, granting permissions to the service account
A kubeconfig containing credentials for the service account

This document uses the Armory spinnaker-tools Go CLI (available on Github) to create many of these resources. There are separate instructions to perform these steps manually.

Halyard uses this Kubeconfig file to create the Kubernetes deployment objects that create the microservices that compose Armory. This same Kubeconfig is passed to Armory so that Armory can see and manage its own resources.

Obtain the spinnaker-tools CLI tool. Go to https://github.com/armory/spinnaker-tools/releases, and download the latest release for your operating system (OSX and Linux available). You can also use curl:

# If you're not already in the directory
cd ~/aws-spinnaker
# If you're on Linux instead of OSX, use this URL instead:
# https://github.com/armory/spinnaker-tools/releases/download/0.0.6/spinnaker-tools-linux
curl -L https://github.com/armory/spinnaker-tools/releases/download/0.0.6/spinnaker-tools-darwin -o spinnaker-tools
chmod +x spinnaker-tools

Run the tool. Feel free to substitute other values for the parameters:

# The 'aws eks update-kubeconfig' command from above will create/update this file
SOURCE_KUBECONFIG=kubeconfig-aws
# Get the name of the context created by the aws tool)
CONTEXT=$(kubectl --kubeconfig ${SOURCE_KUBECONFIG} config current-context)
DEST_KUBECONFIG=kubeconfig-spinnaker-system-sa
SPINNAKER_NAMESPACE=spinnaker-system
SPINNAKER_SERVICE_ACCOUNT_NAME=spinnaker-service-account

./spinnaker-tools create-service-account \
 --kubeconfig ${SOURCE_KUBECONFIG} \
 --context ${CONTEXT} \
 --output ${DEST_KUBECONFIG} \
 --namespace ${SPINNAKER_NAMESPACE} \
 --service-account-name ${SPINNAKER_SERVICE_ACCOUNT_NAME}

You should be left with a file called kubeconfig-spinnaker-system-sa (or something similar, if you’re using a different namespace for spinnaker)

Create the S3 bucket and credentials

If you do not yet have an S3 bucket, create the S3 bucket:

Log into the AWS Console (web UI)
Navigate to the S3 Console (Click on “Services” at the top, and then on “S3” under “Storage”)
Click on “Create Bucket”
Specify a globally unique name for this bucket, in your AWS region of choice, following your organization’s naming convention (if applicable). For this document, we will use, spinnaker-jq6cqvmpro.
Click “Next”
Select the following two checkboxes:
- Keep all versions of an object in the same bucket
- Automatically encrypt objects when they are stored in S3
Click “Next”
Do not add any additional permissions, unless specified by your organization. Click “Next”
Click “Create bucket”

Armory (the front50 service, specifically) will need access to your newly-created bucket. There are a number of ways to achieve this. This document describes two mechanisms to do this.

By default, Armory will store all Armory information in a folder called front50 in your bucket. You can optionally specify a different directory (for example, if you’re using a pre-existing or shared S3 bucket).

Create an IAM user using an inline policy

You can create an IAM user with credentials, and provide that to Armory via Halyard

Log into the AWS Console (Web UI)
Navigate to the IAM Console (Click on “Services” at the top, and then on “IAM” under “Security, Identity, & Compliance”)
Click on “Users” on the left
Click on “Add user”
Give your user a distinct name, per your organization’s naming conventions. For this document, we will use s3-spinnaker-jq6cqvmpro
Click on “Programmatic access”
We will not be adding a distinct policy to this user. Click on “Next: Tags”. You may receive a warning about how there are no policies attached to this user - this warning can be ignored.
Optionally, add tags, then click on “Next: Review”
Click “Create user”
Save the Access Key ID and Secret Access Key - these will be used later, during Halyard configuration
Click “Close”

Then, add an inline policy to your IAM user:

Click on your newly-created IAM user
Click on “Add inline policy” (on the right)
Click on the “JSON” tab

Add this text (replace s3-spinnaker-jq6cqvmpro with the name of your bucket)

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": "s3:*",
 "Resource": [
 "arn:aws:s3:::spinnaker-jq6cqvmpro",
 "arn:aws:s3:::spinnaker-jq6cqvmpro/*"
 ]
 }
 ]
}

Click on “Review Policy”
Give your inline policy some name. For example s3-spinnaker-jq6cqvmpro
Click “Create Policy”

Create an IAM policy attached to the Kubernetes nodes using an inline policy

Alternately, you can attach an IAM policy to the role attached to your Kubernetes nodes.

Log into the AWS Console (Web UI)
Navigate to EC2 (Click on “Services” at the top, and then on “EC2” under “Compute”)
Click on one of your Kubernetes nodes
In the bottom section, look for “IAM role” and click on the role
Click on “Add inline policy” (on the right)
Click on the “JSON” tab

Add this text (replace s3-spinnaker-jq6cqvmpro with the name of your bucket)

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": "s3:*",
 "Resource": [
 "arn:aws:s3:::spinnaker-jq6cqvmpro",
 "arn:aws:s3:::spinnaker-jq6cqvmpro/*"
 ]
 }
 ]
}

Click on “Review Policy”
Give your inline policy some name. For example s3-spinnaker-jq6cqvmpro
Click “Create Policy”

Stage files on the Halyard machine

On the Halyard machine, choose a local working directory for Halyard. In it, we will create two folders:

WORKING_DIRECTORY/.hal
WORKING_DIRECTORY/.secret
WORKING_DIRECTORY/resources

# Feel free to use some other directory for this; make sure it is a persistent directory.
# Also, make sure this directory doesn't live on an NFS mount, as that can cause issues
WORKING_DIRECTORY=~/aws-spinnaker/
mkdir -p ${WORKING_DIRECTORY}/.hal
mkdir -p ${WORKING_DIRECTORY}/.secret
mkdir -p ${WORKING_DIRECTORY}/resources

You should have one files:

A kubeconfig file (kubeconfig-spinnaker-system-sa) with the credentials for a service account in your EKS cluster

Copy it into .secret so it is available to your Halyard docker container:

cp kubeconfig-spinnaker-system-sa ${WORKING_DIRECTORY}/.secret

Start the Halyard container

On the Halyard machine, start the Halyard container .

If you want to install open source Spinnaker instead, use gcr.io/spinnaker-marketplace/halyard:stable for the Docker Halyard image reference in substitution of armory/halyard-armory:<image_version> in the commands below

Before you execute the command below, you need to set permissions on the host (local) directories mapped to the Docker container. These directories must allow for modification from within the container. The ~/.hal folder within the host (local) system directory needs write permissions (chmod 777 ~/.hal), or you will encounter issues when attempting to execute a hal deploy apply from within the container.

docker run --name armory-halyard -it --rm \
 -v ${WORKING_DIRECTORY}/.hal:/home/spinnaker/.hal \
 -v ${WORKING_DIRECTORY}/.secret:/home/spinnaker/.secret \
 -v ${WORKING_DIRECTORY}/resources:/home/spinnaker/resources \
 armory/halyard-armory:1.12.1

The installer expects to find your kubeconfig named config in the .kube directory you map below. If you’ve named your config something else, you need to rename or symlink the file accordingly.

Enter the Halyard container

From a separate terminal session on your docker machine, create a second bash/shell session on the Docker container:

docker exec -it armory-halyard bash

# Also, once in the container, you can run these commands for a friendlier environment to:
# - prompt with information
# - alias for ls
# - cd to the home directory
export PS1="\h:\w \u\$ "
alias ll='ls -alh'
cd ~

Add the kubeconfig and cloud provider to Armory (via Halyard)

From the docker exec separate terminal session, add (re-export) the relevant environment variables

###### Use the same values as the start of the document
# Enter the namespace that you want to install Armory in. This should have been created in the previous step.
export NAMESPACE="spinnaker-system"

# Enter the name you want Armory to use to identify the cloud provider account
export ACCOUNT_NAME="spinnaker"

# Update this with the full path to your kubeconfig inside the container)
export KUBECONFIG_FULL=/home/spinnaker/.secret/kubeconfig-spinnaker-system-sa

Use the Halyard hal command line tool to add a Kubernetes account using your minified kubeconfig

Configure the kubeconfig:

# Enable the Kubernetes cloud provider
hal config provider kubernetes enable

Note: If you get an AccessDenied error, change permissions on the host machine’s .hal folder to allow read/write access by the Halyard container. Example: chmod 777 ~/.hal.

Next, configure the account:

# Add account
hal config provider kubernetes account add ${ACCOUNT_NAME} \
 --provider-version v2 \
 --kubeconfig-file ${KUBECONFIG_FULL} \
 --only-spinnaker-managed true \
 --namespaces ${NAMESPACE}

Configure Armory to install in Kubernetes

Important: This will by default limit your Armory to deploying to the namespace specified. If you want to be able to deploy to other namespaces, either add a second cloud provider target or remove the --namespaces flag.

Use the Halyard hal command line tool to configure Halyard to install Armory in your Kubernetes cluster

hal config deploy edit \
 --type distributed \
 --account-name ${ACCOUNT_NAME} \
 --location ${NAMESPACE}

Enable Artifacts

Within Armory, ‘artifacts’ are consumable references to items that live outside of Armory, such as a file in a git repository or a file in an S3 bucket. The Artifacts feature must be explicitly turned on.

Enable the “Artifacts” feature and the “http” artifact provider:

# Enable artifacts
hal config features edit --artifacts true
hal config artifact http enable

(In order to add specific types of artifacts, there are further configuration items that must be completed. For now, it is sufficient to just turn on the artifacts feature with the http artifact provider. This will allow Armory to retrieve files via unauthenticated http.)

Configure Armory to use your S3 bucket

Use the Halyard hal command line tool to configure Halyard to configure Armory to use your S3 bucket

If you are using an IAM user

# Update these with the information from the bucket that you created
export BUCKET_NAME=spinnaker-jq6cqvmpro
export REGION=us-west-2
export ACCESS_KEY_ID=<access-key>

# This will prompt for the secret key
hal config storage s3 edit \
 --bucket ${BUCKET_NAME} \
 --access-key-id ${ACCESS_KEY_ID} \
 --secret-access-key \
 --region ${REGION}

hal config storage edit --type s3

If you are using the IAM instance roles

# Update these with the information from the bucket that you created
export BUCKET_NAME=spinnaker-jq6cqvmpro
export REGION=us-west-2

# This will prompt for the secret key
hal config storage s3 edit \
 --bucket ${BUCKET_NAME} \
 --region ${REGION} \
 --no-validate

hal config storage edit --type s3

If you want to use a specific folder in the bucket

By default, Halyard will configure Armory to use the folder front50 in your S3 bucket. You can configure it to use a different folder with this command:

ROOT_FOLDER=not_front50
hal config storage s3 edit --root-folder ${ROOT_FOLDER}

Choose the Armory version

Before Halyard will install Armory, you should specify the version of Armory you want to use.

You can get a list of available versions of spinnaker with this command:

hal version list

If you are installing Armory, you will get a version that starts with 2.x.x

If you are installing open source Spinnaker and using gcr.io/spinnaker-marketplace/halyard:stable, you will get a version that starts with 1.x.x

And then you can select the version with this:

# Replace with version of choice:
export VERSION=$(hal version latest -q)
hal config version edit --version $VERSION

Install Armory

Now that your Halconfig is completely configured for the initial Armory deployment, you can tell Halyard to actually install Armory:

hal deploy apply

Once this is complete, congratulations! Armory Continuous Deployment is installed. Now, we have to access and expose it.

Connect to Armory Continuous Deployment using `kubectl port-forward`

If you have kubectl on a local machine with access to your Kubernetes cluster, you can test connecting to it with the following:

NAMESPACE=spinnaker-system
DECK_POD=$(kubectl -n ${NAMESPACE} get pod -l cluster=spin-deck -ojsonpath='{.items[0].metadata.name}')
GATE_POD=$(kubectl -n ${NAMESPACE} get pod -l cluster=spin-gate -ojsonpath='{.items[0].metadata.name}')
kubectl -n ${NAMESPACE} port-forward ${DECK_POD} 9000 &
kubectl -n ${NAMESPACE} port-forward ${GATE_POD} 8084 &

Then, you can access Armory at http://localhost:9000

(If you are doing this on a remote machine, this will not work because your browser attempts to access localhost on your local workstation rather than on the remote machine where the port is forwarded)

Note: Even if the hal deploy apply command returns successfully, the installation may not be complete yet. This is especially the case with distributed Kubernetes installs. If you see errors such as Connection refused, the containers may not be available yet. You can either wait or check the status of all of the containers using the command for your cloud provider (such as kubectl get pods --namespace spinnaker).

Install the NGINX ingress controller

In order to expose Armory to end users, you have perform the following actions:

Expose the spin-deck (UI) Kubernetes service on some URL endpoint
Expose the spin-gate (API) Kubernetes service on some URL endpoint
Update Armory (via Halyard) to be aware of the new endpoints

We’re going to install the NGINX ingress controller on AWS (this uses the Layer 4 ELB, as indicated in the NGINX ingress controller documentation - you can use other NGINX ingress controller configurations such as the Layer 7 load balancer per your organization’s ingress policy.)

(Both of these are configurable with Armory, but the NGINX ingress controller is also generally much more configurable)

From the workstation machine (where kubectl is installed):

Install the NGINX ingress controller components:

kubectl --kubeconfig kubeconfig-aws apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/provider/aws/deploy.yaml

Install the NGINX ingress controller AWS-specific service:

kubectl --kubeconfig kubeconfig-aws apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/provider/aws/service-l4.yaml
kubectl --kubeconfig kubeconfig-aws apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/provider/aws/patch-configmap-l4.yaml

Set up the Ingress for `spin-deck` and `spin-gate`

Identify the URLs you will use to expose Armory’s UI and API.

# Replace with actual values
SPIN_DECK_ENDPOINT=spinnaker.some-url.com
SPIN_GATE_ENDPOINT=api.some-url.com
NAMESPACE=spinnaker-system

Create a Kubernetes Ingress manifest to expose spin-deck and spin-gate (change your hosts and namespace accordingly):

tee spin-ingress.yaml <<-'EOF'
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
 name: spinnaker-nginx-ingress
 namespace: NAMESPACE
 labels:
 app: spin
 cluster: spin-ingress
 annotations:
 kubernetes.io/ingress.class: "nginx"
spec:
 rules:
 - host: SPIN_DECK_ENDPOINT
 http:
 paths:
 - backend:
 serviceName: spin-deck
 servicePort: 9000
 path: /
 - host: SPIN_GATE_ENDPOINT
 http:
 paths:
 - backend:
 serviceName: spin-gate
 servicePort: 8084
 path: /
EOF

sed -i.bak \
 -e "s|NAMESPACE|${NAMESPACE}|g" \
 -e "s|SPIN_DECK_ENDPOINT|${SPIN_DECK_ENDPOINT}|g" \
 -e "s|SPIN_GATE_ENDPOINT|${SPIN_GATE_ENDPOINT}|g" \
 spin-ingress.yaml

Create the Ingress

kubectl apply -f spin-ingress.yaml

Configure Armory to be aware of its endpoints

Armory must be aware of its endpoints to work properly.

This should be done from the halyard container:

SPIN_DECK_ENDPOINT=spinnaker.some-url.com
SPIN_GATE_ENDPOINT=api.some-url.com
SPIN_DECK_URL=http://${SPIN_DECK_ENDPOINT}
SPIN_GATE_URL=http://${SPIN_GATE_ENDPOINT}

hal config security ui edit --override-base-url ${SPIN_DECK_URL}
hal config security api edit --override-base-url ${SPIN_GATE_URL}

hal deploy apply

Set up DNS

Once the ingress is up (this may take some time), you can get the IP address for the ingress:

$ kubectl describe -n spinnaker-system ingress spinnaker-nginx-ingress
Name: spinnaker-nginx-ingress
Namespace: spinnaker-system
Address: 35.233.216.189
Default backend: default-http-backend:80 (10.36.2.7:8080)
Rules:
 Host Path Backends
 ---- ---- --------
 spinnaker.some-url.com
 / spin-deck:9000 (<none>)
 api.some-url.com
 / spin-gate:8084 (<none>)
Annotations:
 kubectl.kubernetes.io/last-applied-configuration: {"apiVersion":"extensions/v1beta1","kind":"Ingress","metadata":{"annotations":{"kubernetes.io/ingress.class":"nginx"},"name":"spinnaker-nginx-ingress","namespace":"spinnaker"},"spec":{"rules":[{"host":"spinnaker.some-url.com","http":{"paths":[{"backend":{"serviceName":"spin-deck","servicePort":9000},"path":"/"}]}},{"host":"api.some-url.com","http":{"paths":[{"backend":{"serviceName":"spin-gate","servicePort":8084},"path":"/"}]}}]}}

 kubernetes.io/ingress.class: nginx
Events:
 Type Reason Age From Message
 ---- ------ ---- ---- -------
 Normal CREATE 28s nginx-ingress-controller Ingress spinnaker/spinnaker-nginx-ingress
 Normal UPDATE 20s nginx-ingress-controller Ingress spinnaker/spinnaker-nginx-ingress

Set up DNS so that your two URLs point to the IP address for the ingress (in the above, configure spinnaker.some-url.com and api.some-url.com to point to 35.233.216.189). This can be done via whatever your organization uses for DNS.

Configuring TLS certificates

Configuration of TLS certificates for ingresses is often very organization-specific. In general, you would want to do the following:

Add certificate(s) so that your ingress controller can use them
Configure the ingress(es) so that NGINX (or your ingress) terminates TLS using the certificate(s)
Update Armory to be aware of the new TLS endpoints (note https instead of http)

SPIN_DECK_ENDPOINT=spinnaker.some-url.com
SPIN_GATE_ENDPOINT=api.some-url.com
SPIN_DECK_URL=https://${SPIN_DECK_ENDPOINT}
SPIN_GATE_URL=https://${SPIN_GATE_ENDPOINT}
hal config security ui edit --override-base-url ${SPIN_DECK_URL}
hal config security api edit --override-base-url ${SPIN_GATE_URL}
hal deploy apply

Next steps

Now that you have Armory up and running, here are some of the next things you may want to do:

Configuration of certificates to secure your cluster (see this section for notes on this)
Configuration of Authentication/Authorization (see the Open Source Spinnaker documentation)
Add Kubernetes accounts to deploy applications to (see Creating and Adding a Kubernetes Account to Armory as a Deployment Target)
Add GCP accounts to deploy applications to (see the Open Source Spinnaker documentation)
Add AWS accounts to deploy applications to (see the Open Source Spinnaker documentation)

Continuous-Deployment: Upgrade Spinnaker to Armory Continuous Deployment

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

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

Overview of upgrading Spinnaker to Armory Continuous Deployment

Armory Continuous Deployment for Spinnaker is installed with Armory-extended Halyard, very similarly to the way Open Source Spinnaker^TM is installed with Open Source Halyard. These are the key differences:

Armory-extended Halyard installs Armory’s enterprise distribution of Spinnaker; Open Source Halyard installs Open Source Spinnaker.
Armory versions are one major version ahead of Open Source. For example, Armory 2.18.x maps to Open Source Spinnaker 1.18.x.
Armory has an extra subcommand block hal armory (mapping to an armory block in your .hal/config), which controls Armory-specific features.

This guide differentiates between the two by referring to them as Armory and open source Spinnaker, respectively.

If you are currently on open source Spinnaker and interested in upgrading to Armory, you can easily upgrade if you used Halyard to install your Spinnaker cluster.

This guide assumes the following:

Spinnaker is currently running in Kubernetes
Spinnaker is configured with some form of persistent storage (Minio, S3, GCS, or AZS)
Spinnaker was installed with Halyard in one of these forms:
- Halyard is running locally on a workstation
- Halyard is running in a Docker container in Docker daemon (in Linux, Windows, or OSX)
- Halyard is running in a Kubernetes pod

Depending on where Halyard is currently running, the detailed installation instructions will be slightly different, but the high level process is the same:

Start Armory-extended Halyard in a Docker container with your open source Halyard configuration directories available to Armory Halyard.
Enter the Armory-extended Halyard container.
Update the Spinnaker version to use an Armory version. Recall that Armory versions are ahead of open source Spinnaker by one major version.
Apply your changes.

Halyard running locally on a workstation

If Halyard is running locally on your workstation, then perform the following steps:

Make copies of any directores used by Halyard. These include~.hal and ~.kube and potentially ~/.aws, ~/.config/gcloud, ~/.azure). You can mount these directly into Halyard, but it may be safer to operate on copies.
```
mkdir -p ~/armory/.config
cp -rpv ~/.hal ~/armory/
cp -rpv ~/.aws ~/armory/
cp -rpv ~/.kube ~/armory/
cp -rpv ~/.azure ~/armory/
cp -rpv ~/.config/gcloud ~/armory/.config
```
Omit any directories that do not apply to you. For example, if you do not use Azure, omit it.
Start Halyard as a Docker container in daemon mode, with your directories mounted in (add/remove volume mounts as applicable):
```
docker run --name armory-halyard --rm \
 -v ${HOME}/armory/.hal:/home/spinnaker/.hal \
 -v ${HOME}/armory/.kube:/home/spinnaker/.kube \
 -v ${HOME}/armory/.aws:/home/spinnaker/.aws \
 -v ${HOME}/armory/.azure:/home/spinnaker/.azure \
 -v ${HOME}/armory/.config:/home/spinnaker/.config \
 -d \
 -u $(id -u) \
 index.docker.io/armory/halyard-armory:1.12.1
```
Omit any directories that do not apply to you. For example, if you do not use Azure, omit it.

The above specifies that Halyard will run as your local user id. Depending on how your Halyard daemon was initially run and what user id owns the various Halyard directories, you may need to specify some other user. For example, if user 1000 owns the .hal directory, replace “-u $(id -u)” with “-u 1000”
Exec into the Halyard container
```
docker exec -it armory-halyard bash
```
Update the version of Spinnaker
```
hal config version edit --version $(hal version latest -q)
```
This will use the latest stable version; If you want to use a different version, use hal version list to get a list of available versions. Then, run hal config version edit --version X.X.X to specify a version.
Apply your changes
```
hal deploy apply
```

Halyard running in a Docker container in Docker daemon

If Halyard is already running in a Docker container in your Docker daemon, you can do an in-place upgrade.

First, do a backup of your existing Halyard configuration. Exec into the Docker container, then run hal backup create.
Stop the Halyard docker container, and re-start it with the Armory-extended Halyard image (index.docker.io/armory/halyard-armory:1.12.1) instead of the open source Halyard image (gcr.io/spinnaker-marketplace/halyard:stable). Also, change the user id for Armory-extended Halyard to be 1000. For example, if you run the previous Docker image (open source Halyard) like this:
```
docker run --name halyard --rm \
 -v ${HOME}/armory/.hal:/home/spinnaker/.hal \
 -v ${HOME}/armory/.kube:/home/spinnaker/.kube \
 -d \
 gcr.io/spinnaker-marketplace/halyard:stable
```
Then run Armory-extended Halyard like this:
```
docker run --name armory-halyard --rm \
 -v ${HOME}/armory/.hal:/home/spinnaker/.hal \
 -v ${HOME}/armory/.kube:/home/spinnaker/.kube \
 -d \
 index.docker.io/armory/halyard-armory:1.12.1
```
Note the different Docker image and different container name.
Exec into the Halyard container:
```
docker exec -it armory-halyard bash
```
Update the version of Spinnaker:
```
hal config version edit --version $(hal version latest -q)
```
This will use the latest stable version. If you want to use a different version, use hal version list to get a list of available versions, and then hal config version edit --version X.X.X to specify a specific version.
Apply your changes
```
hal deploy apply
```

Halyard running in a Kubernetes pod

If Halyard is running in your Kubernetes cluster, either as a Kubernetes Deployment or a Kubernetes StatefulSet, then you can do an in-place upgrade:

First, update the image for your Halyard Deployment / StatefulSet from the open source Halyard image (gcr.io/spinnaker-marketplace/halyard:stable) to the Armory-extended Halyard image (index.docker.io/armory/halyard-armory:1.12.1)
Wait for the pod to start up.
Exec into your Kubernetes pod (insert your namespace and pod name, accordingly):
```
kubectl exec -it spinnaker bash
```
Update the version of Spinnaker:
```
hal config version edit --version $(hal version latest -q)
```
This will use the latest stable version. If you want to use a different version, use hal version list to get a list of available versions, and then hal config version edit --version X.X.X to specify a specific version.
Apply your changes:
```
hal deploy apply
```

Revert back to Spinnaker

If you want to go back to open source Spinnaker, you can repeat the same process as above with open source Halyard. Specifically, replace the Armory-extended Halyard image with the open source Halyard image, update Spinnaker version (from 2.x to 1.x), and run hal deploy apply

Troubleshooting

Depending on what version of Halyard / Armory-extended Halyard you’re moving to/from, there may be some fields in your Halyard configuration that are present in one version but not the other. You’ll see an Unrecognized field error like this:

$ hal deploy apply
- Get current deployment
 Failure
Problems in Global:
! ERROR Could not translate your halconfig: Unrecognized field
 "nodeSelectors" (class
 com.netflix.spinnaker.halyard.config.model.v1.node.DeploymentEnvironment), not
 marked as ignorable (14 known properties: "size", "initContainers",
 "updateVersions", "consul", "customSizing", "vault", "gitConfig", "location",
 "sidecars", "haServices", "accountName", "type", "hostAliases",
 "bootstrapOnly"])
at [Source: N/A; line: -1, column: -1] (through reference chain:
 io.armory.halyard.config.model.v1.node.ArmoryHalconfig["deploymentConfigurations"]->java.util.ArrayList[0]->com.netflix.spinnaker.halyard.config.model.v1.node.ArmoryDeploymentConfiguration["deploymentEnvironment"]->com.netflix.spinnaker.halyard.config.model.v1.node.DeploymentEnvironment["nodeSelectors"])

- Failed to get deployment name.

If you see the above error, go to the /home/spinnaker/.hal/config file in your Halyard container, search for the offending field, and remove the yaml block (comment it out or completely remove it).

For example, in the above case, find the deploymentEnvironment.nodeSelectors field, and remove it. Repeat as necessary.

Continuous-Deployment: QuickStart for Deploying to AWS from Spinnaker

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

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

Armory Docs – Guides for Installing Armory Continuous Deployment for Spinnaker

Continuous-Deployment: Install Armory Continuous Deployment for Spinnaker in Air-Gapped Environments

Overview of air-gapped environments

Before you begin

Inspect the Armory Continuous Deployment Bill of Materials

What’s next

Continuous-Deployment: Install Armory Continuous Deployment from the AWS Container Marketplace

Note

Overview of the Armory Operator

AWS Resources

Prerequisites for using the Armory Operator

Installation summary

Create an AWS bucket

Create and configure the AWS IAM roles for your Kubernetes cluster

IAM role for Armory Operator Pod

IAM role for Front50 Pod

IAM role for Clouddriver pod

Install the Armory Operator Custom Resource Definitions (CRDs)

Install the Armory Operator

Creating a SpinnakerService Custom Resource

Exposing your Armory instance

Set up an Ingress for spin-deck and spin-gate

Configure Armory to be aware of its endpoints

Configure TLS certificates

Next steps

Continuous-Deployment: Install Armory Continuous Deployment in Amazon Web Services (AWS)

Overview of installing Armory in AWS

AWS Resources

Before you begin

Installation summary

Connect to the Kubernetes cluster

Connecting to an EKS cluster

Connecting to other Kubernetes clusters

Create a kubeconfig file for Halyard/Armory

Create the S3 bucket and credentials

Create an IAM user using an inline policy

Create an IAM policy attached to the Kubernetes nodes using an inline policy

Stage files on the Halyard machine

Start the Halyard container

Enter the Halyard container

Add the kubeconfig and cloud provider to Armory (via Halyard)

Configure Armory to install in Kubernetes

Enable Artifacts

Configure Armory to use your S3 bucket

If you are using an IAM user

If you are using the IAM instance roles

If you want to use a specific folder in the bucket

Choose the Armory version

Install Armory

Connect to Armory Continuous Deployment using kubectl port-forward

Install the NGINX ingress controller

Set up the Ingress for spin-deck and spin-gate

Configure Armory to be aware of its endpoints

Set up DNS

Configuring TLS certificates

Next steps

Continuous-Deployment: Upgrade Spinnaker to Armory Continuous Deployment

Overview of upgrading Spinnaker to Armory Continuous Deployment

Halyard running locally on a workstation

Halyard running in a Docker container in Docker daemon

Halyard running in a Kubernetes pod

Revert back to Spinnaker

Troubleshooting

Continuous-Deployment: QuickStart for Deploying to AWS from Spinnaker

Set up an Ingress for `spin-deck` and `spin-gate`

Create a `kubeconfig` file for Halyard/Armory

Connect to Armory Continuous Deployment using `kubectl port-forward`

Set up the Ingress for `spin-deck` and `spin-gate`