Injecting a prebaked AMI (and other parameters) into a Spinnaker Pipeline

Aug 22, 2016 by Isaac Mosquera

While Spinnaker has a preferred way of doing things it’s also highly customizable. The easiest way to use Spinnaker is to have it bake your pipeline using Rosco + Packer and pass it along to the next deployment stage. Below is a fairly standard way of using Spinnaker.

But what if your AMI is baked as part of the continuous integration server like TravisCI, CircleCI and not Jenkins? In order for Spinnaker to work well with this model we’ll have to do a few things:

  1. Create a custom parameter that is used to specify the AMI that was created during CI process that will be used within the deployment process. Make sure that your deployment account has access to the AMI.
  2. Use Spinnaker’s pipeline expressions that allow you to access parameters & properties that were created or passed in during run process. This allows stages to pass along values to next stages. We’ll have to modify the pipeline JSON to accept a custom value that we pass when the pipeline is kicked off.
  3. Kick-off the pipeline once the external CI service’s job is complete. The CI service should run unit tests, build & create AMI and then publish the AMI to an account accessible by Spinnaker.

Create A Custom Trigger Parameter

We’ll start by creating a parameter that is used at the beginning of the pipeline. Make sure to go back to your Configuration stage, which is the first one in the pipeline.

Then add a parameter with whatever value you want to use downstream. For our use-case we want to build a pre-baked AMI so we’ll change that here. We’ve added the name prebaked_ami with a default value: ami-0123456789 that we’ll get to use in later stages with the pipelines expressions feature by referring to this variable ${trigger.parameters.prebaked_ami}.

Use Pipeline Expressions

The next step is use the pipeline expressions feature to modify the pipeline by exposing the pipeline JSON and manually modifying it. If manually modifying the JSON scares you a bit, that’s okay. You can always store the final JSON in a SCM like git and post the JSON to Spinnaker’s robust API to manage the pipeline.

Once you have access to the JSON we’ll want to add expression parameter that we prepared earlier: ${trigger.parameters.prebaked_ami} to the clusters array in the JSON. This will tell the pipeline to use the value that we’ll pass in in the next step.

Note: You’ll see a little warning symbol on top of the pipeline saying that you need a bake step. You can safely ignore this warning as we added the amiName field to the JSON.

Kick-off The Pipeline

The last step is the easiest which is calling the Spinnaker API to kick-off the appropriate pipeline with the parameter(s) that are required as input. Spinnaker is 100% API based and all UI functionality is accessible through an API. If you’re interested in learning more about Spinnaker’s API you can always go to your instance’s swagger interface:

Below is the simple curl command that will trigger the pipeline

curl \
'http://${YOURINSTANCE}:8084/pipelines/${app_name}/${pipeline_name' \
-H 'Content-Type: application/json;charset=UTF-8' \
--data-binary '{"type":"manual","parameters":{"prebaked_ami":"${baked_ami_id}","user":"[anonymous]"}'

Recently Published Posts

A Faster Way to Evaluate Self-Hosted Continuous Deployment from Armory

Sep 30, 2022

Introducing Quick Spin One of the most common challenges that organizations face when implementing a continuous deployment strategy is the time and focus that it takes to set up the tools and processes. But a secure, flexible, resilient and scalable solution is available right now. Want to see if it’s the right tool for your […]

Read more

3 Common Spinnaker Challenges (and Easy Ways to Solve Them)

Sep 27, 2022

Spinnaker is the most powerful continuous delivery tool on the market.  DevOps engineers and developers recognize this power and are looking to use Spinnaker as a foundational tool in their Continuous Integration and Continuous Delivery (CI/CD) process for hybrid and multi-cloud deployments. Such a powerful, expansive open source tool needs expertise within your organization to […]

Read more

Streamline Advanced Kubernetes Deployments from GitHub Actions with New Armory Service

Sep 23, 2022

Today, Armory is excited to announce the availability of the GitHub Action for Armory Continuous Deployment-as-a-Service. GitHub is where developers shape the future of software. After a developer writes and tests their code in GitHub, it must be deployed. Armory’s GitHub Action for Continuous Deployment-as-a-Service extends the best-in-class deployment capabilities to Kubernetes. CD-as-a-Service enables declarative […]

Read more