Armory Docs – QuickStart for Deploying to AWS from Spinnaker

Continuous-Deployment: AWS QuickStart Step 1

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

The AWS QuickStart walks you through configuring your Spinnaker instance hosted on AWS to deploy to AWS.

Note

This guide assumes that Spinnaker is installed with Halyard, not Operator.

Prerequisites

Before you start, ensure that you complete the following requirements:

Have your AWS Account number available in a text editor*
Have Minnaker installed on AWS. For more information about Minnaker, see Minnaker.
SSH into your Minnaker Instance with AWS keys

Need help setting this up? - For a guided tutorial, watch the Video Walkthrough at the bottom of this document.

Prepare AWS by creating Roles, Permissions, and Trust

In this step, we configure 2 AWS Roles to enable Spinnaker to deploy to your AWS environment

Create - “Spinnaker-Managed-Role” in AWS Console -> IAM -> Roles.
Bind “PowerUserAccess” to “Spinnaker-Managed-Role” in Permissions.

“PassRole-and-Certificate” (inline policy for Spinnaker-Managed-Role):

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Action": [
 "iam:ListServerCertificates",
 "iam:PassRole"
 ],
 "Resource": [
 "*"
 ],
 "Effect": "Allow"
 }
 ]
}

Create - “Spinnaker-Managing-Role”.
Bind “PowerUserAccess” to “Spinnaker-Managing-Role”.

“BaseIAM-PassRole” (Create as inline policy on “Spinnaker-Managing-Role”). You must replace [YOUR_AWS_ACCOUNT_ID] with your actual AWS account id.

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": [
 "ec2:DescribeAvailabilityZones",
 "ec2:DescribeRegions"
 ],
 "Resource": [
 "*"
 ]
 },
 {
 "Action": "sts:AssumeRole",
 "Resource": [
 "arn:aws:iam::[YOUR_AWS_ACCOUNT_ID]:role/Spinnaker-Managed-Role"
 ],
 "Effect": "Allow"
 }
 ]
}

Spinnaker-Managed-Role -> Trust relationship

Now, “Spinnaker-Managed-Role” must have Trust relationship with “Spinnaker-Managing-Role”. You must replace [YOUR_AWS_ACCOUNT_ID] with your actual AWS account id.

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Principal": {
 "AWS": "arn:aws:iam::[YOUR_AWS_ACCOUNT_ID]:role/Spinnaker-Managing-Role",
 "Service": [
 "ecs.amazonaws.com",
 "application-autoscaling.amazonaws.com",
 "ecs-tasks.amazonaws.com",
 "ec2.amazonaws.com"
 ]
 },
 "Action": "sts:AssumeRole"
 }
 ]
}

Bind “Spinnaker-Managing-Role” to Minnaker Instance in AWS Console

Locate your Minnaker EC2 instance in the AWS Console and click Action > Instance Settings > Attach Replace IAM Role.
From the dropdown menu, find “Spinnaker-Managing-Role” and click Apply to bind the Role to the Minnaker Instance.

Verify Roles are configured correctly

Download the aws-cli:
```
sudo snap install aws-cli --classic
```

Verify “Spinnaker-Managing-Role”:

aws sts get-caller-identity

The command returns output similar to the following output:

ubuntu:~$ aws sts get-caller-identity
{
 "UserId": "AROA3SQXSP.............7893f355",
 "Account": "[YOUR_AWS_ACCOUNT_ID]",
 "Arn": "arn:aws:sts::[YOUR_AWS_ACCOUNT_ID]:assumed-role/Spinnaker-Managing-Role/i-0e.........7893f355"
}

Verify that Spinnaker Managing Role can Assume Managing Role:

aws sts assume-role --role-arn arn:aws:iam::[YOUR_AWS_ACCOUNT_ID]:role/Spinnaker-Managed-Role --role-session-name test

The command returns output similar to the following output:

ubuntu:~$ aws sts assume-role --role-arn arn:aws:iam::[YOUR_AWS_ACCOUNT_ID]:role/Spinnaker-Managed-Role --role-session-name test
{
 "Credentials": {
 "Expiration": "2020-01-09T01:03:05Z",
 "AccessKeyId": "AWS_ACCESS_KEY",
 "SecretAccessKey": "AWS_SECRET_ACCESS_KEY",
 "SessionToken": "FwoGZXIvYXdzEGEaDEyTECcALWUjAgy0GyKoAZ5PapC1qqFwN55X0vRISdtZh19mR3V9p3i5dGZugt3FQ4DNOamVgIG82I1qaspn83aBefdbpUtznN9fJxwPNoRhYinVgIXGdsTWnBuQ57U7s/cDoHosvV5+J3oZj8ffjLInzsI05IrRBiOTmqU3caEP/e+6N5nzHg/9+aS6TCWjCIzjL0mHtclBBQ7k/dijrg/5vTVFh8UGakcJL3SV6gaCHj0k6BUzEii529nwBTItq6/QISV8wfGNLQJOPDB5P3zoQkHjkpoWCEh1p0oc4hEwki8F7NutXNrg14W+"
 },
 "AssumedRoleUser": {
 "AssumedRoleId": "AROA3SQXSP6SGOWFHHJ7B:test",
 "Arn": "arn:aws:sts::[YOUR_AWS_ACCOUNT_ID]:assumed-role/Spinnaker-Managed-Role/test"
 }
}

Congratulations

You have completed the 1st step in setting up the Spinnaker AWS Provider. For Step 2, see AWS Quick Start Step 2.

Continuous-Deployment: AWS QuickStart Step 2

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

Need help setting this up? - For a guided tutorial, see the video walkthrough at the bottom of this page.

Note

This guide assumes that Spinnaker is installed with Halyard, not Operator.

Prerequisites

Before you start, ensure that have completed the following requirements:

Finish AWS QuickStart Step 1.
Have access to the Kubernetes cluster you would like to deploy to, and you need cluster admin permissions on that Kubernetes cluster.
Have kubectl installed on your local workstation have the context set to the EKS cluster you want to deploy to.

Running the following command from your local machine should return the namespaces for the EKS cluster you want to deploy to.
```
kubectl get ns
```
Have a way to copy files from your local workstation to the Minnaker VM, such as scp.

First: Configure the AWS Provider for Spinnaker

Adding AWS Role to Spinnaker through Halyard configuration. Note AWS account name is within Spinnaker and will appear in UI

NOTE: You MUST configure the regions that Spinnaker can deploy to in the hal command below.

The Account name is arbitrary and should be a name that is an identifiable. The name is visable in Spinnaker UI. The following examples use aws-dev-1.

Set environment variables for halyard command:

export AWS_ACCOUNT_NAME=aws-dev-1 \
export ACCOUNT_ID=[YOUR_ACCOUNT_ID] \
export ROLE_NAME=role/Spinnaker-Managed-Role

Add the AWS provider account to Spinnaker:

hal config provider aws account add ${AWS_ACCOUNT_NAME} \
 --account-id ${ACCOUNT_ID} \
 --assume-role ${ROLE_NAME} \
 --regions us-east-1,us-west-2

Enable the AWS provider:
```
hal config provider aws enable
```

Add an account to the ECS provider:

hal config provider ecs account add ecs-account-name --aws-account aws-dev-1

Enable the ECS provider:
```
hal config provider ecs enable
```
Apply the new configurations and redeploy Spinnaker:
```
hal deploy apply
```

Tag AWS Subnets for Spinnaker Auto Discovery

If subnets do not appear in Deck (the Spinnaker UI), perform AWS Subnet tagging. “example-purpose” should be a descriptor of the subnet and will appear in the Spinnaker UI dropdown.

For more information about AWS Subnet tagging, see AWS: Configuring AWS Networking.

Key Value
immutable_metadata {"purpose":"example-purpose"}

Replace example-purpose with your subnet identifier. The subnet shows up in Deck as a dropdown option.

Example:

Key: immutable_metadata
Value: {"purpose":"us-west-2-dev-subnet"}

Second: Connect Spinnaker to an Amazon EKS cluster

For the tasks in this section, complete them on your local workstation, not from the Minnaker VM.

Using spinnaker-tools

spinnaker-tools is a wrapper that performs a series of kubectl commands for you to automate creating a service account.

On your local workstation (where you currently have access to Kubernetes), download the spinnaker-tools binary:

If you’re on a Mac:

curl -L https://github.com/armory/spinnaker-tools/releases/download/0.0.7/spinnaker-tools-darwin -o spinnaker-tools
chmod +x spinnaker-tools

If you’re on Linux:

curl -L https://github.com/armory/spinnaker-tools/releases/download/0.0.7/spinnaker-tools-linux -o spinnaker-tools
chmod +x spinnaker-tools

Then, run it:

./spinnaker-tools create-service-account

Provide the following information:

Select the Kubernetes cluster to deploy to (this helps if you have multiple Kubernetes clusters configured in your local kubeconfig)
Select the namespace (choose the kube-system namespace, or select some other namespace or select the option to create a new namespace). This is the namespace that the Kubernetes ServiceAccount will be created in.
Enter a name for the service account. You can use the default spinnaker-service-account, or enter a new (unique) name.
Enter a name for the output file. You can use the default kubeconfig-sa, or you can enter a unique name. You should use something that identifies the Kubernetes cluster you are deploying to (for example, if you are setting up Spinnaker to deploy to your us-west-2 dev cluster, then you could do something like kubeconfig-us-west-2-dev)

spinnaker-tools uses this information to create the service account (and namespace, if applicable) and the ClusterRoleBinding. It then creates the kubeconfig file with the specified name.

Copy this file from your local workstation to your Minnaker VM. You can use scp or some other copy mechanism.

Add the kubeconfig to Spinnaker’s Halyard configuration

On the Minnaker VM, move or copy the file to /etc/spinnaker/.hal/.secret. Make sure you are creating a new file, not overwriting an existing one.

Then, run this command:

hal config provider kubernetes account add kubeconfig-sa-eks \
 --provider-version v2 \
 --kubeconfig-file /home/spinnaker/.hal/.secret/kubeconfig-sa-eks \
 --only-spinnaker-managed true

Note:

Update the --kubeconfig-file path with the correct filename. Note that the path will be /home/spinnaker/... not /etc/spinnaker/.... This is because this command runs inside the Halyard container, which has local volumes mounted into it.

Apply your changes

Run this command to apply your changes to Spinnaker:

hal deploy apply --wait-for-completion

Congratulations

You have configured the Spinnaker AWS Provider and Kubernetes Account for EKS. You can now deploy to EC2, ECS, Fargate, and EKS. Lets build some pipelines in AWS QuickStart Step 3.

Continuous-Deployment: AWS QuickStart Step 3

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

Need help setting this up? - For a guided tutorial, see the video walkthrough at the bottom of this page.

Note

This guide assumes that Spinnaker is installed with Halyard, not Operator.

Prerequisite

Before you start, ensure that have completed the following requirements:

Finish AWS QuickStart Step 2

Deploy to EC2 and EKS

Before you start, you need to log in to Deck, the Spinnaker UI.

You can access it by navigating to the Public IP address of your instance in a browser. You can get the Public IP address from your AWS Console.

If you have forgotten the password to your Minnaker instance you can recover your password with the following steps:

SSH to the Minnaker host VM. Do not exec into the Halyard pod though.
Run the following command:

cat /etc/spinnaker/.hal/.secret/spinnaker_password

The command returns the password for Minnaker.

After you log in to Deck, perform the following steps:

Create an Application called QuickStart by clicking “Applications” tab > “Action” (top right) > “Create New App” with the following Settings

Go into Application QuickStart and create your first pipeline. This pipeline will deploy to an EC2 instance.
Click Add Stage + and search for a Bake stage to bake an AMI.
Select the AWS Region you want to deploy to.
Click Add Server Group and configure basic AMI bake settings: Account, Region, Subnet, Instance Type, and AWS SSH key. Note: For more information about setting up your Bake Stage, please check out configuring AWS networks, which includes guides about requirements regarding subnet configuration.
Click Done and then Save Changes in the bottom right corner.
Click Add Stage and add another stage called Deploy for AWS EC2.
Click the “Back to Execution” button on the top left of the Pipeline Name
Run your Pipeline and Validate! The end result will be an Auto Scaling Group build within your AWS subnet.

EC2 Pipeline and deployment

Note - Don’t mind the red dot in the Bake Stage. It’s an informational tip suggesting a CI Trigger should be configured for a Bake Stage to ensure you are deploying the latest code and artifacts.

EKS deployment

Note As a prerequisite, create a “quickstart” namespace in EKS:

kubectl create ns quickstart

Navigate to the pipeline page within your QuickStart application.
Click Create button in top right corner.
Give the name Deploy-to-EKS.
Click Add Stage and Search / Select Deploy(Manifest).
Select the kubeconfig-sa-eks account created in Step 2.
Select the quickstart namespace.
Scroll down and paste in the Deployment yaml below.
Click Save Changes in the bottom right corner.
Now create another stange after the Deployment stage. Again select Deploy(Manifest).
Select the kubeconfig-sa-eks account and the quickstart namespace for deployment.
Scroll down and paste in the Service yaml below.
Click Save Changes.

Time to run your EKS pipeline and validate

Click back to the pipeline page using the Back to Executions to the left of the pipeline name.
Click on the Start Manual Execution on the new pipeline. Then, click Execution Details to see pipeline in action.

Deployment yaml definition

Copy and paste the following example into the text field in the 1st Deploy Manifest stage.

apiVersion: apps/v1
kind: Deployment
metadata:
 name: my-nginx
spec:
 replicas: 2
 selector:
 matchLabels:
 run: my-nginx
 template:
 metadata:
 labels:
 run: my-nginx
 spec:
 containers:
 - image: nginx
 name: my-nginx
 ports:
 - containerPort: 80

Service yaml for last Deployment Stage

Copy and paste the following example into the text field in the 2nd Deploy Manifest stage.

apiVersion: v1
kind: Service
metadata:
 labels:
 run: my-nginx
 name: my-nginx
spec:
 ports:
 - port: 80
 protocol: TCP
 targetPort: 80
 selector:
 run: my-nginx
 type: LoadBalancer

Validation in EKS and in Spinnaker

In EKS run the following commands to see nginx pods being created: kubectl get pods -n quickstart.
In Deck, the Spinnaker UI, navigate to the Applications page and see the deployment and containers there.

Under Load Balancers, click on Apps to view the status of your service.
In the Status section on the right of the page, locate the Ingress address that was created to allow public access to your new deployment.

Copy and paste the FQDN from the load balancer status section into a web browser to test the NGINX landing page.

Congratulations

You completed the QuickStart exercise! You can now deploy to AWS using Spinnaker. What’s Next?

Connect your Spinnaker instance to your repositories / artifacts (Github, Sonatype, Artifactory, DockerHub, ECR, GCR, etc).
Build in a automated trigger from your CI systems (Jenkins, Bamboo, CircleCI, TravisCI, Nexus, Git, Generic Webhook, etc).
Integrate with 3rd party systems (OKTA, Sumo Logic, Splunk, Datadog, Newrelic, Slack, etc).
Integrate with DevSecOps tools (Xray, ChaosMonkey, Artifactory, etc).

To get expert help in any of the areas above you can contact Armory.io at https://go.armory.io/needs-analysis

Armory Docs – QuickStart for Deploying to AWS from Spinnaker

Continuous-Deployment: AWS QuickStart Step 1

Note

Prerequisites

Prepare AWS by creating Roles, Permissions, and Trust

In this step, we configure 2 AWS Roles to enable Spinnaker to deploy to your AWS environment

Bind “Spinnaker-Managing-Role” to Minnaker Instance in AWS Console

Login to your Minnaker EC2 Instance with SSH (Outside of Halyard Container)

Verify Roles are configured correctly

Congratulations

Continuous-Deployment: AWS QuickStart Step 2

Note

Prerequisites

First: Configure the AWS Provider for Spinnaker

Adding AWS Role to Spinnaker through Halyard configuration. Note AWS account name is within Spinnaker and will appear in UI

Tag AWS Subnets for Spinnaker Auto Discovery

Second: Connect Spinnaker to an Amazon EKS cluster

Using spinnaker-tools

Add the kubeconfig to Spinnaker’s Halyard configuration

Apply your changes

Congratulations

Continuous-Deployment: AWS QuickStart Step 3

Note

Prerequisite

Deploy to EC2 and EKS

EC2 Pipeline and deployment

EKS deployment

Time to run your EKS pipeline and validate

Validation in EKS and in Spinnaker

Congratulations