VPC Preferences

Overview

A well behaved yac service will prompt you for any parameters it needs (e.g. subnet ids, ssh keys, etc.) when you install it via >> yac stack.

But you can improve the service installation experience through vpc preferences.

You can also ensure consistency of resource naming and tagging.

Implementation

Folder Layout

VPC Preferences are encoded in vpc-prefs.json, and reference files in the lib and stack directories.

The test directory contains units tests for each lib function.

vpc_prefs.json

SectionCode
prefs-name

Best practice to use <your company name/<your group name>:<version> for the prefs-name, since you'll probably want a unique set of default rules per group, especially for VPC subnets usage and az's.

 

 

"prefs-name": {
    "comment": "the name to associate with this set of preferences",
    "value": "nordstrom-sets:1.0"
  }
resource-namer
  "resource-namer": {
    "comment": ["script to run for naming resources in our vpc."],
    "value": "lib/namer.py"
  }
stock-templates
"stock-templates": {
   "comment": ["overrides of (and additions to) the yac stock templates for our VPC."],
   "asg":  "stack/yac-asg-stack.json",
   "db":   "stack/yac-db-stack.json",
   "eelb": "stack/yac-eelb-stack.json",
   "efs":  "stack/yac-efs-stack.json",
   "ielb": "stack/yac-ielg-stack.json"
 }
vpc-inputs

input scripts are one of things that make yac so flexible.

The script can be used to implement arbitrary business logic (e.g. for mapping resources to VPC subnets).

  "vpc-inputs": {
    "comment": ["script to run for getting additional parameters for resources in our VPCs that ",
                "are driven by sets resource-placement business logic."],
    "value": "lib/inputs.py"
  }
vpc-params
  • Anything in the vpc-params section will get copied into the service-params, and will be available to lib/inputs.py

  "vpc-params": {
    "subnets-name-tags": {
      "comment": ["The substring used to identify the subnets (by name) where yac resources should",
                  "be placed in our VPCs, one substring per layer."],
      "public":  "external-public-general",
      "dmz":     "external-private-general",
      "private": "internal-general"
    }, 
    "db-subnet-group-name-substring": {
      "comment": "The db subnet group we should use should contain this substring for all vpcs",
      "value": "internalgeneral"
    },
    "ntp-servers": {
      "comment": "The ntp servers that can be polled to sync time. Must use a semicolon delimitter (per our typical boot.sh files)",
      "value": "ntp001-6a.net.nordstrom.net;ntp319-1a.net.nordstrom.net"
    },        
    "vpc-name-tags": {
      "comment": "the default vpc for each environment",
      "dev":     "continuous",
      "stage":   "staging",
      "prod":    "infrastructure",
      "archive": "infra"
    }}

Sharing VPC Preferences

Sharing is easy:

yac prefs --share=<path>

 

yac will save your file to its registry and make it available to any other yac users that need to build resources in your vpc.

Tapping Shared VPC Preferences

yac users can configure yac to use a set of vpc preferences as follows:

yac prefs --set=<prefs name>

Once set, vpc preferences are persisted locally until cleared or overwritten with a new batch.

If you are in hosting business, you could quickly switch between vpc preferences by simply toggling between your vpc preference setpoints.