This codelab covers some of the basics of Spinnaker.
For this codelab you're going to use a red/black deployment strategy.
If you already have the most recent version of
gcloud installed, on the machine where you're running this codelab, skip this step.
curl https://sdk.cloud.google.com | bash
gcloudto your account:
gcloud auth login <your email address>
gcloud services enable compute.googleapis.com --project <your project id>
This installation might take a few moments to finish.
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
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-codelab instance is created quickly, but it will take a few minutes for Spinnaker to come up completely.
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:
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.
The two deploy pipelines you create in this codelab both require load balancers, though the manual-judgment stage does not.
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.
The pipeline configuration page is displayed.
The Bake stage creates a Compute Engine image with the package built by the Jenkins job that triggered this pipeline.
The Deploy stage take the Compute Engine image constructed in the Bake stage and deploys it into a test environment.
This stage removes all but the most recent server group.
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.
The Hello-Build job is displayed. If instead you're on the Jenkins home page, click Hello-Build to open up that job.
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.
The pipeline you're going to create here will be triggered by completion of the Bake & Deploy to Test pipeline.
This stage causes the pipeline to stop and wait for a human to confirm before continuing.
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 (
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).
This load balancer is for the
You want this pipeline to start when the Validate Test pipeline finishes successfully.
This stage selects the image that was previously deployed in the test cluster.
This stage deploys the image to the
You'll now run all three pipelines. But for the third pipeline, you'll change the strategy from "none" to "red/black."
When the Bake & Deploy to Test pipeline finishes, the Validate Test pipeline waits for you to approve.
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.
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.
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.)
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.
Do this for each server group.
Do this for both load balancers.
spinnaker-codelabinstance, and click DELETE.