-
Notifications
You must be signed in to change notification settings - Fork 167
RFC: Profiles
The AWS SDK's (and AWS CLI) support configuration of various "profiles" via the default ~/.aws/config and ~/.aws/credentials files. Profiles would be a natural way to support cross region and cross account provisioning of stacks.
As an example, say you wanted to provision a set of stacks in both us-east-1 and us-west-1 for redundancy. With profile support, you could do something like this:
$ echo <<EOF > .aws/config.prod
[profile hot]
region = us-east-1
role_arn = arn:aws:iam::1234:role/Stacker
[profile cold]
region = us-west-1
role_arn = arn:aws:iam::1234:role/Stacker
EOF
Then specify the profile to build a stack with:
stacks:
- name: vpc-east
profile: hot
class_path: blueprints.VPC
- name: vpc-west
profile: cold
class_path: blueprints.VPC
Then build out the stacks using the given profiles:
$ AWS_CONFIG_FILE=.aws/config.prod stacker build prod.env stacker.yaml
There's a few areas within Stacker that should be refactored to make this easy:
- Remove the --region flag or replace it with a --default-profile flag: The --region flag won't make a lot of sense in a profile world, but it might make sense to have a --default-profile flag, which would be used to specify the default profile when one isn't explicitly provided for a stack (and also as the profile to use for uploading to s3).
- Refactor lookups/providers to support profiles
Helpers for building out cross profile config?
If you're building out stacks for cross region/account, you'll probably end up with a lot of duplication between stack configurations. I don't think we should try to support this in the yaml config, and instead people should pre-process their stacker config to generate it programmatically before piping it to stacker. Like:
$ ./generate.py | stacker build prod.env
The potentially annoying thing is that, in order for this to work, similar stacks in different profiles need to be named different, so that you can use ${output }
to reference the stack.
How should this work with xref?
I think, to start, xref should just use the default profile.