Skip to content
Eric Holmes edited this page Jun 21, 2017 · 10 revisions

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

Implementation

There's a few areas within Stacker that should be refactored to make this easy:

  1. 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).
  2. Refactor lookups/providers to support profiles

Questions

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.

Clone this wiki locally