orange-policeman-5911901/27/2019, 12:34 AM
1. What is the support for multiple environments, e.g.: I'd prefer that we have say, 3 accounts instead of 1 account with 3 stacks, is that possible - how do API keys work in this case? What does Pulumi recommend to handle secrets across environments and say, prohibit a "Staging" environment API key from being used to deploy to the "Production" environment?There are several options. You can use any mix of cloud-provider accounts you want, and use either a single Pulumi stack which manages resources in multiple cloud-provider accounts or separate Pulumi stacks for each of the cloud-provider accounts. We provide RBAC as part of the stack management offered by pulumi.com for organiations, so you can restrict which Pulumi user accounts have read/write access to which stacks - which can provide a layer of defense in depth on top of your IAM configuration for you cloud provider. The most common approach here is to have separate Pulumi stacks per environment you are targeting, and set each stack's configuration with the desired secrets. Because it's all just code, you can also do whatever verification you want up front in the deployment to protect against accidentally deploying a stack with incorrect credentials - like comparing the account number of the credentials used for the deployment against a fixed account number that the stack is configured to deploy against, or providing all cloud provider credentials in explicit config so that no ambient credentials are used.
2. We use GitLab review apps to deploy many branches to Kubernetes, each as their own independent version of our entire backend/frontend, so we often have many versions of our pre-staging infrastructure running simultaneously. What would Pulumi recommend to handle this case? Are these considered their own "stacks", and would the pricing then be dependent on how manyThe simplest model is that each review app is it's own Pulumi stack. This is actually a really good fit for the stacks model - especially if you automate stack creation/teardown as part of the review app lifecycle. Re: pricing we've definitely heard the feedback on scalability of the pricing model for use cases like this and are working on some changes. @adamant-restaurant-73893 can follow-up to walk through some of what we're thinking there if you are interested. But high-level point is we definitely don't want pricing to be a blocker here - we absolutely want to enable these use cases that involve many small stacks.
gifted-island-5570201/29/2019, 7:20 PM
orange-policeman-5911901/31/2019, 7:31 PM
adamant-restaurant-7389302/07/2019, 12:36 AM