This codelab covers some of the basics of Spinnaker.

What you'll need

What you'll build

For this codelab you're going to use a red/black deployment strategy.

What you'll learn

Install gcloud

If you already have the most recent version of gcloud installed, on the machine where you're running this codelab, skip this step.

  1. Run this command, then follow the prompts:
curl https://sdk.cloud.google.com | bash
  1. Authenticate gcloud to your account:
gcloud auth login <your email address>
  1. Enable the Compute Engine API
gcloud services enable compute.googleapis.com --project <your project id>

This installation might take a few moments to finish.

Provision Spinnaker (with Jenkins)

We provide a pre-configured Compute Engine image that includes Spinnaker, Jenkins, and aptly, along with embedded startup scripts to configure everything together for you.

Create an instance of this image in your GCP project by running the following commands (substituting your project ID for <your 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

The spinnaker-codelab instance is created quickly, but it will take a few minutes for Spinnaker to come up completely.

Connect to Spinnaker

After you wait for approximately 5 minutes, use the following command to open an SSH tunnel to connect to Spinnaker from your local workstation:

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"

Now that you have your Spinnaker instance running (plus Jenkins, and so on) you're ready to create the first pipeline: "Bake & Deploy to Test."

This pipeline bakes a Compute Engine image and then deploys it to the test environment. The process looks like this:

Create an application in Spinnaker

An application, in Spinnaker, represents the service you are going to deploy, configuration for that service, and the infrastructure on which it will run. You can use the `spin` command-line interface to do this, but this codelab uses the manual steps in the UI.

  1. Navigate to the Spinnaker UI: http://localhost:9000.
  2. On the Spinnaker home page, click Actions (top-right), and select Create Application.
  3. Fill out these fields, in the New Application dialog:
  1. Click Create.

Create a load balancer

The two deploy pipelines you create in this codelab both require load balancers, though the manual-judgment stage does not.

  1. Navigate to the LOAD BALANCERS tab.
  2. Click Create Load Balancer, select Network as the type, and click Create Network load balancer.
  3. Make sure Account is set to "my-google-account".
  4. For Region select "us-east1".
  5. Type "test" in the Stack field.
  6. In the Listener section, set the Port Range to "8080".
  7. In the Health Check section, set the Port to "8080", and set the Path to "/hello".
  8. Optionally, select "1" for everything in Advanced Settings, to allow server groups to report health faster.
  9. Click Create.

Create the pipeline and add a trigger

This first pipeline generates a Compute Engine image from a package, then deploys the image on server groups in the test cluster. You want this pipeline to be triggered every time the Jenkins continuous integration job completes.

You can use the `spin` command-line interface to do this, but this codelab uses the manual steps in the UI.

  1. Navigate to the PIPELINES tab and click Configure a new pipeline.
  2. Name the pipeline "Bake & Deploy to Test".
  3. Click Create.

The pipeline configuration page is displayed.

  1. In the Automated Triggers section, click Add Trigger.
    With this trigger, you'll configure the pipeline to run every time your Jenkins job completes.
  2. For Type, select, Jenkins.
  3. For Master, select "CodelabsJenkins".
  4. For Job select "Hello-Build".

Add a Bake stage

The Bake stage creates a Compute Engine image with the package built by the Jenkins job that triggered this pipeline.

  1. Click Add stage.
  2. Select Bake from the Type drop down.
  3. Type "hello-karyon-rxnetty" in the Package field.
  4. Select trusty as the Base OS.

Add a Deploy stage

The Deploy stage take the Compute Engine image constructed in the Bake stage and deploys it into a test environment.

  1. Click Add stage.
  2. Select Deploy in the Type drop down.
  3. In the Deploy Configuration section, click Add server group.
  4. Under Basic Settings, select "us-east1" for Region.
  5. Type "test" in the Stack field.
  6. Under Load Balancers, select or type "codelab-test".
  7. For Zone, select "us-east1-b".

  1. For Instance Type, select Custom Type and "f1-micro" from the drop-down.
  2. For Capacity: Number of Instances, keep the "1".

  1. Click Add.

Add a Destroy Server Group stage

This stage removes all but the most recent server group.

  1. Click Add Stage.
  2. For Type, select Destroy Server Group.
  3. For Regions, select us-east1.
  4. In the Cluster field, type "codelab-test".
  5. For Target, select Previous Server Group.
  6. Click Save Changes.

This completes the pipeline. Next, you'll trigger it by running a build of the Jenkins job.

Note: this pipeline will fail the first time you run it because the selector for "Previous Server Group" will find nothing (no server groups are in the test cluster yet). Run it a second time, and it will succeed.

  1. Navigate to http://localhost:5656, and log in to Jenkins.

Username: "admin"

Password: "admin"

The Hello-Build job is displayed. If instead you're on the Jenkins home page, click Hello-Build to open up that job.

  1. Click Build Now.

It'll take a few moments before the Jenkins trigger starts the pipeline, but soon you'll see the pipeline in a running status in Spinnaker on the Pipelines tab.

The first time you run this pipeline, the Destroy Server Group stage fails. This is because the Previous Server Group target has no previous server group to find (no server groups presently in the test cluster). However, the Deploy stage does succeed, so Spinnaker creates a test cluster.

Run the pipeline again, either by kicking off another build from Jenkins, or by manually triggering from the PIPELINES tab in Spinnaker (click Start Manual Execution). The whole pipeline will succeed this time, and your pipeline execution details will look like this:

You can now see in the CLUSTERS tab that a new server group (V001) is deployed to the test cluster, and the previous server group (V000) does not exist (because of the Destroy Server Group stage).

You can also click on a server group to see the server group details. In the details panel on the right, you can see in 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.

You're now going to create a second pipeline, "Validate Test," a simple one-stage manual-judgment gate before pushing to production.

Create the "Validate Test" pipeline

The pipeline you're going to create here will be triggered by completion of the Bake & Deploy to Test pipeline.

  1. Navigate to the PIPELINES tab and click Create.
  2. Name the pipeline "Validate Test," then click Create.
  3. Click Add Trigger.
  4. Select Pipeline as the type and "codelab" as the application.
  5. Select "Bake & Deploy to Test" as the pipeline, and check the successful box.
  6. Make sure Trigger Enabled is checked.

Add the Manual Judgment stage

This stage causes the pipeline to stop and wait for a human to confirm before continuing.

  1. Click Add Stage.
  2. Select Manual Judgment from the Type drop down.
  3. Add Instructions for the user who will perform the manual judgment.
    For example, "Validate the test cluster."
  4. Click Save Changes.

You're now going to create a third pipeline, "Promote to Prod," which takes the image that was deployed in the test cluster, and deploys it to the production environment (prod).

This deployment uses the red/black strategy (also known as blue/green). When the health of the new server group is verified, Spinnaker immediately disables the previous server group in the same cluster. (Spinnaker disables here, rather than destroys, so that you can quickly roll back by just re-enabling the old server group).

Create another load balancer

This load balancer is for the prod environment.

  1. Navigate to the LOAD BALANCERS tab.

  1. Click the Create Load Balancer button, and select "Network" as the load balancer type.
  2. Configure the load balancer:
  1. Click Create.

Create the pipeline and add a trigger

You want this pipeline to start when the Validate Test pipeline finishes successfully.

  1. From the PIPELINES tab, click the Create button.
  2. Name the pipeline "Promote to Prod" and click Create.
  3. Click Add Trigger.
  4. Select "Pipeline" from the drop down menu for Type.
  5. Select your application ("codelab").
  6. Select the "Validate Test" pipeline.
  7. Check successful, and make sure Trigger Enabled is also checked.

Add the Find Image stage

This stage selects the image that was previously deployed in the test cluster.

  1. In pipeline config for the Promote to Prod pipeline, click Add Stage.
  2. For Type, select Find Image from Cluster.
  3. Select the region of the test server group: us-east1.
  4. For Cluster, type "codelab-test".
  5. For Server Group Selection, select Newest.

Add the Deploy stage

This stage deploys the image to the prod environment.

  1. Click Add Stage.
  2. For Type, select Deploy, and name it "Deploy".
  3. In the Deploy Configuration section, click Add server group.
  4. If you're prompted to do so,, click Continue without a template.
  5. Under Basic Settings, select "us-east1" as the Region, and type "prod" in the Stack field.
  6. For Strategy, select None.
    You want Red/Black, but first you need to run this with no strategy, then change it to Red/Black and re-run it.
  7. In the Load Balancers section, add your load balancer ("codelab-prod").
  8. Under Zones, select "us-east1-b".
  9. Under Instance Type, choose Custom and select f1-micro from the dropdown.
  10. Under Capacity, leave the number of instances set to "1".
  11. Click Add.
  12. Click Save Changes to save your pipeline.

You'll now run all three pipelines. But for the third pipeline, you'll change the strategy from "none" to "red/black."

  1. Start another bake in Jenkins.
  1. Navigate to http://localhost:5656, and log in to Jenkins, if you're not still logged in.

Username: "admin"

Password: "admin"

  1. From the Hello-Build job, click Build Now.

When the Bake & Deploy to Test pipeline finishes, the Validate Test pipeline waits for you to approve.

  1. Click Continue.

This triggers the Promote to Production pipeline:

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

Add the red/black strategy

When you created the Promote to Prod pipeline, you selected no deployment strategy. This ensured that the pipeline would create the server group. Now that you've validated that the pipeline runs, you will edit it to use the red/black strategy, then run it again.

  1. From the pipelines tab, click Configure on the Promote to Prod pipeline.
  2. Select the Deploy stage.
  3. Under Deploy Configuration, click the edit button on the entry for the server group.

  1. Under Strategy, select Red/Black.
  2. Enter "2" as the Maximum number of server groups to leave.
  3. Click Done, then click Save Changes for the whole pipeline.

Re-run the pipeline

You can manually re-run the pipeline, from the PIPELINES tab, by clicking Start Manual Execution.

...or for more fun, you can start the Jenkins build again.

Because you selected the red/black deployment strategy for the deployment, there will be only one enabled/active server group resident in the prod cluster, with previous ones disabled (grey)

This will be true even if you run it again (and again).

The reason for using the red/black deployment strategy is that you can easily roll back to the previous release if something goes wrong.

The red/black strategy disassociates the old server group from the load balancer so it takes no traffic, but it keeps the nodes in the server group up, standing by. When you roll back, you restore traffic to it, while disassociating the new server group. (The new server group still exists—it's just not receiving traffic.)

  1. Go to INFRASTRUCTURE>CLUSTERS and click the active server group (in prod).
  2. In the Server Group Actions drop-down, click Rollback.

  1. In the resulting dialog, select the server group that you want to roll back to.

  1. Click Submit.

You can now see the previously active server group disabled, and the first server group re-enabled.

To save money, remove all the infrastructure you created for this codelab that you're not going to use for anything else.

  1. From the CLUSTERS tab, select a server group, click the Server Group Actions button, and select Destroy.

Do this for each server group.

  1. From the LOAD BALANCERS tab, click a load balancer, click the Load Balancer Actions button, and select Delete Load Balancer.

Do this for both load balancers.

  1. From the Google Cloud Console, select VM Instances from the main menu.
  2. Select the spinnaker-codelab instance, and click DELETE.