Armory Docs – AWS Guides for Spinnaker

Continuous-Deployment: Use an Amazon Machine Image in a Spinnaker Pipeline

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

Overview

In this guide, you create a pipeline that takes the Debian package produced by a Jenkins job and uses it to create an Amazon Machine Image (AMI) before deploying that image to a server group.

Prerequisites for using an AMI in Spinnaker

A configured Jenkins Master
A Jenkins job that archives a Debian package
A security group within AWS with appropriate permissions

Step 1: After selecting your Application, click the Pipelines category.

Step 2: On this page, click the “+” icon.

Step 3: Input a name for your new pipeline

Note: Strategy will be covered in a separate guide.

Step 4: On this page you will see

A visual representation of your pipeline and its stages
Execution Options
Automated Triggers
Parameters
Notifications
Description

Step 5: The first thing you should do is set up how your pipeline will be triggered. Scroll down to the Automated Triggers sub section. This section will allow you to select a Type first, looking like this.

Step 6: For this example we will select Jenkins. By adding a trigger we are defining how our pipeline will be initiated.

Note: The Property File is an important topic that will be covered in a separate guide.

Step 7: Before you test your pipeline, you may want to consider enabling or disabling the trigger via the checklist at the bottom.

Step 8: Add a new stage.

Click the add stage button in the visual representations section.

Step 9: Select Bake from the different types category.

Step 10: Select the region you want to bake in.

Enter the name of the package that was archived by the Jenkins job.

Note: The package name should not include any version numbers. (e.g.: If your build produces a deb file named myapp_1.27-h343, you would want to enter myapp here.)
Note: If you would like to configure your own Base AMI under the Advanced Options, the Base OS configuration will be ignored.

Step 11: Now add a Deploy stage by clicking Add Stage again. In the Type category select Deploy. Deploy’s configuration settings should pop up on the screen.

Note: If we want to reorganize the order that the stages execute in the pipeline, we can add or remove precursor stages in the Depends On category.

Step 12: In the Deploy Configuration, click on the “Add server group” button. Pick your provider. For our example it will be AWS.

Step 13: Select “Continue without a template”.

Since this is a new application we will not choose to copy a configuration from a template.

Step 14: Set up the Deploy Strategy.

We will use the Highlander strategy for this example, which will ensure that only one server group for our application exists at a time.

Note: Different deployment strategies are important and there will be a separate guide for those.

Step 15: Select a security group

The security group will define the access rights to your resource.

Step 16: Select Instance Type.

Make sure to select the right instance type for your application, preferably the one that is running in production currently.

Step 17: Select the Capacity

Select how many instances you want in your server group on deploy. For our example, we will set it at 1.

Step 18: Add the server group.

Click “Add” and you’ll be brought back to your Application and to see your new Deploy Configuration.

Step 19: Save the changes

Press “Save Changes” at the bottom right of your window.

Step 20: Go back to the Pipeline Overview.

You should see your new pipeline. Click on “Start Manual Execution”.

Step 21: Select the build to run.

You will be able to select a Build for your Jenkins job from a drop down menu. By default, Spinnaker will not recreate an AMI unless the underlying package has changed. If you would like to force it, you may use the checkbox for “Rebake”.

Step 22: Run

You should see a progress bar where blue represents running and green represents complete. Gray represents not ran or canceled. Red is a failed task.

If your pipeline does not succeed, refer to one of the troubleshooting sections in the pipelines, baking, or deploying guides.

Continuous-Deployment: Bake Amazon Machine Images in a Spinnaker Pipeline

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

The phrase “baking images” is used within Armory and Spinnaker^TM to refer to the process of creating machine images.

Prerequisites for baking AMIs

You are familiar with creating applications and pipelines.
You are deploying to Amazon Web Services (AWS).
You have configured Armory to work with Jenkins. See the Use Jenkins in Spinnaker guide for more information.
You are familiar with Debian packages. See the Debian Packages guide for more information.

Example of how to bake an AMI in a pipeline

In this example, you bake an image containing a Debian package created by a Jenkins job.

First, look at the the Jenkins job that builds our package.

The last run archived a package named armory-hello-deploy_0.5.0-h5.c4baff4_all.deb

In Armory, create a new pipeline named bake-example.

On the configuration stage, down and add a new Jenkins automated trigger. Select my master, and then select the Jenkins job shown above (armory/job/armory-hello-deploy/job/master). For this example, there is no need to worry about setting a properties file.

Next I add a bake stage (add stage -> Type: Bake)

Select the us-west-2 region. For the Package field, I enter the base name of my package. In my case, the entire package filename is armory-hello-deploy_0.5.0-h5.c4baff4_all.deb so I will input armory-hello-deploy. Also, I know that my package is created for Ubuntu 14, so I make sure to select the ’trusty (v14.04)’ option.

like:

At this point if I want to see more details about my bake, I can click the ‘View Bakery Details’ box. A new window will open up with the bakery logs. In my case, the first few lines look like:

==> amazon-ebs: Prevalidating AMI Name...
 amazon-ebs: Found Image ID: ami-3d50120d
==> amazon-ebs: Creating temporary keypair: packer_58dc1ccb-b936-7104-ebe0-0984e888ca78
==> amazon-ebs: Creating temporary security group for this instance...
==> amazon-ebs: Authorizing access to port 22 the temporary security group...
==> amazon-ebs: Launching a source AWS instance...
 amazon-ebs: Instance ID: i-08327d863d1911675
==> amazon-ebs: Waiting for instance (i-08327d863d1911675) to become ready...
==> amazon-ebs: Adding tags to source instance
==> amazon-ebs: Waiting for SSH to become available...
==> amazon-ebs: Connected to SSH!
==> amazon-ebs: Pausing 30s before the next provisioner...
==> amazon-ebs: Provisioning with shell script: /opt/spinnaker/config/packer/install_packages_armory.sh
 amazon-ebs: repository=
 amazon-ebs: package_type=deb
 amazon-ebs: packages=armory-hello-deploy=0.5.0-h5.c4baff4
...

Under the hood, Spinnaker is leveraging HashiCorp’s Packer tool to create images. The above is a Packer log file.

The thing I wanted to point out here is that the correct version of the package is getting passed down to the bakery.

After the bake is successful, I see:

Notice that the AMI name and ID are shared in the lower right’s blue box - in this example it is “armory-hello-deploy-all-20170329204459-trusty (ami-c78410a7)”.

If I press ‘Start Manual Execution’ again, since the package version hasn’t changed, it will reuse the same image rather than rebaking. The screen for that looks like:

Notice the whole pipeline only ran for ‘00:00’ and the UI says ‘No changes detected; reused existing bake’

Advanced options for baking AMIs

You can do additional things like use a specific base AMI, specify your baked AMI’s name, use a custom packer script, or pass variables to a packer script.

If you would like to change the name in AWS of your AMI, you can do so by selecting the ‘Show Advanced Options’ checkbox in the Bake Stage Configuration. Continuing from our example above, when I see:

What do all of these fields mean? Great question!

Changing an AMI’s name

If I were to instead input ‘mycustomname’ into the ‘AMI Name’ field, like:

After re-running the pipeline, I see that Spinnaker named the AMI mycustomname-all-20170329220104-trusty

Then I add ‘mycustomsuffix’ to the ‘AMI Suffix’ field:

Repeating the bake, I see that Spinnaker named the AMI mycustomname-all-mycustomsuffix-trusty

Base AMIs

Often you will want to specify a base image for use in your bake. In that case you will use the ‘Base AMI’ field, not to be confused with the ‘Base Name’ field. As an example, I have specified ami-4d78c02d:

In this situation, the base OS selection (ubuntu/trusty/windows) will be ignored.

You can also select a base AMI more dynamically by combing the ‘Bake’ stage type with the ‘Find Image’ stage type. For more details check out the Find Images Guide.

Adding Debian repositories

It is common practice to use a base image throughout your team or organization. Usually this base image will be kept up to date with security patches and will contain common tools (DataDog, Splunk, etc.). It is also a good place to register your Debian repository’s GPG keys.

If you need to add repositories on a per bake basis, you can use the ‘Extended Attributes’ within the ‘Advanced Options’ section. You can add a key/value pair where the key is labeled ‘repository’ and the value is a space separated list of repository URLs. For example:

This will add Armory’s bintray debian repository to the bake.

Regions

By selecting a region, you are selecting which region the bake will take place. When a bake happens, an instance is spun up, the desired packages are installed, and then a snapshot is taken. The location where the instances spin up is determined by which region you select. Multiple regions may be selected at once.

Rebaking

When a bake step executes, Spinnaker looks for a previously created image before baking a new one. It uses the set of packages (and their versions) that users specify in the bake stage configuration to determine if the bake is neccessary.

You can force Spinnaker to always bake by selecting the ‘Rebake: Rebake image without regard to the status of any existing bake’ checkbox on the bake stage configuration screen. You also have the option to force rebaking when manually executing a pipeline.

Bake and copy vs multi-region bake

There are two options for getting an image to multiple regions in AWS. A common practice outside of Spinnaker is to create your AMI and then copy it to the regions you need. However, Spinnaker by default will do a multi-region bake. This means if you select more than one region it will go through the process of creating an image in each region (spin up an instance, install the packages, etc).

There are trade-offs to each approach. Generally, Spinnaker’s default multi-region bake approach is faster than the bake and copy approach. However, if you need to limit all baking activities to one region then there isn’t much of a choice.

Custom bake scripts

If you would like to use a custom Packer script to bake your AMI you will need to contact your Spinnaker Administrator. The script will have to be installed on your Spinnaker instances.

Caching bakes

Spinnaker will cache bakes and not re-run a bake to save time if it finds the bake key in its cache. When Spinnaker bakes a package it creates a unique key based on the following components: Cloud Provider Type, Base OS, Base AMI, AMI Name, Packer Template Filename, Var Filename, Package Name and Package Version. If any of those components change at the time of bake it will rebake otherwise it’ll use the cached AMI.

Package name and version

By default, Spinnaker looks for an artifact from the Jenkins build that triggered the bake to parse out version information. Below are valid names to packages:

subscriberha-1.0.0-h150
subscriberha-1.0.0-h150.586499
subscriberha-1.0.0-h150.586499/WE-WAPP-subscriberha/150

This allows you to just specify subscriberha as the package in your bake stage and Spinnaker will handle which version to bake based on the Jenkins trigger that was chosen at execution time.

Troubleshooting

When you have a failing bake step and you do not know why, a good place to start is with the bakery log. You can find a link to the bakery log in the Detail of your bake step on the pipeline execution screen

Click the link that says ‘View Bakery Details’. It can be helpful to track down the last command that the bakery executed.

Another source of information is the pipeline’s source link. You can find this link in small writing in the far bottom right of the pipeline execution detail screen. The ‘source’ is a JSON representation of the data generated by Spinnaker when running your pipeline (not just the bake step).

Continuous-Deployment: Bake and Find Custom Amazon Machine Images in Spinnaker

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

Prerequisites and assumptions

You have experience baking and deploying images with Spinnaker

Spinnaker provides a lot of auto-magic for determining which AMI should be deployed to which server group. However, sometimes it is necessary to override Spinnaker’s selection.

Dynamic base AMI

Sometimes you may want to build your AMI in several different pipelines before deploying it. This is a popular method when you need to add a layer of standard tools and daemons to all of your instances (ex: Splunk or DataDog agents). Also, you may want to do regular security updates and have it roll out to all instances in your organization.

Let’s go through an example.

I have created a multi-region bake pipeline that creates AMIs from a package built on Jenkins. For directions on how to create a pipeline like this, check out the baking guide. You can see it running here:

Next I want to create a pipeline that is triggered by a Jenkins job and installs the package that Jenkins created. However, I want that package to be installed on top of one of the AMIs from the multi-region bake above.

I start by creating a new pipeline.

I add an automated trigger to build from a Jenkins’ job. For a more detailed example of this, check out the baking guide.

Now I add a ‘Find Images From Tags’ stage and input ‘armoryami’ in the ‘Package’ field. The ‘package’ you input needs to match the package installed by the baked AMI in the prior bake pipeline.

By checking the ‘us-west-2’ checkbox, I am telling Spinnaker to find images in only that regions and make it available to the rest of the pipeline.

Next I want to add my own package to this AMI. First, I add a bake stage. Since my Jenkins’ job created an artifact named ‘armory-hello-deploy’, I input that into the ‘Package’ field. The next part is a little tricky. I need to specify the correct base AMI by checking the ‘Show Advanced Options’ and using the expression language in the ‘Base AMI’ field.

As you can see, the expression I use is:

{ #stage('Find Image from Tags')['context']['amiDetails'][0]['imageId'] }

What is happening here?

The #stage("Find Image from Tags") function references the previous pipeline stage named ‘Find Image from Tags’. This function returns a map of data.
The ‘context’ field of the map is populated after the ‘Find Image from Tags’ stage runs and contains the resulting data.
The ‘amiDetails’ field is an array of all images found. This is especially relevant if you are looking for images in multiple regions. Although in our case, we are just working in ‘us-west-2’, so there is only one element in the array, ‘[0]’.
Lastly, the ‘Base AMI’ field in the ‘Bake Configuration’ is expecting an AMI id as input so after we specify element ‘[0]’, we further specify ‘[imageId]’ to get the AMI id of the image.

We can now execute the pipeline with the above inputs.

Notice the ‘Results’ box in the lower right hand corner. After inspecting it and comparing it to the bake pipeline in the very beginning of the example, I can see that Spinnaker did indeed choose the correct AMI.

If you wanted to deploy this image, you can just add a deploy step and Spinnaker will deploy the correct AMI. For more instructions on deploying, check out the deployment guide.

Continuous-Deployment: Deploy an Application to Amazon EC2

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

How Spinnaker deploys applications

The primary objective of Spinnaker^TM is to deploy your software. To do that, you need to bake an image and then use that same image to deploy to all of your environments.

The typical type of distributed application that Spinnaker deploys is one with a cluster of homogeneous instances behind a load balancer. The load balancer is responsible for detecting healthy and unhealthy instances.

This guide continues the example in the Bake Amazon Machine Images in a Spinnaker Pipeline guide. Here, you deploy a simple web server that serves a page with details about its environment.

Prerequisites for deploying an application to EC2

You know how to create pipelines.
You have read the Bake Amazon Machine Images in a Spinnaker Pipeline guide and completed the steps to bake an image.
You have read the Spinnaker Nomenclature and Naming Conventions guide.
You are familiar with Elastic Load Balancing (ELB) configuration.
You have already created a security group to use in your application.

Create a load balancer

Go to the application screen to create a load balancer. Select the Load Balancers tab:

Press the ‘+’ on the right to create a new load balancer, you may need to select AWS > then select a Load Balance Type.

We’ll enter ‘prod’ into the ‘Stack’ field because our environment contains dev, stage, and prod.

Set the VPC Subnet Type grouping by tagging VPCs so that they appear in the VPC dropdown selection in Spinnaker. This change may take some time to cache and reflect in Spinnaker. In the Firewalls section, select your firewall, which maps to the preconfigured security group. Create the forwarding ports in the Listeners section. Finally, create the Health Check.

Then press Create.

Create a deploy pipeline

Navigate to the configuration screen of the previously created pipeline from the Bake Amazon Machine Images in a Spinnaker Pipeline guide.

Select Add Stage and select Deploy from the Type dropdown.

Select Add server group option in the ‘Deploy Configuration’

Select AWS option for the provider.

We’ll be shown the option to copy a configuration from a currently running server group if a server group for this application already exists. In our case, let’s select ‘None’ and continue.

Select the same VPC Subnet type as the ELB you just made. Remember to input ‘prod’ to the Stack field since that is what you used when creating the ELB.

If you skipped the ELB steps above and do not see the VPCs grouping available, or you need to crate a new VPC group, follow the instructions in the VPC Subnet Type guide. Tag your VPCs so that they are available for selection in the dropdown.

For this example, you use a Blue/Green deployment strategy. Leave 3 maximum server groups alive for normal services allows you to manually rollback in case of emergency easily.

Scroll down and select the load balancer that was just created from the list and select the preconfigured security group.

Note, the Firewall in this case will be for the EC2 instances.

Under the Instance Type section, select ‘Micro Utility’.

We’ll set the capacity at 1 for now, but we can later set it up to do auto-scaling.

Scroll all the way down to the Advanced Settings section and change the Health Check Type from ‘EC2’ to ‘ELB’, we’ll later see green boxes for health instances, gray for EC2 healthcheck instances, or red for unhealthy instances.

Select the keypair for the EC2 instances in Key Name.

Erase the IAM Instance Profile field. In our example, we don’t need access to any other AWS resources and the field may be filled in by default depending on your configurations.

Then click Add to complete this step.

We return back to the deploy stage, with it now looking like:

Finally, we can click Save Changes and select the back arrow to return to the Pipeline Executions screen.

I press ‘Start Manual Execution’ on my pipeline. This is what I see:

When this pipeline finishes the Bake stage, we can see it’s current stage/tasks status and we can also see it in the Clusters tab to see a new server group come up.

For more information about the details of this screen, see the Spinnaker's Application Screen guide.

I can see here that a new server has indeed come up and is healthy. Healthy in this case means that it has passed the ELB health check. If you are having problems with your instances not passing the health check, see the common errors section.

Now, to demonstrate the Blue/Green, go back to the Pipeline Executions screen and press ‘Start Manual Execution’ again. Then go back to the ‘Clusters’ tab to watch the execution process.

First you see that a new server group named v001 is being created. It doesn’t have any instances in it yet:

After a few moments an instance is created and is initially ‘unhealthy’:

Once it passes its healthchecks and becomes healthy, it will visually indicate so by turning green. At this point Armory will add the server group to the load balancer.

Immediately after that, the old server group is removed from the load balancer. Armory will turn the old server group’s instances blue. This means that they are disabled and no longer receiving traffic.

Because of how I configured my deploy stage, the old Blue server group will stick around until I either manually scale it down or destroy it. If you like, you can configure your deploy stage to automatically scale down the old server group after the new one is healthy.

Common errors and troubleshooting

If you are having trouble try checking out some of these topics:

Deploy times out

Often when your deploy stage is timing out, it is because your instances are never becoming healthy. In this case, Armory will keep terminating and replacing the instances.

Investigating red instances

Select your red instance and hover your cursor over the red triangle next to the load balancer under the ‘Status’ section. This should display some helpful information for understanding why your instance is not deploying correctly.

Incorrect health check

You have the option when deploying a new server group to use either EC2 or ELB health checking. When instances aren’t passing this health check they will be terminated and replaced. If you are experiencing strange behavior, double check that the correct health check is selected.

Deploy AZs vs ELB AZs

It is possible to set your ELB to work with certain AZs but then deploy your server group to another AZ. If you have your health check set to ELB, then your instances will never become healthy. You can tell when this happens by hovering you mouse over the red triangle described above.

Unknown errors

Sometimes you may encounter an ‘Unknown Error’ message when executing your deploy. Something like, “Shrink cluster: Exception: No reason provided.” These errors are almost always caused by a field having an incorrect value in the deploy configuration. This particular “Shrink cluster” error was caused by the server group’s region being invalid.

Deployment strategies

Blue/Green

This strategy was formerly called “Red/Black” in Spinnaker.

This strategy deploys a fresh server group and add it to the load balancer. The older server group will then be disabled.

When you configure this strategy you can choose to scale down the old server group. You can always scale it back up if you need it for a rollback. Also, you can choose how many old server groups to leave in the cluster.

Highlander

This strategy creates a new server group and add it to the load balancer. Once everything is healthy, the old server group(s) will be destroyed.

None

This strategy deploys a new server group. It won’t do anything about the older server groups. They will just all be in the load balancer together like one big happy family!

What does disabled mean?

When an instance is disabled within Armory, it is removed from all load balancers. Depending on how your application receives work, this may or may not stop your application from doing work. If your application receives work via the load balancer - like a web application - then it should actually be disabled. However, if you have an application that works similarly to pulling workloads off of a distributed queue (SQS, Kafka, etc), then removing it from a load balancer won’t change anything. In fact, it was probably never in a load balancer.

You can re-enable a server group by selecting it from the ‘Cluster’ screen, click the ‘Server Group Actions’ button on the right panel and click ‘Enable’.

UserData

You can pass custom information to your deployed instances through the ‘User Data’ field under the ‘Advanced Settings’ section of the deploy stage configuration.

Make sure to base64 encode the content before putting it into the field in the options.

UserData issues

If the default UserData doesn’t work with your instance launch sequence, there are two work-arounds you can use.

If the UserData you want to use is bash-compatible and will fit after that existing chunk of variables that Armory puts in, you can just put your base64 encoded UserData into the cluster config.
Adjust the UserData template using information from Clouddriver’s AWS UserData README. When we use that option we normally point udfRoot at something like /opt/spinnaker/config/custom-udf, and then add the custom-udf directory to the config package we release Spinnaker from. If you want to turn it off completely that means just adding the udfRoot option to clouddriver-local.yml, and putting a blank file at /opt/spinnaker/config/custom-udf/udf0 .

Passing environment data to your deployed instances

The default configuration of Spinnaker creates a file /etc/default/server-env on every instance with information about its environment. In the example above, server-env looks like:

CLOUD_ACCOUNT="default-aws-account"
CLOUD_ACCOUNT_TYPE="default-aws-account"
CLOUD_ENVIRONMENT="default-aws-account"
CLOUD_SERVER_GROUP="test-example-v001"
CLOUD_CLUSTER="test-example"
CLOUD_STACK="example"
CLOUD_DETAIL=""
EC2_REGION="us-west-2"
LAUNCH_CONFIG="test-example-v001-03302017224619"

Rolling back

Yup. Sometimes you need to rollback to a known previously working state.

Automatically

From the ‘Cluster’ tab, select a server group. Click the button on the right pane labeled ‘Server Group Actions’ and press ‘Rollback’

In the window that pops up, you can select which server group to rollback to.

The server group that you select will re-enabled and scaled up to the necessary number of replicas. Then the rolled back server group will be disabled.

Manually

If you are ever in a situation where you need to roll back without Spinnaker, you can do so from the AWS console. You will basically run through the process that Spinnaker would do automatically:

Scale up the older Auto Scaling Groups (ASG)
Add those instances to the ELB
Remove the newer ASG’s instances from the ELB
Scale down or delete the new ASG

Additional launch block devices

If you want additional block devices or a larger root partition you’ll need to add an a new list to the pipeline JSON. Unfortunately at this time there is no UI to add block devices.

Edit your pipeline’s JSON
Find your deployment dictionary. You’ll need to add the object of pairs for each cluster definition.
Add your custom block devices for launch under the key blockDevices.
Make sure that AMI Block Device Mappings is set to Defaults for selected instance type .

Block devices definition

"blockDevices": [
 {
 "deleteOnTermination": [true|false],
 "deviceName": "[device string]",
 "iops": [integer ranging from 100-20000],
 "size": [integer, size in GB, range from 1GB-64TB],
 "volumeType": "[st1|io1|gp2|sc1]"
 }
]

Example of additional block devices

"clusters": [
 {
 "account": "my-aws-account",
 "application": "myapplication",
 "blockDevices": [
 {
 "deleteOnTermination": true,
 "deviceName": "/dev/sda1",
 "size": 32,
 "volumeType": "gp2"
 }
 ]
 "copySourceCustomBlockDeviceMappings": false,
 "useAmiBlockDeviceMappings": false
 },
 ...
]

VPC subnet type

Throughout Spinnaker, Subnet Type is an abstraction of subnets within AWS.

You can find fields that you use to specify VPC Subnet type when creating load balancers, deploying server groups, etc.

In order to use a subnet within Spinnaker, you will need to tag it in AWS a certain way.

There are two ways you can tag them. One option is to use the convention spinnaker.<internal|external>.<region> for the subnet’s name. In the screenshot below, you can see that is what I have done on my subnets.

Another option is to create a tag named immutable_metadata with value {"purpose": "MySubnetNameInsideSpinnaker"}

Continuous-Deployment: Use Amazon Secure Storage Service (S3) Artifacts in Spinnaker

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

Before you start, you need to configure an S3 artifact account. If you don’t see an S3 option for Expected Artifacts “Match against” in the UI, you’ll need to double-check your installation is configured with the S3 account.

Identifying an S3 file as an artifact

On a pipeline’s Configuration, you’ll want to “Add Artifact”. If S3 has been configured, you should be able to select “S3” to “Match against”. Now all you should need to do is enter the object path as an S3 URL (ie. s3://mybucket/myfolder/myfile.yaml). You will want to select “Default Artifact” so that, if the pipeline is run manually, it knows what file to pull (because the artifact won’t be present in the trigger otherwise). Note that you can choose a completely different path – or even a complete different artifact source – for your default artifact.

Referencing the new image

Depending on what you’re using the file for, the artifact should show up as a possible selection in later stages. For example, if you wanted to use the S3 file as a deployment manifest, you could reference it in the “Deploy (Manifest)” stage: