Spinnaker – Codelabs

Docs: App Engine: Source to Prod

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

This tutorial is deprecated and no longer supported, but left for reference. Halyard is no longer supported or maintained

Overview

This codelab provides an overview of Spinnaker’s integration with App Engine. You’ll build and run a simple App Engine deployment pipeline with the following steps:

Prerequisites

Be sure you have your Google Cloud Platform project’s ID. This value will be referenced as GCP-PROJECT-ID below.
Be sure you have gcloud installed, and that it is authenticated with your GCP project. In most cases, this should only require running gcloud auth login <your@email.com> and following the instructions in the prompt. If you don’t have gcloud installed locally, you can always run gcloud from inside Cloud Shell, which you can open from your GCP console.
Be sure you have the App Engine Admin and Compute Engine APIs enabled for your GCP project:

gcloud services enable appengine.googleapis.com
gcloud services enable compute.googleapis.com

If this is your first time deploying to App Engine in your project, execute the following command to create an App Engine application. You cannot change the region, so choose wisely: gcloud app create --region <e.g., us-central>.

Configuration & installation

We’re going to trigger our Spinnaker pipelines using Github webhooks. In order to do so, we will have to expose Spinnaker’s API gateway to external traffic. If you are going to use this installation beyond this codelab, you should follow the guides for securing Spinnaker.

Create a new firewall rule for your GCP project. Github sends webhooks from IPs in the CIDR ranges queried below.

gcloud compute firewall-rules create allow-github-webhook \
    --allow="tcp:8084" \
    --source-ranges=$(curl -s https://api.github.com/meta | python -c "import sys, json; print ','.join(json.load(sys.stdin)['hooks'])") \
    --target-tags="allow-github-webhook"

Provision a new virtual machine. We’ll install Spinnaker on this machine:

gcloud compute instances create $USER-spinnaker \
    --scopes="https://www.googleapis.com/auth/cloud-platform" \
    --machine-type="n1-highmem-4" \
    --image-family="ubuntu-1404-lts" \
    --image-project="ubuntu-os-cloud" \
    --zone="us-central1-f" \
    --tags="allow-github-webhook"

Next, run the following command to SSH into the machine we’ve just provisioned. We’ll also pass flags to forward ports 9000 and 8084 - Spinnaker’s UI and API servers listen on these ports.

gcloud compute ssh $USER-spinnaker --ssh-flag="-L 9000:localhost:9000" --ssh-flag="-L 8084:localhost:8084"

Download and install Halyard on this machine. Halyard is a tool for configuring, installing, and updating Spinnaker.

curl -O https://raw.githubusercontent.com/spinnaker/halyard/master/install/debian/InstallHalyard.sh

sudo bash InstallHalyard.sh

Once you’ve installed Halyard, run the following commands to configure Spinnaker for deploying to App Engine:

hal config version edit --version $(hal version latest -q)

hal config provider appengine enable

hal config provider appengine account add my-appengine-account --project $GCP-PROJECT-ID

hal config storage gcs edit --project $GCP-PROJECT-ID

hal config storage edit --type gcs

Then run the following command to allow Spinnaker’s API gateway to accept external requests:

mkdir -p ~/.hal/default/service-settings
echo "host: 0.0.0.0" | tee ~/.hal/default/service-settings/gate.yml

Run sudo hal deploy apply to install and run Spinnaker.

The installation process will take several minutes. While you’re waiting for Spinnaker to start, you can configure your Github webhook:

Determine your Spinnaker instance’s external IP:

gcloud compute instances describe $USER-spinnaker | grep natIP

Fork this repository, which contains a sample App Engine application: https://github.com/danielpeach/redblue .
Inside your fork, click “Settings”, then “Webhooks”, then “Add Webhook”.
Under “Payload URL”, enter http://{externalIP}:8084/webhooks/git/github.
Under “Content Type”, select application/json.

At this point, Spinnaker should be up and running. Point your browser at localhost:9000 to view Spinnaker’s UI.

Deploy to App Engine

First, we’ll create a Spinnaker application.

In the top-right corner of the UI, click “Actions”, then Create Application.
Under “Name”, enter codelab.
Under “Owner Email”, enter your email address.
Under “Account(s)”, select my-appengine-account. This is the account we configured with Halyard - it is associated with a set of credentials that allows Spinnaker to deploy to App Engine within your project. You can configure Spinnaker with multiple accounts to deploy to multiple GCP projects.
Click “Create”.

Once your application has been created, you’ll be taken to the “Clusters” tab. Click “Create Server Group”. A Spinnaker server group is an App Engine Version. When creating server groups, Spinnaker applies its own naming conventions: all Versions created from the application “codelab” will be prefixed with “codelab-”
Under “Stack”, enter default. Omit “Detail”. In a Spinnaker application, a Cluster is a logical grouping of server groups with the same Stack and Detail. It can be helpful to use the name of an App Engine Service as the value for Stack - in our case, our Version will be deployed to the Service named “default”.
Under “Git Repository URL”, enter https://github.com/{YourGitHubUsername}/redblue.git; i.e., the URL to the repository you forked earlier.
Under “Branch”, enter master.
Under “Config Filepaths”, enter app.yaml.
Click “Create”.

Your server group will take a moment to deploy. Once it appears in the UI, click on the section labeled “V000”. You should see a panel open on the right with details about the server group. To view the app you just deployed, click one of the links under “DNS”. It should be a “Hello World” page with a bright red background.

Click on the tab labeled “Load Balancers”. You will see a panel labeled “default”. This is your default App Engine Service. If you deploy Versions to different App Engine Services, those Services will also appear under this tab.

Deployment pipeline

Next, we’ll build a deployment pipeline. It will include the following stages:

Trigger on a GitHub webhook - this will be triggered by a push to the forked repository.
Deploy - we’ll deploy the updated app to App Engine.
Edit Load Balancer - we’ll split traffic between our two server groups.
Manual Judgment - we’ll verify that we’re ready to move all traffic to the new server group. This stage could be a stand-in for integration tests or canary analysis.
Enable - we’ll send 100% of traffic to the new server group.
Wait - we’ll wait for two minutes to be sure everything is OK before destroying the old server group. In a real deployment pipeline, it’s likely that this wait time would be longer - perhaps an hour or more.
Destroy - we’ll destroy the old server group.

Pipeline creation

Click on the “Pipelines” tab adjacent to the “Clusters” and “Tasks” tabs.
Click “New”.
Under “Pipeline Name”, enter Deploy And Promote.
Click “Create”.

Webhook trigger

Under “Automated Triggers”:

Under “Type”, select Git.
Under “Repo Type”, select github.
Under “Organization or User”, enter your GitHub username.
Under “Project”, enter redblue.
Under “Branch”, enter release.

Deploy stage

Click “Add Stage”.
Under “Type”, select Deploy.

Click “Add server group”.
Under “Stack”, enter default.
Under “Git Repository URL”, enter https://github.com/{YourGithubUsername}/redblue.git; i.e., the URL to the repository you forked earlier.
Under “Branch”, enter release.
When configuring your Git webhook trigger, you can specify a regex - the pipeline will only be triggered if the commit to the repository occurs on a branch matching the regex. We can dynamically deploy to App Engine from the branch matching the regex by clicking “Resolve via trigger” in this dialog.
Under “Config Filepaths”, enter app.yaml.
Click “Add”.

Edit Load Balancer stage

Click “Add Stage”, then under “Type”, select Edit Load Balancer.
Under “Stage Name”, enter Split Traffic 5%/95%.
Click “Add Load Balancer”. In the dialog that pops up, select default - this is your App Engine default Service.

This next part is tricky. We’ll specify how much traffic each server group will receive. We could specify their exact names - e.g., codelab-default-v000 and codelab-default-v001 - but we want to run this pipeline over and over again as we make changes to our app. We will need to resolve the names of the server groups dynamically.

These steps allow us to allocate traffic to the newest server group in the Cluster codelab-default - this will always be the server group we deploy in our “Deploy” stage:

Next to the percent symbol, enter 5. This is the percentage of traffic that this server group will receive.
Under “Locator”, select Coordinates.
Under “Cluster”, click “Toggle for list of existing clusters”, then select codelab-default.
Under “Target”, select Newest server group.

These steps to allocate traffic to the second-oldest server group in the Cluster codelab-default - when we run this pipeline for the first time, it will be the server group we deployed at the beginning of this codelab:

Click “Add allocation”
Next to the percent symbol, enter 95. This is the percentage of traffic that this server group will receive.
Under “Locator”, select Coordinates.
Under “Cluster”, click “Toggle for list of existing clusters”, then select codelab-default.
Under “Target”, select Previous server group.
Click “Done”.

Manual Judgment stage

Click “Add Stage”, then under “Type”, select Manual Judgment.
Under “Stage Name”, enter Validate Release.
Under “Instructions”, enter Verify that the new release should receive 100% of traffic.

Enable stage

Click “Add Stage”, then under “Type”, select Enable Server Group.
Under “Stage Name”, enter Enable Release.
Under “Cluster”, click “Toggle for list of existing clusters”, then select codelab-default.
Under “Target”, select Newest server group.

When this stage runs, all traffic will be directed to the server group deployed in this pipeline.

Wait stage

Click “Add Stage”, then under “Type”, select Wait.
Under “Wait time (seconds)”, enter 120.

Destroy stage

Click “Add Stage”, then under “Type”, select Destroy Server Group.
Under “Stage Name”, enter Destroy Previous Release.
Under “Cluster”, click “Toggle for list of existing clusters”, then select codelab-default.
Under “Target”, select Previous server group.

When we run this pipeline for the first time, this stage will destroy the first server group we deployed in this codelab.

Once you’re finished configuring your stages, click “Save Changes” on the bottom right corner of the screen.

Pipeline trigger

If you haven’t already done so, clone your forked repository to your local workstation.
Check out a new branch named “release”.
Open “main.py” in your favorite text editor.
On the line that starts with self.response.write, replace background-color: red with background-color: blue.
Using git, add and commit your changes. Push your changes to your remote repository; i.e., git push origin release.
If we’ve configured everything correctly, you should see your pipeline start within Spinnaker. If you haven’t configured a webhook, you can also click “Start Manual Execution” to start your pipeline.

Pipeline execution

Under the “Pipelines” tab, you should see your running pipeline.

Once the “Split Traffic 5%/95%” stage completes, your pipeline will pause on the “Validate Release” stage. Two points of interest:

Under the “Clusters” tab, you should see your new server group. Click on the new server group; a panel should open on the right. Click one of the links under “DNS” - your site’s background will have changed to blue.
Under the “Load Balancers” tab, click on the load balancer labeled “Default”; a panel should open on the right. Under “Traffic Split”, you should see the relative traffic allocations between your two server groups:

Once you’re ready, go back to the “Pipelines” tab. Click “Continue” on the “Validate Release” stage. Your pipeline will continue:

Your new server group will receive 100% of traffic.
Your pipeline will wait for two minutes.
The first server group (the one we deployed at the beginning of this codelab) will be destroyed.

Clean up

If you’re done with this codelab, run gcloud compute instances delete $USER-spinnaker to destroy your Spinnaker installation.

Docs: Azure VM Scale Sets: Source to Prod

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

In this codelab, you will create a source-to-prod continuous delivery pipeline for a simple java based application targeting VM Scale Sets in Azure.

After completing this lab the following workflow will happen:

A developer pushes a commit to Github
Jenkins automatically builds a Debian package and pushes it to an Aptly repository
Spinnaker bakes the new package into an image
Spinnaker deploys to a test environment and disables the previous deployment
Spinnaker waits for a manual judgement of the test environment
Spinnaker deploys the image to the production environment and disables the previous deployment.

This codelab will walk through the following steps to implement this scenario:

1. Deploy Spinnaker and Jenkins on Azure

You need the following resources to perform the codelab:

Azure subscription: You can create one for free using the Azure Free trial .
Spinnaker and Jenkins VM:

From a shell run the following command that will walk you through all the steps necessary to deploy Jenkins and Spinnaker in Azure.

NOTE: When running the following script, ensure that you type vmss when asked to select the target.

bash <(curl -sL https://aka.ms/DeployDevOps)

In the output of the above script you will find the command to open an SSH tunnel to the DevOps VM that has just been deployed. The command should look like this:

ssh -L 8080:localhost:8080 -L 9000:localhost:9000 -L 8084:localhost:8084 -L 8087:localhost:8087 username@fqdn_of_your_devops_vm

NOTE: You will have to enter the password that you have specified in the previous step.

2. Verify Jenkins

After you have started your ssh tunnel, navigate to http://localhost:8080/ on your local machine.
The instance should already be unlocked and your first account setup. Login with the credentials you specified when deploying the template.
Click Install suggested plugins:
Your Jenkins instance is now ready to use!
Run the Sample Aptly Job by clicking on the run button for the job. Verify that the job completes successfully.

3. Prepare your environments

I. Create the “codelab” application

Navigate to your Spinnaker dashboard by using http://localhost:9000 on your local machine.
Click on the Actions menu on the right
In the New Application window, enter the following values:

Name: codelab
Owner Email: Enter your email

And click Create

You can read more how the Spinnaker application matches to Azure resources in the Azure reference for Spinnaker

II. Create a firewall

Navigate to the FIREWALLS page and click on the Create Firewall button.
Provide the following values in the Create New Firewall dialog:

Detail: web
Account: my-azure-account (should be selected by default)
Region: westus (select the region that is closest to your location)

Ingress (click Add new Firewall Rule):
Protocol: TCP
Start Port: 80
End Port: 80

And click Create, if the loadbalancer does not appear in the page once the creation is complete, refresh your browser.

Note: We are using westus for the region but you can select any other region that is closer to your location. Be careful to match the region in the following steps.

You can read more about the implementation of Network Security Groups in Azure in the Azure reference for Spinnaker

III. Create a load balancer

Navigate to the LOAD BALANCERS page and click the Create Load Balancer button.
Provide the following values in the “Create New Load Balancer” dialog:

Account: my-azure-account
Region: westus (unless you have selected a different region previously)
Virtual Network: devopsVnet
Subnet: devopsSubnet1
Stack: test
Detail: frontend

Verify that the Listener is configured as follows:
Protocol: HTTP
External Port: 80
Internal Port: 8080

And click Create.

The virtual network devopsVnet and the subnets devopsSubnet# were created for you by the script that you ran in the Deploy Spinnaker and Jenkins on Azure step.

You can learn more about the implementation of the Spinnaler Load Balancer in the Azure reference for Spinnaker .

Repeat the above steps to create a second load balancer for production. Use the same parameters but the following change:

Stack: prod

NOTE: It will take approximately 15 minutes to provision the two loadbalancers.

4. Create the continuous delivery pipeline

In this section you will create a Spinnaker pipeline that will bake the image from a Jenkins build then deploy it to test.

I. Create a new pipeline

Navigate to the PIPELINES page and click on the New button (+ sign) on the right to create a new pipeline.
Name your pipeline: “Deploy codelab” and click Create.

II. Add a trigger for the pipeline

Click Add Trigger in the Deploy codelab window.
Select the following options:

Type: “Jenkins”
Master: “Jenkins”
Job: “hello-karyon-rxnetty”
Property File: leave empty

III. Add Bake stage

Click Add stage in the Deploy codelab window.
Enter the following values:

Type: Bake
Stage Name: Bake
Regions: westus (or select the region that you have selected when creating the Firewall)
Package: hello-karyon-rxnetty
Base OS: ubuntu (v14.05)

IV. Add Deploy to test stage

Click Add stage
Enter the following values:

Type: Deploy
Stage Name: Deploy to Test
Depends On: Bake

V. Create test deployment configuration

Click Add server group in the Deploy Configuration section.
Click “Continue without a template”
In the “Configure Deployment Cluster” enter the following values:

Account: my-azure-account
Region: westus (or select the region that you have selected when creating the Firewall)
Stack: test
Details: tutorial
Load Balancers: codelab-test-frontend
Subnets: devopsSubnet2
Firewalls: codelab-web
“Advanced Settings”:
- Custom Data: TEST
- Custom Script: https://raw.githubusercontent.com/azure-devops/hello-karyon-rxnetty/master/scripts/setcustomenv.sh
- Command To Execute: sudo bash ./setcustomenv.sh
Click Add

NOTE: Record the name of the cluster. it will be used in the next step.

VI. Enable test deployment

Click Add stage in the Deploy codelab section.
Enter the following values:

Type: Enable Server Group
Stage Name: Enable Test Deployment
Depends On: Deploy to Test
Account: my-azure-account
Regions: westus (or select the region that you have selected when creating the Firewall)
Cluster: codelab-test-tutorial (or the name of your cluster if you have used different values)
Target: Newest Server Group

VII. Manual judgment

Click Add stage in the Deploy codelab section.
Use the following values:

Type: Manual Judgment
Name: Manual Judgment
Depends On: Enable Test Deployment
Instructions: Validate test cluster

VIII. Add Deploy to Prod stage

Click Add stage in the Promote to Prod section.
Use the following values to configure the stage:

Type: Deploy
Stage Name: Deploy to Prod
Depends On: Manual Judgment

IX. Create production deployment configuration

Click Add server group in the Deploy Configuration section.
Click Continue without a template
In the Configure Deployment Cluster enter the following values:

Account: my-azure-account
Region: westus (or select the region that you have selected when creating the Firewall)
Stack: prod
Details: tutorial
Load Balancers: codelab-prod-frontend
Subnets: devopsSubnet2
Firewalls: codelab-web
“Advanced Settings”:
- Custom Data: PROD
- Custom Script: https://raw.githubusercontent.com/azure-devops/hello-karyon-rxnetty/master/scripts/setcustomenv.sh
- Command To Execute: sudo bash ./setcustomenv.sh
Click Add

NOTE: Record the name of the cluster. it will be used in the next step.

X. Enable prod deployment

Click Add stage in the Deploy codelab section.
Use the following values to configure this stage:

Type: Enable Server Group
Stage Name: Enable Prod Deployment
Depends On: Deploy to Prod
Account: my-azure-account
Regions: westus (or select the region that you have selected when creating the Firewall)
Cluster: codelab-prod-tutorial
Target: Newest Server Group
Click Save Changes

5. Trigger your pipeline

In this step you will try out the pipeline that you have just built.

Go to Jenkins and start a new build of the “Sample Aptly Job” like you did in the section “ Verify Jenkins ”. You should see your Spinnaker pipeline running soon after your Jenkins job finishes.
Navigate to the PIPELINES tab
Click on Details to get more information about the status of your deployment
Connect to your application. You can find the public name of your application by looking at the DNS Name that has been assigned to your load balancer.

6. Tear Down

I. Delete your pipeline

In the configuration of your pipeline, click on Pipeline Actions then click on Delete

II. Delete your server groups

Navigate to the CLUSTERS section.
Select each Server Group in the list and select Destroy for each of them.

III. Delete your load balancers

Navigate to the LOAD BALANCERS section.
Select each Load Balancer in the list then in the Load Balancer Actions select Delete Load Balancer

IV. Delete your firewall

Navigate to the FIREWALL section.
Select each Firewall in the list then in the Firewall Actions select Delete Firewall

Docs: Bake and Deploy Pipeline

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

VM only: This codelab requires you have a VM (for example, on AWS or GCP) on which to run it.

For Kubernetes, try Kubernetes Source-to-Prod ,

To walk you through some of the basics with Spinnaker, you’re going to set up a Spinnaker pipeline that bakes a virtual machine (VM) image containing redis, then deploys that image to a test cluster.

Note here that the us-east-1a availability zone is currently full, so it will need to be deselected in the corresponding ‘region’ checkbox list for each of these steps.

Set up Spinnaker

If you don’t already have a running Spinnaker instance, you’ll need to set one up before you continue. Read the setup guide to install Spinnaker.

Once you have deployed Spinnaker, navigate to the ui .

Create a Spinnaker application

In Spinnaker, click Actions > Create Application
Input example for the Name field and your email address for the Owner Email field.
Click on the Consider only cloud provider health when executing tasks button next to Instance Health.
Click the Create button.

Create and configure a firewall

Next, you’ll create a firewall that specifies traffic rules for the cluster. You’ll configure the rules to allow all incoming traffic on port 80, for clusters associated with this firewall.

Click FIREWALLS, then click the + button to create a firewall.
Input test for the Detail (optional) field and Test environment for the Description field.
If running on AWS

Select defaultvpc as the VPC field
Click Add new Firewall Rule.
Click default on the Firewall dropdown.
Change Start Port and End Port to 80.

If running on GCP

Click Add New Source CIDR and use the default 0.0.0.0/0 value for the Source Range field.
Click Add New Protocol and Port Range. Use the default TCP value for the Protocol field. Change Start Port and End Port to 80.

Click the Create button.

Create a load balancer

Next, you’ll create a load balancer in Spinnaker.

Click LOAD BALANCERS, then click the + button to create a load balancer.
Input test for the Stack field.
If running on AWS, select internal (defaultvpc) from the VPC Subnet dropdown.
Click the Next button.
If running on AWS

Select example-test from the Firewalls dropdown.
Hit Next, then Create.

If running on GCP

Deselect the Enable health check? checkbox.

Click the Create button.

Create a deployment pipeline

Your final task is to set up a Spinnaker pipeline. Let’s name it Bake & Deploy to Test. The pipeline will produce an image containing the redis-server package and then deploy it. In this tutorial, you’ll trigger the pipeline manually.

To create the pipeline:

Click PIPELINES, then click Configure and select Create New… from the dropdown.
Input Bake & Deploy to Test for the Pipeline Name.
Click the Create Pipeline button.

Set up the first stage of the pipeline

You’re now going to create the first stage of the pipeline. It will build an image from an existing redis-server package.

Click Add stage.
Select Bake from the Type pulldown menu.
Input redis-server for the Package field.
Click Save Changes.

Set up the second stage of the pipeline

You’re now going to set up the second stage of the pipeline. It takes the image constructed in the Bake stage and deploys it into a test environment.

Click Add stage.
Select Deploy from the Type dropdown.
Under the Server Groups heading, click Add server group.
Click the Continue without a template button.

Next, In the Configure Deployment Cluster window, input “test” for the Stack field.

If running on AWS, select defaultvpc under VPC Subnet.
Click the Next button.
Click the text area next to the Load Balancers heading, then select example-test. Click the Next button.
Click the Firewalls form field, then click example-test (example-test). Click the Next button.
If running on AWS

Click on the Micro Utility button to set the Instance Profile, then click Next.
Select the Medium: m3 size, then click Next.

If running on GCP

Click on the Micro Utility button to set the Instance Profile, then click Next.
If running on GCP, select the Micro size, then click Next.

Input 2 for the Number of Instances field, then click the Add button.
Save the pipeline configuration by clicking the Save Changes button.

Try it out!

Click PIPELINES in the navigation bar.
Click Start Manual Execution for the Bake & Deploy to Test pipeline.
Click Run.

Now, watch Spinnaker in action. A MANUAL START section will appear, and will show progress as the pipeline executes. At any point during pipeline execution, click on the horizontal bar to see detailed status for any of the stages in the pipeline.

Feel free to navigate around the Spinnaker menus, create new pipelines, clusters, server groups, load balancers, and firewalls, etc. and see what happens.

When you’re ready to stop, don’t forget to cleanup your resources. An easy way to do this is to visit the pipelines, clusters, load balancers, and firewalls pages, click on the ones created and select the appropriate Delete command from the Actions pulldown on the right.

Docs: Continuous Delivery to Kubernetes on Oracle

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

In this codelab you will configure a Spinnaker pipeline to deploy an application from Kubernetes manifest files targeting Kubernetes on Oracle Cloud Infrastructure Container Engine (OKE).

Prerequisites

Before we begin, we need to do the following:

Configure Kubernetes

If you don’t already have a cluster for this purpose, you can follow this tutorial until a Kubernetes cluster on OKE is created.

Create a compute instance

Create a compute instance on Oracle Cloud Infrastructure (OCI) to host Spinnaker by following these instructions . Spinnaker supports Ubuntu 18.04 or higher.

Install and configure Spinnaker

SSH onto the compute instance you previously created. IP is its public ip address.

ssh ubuntu@IP

Set up Oracle Object Storage as your Spinnaker storage by following these steps: Adding Oracle Object Storage to Spinnaker .
Set up your Kubernetes Cloud provider by following these steps: Setting up OKE .
Install spinnaker per using a debian installation

Accessing Spinnaker

By default, the Spinnaker UI runs on port 9000. You can use an SSH tunnel to access this from your workstation.

ssh -A -L 9000:localhost:9000 -L 8084:localhost:8084 ubuntu@IP

Now Spinnaker UI is available at http://localhost:9000 .

1: Create a Spinnaker application

In this exercise, you’ll set up a pipeline to deploy a tomcat8 from Kubernetes manifest file to OKE.

Navigate to Spinnaker at http://localhost:9000 .

From the Spinnaker home page, create a new Spinnaker Application by clicking on the Actions drop down at the upper right and clicking on Create Application.

In the New Application dialog:

Enter “codelaboke” for Name.
Enter your email for Owner Email.
Add “kubernetes” to Cloud Providers.
Click the Create button.

2: Create a load balancer

Navigate to the “Load Balancers” tab and click the Create Load Balancer button, enter the following yaml in the Manifest:

kind: Service
apiVersion: v1
metadata:
  name: codelaboke-test-lb
  annotations:
    service.beta.kubernetes.io/oci-load-balancer-shape: 400Mbps
spec:
  type: LoadBalancer
  selector:
    load-balancer-codelaboke-test-lb: 'true'
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

The service annotation “service.beta.kubernetes.io/oci-load-balancer-shape” determines the load balancer’s total pre-provisioned maximum capacity (bandwidth) for ingress plus egress traffic. Available shapes include 100Mbps, 400Mbps, and 8000Mbps.

Click Create. This will create the load balancer shown below.

3: Create a “Deploy to Test” pipeline

Create the pipeline

Create a new pipeline by navigating to the PIPELINES tab and clicking the New button

Name the pipeline “Deploy to Test”.
Click the Create button.

Set up Deploy stage

There are multiple ways to deploy Kubernetes manifests using the Kubernetes provider. More details can be found in this Deploying Kubernetes Manifests guide.

It is preferred to use artifacts as manifests. However, in this tutorial, the manifest is supplied statically to a pipeline as text for simplicity.

Click Add stage.
Select “Deploy (Manifest)” in the Type drop down.
In the Deploy (Manifest) Configuration section, enter the following yaml as Text for Manifest Source.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: codelaboke-test-cluster
spec:
  replicas: 3
  selector:
    matchLabels:
      codelaboke-test-cluster: 'true'
  template:
    metadata:
      labels:
        codelaboke-test-cluster: 'true'
        load-balancer-codelaboke-test-lb: 'true'
    spec:
      containers:
        - image:  tomcat:8.0
          name: tomcat8
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /
              port: 8080

Save the pipeline.

4. Deploy

Run a “Start Manual Execution” in “Deploy to Test” to Test pipeline.

Navigate to the Clusters tab, and you will see this.

You can test the application by visiting the ingress ip address of the Load Balancer “codelaboke-test-lb”. In this example, the Load Balancer listens to HTTP on port 80.

Docs: DC/OS: Source to Prod

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

0. Setup

Prerequisites

Github repository with the source code to deploy
Enterprise DC/OS cluster (1.8 or greater)
- Marathon-lb is should be installed and running
- For the examples in this codelab we’ll say that it’s at https://dcos.example.com so you should replace that with the URL to your cluster
Jenkins instance
- This can be installed on your DC/OS cluster as a Mesosphere Universe package

Configure Spinnaker

clouddriver-local.yml

dcos:
  enabled: true
  clusters:
    - name: codelab-cluster
      dcosUrl: https://dcos.example.com
      insecureSkipTlsVerify: true
  accounts:
    - name: codelab-dcos-account
      dockerRegistries:
        - accountName: my-docker-registry
      clusters:  
        - name: codelab-cluster
          uid: ${DCOS_USER}
          password: ${DCOS_PASSWORD}
dockerRegistry:
  enabled: true
  accounts:
  - name: my-docker-registry
    address: https://index.docker.io
    repositories:
    - lwander/spin-kub-demo
    username: ${DOCKER_USER}
    password: ${DOCKER_PASSWORD}

Enable Docker

Configure a docker registry

Set up the DC/OS provider

First, enable the provider:

hal config provider dcos enable

Next we need to add our DC/OS cluster:

hal config provider dcos cluster add codelab-cluster \
    --dcos-url $CLUSTER_URL \
    --skip-tls-verify # For simplicity we won't worry about the
    # certificate for the cluster but this would not be recommended
    # for a real deployment

Create a Spinnaker account that has credentials for the cluster.

hal config provider dcos account add codelab \
    --cluster codelab-cluster \
    --docker-registries my-docker-registry \
    --uid $DCOS_USER \
    --password $DCOS_PASSWORD

Note: Make sure that your DC/OS user has permission to deploy applications under a /codelab group in Marathon

And deploy the config with hal

sudo hal deploy apply

1. Create a Spinnaker application

Spinnaker applications are groups of resources managed by the underlying cloud provider, and are delineated by the naming convention <app name>-.

Under the Actions dropdown select Create Application and fill out the following dialog:

You’ll notice that you were dropped in this Clusters tab for your newly created application. In Spinnaker’s terminology a Cluster is a collection of Server Groups all running different versions of the same artifact (Docker Image). Furthermore, Server Groups are DC/OS Services

2. Create a demo server group

Next we will create a Server Group as a sanity check to make sure we have set up everything correctly so far. Before doing this, ensure you have at least 1 tag pushed to your Docker registry with the code you want to deploy. Now on the Clusters screen, select Create Server Group/Job, choose Server Group from the drop down and hit Next to see the following dialog:

Fill out the basic settings and select your Docker image to use.

Select the Bridge network type and the port that the process in the container will listen on.

Add the labels that marathon-lb will use to route traffic to your instance.

Finally, add a health check and then click Create.

Test that you can reach your service with the following command (where $VHOST is the HAPROXY_0_VHOST value from your server group)

curl --header "Host: dev.example.com" http://$PUBLIC_AGENT

3. Git to dev pipeline

Now let’s automate the process of creating server groups associated with the dev stack. Navigate to the Pipelines tab, select Configure > Create New… and then fill out the resulting dialog as follows:

In the resulting page, select Add Trigger, and fill the form out as follows:

Now select Add Stage just below Configuration, and fill out the form as follows:

Next, in the Server Groups box select Add Server Group, where you will use the already deployed server group as a template like so:

In the resulting dialog, we only need to make one change down in the Container subsection. Select the image that will come from the Docker trigger as shown below:

Lastly, we want to add a stage to destroy the previous server group in this dev cluster. Select Add Stage, and fill out the form as follows:

4. Verification pipeline

Back on the Pipelines dialog, create a new pipeline as before, but call it “Manual Judgement”. On the first screen, add a Pipeline trigger as shown below:

We will only add a single stage, which will serve to gate access to the prod environment down the line. The configuration is shown here:

Keep in mind, more advanced types of verification can be done here, such as running a DC/OS batch job to verify that your app is healthy, or calling out to an external Jenkins server. For the sake of simplicity we will keep this as “manual judgement”.

5. Promote to prod

Create a new pipeline titled “Deploy to Prod”, and configure a pipeline trigger as shown here:

Now we need to find the deployed image in dev that we previously verified. Add a new stage and configure it as follows:

Now, to deploy that resolved image, add a new stage and configure it as follows.

Select Add Server Group, and again use the dev deployment as a template:

This time we need to make three changes to the template. First, change the “stack” to represent our prod cluster:

Next in the container section:

Lastly in the labels section:

Now to prevent all prior versions of this app in production from serving traffic once the deploy finishes, we will add a “Disable Cluster” stage like so:

Save the pipeline, and we are ready to go!

7. Run the pipeline

Push a new branch to your repo, and wait for the pipeline to run.

NEW_VERSION=v1.0.0 git checkout -b $NEW_VERSION git push origin $NEW_VERSION

Once the Manual Judgement stage is hit, use curl to “verify” your deployment.

curl --header "Host: dev.example.com" http://$PUBLIC_AGENT

Hit continue once you are ready to promote to prod.

To verify, use curl again:

curl --header "Host: prod.example.com" http://$PUBLIC_AGENT

Once the pipelines are done, you can see the dev and prod stacks in the Clusters tab:

Docs: Deploy Artifacts from Artifactory to CF

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

In this codelab, you will deploy an artifact to Cloud Foundry via a Spinnaker pipeline. The pipeline is triggered by an artifact published to a JFrog Artifactory Maven repository or by an app manifest stored in a GitHub repository.

Prerequisites

This codelab assumes you have the following:

Artifact support enabled .
An Artifactory repository configured to accept a Maven artifact—the JAR for your application
A GitHub repository containing a manifest with which to deploy your application

1. Add Artifactory Search to Spinnaker

a. Enable the Artifactory repository:

$ hal config repository artifactory enable

b. Add a search for your repository:

$ hal config repository artifactory search add spring-artifactory --base-url https://my.repo.example.com \
  	--repo my-example-repo --groupId com.example.mygroup --username example --password mypassword

2. Add Maven Account to Spinnaker

a. Enable the Maven artifact provider:

$ hal config artifact maven enable

b. Add an artifact account for Maven:

$ hal config artifact maven account add spring-artifactory-maven --repository-url https://my.repo.example.com

3. Add GitHub Account to Spinnaker

See the documentation about how to Configure a GitHub artifact account .

a. After generating an access token with the repo scope, store that token in a token file (TOKEN_FILE).

$ TOKEN_FILE=<Insert Path to Token File>

b. Enable the GitHub artifact provider:

$ hal config artifact github enable

c. Add an artifact account (GITHUB_ACCOUNT) for GitHub:

$ GITHUB_ACCOUNT=<Insert GitHub Account Name>
$ hal config artifact github account add $GITHUB_ACCOUNT \
  --token-file $TOKEN_FILE

d. Apply your changes:

$ hal deploy apply

4. Configure GitHub Repository Webhook

a. Follow the documentation about Configuring GitHub Webhooks . Take note of the secret you provide to GitHub for the webhook.

5. Configure the Application and Pipeline

a. Create a new pipeline for your application. In the pipeline configuration, add an Artifactory trigger to the Automated Triggers, as shown below.

b. In the Artifact Constraints dropdown for the Artifactory trigger, select “Define a new artifact…” and populate the Expected Artifact form with the details of the artifact that will be published to the Artifactory repository.

c. Add a Git trigger to the Automated Triggers, as shown below. Supply the secret you used in Step 4a.

d. In the Artifact Constraints dropdown for the Git trigger, select “Define a new artifact…” and populate the Expected Artifact form with the details of the manifest stored in the GitHub repository.

e. Add a “Deploy” stage to the pipeline. This stage deploys to the test environment.

f. Add a new server group and provide details on deployment settings, the application artifact, and the manifest artifact:

g. Add a “Manual Judgment” stage. You can use this stage, or stages such as “Script” or “Canary Analysis”, to verify a deployment before promoting it from the test environment.

Add any desired configuration, such as notifications for when the stage is awaiting judgment or is manually judged to continue or stop.

After you have validated and approved the deployment, the next stage (following this “Manual Judgment” stage) deploys to the production environment.

h. Add a “Clone Server Group” stage to the pipeline. This stage promotes the deployed application to the production environment.

i. Add a clone configuration and provide details on deployment settings, the source server group, and the manifest:

This clone configuration promotes the exact same application to the production environment as you deployed to the test environment with the “Deploy” stage in Step 5e.

You may wish to provide a different manifest when deploying the application to the production environment. For this alternate manifest to trigger pipeline executions, you would need to create a separate pipeline that deploys to the production environment.

6. Publish the Application Artifact or Commit Configuration Changes

a. Publish the application artifact to your Artifactory repository. You can also update the application manifest and push a new commit to its GitHub repository.

b. The published artifact or Git repository push triggers your pipeline, and you should see it deploy a new server group for the application, then promote the application to staging.

Docs: Deploy GCS Pub/Sub Artifacts to Google App Engine

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

The goal of this codelab is to trigger a Spinnaker pipeline with a Pub/Sub message from GCS upon upload of a tarball.

In this codelab, you will deploy artifacts to Google App Engine (GAE) via a Spinnaker pipeline. The pipeline is configured to trigger on Pub/Sub messages from a GCS bucket serving as an artifact repository. The Pub/Sub messages contain context that allows Spinnaker to parse and deploy the stored artifacts.

This codelab takes about an hour.

Prerequisites

This codelab assumes you have a billing-enabled GCP project. Also, install gcloud if you haven’t already.

Set up your environment

Create a GCS bucket to store artifacts

In the environment where you have gcloud installed, run the following commands:

$ BUCKET_NAME=gs://<some_name> && PROJECT_ID=<project_id>
$ gcloud auth login
$ gsutil mb -p $PROJECT_ID $BUCKET_NAME

Set up Google Cloud Pub/Sub to listen to bucket object changes

GCP documentation includes the steps for configuring GCS to publish Pub/Sub messages, but here is a summary.

Enable the Cloud Pub/Sub API .
Name your topic and subscription:

TOPIC_NAME=<topic>
SUBSCRIPTION_NAME=<subscription>

Create the GCS Pub/Sub notification: gsutil notification create -t $TOPIC_NAME -f json $BUCKET_NAME.
Verify with gsutil notification list $BUCKET_NAME.
Create a pull subscription: gcloud pubsub subscriptions create $SUBSCRIPTION_NAME --topic $TOPIC_NAME.

Configure and deploy your Spinnaker instance

Configure Spinnaker to deploy to GAE

If Spinnaker is not yet configured, install it by following the installation instructions and then add/configure the app engine cloud provider .

Note that while configuring the GAE cloud provider, you will create a service account with roles/storage.admin enabled and set two environment variables:

SERVICE_ACCOUNT_NAME=spinnaker-appengine-account
SERVICE_ACCOUNT_DEST=~/.gcp/appengine-account.json

In addition to the roles/storage.admin, the service account also needs roles/pubsub.subscriber.

Add the role to the service account:

gcloud projects add-iam-policy-binding $PROJECT \
    --role roles/pubsub.subscriber \
    --member serviceAccount:$SA_EMAIL # service account email from GAE setup.

Optionally generate a new service account key:

rm $SERVICE_ACCOUNT_DEST && gcloud iam service-accounts keys create $SERVICE_ACCOUNT_DEST \
    --iam-account $SA_EMAIL

We’ll need this service account later, so keep these environment variables handy.

Configure Spinnaker to listen to the Google Cloud Pub/Sub subscription

First, configure your GCS artifact provider.

Enable artifact support .
Enable the GCS artifact provider by adding to clouddriver-local.yml

artifacts:
  gcs:
    enabled: true
    accounts:
    - name: my-artifact-account
      json-path: /mnt/some/path

It’s recommended to use an external secrets manager instead of directly mounting secrets onto pods.

Now configure Spinnaker to receive messages from your Google Cloud Pub/Sub subscription.

Enable Google Pub/Sub by adding to the echo-local.yml:

pubsub:
  enabled: true
  google:
    enabled: true

Add your subscription to Google Pub/Sub:

pubsub:
  enabled: true
  google:
    enabled: true
    subscriptions:
    - name: my-gcs-subscription
      project: project-id
      json-path: </mnt/secretorSecretManagerReference>
      message-format: GCS

Deploy Spinnaker with these changes

Configure your pipeline

Create an application:

a. Navigate to the Spinnaker UI by going to localhost:9000 in a browser.

b. Create a new Spinnaker application by selecting Actions > Create Application.

c. Give the application a name and an admin email. If you have more than one cloud provider configured, add ‘appengine’ to the Cloud Providers.

d. Click the check box beside ‘Consider only cloud provider health when executing tasks’ and create the application.
Create a new pipeline and add an expected artifact.

a. Select the Pipelines tab in the Spinnaker UI and click Create to create a new pipeline.

b. After naming the pipeline, you will be brought to the pipeline configuration screen.

c. Add an artifact under the Expected Artifacts section of the pipeline configuration.

d. Select GCS as the artifact type.

e. In the Object path text box, put gs://$BUCKET_NAME/app.tar with the explicit value for the bucket name (Spinnaker won’t know about your environment variables).
Configure a pipeline trigger.

a. In the Automated Triggers configuration section, add a new trigger.

b. Select ‘Pub/Sub’ as the trigger type.

c. Select ‘google’ as the Pub/Sub System Type and select ‘my-gcs-subscription’ as the Subscription Name.

d. Add an attribute constraint with key ’eventType’ and value ‘OBJECT_FINALIZE’. This prevents your pipeline from triggering twice from one GCS event.

e. Select the ‘…/app.tar’ expected artifact in the Expected Artifacts drop down.

f. Save the pipeline with the Save Changes button in the bottom right corner of the pipeline configuration screen.
Create and configure a deploy stage in your pipeline.

a. Click Add stage near the top of the configuration screen to add a new stage.

b. Select ‘Deploy’ as the stage Type. Click Add server group to open the server group configuration modal.

c. In Basic Settings, select ‘GCS’ as the Source Type.

d. Select ‘my-artifact-account’ as the Storage Account.

e. Select ‘via pipeline artifact’ in Resolve URL.

f. Select the ‘…/app.tar’ artifact in the Expected Artifact drop down.

g. In Config Files, add ‘app.yaml’ in the Config Filepaths.

Package and upload your application to GCS

Acquire a “Hello World” application and upload to GCS

Clone a sample GAE application: git clone https://github.com/GoogleCloudPlatform/python-docs-samples.git
Package your application as a tarball: cd python-docs-samples/appengine/standard/hello_world; tar -cvf app.tar *
Upload the tarball to the GCS bucket: gsutil cp app.tar $BUCKET_NAME

Docs: Deploy GCS Pub/Sub Artifacts to Cloud Foundry

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

In this codelab, you will deploy an artifact to Cloud Foundry via a Spinnaker pipeline that is triggered by JAR uploads to a Google Cloud Storage (GCS) bucket.

Prerequisites

This codelab assumes you have the following:

A billing-enabled Google Cloud Platform (GCP) project.
The gcloud CLI tool (installed locally on your computer).
Artifact support enabled .

1. Create a GCS Bucket for Artifact Storage

a. Log in with gcloud:

$ gcloud auth login

b. Run the gsutil mb command to create a bucket within your GCP project, giving your project’s ID (PROJECT_ID below) and the name of the bucket to create (BUCKET):

$ PROJECT_ID=<Insert Project ID>
$ BUCKET=gs://<Insert Bucket Name>
$ gsutil mb -p $PROJECT_ID $BUCKET

2. Enable Google Cloud Pub/Sub

a. Enable the GCP Cloud Pub/Sub API, then use gsutil to create a Pub/Sub notification, giving a topic name (TOPIC) and your GCS bucket name (BUCKET):

$ TOPIC=<Insert Topic Name>
$ gsutil notification create -t $TOPIC -f json $BUCKET

b. Now create a pull subscription, giving a subscription name (GCP_SUB_NAME) and the topic name used in the last command (TOPIC):

$ GCP_SUB_NAME=<Insert Subscription Name>
$ gcloud beta pubsub subscriptions create $GCP_SUB_NAME --topic $TOPIC

3. Create a GCP Service Account

a. Following the GCP documentation on Creating and Managing Service Accounts , create a new service account, giving it the Storage Admin (roles/storage.admin) and Pub/Sub Subscriber (roles/pubsub.subscriber) roles.

b. Create a key for the service account and download the key in JSON format to your computer. In this codelab, the path to the JSON key file will be referred to as JSON_SA_KEY:

$ JSON_SA_KEY=<Insert Path to Service Account Key JSON File>

4. Tell Spinnaker to Use the Pub/Sub Subscription

a. Enable the GCS artifact provider:

$ hal config artifact gcs enable

b. Now add an artifact account for your GCS bucket, providing the path to the service account JSON key file and an account name (ACCOUNT below):

$ ACCOUNT=<Insert Account Name>
$ hal config artifact gcs account add --json-path $JSON_SA_KEY $ACCOUNT

c. Enable GCP Cloud Pub/Sub support:

$ hal config pubsub google enable

d. Finally, add the subscription you created in step 2, providing a subscription name (SPIN_SUB_NAME), your GCP project’s name (PROJECT_NAME), the GCP Cloud Pub/Sub subscription name (GCP_SUB_NAME), and the path to the service account JSON key file:

$ SPIN_SUB_NAME=<Insert Spinnaker Subscription Name>
$ PROJECT_NAME=<Insert GCP Project Name>
$ hal config pubsub google subscription add $SPIN_SUB_NAME \
--project $PROJECT_NAME \
--subscription-name $GCP_SUB_NAME \
--message-format GCS \
--json-path $JSON_SA_KEY

e. Apply your changes:

$ hal deploy apply

5. Configure the Application and Pipeline

a. Create a new pipeline for your application. In the pipeline configuration, under Automated Triggers, add a new trigger and configure it as follows:

For Type, select “Pub/Sub”.
For Pub/Sub System Type, select GCP Cloud Pub/Sub.
For Subscription Name, select your GCP Cloud Pub/Sub Spinnaker subscription.
Under Attribute Constraints, add an entry with the key eventType and value OBJECT_FINALIZE (see the Google Cloud Storage documentation ).

b. In the Artifact Constraints dropdown, select “Define a new artifact…” to bring up the Expected Artifact form. Provide the artifact information:

For Display Name, enter your own artifact display name or keep the auto-generated default.
In the Account dropdown, select your GCS account.
In the Object path field, enter the path to the artifact.

c. Click Save Artifact.

d. Add a Deploy stage to the pipeline. Create a new server group and provide details on deployment settings, the application artifact, and the manifest artifact:

6. Upload the Application and Manifest Artifacts

a. Upload the application manifest and application archive to your GCS bucket. With the pipeline trigger for your GCP Cloud Pub/Sub subscription, the pipeline will run when you upload the application archive to the bucket. The below example uses the gsutil cp command:

$ gsutil cp application.jar $BUCKET

b. The GCS bucket upload will trigger a pipeline execution, and you should see the pipeline deploy a new server group for the application.

Docs: GCE Source To Prod

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

In this codelab, you create a cohesive workflow which takes source code and builds, tests and promotes it to production. You can also watch a video of this codelab in this Youtube playlist .

This will be accomplished via 3 pipelines:

Bake & Deploy to Test
Validate Test
Promote to Prod

You will be using a custom-built image that includes sample application source code, a Jenkins instance, a Debian repository (aptly) and a Spinnaker instance.

This codelab is an extension of the Hello World Deployment tutorial. It runs specifically on the Google Cloud Platform, and requires a billing-enabled GCP project.

Part 0: Set up environment

Install gcloud

If you have gcloud installed, skip to the next section, “ Provision an instance of Spinnaker ”.

Install gcloud by running the following command and following through the prompts:

curl https://sdk.cloud.google.com | bash

Authenticate gcloud to your account with your email address:

gcloud auth login <your email address>

Enable the Compute Engine API

Navigate to the Google Cloud Console and enable the Compute Engine API .

Provision an instance of Spinnaker and Jenkins

We’ve created a single GCE image that includes Spinnaker, Jenkins, and aptly, along with embedded startup scripts that configure everything together for you. Create an instance of this image by running the following commands.

Fill in your project for $MY_PROJECT

MY_PROJECT=<your project>
INSTANCE_NAME=spinnaker-codelab
ZONE=us-east1-b

gcloud compute instances create $INSTANCE_NAME \
    --project $MY_PROJECT \
    --zone $ZONE \
    --image spinnaker-codelab \
    --image-project marketplace-spinnaker-release \
    --machine-type n1-highmem-4 \
    --scopes cloud-platform \
    --metadata startup-script=/var/spinnaker/startup/first_codelab_boot.sh,gce_account=my-google-account

Spinnaker will take a few minutes to auto configure and start up. Take 3 minutes to skim through Part 1 of this codelab below…

Open an SSH tunnel through which your local workstation will connect to Spinnaker:

gcloud compute ssh $INSTANCE_NAME \
    --project $MY_PROJECT \
    --zone $ZONE \
    --ssh-flag="-L 8084:localhost:8084" \
    --ssh-flag="-L 9000:localhost:9000" \
    --ssh-flag="-L 5656:localhost:5656"

Part 1: Bake & deploy to test

In this first exercise, you’ll set up a pipeline, named Bake & Deploy to Test, which builds a GCE image, deploys it as a server group to a test cluster, then destroys the previous server group in that cluster (also called the “Highlander” strategy). The pipeline is triggered by a Jenkins continuous integration job.

The workflow is shown in the figure below.

Create a Spinnaker application

Navigate to Spinnaker at http://localhost:9000 .

From the Spinnaker home page, create a new Spinnaker Application by clicking on the Actions drop down at the upper right and clicking on Create Application.

In the New Application dialog:

Enter “codelab” for Name.
Enter your email for Owner Email.
Click the Create button.

Create a load balancer

First we create a load balancer for your cluster. Navigate to the LOAD BALANCERS tab, click the Create Load Balancer button, and select Network as the type of load balancer.

Enter “test” for Stack.
In the Listener section, set the Port Range to be 8080, as that’s the port that our sample application listens on.
In the Health Check section, enter “8080” for Port and “/hello” for Path.
Optionally, enter 1 for all advanced settings values so server groups report healthy much faster.
Click the Create button.

Set up pipeline: “Bake & Deploy to Test” pipeline

The purpose of this pipeline is to generate a GCE image from a package, and then deploy the image on server groups in the test cluster. We want this pipeline to be kicked off every time the Jenkins continuous integration job completes.

Create a new pipeline by navigating to the PIPELINES tab and clicking the Create button

Name the pipeline “Bake & Deploy to Test”.
Click the Create button.

Configure the pipeline

The first step in setting up a pipeline is to configure the pipeline. In particular, we need to specify an automated trigger that will kick off the pipeline.

We want this pipeline to kick off every time our Jenkins job completes. In the Automated Triggers section of the pipelines form:

Click Add Trigger.
Select “Jenkins” from the drop down menu for Type.
Specify “CodelabJenkins” for the Master Jenkins instance.
Specify “Hello-Build” for Job.

Refer to the figure below for an illustration of what the pipeline’s Configuration form looks like when we’re done.

Set up Bake stage

The purpose of our “Bake” stage is to create a GCE image with the package that was built by the Jenkins job that triggered this pipeline.

Click Add stage.
Select “Bake” in the Type drop down.
Enter the Debian package you wish to include, “hello-karyon-rxnetty”, in the Package field.
Select “trusty” as the Base OS.

Set up Deploy stage

The purpose of the “Deploy” stage is to take the GCE image constructed in the “Bake” stage and deploy it into a test environment.

Click Add stage.
Select “Deploy” in the Type drop down.
In the Deploy Configuration section, click Add server group.
In the dialog that appears, click Continue without a template.
In the Basic Settings section, enter “test” in the Stack field.
In the Load Balancers section, add your load balancer (“codelab-test”).

Security groups map to GCP firewall rules, along with the use of target tags to route traffic. There are default firewall rules in place which are sufficient for our use here.

Click on the Instance Type tab on the left.
In the Instance Type section, choose “f1-micro” in the drop down.

In the Capacity section, leave 1 as the number of instances and click Add.

Set up Destroy Previous Server Group stage

In this tutorial use case, on successive deployments of new server groups to the test cluster, we don’t need the previous server group anymore.

Click Add Stage.
Select “Destroy Server Group” for Type.
Check us-east1, the region of the previous test server group that you want to destroy.
Enter codelab-test for the Cluster.
Select “Previous Server Group” for Target.
Click Save Changes.

The pipeline is now complete. Take a moment to review the stages of this pipeline that you just built.

Try it out

Now let’s run this pipeline. We trigger it by manually running a Build of the Jenkins job.

Navigate to your Jenkins console at http://localhost:5656 .
- Username: admin
- Password: admin
Click on the “Hello-Build” job.
Click Build Now.

It may take a while for the polling to trigger the job, but soon in the PIPELINES tab you can see progress, status and details.

The first time this pipeline is run, the Destroy Server Group stage will fail, because the selector for “Previous Server Group” will find nothing (no server groups presently in the test cluster). The Deploy stage, however, does succeed, so a test cluster will be created.

Try running it again, either by running another Build of the Jenkins job, or by manually triggering from the PIPELINES tab (click Start Manual Execution). It will succeed all the way, and your pipeline execution details will look like below:

You can now see in the CLUSTERS tab that a new server group has been deployed to the test cluster, and the previous server group is destroyed (i.e. does not exist).

You can also introspect server group details by clicking on a server group. In the details panel on the right, you can see under the PACKAGE section details about how we built this server group. Information like package name, build number, down to commit hash and link to the Jenkins job.

Part 2: Validate test

The second pipeline, named “Validate Test”, is a simple one-stage placeholder to represent some gating function before pushing to prod.

Furthermore, we configure the prod deployment to implement the red/black strategy (a.k.a. blue/green), which means that upon verifying health of the new server group it will immediately disable the previous server group in the same cluster. Here we disable rather than destroy, so that rollbacks can be quickly accomplished simply by re-enabling the old server group.

Set up pipeline: “Validate Test” pipeline

Create a new pipeline by navigating to the PIPELINES tab and clicking Configure, then Create New …

Name the pipeline “Validate Test”.
Click the Create button.

Configure the pipeline

We want this pipeline to kick off when the Bake & Deploy to Test pipeline completes.

Click Add Trigger.
Select “Pipeline” from the drop down menu for Type.
Select your application.
Select the “Bake & Deploy to Test” pipeline.
Check “successful”.

Set up Manual Judgment stage

We stop and wait for human confirmation to continue:

Click Add stage.
Select “Manual Judgment” in the Type drop down.
Specify Instructions, for example “Validate the test cluster”.
Click Save Changes.

Part 3: Promote to prod

The third pipeline, “Promote to Prod”, takes the image that was deployed in the test cluster, and deploys that image to the prod environment, thereby promoting it.

Create a load balancer

We create a load balancer for the prod cluster. Navigate to the LOAD BALANCERS tab and click the Create Load Balancer button:

Enter “prod” for Stack.
In the Listener section, set the Port Range to 8080.
In the Health Check section, enter “8080” for Port and “/hello” for Path.
Optionally, enter 1 for all health check values.
Click the Create button.

Set up pipeline: “Promote to Prod” pipeline

Create a new pipeline by navigating to the PIPELINES tab and clicking Configure, then Create New …

Name the pipeline “Promote to Prod”.
Click the Create button.

Configure the pipeline

We want this pipeline to kick off when the Validate Test pipeline completes.

Click Add Trigger.
Select “Pipeline” from the drop down menu for Type.
Select your application.
Select the “Validate Test” pipeline.
Check “successful”.

Set up Find Image stage

In the “Find Image” stage, we select the image that was deployed in the test cluster.

Click the Add stage button:

Select “Find Image from Cluster” for the stage Type.
Check the region of the test server group to pick the image from.
Enter codelab-test for the Cluster.
Choose “Newest” for the Server Group Selection.

Set up the Deploy stage

We deploy the image that was picked, to the prod cluster.

Click Add stage.
Select “Deploy” in the Type drop down.
In the Server group section, click Add server group.
In the dialog that appears, click Continue without a template.
In the Basic Settings section, enter “prod” in the Stack field.
For Strategy, select “Red/Black”. Note: Blue/Green replaces Red/Black in Spinnaker v1.30+.
Enter “2” as the Maximum number of server groups to leave
In the Load Balancers section, add your load balancer (“codelab-prod”).
and click the Instance Type tab on the left.

In the Instance Type section, choose “f1-micro” in the drop down.
In the Capacity section, leave 1 as the number of instances and click Add.
Click Save Changes to save your prod pipeline.

Trying it out

Now let’s run through it all. Run a Build in Jenkins.

When the Bake & Deploy to Test pipeline completes, the Validate Test pipeline will trigger and wait for user input.

Click Continue. This will trigger the Promote to Prod pipeline:

In the CLUSTERS tab, you can see that a server group has been deployed to the prod cluster.

Because we selected the red/black (blue/green) deployment strategy for the deployment, there should always be only one enabled/active server group resident in the prod cluster cluster, with previous ones disabled (grey), even after successive runs of this pipeline. Try it out by manually invoking the promotion pipeline again.

Extra stuff

Roll back

Sometimes things go wrong and you need to roll prod back to the previous release. We employed the red/black (blue/green) strategy, which disables the previous server group. In practice, this is disassociating the server group from the load balancer so it takes no traffic, while keeping the nodes in the server group up, standing by.

To roll back back to the previous server group, first kick off another instance of the Promote to Prod pipeline so that you have a previous disabled server group in the PROD cluster to roll back to. When this pipeline completes, navigate to the CLUSTERS tab and click the active server group.

In the Server Group Actions drop down on the right, click Rollback.
In the dialog that appears, select the server group you would like to restore (that is, the server group you would like to roll back to).
Click Submit.

When the task completes (you can check progress in the TASKS tab), you will see that the specified server group is now the active one, while the previous one is disabled (grey).

Triggering the Jenkins job by changing source

So far you’ve been triggering the Jenkins job manually over unchanging source code. Consequently, you’ll notice that all server groups point back to the same Jenkins job. This is because Spinnaker can detect whether a re-bake is necessary, and because there were no changes, it simply returned the same image.

The image you’re using does have Jenkins polling for updates to the local git repo. If you trigger the Jenkins job as a result of a code change, the image that’s built will be different, and you’ll see the build info change throughout the entire pipeline chain.

You can update source by doing the following from your ssh terminal:

sudo su jenkins
cd /var/lib/jenkins/hello-karyon-rxnetty

Now change the number on the “release” line:

vi build.gradle

Finally, commit your changes to trigger a new Jenkins build:

git commit -a -m "Bump release number"

You’ll see the whole sequence again, but with a key difference: a new image will be baked, and the server groups deployed as a result will show different build info.

Docs: An Introduction to Spinnaker: Hello Deployment

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

This guide will run through the workflow of setting up an example application deployment with Spinnaker. It assumes you already have Spinnaker up and running on AWS or GCE. A guide for installation can be found here .

Below is a diagram of the workflow we will set up.

Set up Jenkins

Jenkins is a powerful continuous integration server that allows us to do several important things:

Poll our Github repository for changes so Spinnaker knows when to run a pipeline.
Compile and build our example application into a .deb package so Spinnaker can bake it on an image. Spinnaker expects all applications to be deployed as deb packages.

Installing Jenkins

If you already have a Jenkins server, you can skip this step.

In the event you run into issues with these example commands, refer to the instructions at http://pkg.jenkins-ci.org/debian/ for updated commands.

SSH into your instance and run the following:

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install openjdk-8-jdk
wget -q -O - https://pkg.jenkins.io/debian/jenkins.io.key | sudo apt-key add -
sudo sh -c 'echo deb https://pkg.jenkins.io/debian binary/ > /etc/apt/sources.list.d/jenkins.list'
sudo apt-get update
sudo apt-get install jenkins git

Configuring Jenkins

By default, Jenkins listens on port 8080, which is the same port that Spinnaker’s front50 microservice uses. In order to have both installed on the same machine, you’ll need to configure one of them to listen on a different port. These instructions will configure Jenkins to listen on port 5656. You’ll need to ensure that this port is accessible by your Spinnaker instance.

Edit your Jenkins configuration file at /etc/default/jenkins and change the HTTP_PORT entry to:

HTTP_PORT=5656

Now run sudo service jenkins restart to restart Jenkins. Visit port :5656 on your instance and you should see Jenkins start up and present the dashboard.

Enable Jenkins API

Spinnaker communicates with Jenkins by using its REST API. However the API is not enabled by default. To enable it we first must enable global security (which is a good idea anyway). Click “Manage Jenkins” then “Configure Global Security”. Under Access Control check “Jenkins own database” and “allow users to sign up”. Under authorization check “Logged-in users can do anything” and save.

You will now be presented with a login screen. Click the “Create an account” link to register. Take note of your username and password, Spinnaker will need them later. Now you can turn off allowing users to register as you can add them manually from the control panel. The Jenkins API is now enabled.

Set up deb repo

There are several options you can use to set up your private deb repo. This involves leveraging a tool to create the file structure and format for your .deb packages. You will also need to serve them publicly on the internet so they can be installed.

deb-s3

deb-s3 is a ruby gem that allows you to create a publish your packages directly to an s3 bucket. The nice part about this is that you do not have to concern yourself with setting up ports or configuring a web server. S3 handles everything for us.

First create a new s3 bucket to hold your packages, take note of the name and region.

Next edit the properties of your bucket and turn on static website hosting.

We will now install deb-s3 on our Jenkins server.

sudo apt-get install software-properties-common
sudo apt-add-repository ppa:brightbox/ruby-ng
sudo apt-get update
sudo apt-get install build-essential ruby2.2 ruby2.2-dev zlib1g-dev liblzma-dev
sudo gem install bundler

now install the deb-s3 gem globally

sudo gem install deb-s3

The address of your repo will now be http://BUCKET-NAME.s3-website-REGION-NAME.amazonaws.com trusty main

Aptly

Aptly is a tool that easily allows us to manage and publish the packages to the local filesystem. After we install and configure the tool, nginx will host the repository on our jenkins server so it can be consumed during the bake process. Since nginx will run on port 9999 it is important that this port on your Jenkins server will be accessible from the internet.

The following will install aptly to the jenkins user home directory so our jobs can easily use it. We will also create our repo so the jobs can easily add packages.

sudo su - jenkins
cd ~
wget https://dl.bintray.com/smira/aptly/0.9.5/debian-squeeze-x64/aptly
chmod +x aptly

Create our repo named “hello”

./aptly repo create hello

We will now publish our (currently empty) repo and set up nginx to host it on port 9999.

./aptly publish repo -architectures="amd64" -component=main -distribution=trusty -skip-signing=true hello

Set up Nginx to serve aptly deb repo

Install and configure nginx

sudo apt-get install nginx
sudo vim /etc/nginx/sites-enabled/default

Contents of /etc/nginx/sites-enabled/default:

server {
        listen 9999 default_server;
        listen [::]:9999 default_server ipv6only=on;
        root /var/lib/jenkins/.aptly/public;
        index index.html index.htm;
        server_name localhost;
        location / {
                try_files $uri $uri/ =404;
        }
}

Start nginx sudo service nginx start

the address of the repo will be http://JENKINS-SERVER:9999 trusty main

Fork example application

We have set up an example application with a gradle.build ready to package your app for spinnaker deployment. Fork https://github.com/kenzanlabs/hello-karyon-rxnetty via the github UI so you can make changes and see them flow through the Spinnaker pipeline.

Create Jenkins jobs

We will now set up our Jenkins jobs for spinnaker to use.

Polling job

The first is a simple job that polls our git repo for changes. Spinnaker has no knowledge of our repo location, so it needs a way to trigger a pipeline automatically when code is pushed. (A pipeline is a set of actions that handle the application delivery) Spinnaker will poll our polling job and kick off a pipeline when it detects a fresh run.

Ensure the Jenkins git plugin is enabled and create a new freesyle Project named “Hello Poll”.
Add your app fork git address.
Under build triggers check “Poll SCM” and enter * * * * * for Jenkins to poll once a minute. You can now save the job.

Build and publish job

This job will be responsible for building and publishing our package, along with passing the package and version name to Spinnaker.

Create a new freestyle job named “HelloBuild”.
Add the git url for your application fork
Add a build step for “execute shell”
In the textbox, cleanup prior builds and execute the packDeb task ./gradlew clean packDeb
If you used deb-s3 for your repo, add the following:
- deb-s3 upload --bucket BUCKETNAME --arch amd64 --codename trusty --preserve-versions true build/distributions/*.deb
If you used aptly for your repo, add the following:

~/aptly repo add -force-replace hello build/distributions/*.deb ~/aptly publish update -force-overwrite -architectures="amd64" -skip-signing=true trusty

Add a post-build action: “Archive the artifacts” with build/distributions/*.deb as the directory. This allows our deb package name to be passed to spinnaker.

Configure Spinnaker

SSH to your Spinnaker instance by tunneling the needed ports. Tunneling ensures that Spinnaker is not accessible from the internet outside of your ssh connection. This is very important because anyone who has access to Spinnaker can do anything your cloud account can do.

The ports needed:

9000: html/js UI (Deck)
8084: API entrypoint (Gate)
8087: Image bakery (Rosco)

ssh -i yourkey.pem -L 9000:127.0.0.1:9000 -L 8084:127.0.0.1:8084 ubuntu@instanceip

Spinnaker will be accessible on http://localhost:9000 .

Jenkins integration

Before we can begin setting up our workflow, we need to edit the Spinnaker configuration to allow it to communicate with our Jenkins server.

Begin by shutting down Spinnaker. Spinnaker configuration is stored in memory so we need to reload it every time we make a change. You can now edit the master configuration file:

vim /opt/spinnaker/config/spinnaker-local.yml

Scroll down to jenkins section and add your url, username and password from above

  jenkins:
    defaultMaster:
      name: Jenkins # The display name for this server
      baseUrl: http://jenkins-server:5656
      username: jenkinsuser
      password: jenkinspassword

You also need to enable igor, the service that communicates with the jenkins api.

igor:
    enabled: true

Deb repository

The last configuration step is to add our deb repository address to the Rosco config. When Spinnaker is baking the application image, it will add this address to the sources list so it can apt-get install the deb package. For this reason it is important that port 9000 is open on our Jenkins server which hosts the repo.

vim /opt/rosco/config/rosco.yml

Add your repo address from above. For example if we used deb-s3:

debianRepository: http://BUCKET-NAME.s3-website-REGION-NAME.amazonaws.com trusty main

We can now start Spinnaker and start configuring our workflow. # start spinnaker

Create Spinnaker application and resources

The concept of an application allows us to group our resources and pipelines in a logical way. This makes it easy to manage our app in a single place instead of searching for items buried in menus.

Visit http://localhost:9000 and click the actions button -> create application.
Fill out the information, naming it “hello” and click save. We are now ready to add resources to our app.

Create firewall

Now we will create a firewall to allow access to our application. Spinnaker only allows you to attach ingress sources based on another firewall, so we first must create a base security group via the aws console to allow traffic on port 5656 (AWS Security Groups map to Firewalls in Spinnaker).

Now we can use this group as an inbound rule for our application firewall. Click the firewalls tab and add a new firewall.

Select our group as ingress source

Create load balancer

The load balancer will be the entry-point to our application scaling group. Click the load balancers tab and add it.

Set up Spinnaker pipeline

We now have the necessary resources to begin pipeline creation. A pipeline is a group of actions that handle the complete lifecycle of our deployment. It is also a great centralized place to monitor the status of each stage instead of hopping between jenkins or the aws console.

Our pipeline is triggered by polling our Jenkins server to see if our code has updated. We then create two stages.

Click the pipelines tab and add a new pipeline.

Pipeline trigger

Add a trigger and select “jenkins job” then we can select our jenkins server and choose the “hello poll” job. Spinnaker will poll jenkins for a successful run of this job. We know that if it ran then there is new code to deploy from github

Build and package stage

The first stage in our pipeline will be to build and package our app. This also published our deb to our repository for baking. Choose Jenkins for type and select our “hellobuild” job.

Bake stage

The next stage will bake our application. “Baking” refers to booting up an instance, installing our application package, and saving the os image for launching. All of this is handled by packer . Because our build stage returns the name of our deb artifact and knows our repo address, we simply need to select the region(s) and add our application package name. We can also take advantage of the async features of spinnaker and do a multi-region bake.

Deploy stage

Spinnaker will automatically pass our baked image id to the deploy stage. This is where we set up our server group to be deployed to a cluster.

Click “add server group” and configure the server group.

Our app is fairly lightweight so t2.micro will be fine for instance type.

Choose two instances so we can be sure they our load balanced correctly. Our application will display the instance id so we can easily confirm this.

Triggering the pipeline

We can trigger our pipeline several ways. The first way is to simply push to our github repo. Jenkins will detect this and run our polling job, which Spinnaker will detect and kick off our pipeline.

We then can see our pipeline progress to the bake stage.

Finally we reach our deploy stage where our server group is created.

We can also manually trigger the pipeline by clicking the “start manual execution” button. Then we can select a specific build of our app from Jenkins for Spinnaker to use.

Docs: Kubernetes Source to Prod

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

Overview

In this codelab you will configure:

A GitHub repo containing both your code to be deployed, and the Kubernetes manifests that will run your code.
A set of Spinnaker pipelines to deploy changes to your code, manifests, and application configuration from source to production.

0: Prerequisites

Before we begin, we need to do the following:

Configure GitHub

You need some source code and manifests to deploy stored in GitHub. We have a repository you can fork to follow along easily.
Configure DockerHub

The source code in GitHub will be configured to build automatically on tag pushes.
Configure Kubernetes

Two Kubernetes clusters, one for staging and one for prod.
Configure Spinnaker

A running Spinnaker instance, able to deploy to Kubernetes and download artifacts from GitHub.
Configure Webhooks

GitHub & DockerHub webhooks pointing at Spinnaker, alerting when commits and docker images are pushed respectively.

Configure GitHub

The code we’ll be deploying is stored here . Feel free to fork this into your own account, and make changes/deploy from there.

☞ Note: The manifests in this repository point to a specific docker image . If you want to trigger off of changes made to your own docker image, change the image name to reflect that.

Configure DockerHub

If you’re completely unfamiliar with Docker, start here .

This guide covers how to get your GitHub repository (from above) to trigger Docker builds in DockerHub. We’ll be relying on this to automatically push code changes into your staging environment. In the end your repository should look something like this .

☞ Note: Before continuing, run the created trigger at least once to both push a :latest image, as well as validate that your configuration is working. This can be done by pushing a commit to your GitHub repo to trigger a Docker build.

Configure Kubernetes

Create two clusters following one of the guides here . Once you are finished, make sure that you have an up-to-date ~/.kube/config file that has entries for both clusters you want to deploy to. Details on kubeconfig files here .

Configure Spinnaker

We will be deploying Spinnaker to one of your Kubernetes clusters. To do so, start by installing it here .

Configure Storage

Setup storage as per here

Add your Kubernetes accounts

You will need to configure two Kubernetes accounts. See the Kubernetes contexts created in the prior step using:

kubectl config get-contexts

The output should look like (although the names may vary):

CURRENT   NAME                       CLUSTER        AUTHINFO       NAMESPACE
*         staging-demo-us-central1   staging-demo   staging-demo
          prod-demo-us-central1      prod-demo      prod-demo

Record the names of the contexts as $STAGING_CONTEXT and $PROD_CONTEXT.

Now we will register both contexts with Spinnaker. See https://spinnaker.io/docs/setup/install/providers/

Configure GitHub artifact credentials

Make sure to add GitHub as an artifact account . This will allow us to fetch the manifests later.

Configure Docker Registry account

Make sure to add a Docker Registry provider account . This will allow us to configure a Spinnaker pipeline to trigger on a Docker image update.

Deploy Spinnaker

Deploy spinnaker using kustomize and the installation docs

Configure webhooks

Now that Spinnaker is running, you need to point both Docker and GitHub webhooks at Spinnaker to send events when Docker images and manifest changes happen respectively.

Give Spinnaker an external endpoint

:warning: This is for the codelab only! Do not do this in production. We’re giving an unsecured Spinnaker an external endpoint to easily do this codelab, and are taking limited measures to ensure only GitHub and Docker can trigger pipelines. Tear down Spinnaker once you’re done with this codelab, or remove any firewall changes to your Kubernetes cluster.

First, edit the Gate service to bind a node port. This means every node in your Kubernetes cluster will forward traffic from that node port to your Spinnaker gate service. Your nodes should not be accepting requests from external IPs by default, so making this change doesn’t immediately open Spinnaker to public access.

To do this, first run (this will open the service manifest in your text editor):

kubectl edit svc spin-gate -n spinnaker --context $STAGING_CONTEXT

and then change the field

type: ClusterIP

type: NodePort

Next, get the port that spin-gate has bound to. You can check this with

kubectl get svc spin-gate -n spinnaker --context $STAGING_CONTEXT

In my case, I see the port is 31355, which I record into $NODE_PORT (8084 is the port gate is listening on inside the cluster):

NAME        TYPE       CLUSTER-IP    EXTERNAL-IP   PORT(S)          AGE
spin-gate   NodePort   10.7.255.85   <none>        8084:31355/TCP   32m

Now pick any node in the cluster and record its IP as $NODE_IP. In order to get the IP of a node, first get the nodes in the cluster and record one of the names as $NODE_NAME:

kubectl get nodes

Next run the following command to get information about the node and record the ExternalIP as $NODE_IP:

kubectl describe node $NODE_NAME

For the purposes of this codelab, we’ll be sending external webhooks to $NODE_PORT on that node. In order for these webhooks to work, for this codelab only, open your firewall on that node to all addresses for TCP connections on $NODE_PORT. If you were running Spinnaker in production with authentication , only webhooks would be allowed, which you can reject by header or payload. See the webhook guide for more details .

Allow Docker to post build events

These will be used to trigger pipelines based on new Docker images being published. Follow the steps shown here for your repository. The endpoint you configure must be http://${NODE_IP}:${NODE_PORT}/webhooks/webhook/dockerhub.

Allow GitHub to post push events

Follow the steps shown here , where ENDPOINT=http://${NODE_IP}:${NODE_PORT}. Keep track of what you pick as the $SECRET!

1: Create a Spinnaker application

When you first open Spinnaker (if you’ve followed the above prerequisites ) it’ll be running on localhost:9000) you’ll be greeted with the following Applications screen.

By default, Spinnaker indexes your entire cluster, which explains why the screen is prepopulated with unrelated infrastructure. This can be changed by omitting namespaces defined in kubernetes accounts documented here .

Select Actions > Create Application, and fill out the form as shown (the owner email will of course be different):

After hitting Create, you should be brought to an empty Clusters tab:

2: Create a “Deploy to Staging” pipeline

Let’s deploy the manifests and code in our staging cluster by setting up automated pipelines to do so. Start by navigating to Pipelines > Configure a new Pipeline. Name the pipeline as shown and hit create:

At this point we want to add the manifest from GitHub as an expected artifact in this pipeline, meaning we expect each time that this pipeline executes, either a GitHub event will supply us with a new manifest to deploy, or we will use some default or prior manifest.

Select Add Trigger:

Supply the following configuration values:

Field	Value
Type	“Git”
Repo Type	“GitHub”
Organization or User	The user you forked the above code into.
Project	“spin-kub-v2-demo”
Secret	The `$SECRET` chosen above .

We supply the expected artifact to be sure that we only trigger the pipeline when that file changes.

Next we will define a new artifact in the Artifact Constraints field. For Account, select the GitHub artifact account created earlier and then set the File Path to manifests/demo.yml. Lastly, select Use Prior Execution, to tell Spinnaker that if no matching artifact is found, use the last execution’s value. (This will be useful later).

Supply the following configuration values:

Field	Value
Type	“Git”
Repo Type	“GitHub”
Organization or User	The user you forked the above code into.
Project	“spin-kub-v2-demo”
Secret	The `$SECRET` chosen above .
Expected Artifacts	Must reference the `manifests/demo.yml` artifact.

We supply the expected artifact to be sure that we only trigger the pipeline when that file changes.

With the trigger configuration in place, let’s configure a “Deploy manifest” stage.

First add a stage:

Then select the “Deploy (Manifest)” stage type:

Finally, configure the stage with the following values:

Field	Value
Account	“staging-demo”
Cluster	“demo”
Manifest Source	“Artifact”
Expected Artifact	Must reference the `manifests/demo.yml` artifact.
Artifact Account	The GitHub artifact account configured above.

Save the pipeline.

3. Deploy manifests to staging

Trigger the pipeline by pushing a commit to the manifests/demo.yml file in your repository. The pipeline should start in a few seconds. When it completes, click Details to see information about the execution:

There are a couple of things to notice here:

In the top left we get details about the commit that triggered this pipeline.
In the Deploy Status we can see what the YAML was that Spinnaker deployed.
We see that the ConfigMap that we deployed was assigned version -v000. This was done to ensure that you can statically reference this ConfigMap, insulating any Pod that references it from accidental changes.

Next, let’s see what this infrastructure looks like in Spinnaker. Navigate to the Clusters tab, and select the blue Deployment object attached to the Replica Set shown below:

We can see in the Artifact section on the right that we have bound our Docker image as well as our ConfigMap.

Let’s see what our application is serving. Run:

kubectl proxy --context $STAGING_CONTEXT

And then visit the sample service in your browser. Let’s make a change to this service, and configure Spinnaker to listen to Docker builds.

4. Configure Docker triggers

Important: We need to configure DockerHub to build on Tag events only, if we build on every commit, this particular setup will trigger both when manifests & code are changed at once. This can be configured under your Docker repository’s Build Settings tab as shown here:

This build rule will create a matching image tag each time you push a git tag.

Next, in Spinnaker, let’s edit our Pipeline to allow Docker images to trigger a deployment:

First, add another automated trigger next to our Git trigger. Select Type Webhook and input dockerhub for the Source.

Next, define a new artifact in the Artifact Constraints field. For Account, select the Docker Registry account created earlier and input your docker image under Docker image.

Finally, back in the “Deploy (Manifest)” stage configuration, select the Docker artifact to bind in this deployment:

Save the pipeline.

5. Deploy Docker to staging

You can push a tag to your repository by running:

git tag release-1.0
git push origin release-1.0

Notice that this time the trigger was a Webhook trigger, and we see details about both types of artifacts that we deployed. Since the GitHub file artifact was configured to Use Prior Execution, we redeployed the same manifests as last time, but with a new Docker image. Because of this, we did not deploy a new ConfigMap, and kept the version at -v000.

This deployment is a lot faster than the last one, since the docker image was already pulled into our cluster, meaning it took less time for the images to start running and appear as “Healthy”.

Back on the Clusters tab we can see the deployment has rolled out our new image:

6. Configure a validation pipeline

For the sake of a simple codelab, we will control which deployments make it to production by adding a “Manual Judgement” pipeline. In practice, this can be replaced by a canary, integration test suite, or other mechanism for validating staging; however, keeping the manual judgement stage is fine too.

Start by creating a new pipeline, and call it “Validate Staging”:

We only want this pipeline to run when we successfully deploy to our staging environment, so create a Pipeline trigger in this new pipeline like shown:

Add a single stage with type “Manual judgement”:

If desired, you can add additional “Instructions” for how to validate the cluster:

Save the Pipeline.

7. Promote to production

Let’s promote these artifacts into our production cluster. Create a new pipeline, but instead of creating it from scratch, let’s copy the “Deploy to Staging” pipeline like this:

We need to make two changes to this pipeline:

First, delete the webhook and Git triggers, and replace it with a pipeline trigger that depends on the “Validate Staging” pipeline:

Next, change the Account the “Deploy (Manifest)” stage deploys to point at prod-demo:

8. Run the full flow

Now our full flow is ready to go - let’s kick it off by changing the background color of our application.

Open content/index.html in your text editor, and change the background color attribute, and generate a new commit. We can safely push this commit to GitHub without running our pipeline because we are only listening to change to the manifests/demo.yml file in our “Deploy to Staging” trigger. Tag and push this commit to generate a new docker build:

git tag release-1.1
git push origin release-1.1

When Spinnaker prompts you, accept (or reject) the manual judgement:

Keep in mind, if you reject the manual judgement, but later change your mind, you can always trigger this pipeline again using the same context by selecting Start manual execution, and picking the latest parent execution:

Once all three pipelines complete, you should have your docker image running in both environments:

9. Extra credit

At this point there are few things you can play with:

Change the ConfigMap definition in the manifest file. In particular, flip the single flag from “false” to “true”. See what happens to the ConfigMap version.
Roll back a “broken” change either in prod or staging using the “Undo Rollout” stage.
Insert pipeline expressions into your manifest files.

10. Teardown

As referenced above, please teardown Spinnaker once you are done:

hal deploy clean

Docs: Oracle Cloud Infrastructure Source to Prod

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

In this codelab, you will create a cohesive workflow which takes source code and builds, tests, and promotes it to production.

Building the binary from the source code is done outside of Spinnaker, typically in a CI system such as Jenkins, Travis, etc. Spinnaker is integrated with three CI systems. Workflows can be triggered by jobs in these CI systems. The easiest binary form for Spinnaker to produce machine image is debian or rpm packages.

To simplify this tutorial, we will use tomcat8 debian package as a starting point. It is assumed your CI jobs build and publish packages such as tomcat8 and your CI jobs will be used to trigger the Spinnaker workflow.

This tutorial covers the workflow which takes a package and bakes a machine image and then deploys, tests, and promotes it to production.

This will be accomplished via 3 pipelines:

Bake & Deploy to Test
Validate Test
Promote to Prod

Part 0: Set up environment

Create a compute instance

Create a compute instance on Oracle Cloud Infrastructure (OCI) to host Spinnaker by following these instructions . Spinnaker supports Ubuntu 18.04 or higher.

Install and configure Spinnaker

SSH onto the compute instance you previously created. IP is its public ip address.

ssh ubuntu@IP

Set up Oracle Object Storage as your Spinnaker storage by following these steps: Adding Oracle Object Storage to Spinnaker .
Set up your Oracle Cloud provider account by following these Adding Oracle Cloud Provider Account to Spinnaker steps.
Set up your Oracle Bakery by following these Configuring Oracle Cloud Infrastructure Bakery steps.

Note that Oracle-provided images have a default set of firewall rules which allow only SSH access. To bake an image that allows HTTP access like in this tutorial, you need a custom bake template like this one to place in ~/.hal/default/profiles/rosco/packer/codelab.json.

{% raw %}

{
  "variables": {
    "oracle_availability_domain": null,
    "oracle_region": null,
    "oracle_base_image_id": null,
    "oracle_compartment_id": null,
    "oracle_image_name": null,
    "oracle_instance_shape": null,
    "oracle_ssh_user_name": null,
    "oracle_subnet_id": null,
    "oracle_tenancy_id": null,
    "oracle_user_id": null,
    "oracle_fingerprint": null,
    "oracle_ssh_private_key_file_path": null,
    "oracle_pass_phrase": "",

    "appversion": "",
    "build_host": "",
    "build_info_url": "",
    "repository": "",
    "package_type": "",
    "packages": "",
    "upgrade": "",
    "configDir": null
  },
  "builders": [
    {
      "type": "oracle-oci",
      "availability_domain": "{{user `oracle_availability_domain`}}",
      "region": "{{user `oracle_region`}}",
      "base_image_ocid": "{{user `oracle_base_image_id`}}",
      "compartment_ocid": "{{user `oracle_compartment_id`}}",
      "image_name": "{{user `oracle_image_name`}}",
      "shape": "{{user `oracle_instance_shape`}}",
      "ssh_username": "{{user `oracle_ssh_user_name`}}",
      "subnet_ocid": "{{user `oracle_subnet_id`}}",
      "tenancy_ocid": "{{user `oracle_tenancy_id`}}",
      "user_ocid": "{{user `oracle_user_id`}}",
      "fingerprint": "{{user `oracle_fingerprint`}}",
      "key_file": "{{user `oracle_ssh_private_key_file_path`}}",
      "pass_phrase": "{{user `oracle_pass_phrase`}}"
    }
  ],
  "provisioners": [
    {
      "type": "shell",
      "script": "{{user `configDir`}}/install_packages.sh",
      "environment_vars": [
        "repository={{user `repository`}}",
        "package_type={{user `package_type`}}",
        "packages={{user `packages`}}",
        "upgrade={{user `upgrade`}}"
      ],
      "pause_before": "30s"
    },
    {
      "type": "shell",
      "inline": [
       "sudo iptables -I INPUT 1 -p tcp -m state --state NEW -m tcp --dport 8080 -j ACCEPT",
       "sudo netfilter-persistent save",
       "sudo systemctl restart netfilter-persistent.service"
      ]
    }
  ]
}

{% endraw %}

Install spinnaker per using a debian installation

Accessing Spinnaker

By default, the Spinnaker UI runs on port 9000. You can use an SSH tunnel to access this from your workstation.

ssh -A -L 9000:localhost:9000 -L 8084:localhost:8084 ubuntu@IP

Now Spinnaker UI is available at http://localhost:9000 .

Part 1: Bake & deploy to test

In this first exercise, you’ll set up a pipeline, named Bake & Deploy to Test, which builds an image, deploys it as a server group to a test cluster, then destroys the previous server group in that cluster (also called the “Highlander” strategy).

The workflow is shown in the figure below.

Create a Spinnaker application

Navigate to Spinnaker at http://localhost:9000 .

From the Spinnaker home page, create a new Spinnaker Application by clicking on the Actions drop down at the upper right and clicking on Create Application.

In the New Application dialog:

Enter “codelab” for Name.
Enter your email for Owner Email.
Add “oracle” to Cloud Providers. If “oracle” is the only provider configured, there is no Cloud Providers field and “oracle” is the default provider.
Click the Create button.

Set up Virtual Cloud Network

Log into the OCI console and create a Virtual Cloud Network “codelabVCN” with “PLUS RELATED RESOURCES” option.

Take all the defaults for “codelabVCN”, with a couple of additions to the Ingress Rules in the “Default Security List for codelabVCN”.

the instance to be deployed uses port 8080, add an Ingress Rule to allow TCP traffic for port 8080.
the load balancer to be created in this tutorial listens on port 80, add an Ingress Rule to allow TCP traffic for port 80.

The Oracle Cloud Infrastructure Documentation on Security Lists has more details.

Create a load balancer for test cluster

Navigate to the “Load Balancers” tab in Spinnaker and click the Create Load Balancer button:

Enter “test” for Stack.
Enter “lb” in the Detail field.
Select your preferred load balancer shape in the Shape dropdown.
Check Private Load Balancer only if you want to isolate your load balancer from the internet.
Select your preferred account in the Account dropdown.
Select your preferred region in the Region dropdown.
Select “codelabVCN” in the Virtual Network dropdown.
Add Subnets. A public load balancer requires two subnets, each in a separate availability domain.

Edit the Backend Sets section with “8080” for port.
Edit the Listeners section to use the Backend Set just created on Listening Port “80”.
Click the Create button.

Set up pipeline: “Bake & Deploy to Test” pipeline

The purpose of this pipeline is to generate an image from a package, and then deploy the image on server groups in the test cluster. We want this pipeline to be kicked off every time the continuous integration job completes.

Create a new pipeline by navigating to the PIPELINES tab and clicking the link Configure a new pipeline

Name the pipeline “Bake & Deploy to Test”.
Click the Create button.

Configure the pipeline

In reality, we would set up the pipeline with an automated trigger that will kick off the pipeline. Assuming the package is built in CI (Jenkins/Travis/Etc), in the Automated Triggers section of the pipelines form, you would add Jenkins/Travis/Etc. Trigger for your job so that every time these job completes the pipeline would start automatically.

To simplify this tutorial, we will skip the trigger and use tomcat8 package.

Set up Bake stage

The purpose of our “Bake” stage is to create an image with the package that was built by the CI job that triggered this pipeline. It is tomcat8 in this tutorial.

Click Add stage.
Select “Bake” in the Type drop down.
Select your preferred account in the Oracle Account field.
Select your preferred region in the Regions field.
Select your preferred base image as in the Base Image field.
Enter “codelab” in the Image Name field.
Enter “tomcat8” in the Package field.
Enter “codelab.json” in the Template File Name field in the Advanced Options.
Click the “Save Changes” button.

Set up Deploy stage for test cluster

The purpose of the “Deploy” stage is to take the image constructed in the “Bake” stage and deploy it into a test environment.

Click Add stage.
Select “Deploy” in the Type drop down.
In the Deploy Configuration section, click Add server group.
In the dialog that appears, click Continue without a template.
In the Basic Settings section, select “codelabVCN” in the VCN drop down, select desired Availability Domain and Subnet, and enter “test” in the Stack field.

In the Instance Type section, choose your preferred shape in the drop down.
In the Capacity section, enter your preferred number of instances.
In the Load Balancers section, select the load balancer and the Backend Set we created earlier.

Click the “Add” button.
Save this stage of the pipeline.

Destroy previous server group

In this tutorial use case, on successive deployments of new server groups to the test cluster, we don’t need the previous server group anymore.

Click Add Stage.
Select “Destroy Server Group” for Type.
Check the region of the previous test server group that you want to destroy.
Enter “codelab-test” for the Cluster.
Select “Previous Server Group” for Target.
Click Save Changes.

The pipeline is now complete. Take a moment to review the stages of this pipeline that you just built.

Trying it out

Now let’s run this pipeline. We trigger it by manually triggering from the PIPELINES tab (click Start Manual Execution).

Try running it again. It will succeed all the way, and your pipeline execution details will look like below:

You can now see in the CLUSTERS tab that a new server group (codelab-test-v001) has been deployed to the test cluster, and the previous server group (codelab-test-v000) is destroyed (i.e. does not exist).

Part 2: Validate test

The second pipeline, named “Validate Test”, is a simple one-stage placeholder to represent some gating function before pushing to prod.

Furthermore, you configure the prod deployment to implement the red/black (blue/green) strategy, which means that upon verifying health of the new server group, Spinnaker immediately disables the previous server group in the same cluster. Here you disable rather than destroy, so that rollbacks can be quickly accomplished simply by re-enabling the old server group.

Note: Blue/Green replaces Red/Black in Spinnaker v1.30+.

Set up pipeline: “Validate Test”

Create a new pipeline by navigating to the PIPELINES tab and clicking Configure, then Create Pipeline or Strategy

Name the pipeline “Validate Test”.
Click the Create Pipeline button.

Configure the pipeline

We want this pipeline to kick off when the Bake & Deploy to Test pipeline completes.

Click Add Trigger.
Select “Pipeline” from the drop down menu for Type.
Select your application.
Select the “Bake & Deploy to Test” pipeline.
Check “successful”.

Set up Manual Judgment stage

We stop and wait for human confirmation to continue:

Click Add stage.
Select “Manual Judgment” in the Type drop down.
Specify Instructions, for example “Validate the test cluster”.
Click Save Changes.

Part 3: Promote to prod

The third pipeline, “Promote to Prod”, takes the image that was deployed in the test cluster, and deploys that image to the prod environment, thereby promoting it.

Create a load balancer for prod cluster

We create a load balancer for the prod cluster. Navigate to the LOAD BALANCERS tab and click the Create Load Balancer button. Everything is the same as the “codelab-test-lb” load balancer created before. The only exception is to use “prod” instead of “test” for Stack.

Set up pipeline: “Promote to Prod” pipeline

Create a new pipeline by navigating to the PIPELINES tab and clicking Configure, then Create New …

Name the pipeline “Promote to Prod”.
Click the Create Pipeline button.

Configure the pipeline

We want this pipeline to kick off when the Validate Test pipeline completes.

Click Add Trigger.
Select “Pipeline” from the drop down menu for Type.
Select your application.
Select the “Validate Test” pipeline.
Check “successful”.

Set up Find Image stage

In this stage, we select the image that was deployed in the test cluster.

Click the Add stage button:

Select “Find Image from Cluster” for the stage Type.
Check the region of the test server group to pick the image from.
Enter “codelab-test” for the Cluster.
Choose “Newest” for the Server Group Selection.

Set up Deploy stage for prod cluster

We deploy the image that was picked, to the prod cluster.

Click Add stage.
Select “Deploy” in the Type drop down.
In the Server group section, click Add server group.
In the dialog that appears, click Continue without a template.
In the Basic Settings section, everything is the same as the “codelab-test” server group created before. The only exception is to use “prod” instead of “test” for Stack.
In the Load Balancers section, add the “codelab-prod-lb” Load Balancer and the Backend Set previously created.
Click the Add button.
Click Save Changes to save your prod pipeline.

Trying it out

Now let’s run through it all. Run a “Start Manual Execution” in Bake & Deploy to Test pipeline.

When the Bake & Deploy to Test pipeline completes, the Validate Test pipeline will trigger and wait for user input.

Click Continue. This will trigger the Promote to Prod pipeline:

In the CLUSTERS tab, you can see that a server group has been deployed to the prod cluster.

Docs: Safe Deployments

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

Overview

In this codelab, you will improve a deployment process by adding safeguards to your deployments.

This codelab is a continuation of the Kubernetes: code to prod codelab. It assumes you have an application set up and ready to deploy.

Setup

Please follow the steps in the Kubernetes Source to Prod guide to create a deployed Spinnaker cluster.

Making manual operations safer

Using the Rollback action

The rollback action automates the process of restoring to the previous good known server group. This feature enhances a traditionally manual operation by ensuring that the restored cluster is taking traffic before disabling the current server group.

Go to the clusters screen for your application and make sure you have at least one cluster with one server group with an attached load balancer.

If you don’t have an existing server group, click on Create Server Group, select your deployment details (pick an image name and load balancer) and click on CREATE .

Clone this server group:

Select the server group
Click on actions, then select clone server group in the dropdown.
In the new dialog, select Red/Black push (or Blue/Green push) as the strategy. (Note: Blue/Green replaces Red/Black in Spinnaker v1.30+.)
Click CREATE.

Wait for the task to finish. You should now have at least two server groups in your cluster, with the previous one disabled and the new one enabled.

Rollback the deployment:

Select the new server group
Click on actions, then select rollback in the dropdown.

In the new dialog, select the previous server group from the dropdown.

Click OK

You should see a task window and the deployment being rolled back safely and automatically. The previous server group should be eneabled and the current one disabled.

Making a deployment pipeline safer

Creating your deployment pipeline

Go to the Pipelines screen and select Create New

Select Pipeline as the type and name it Safe Deployment

Under Configuration, add a Docker Registry trigger

Point it to your Docker registry and image

Add a new stage of type Deploy

Add a new cluster, select copy configuration from an existing template.

Select your cluster.

Click Use this template.

You should see the details for your cluster filled in.

Select Add

Save the pipeline

Adding an execution window to deployment pipelines

Execution windows allow you to restrict the times of the day or week when deployments can happen. By using execution windows, you can ensure that deployments don’t interfere with times where your service is at peak demand. You can also use execution windows to make sure that there is always someone in the office ready to manually intervene or rollback your pipeline.

Let’s modify our existing pipeline to add a deployment window.

Navigate to the deploy stage of your pipeline.

Check the Restrict execution to specific time windows checkbox

Click on Add an execution window

Enter a start time and end time that will block the deployment if deployed right now.

Save the pipeline

Go to the pipeline screen by clicking on the back arrow next to the pipeline name

Click on Start Manual Execution for your pipeline.

You will see a warning that your deploy stage is waiting for an execution window.

You can click on Skip Execution Window to start the stage right away.

Go back and modify the execution window so your stage falls within the current window.

Execute your pipeline again. You should see your deployment continue without waiting.

Adding a Manual Judgment to deployment pipelines

Manual Judgments serve as a gate for your pipeline. You can add manual judment stages to interrupt the pipeline execution to run a manual check. This is great for teams that have a manual or out-of-band QA process.

Let’s modify our pipeline by adding a manual judgment stage.

Click on Configuration and select Add new stage

Enter “please approve this pipeline” in the instructions

Click on Add Notification Preference.

In the popup dialog:

select type Email
Enter your email address
Select to notify when This stage is awaiting judgment.

Click Update

Go to your deploy stage

Select Manual Judgment in the Depends On field

Your pipeline view should look like this.

Save this pipeline and run it.

Check your email. You should see one that says that your pipeline is awaiting judgment.

Click on the link in your email. You should see the manual judgment awaiting approval.

Click on Continue

Your pipeline should run now.

Changing pipeline behavior based on selected judgment

Manual Judgments can also be used to run a rollback task based on some input.

Go to your Manual Judgement stage and type in “continue” as an input option.

Click on Add Judgment Input and type in “rollback.”

Add a new stage called Rollback of type Wait

In the new stage, check the Conditional on Expression checkbox and enter ${ #judgment("Manual Judgment").equals("rollback")}. In this step, we’re telling Spinnaker to only run this stage if the rollback option was selected.

Select the deploy stage, check the Conditional on Expression checkbox and enter ${ #judgment("Manual Judgment").equals("continue")}.

Save your pipeline and run it.

In the manual judgment stage, select rollback as your input.

You should see that the deploy stage is skipped while the rollback stage runs.

Run your pipeline again, this time selecting continue as your input.

The rollback stage should not run

Creating an automatic rollback pipeline

You can also create a pipeline to run in case a deployment fails.

For this exercise, we’re going to create a pipeline that will trigger if a deployment pipeline fails.

We’re going to make a parent pipeline that will allow us to decide its success status based on a parameter.

Create a new pipeline called Parent Pipeline

Click Show Options
Enter true as an option
Click on Add New Option
Enter false as another option.

Add a new stage of type Check Preconditions.

Add a new Precondition:

Set Check to Expression
Enter ${ parameters["Pipeline Successful"].equals("true") } as the expression.

Click Update

Save your pipeline

Create a rollback pipeline

Create a new pipeline called ‘Child Pipeline’

Under Configuration, add a new automated trigger of type Pipeline

Set your application to be the same as your parent pipeline
Set pipeline name to be Parent Pipeline
Click on Pipeline Status failed

Add a new stage of type Wait

Save your child pipeline

Test your rollback pipeline

Go to the pipelines screen and select Start Manual Execution on your Parent Pipeline

In the popup dialog, select false as the choice for Pipeline Successful

You should see the pipeline fail, and the Child Pipeline run the rollback

If you click on the Parent Pipeline link in the child pipeline, it should take you the the failed execution.

Now run the Parent Pipeline again, this time selecting true.

The child pipeline should not run

Learn more

Hopefully this codelab has given you a taste of the built-in mechanisms for safe deployment in Spinnaker. An almost complete list of safe deployment features in Spinnaker can be found in this blog post .