Other

Subnets

What To Expect

This guide should include:

Overview of how VPCs and Subnets are used within Spinnaker

Configuring Subnets to be used during Deployment stage

VPCs & Subnets

Subnets determine where and how you can deploy AWS resources such as EC2 machines, ELBs and Security Groups. Configuring your Subnets correctly the first time means you won’t have to update your pipelines later with changes.

Configuring Subnets

Spinnaker groups subnets into a single subnet name across multiple availability zones. This makes it simpler for end-users of Spinnaker to choose a group of subnets within a VPC that have a given purpose such as ec2-subnets, elb-subnets or public-subnets. This allows Spinnaker to place the machines within that group and ensure equal redundancy across zones. Below is a logical representation of how Spinnaker groups multiple subnets together. If you want to make a subnet accessible to Spinnaker you’ll have to add a tag and value to the subnet with the following: immutable_metadata={"purpose":"example-purpose"}

Conceptually, this is how Spinnaker groups subnets logically.

Verifying Subnet Configuration

Once you configured the purpose of your subnets you can use the Spinnaker API to double check that settings have been noticed. It will take between 30 seconds and 2 minutes for the changes to be picked up. After that time period you can run:

If the purpose field is non-null then things are configured correctly.

I Don’t See My Subnets or VPCs

Spinnaker caches as much as possible to keep performance through the UI responsive. If you don’t see the subnets and you believe you configured them correctly, then make sure to refresh the cache. You can find the cache going to the config section of your application and clicking refresh all caches. You should also make sure to refresh your browswer cache by using your browser’s development tools and deleting any browser databases.