I started writing this in outlook but outlook doesn't support markdown or something ???????????
- Initially, implemented VPC creation automation
- This should have been implemented in CloudFormation, probably not worth bringing up
- Added a logical layer in VPC resource naming that allows us to
- Fix a salt-master to a VPC
- Then refer to subnets, securitygroups, etc, by generalized names, like “public-subnet”, and “db-SG”
- This allows us to build general instance and load balancer profiles that don’t refer to specific subnetIds, securitygroupIds, etc, and instead are composed at runtime with the configured VPC for the salt-master to determine the actual Ids that need to be shoved through the AWS API
us-west-2.conf
linux_small_vpc_us_west_2:
subnetid: subnet-1d99977f
securitygroupid:
- sg-14b6b876 # ssh
- sg-11b6b873 # db
- sg-1bb6b879 # npre
ssh_interface: private_ips
volumes:
- { device: /dev/sdb, virtualname: ephemeral0 }
extends: linux_small
vs
generic.conf
linux_small_vpc:
subnetid: db-subnet
securitygroupid:
- db-SG
- ssh-SG
- nrpe-SG
ssh_interface: private_ips
volumes:
- { device: /dev/sdb, virtualname: ephemeral0 }
extends: linux_small
The major upside being you don't need to and update the profiles for every AZ/region when you're changing something common. So you go from a set of profiles PER REGION to a single, common profile in generic.conf
- Parts of these generic profiles should probably be converted to CloudFormation, but as it is it solves our problems very well.
- These general configs are then naturally sharable between disparate environments, encouraging both collaboration and realistic test scenarios.
- Better hierarchical config
- In vanilla salt-cloud, configs allow a single level of extension and override, and doesn't attempt to merge nested dictionaries
- To allow for proper indirection, we implement extends to allow infinite depth, and do attempt to merge nested dictionaries where it is safe to do so