https://pulumi.com logo
#general
Title
# general
o

orange-policeman-59119

01/27/2019, 12:34 AM
Second & third: Devops-y questions 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? 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 many
w

white-balloon-205

01/29/2019, 6:00 PM
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 many
The 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.
g

gifted-island-55702

01/29/2019, 7:20 PM
I would also be interested in the planned changes to the stack pricing model 🙂 It would be great to know what we can expect.
o

orange-policeman-59119

01/31/2019, 7:31 PM
Thanks @white-balloon-205, I would like to hear what @adamant-restaurant-73893 and the company are thinking for evaluating per-stack pricing like this. For what it's worth, we typically have between 4 and 10 review apps going at a time, with 3 engineers on staff. I'd expect that to scale linearly or less as we grow, because eventually we'll have "pods" or "teams" of users which work together on feature branches, as opposed to each engineer typically working on one of a few different features at a time.
Hey @white-balloon-205 and @adamant-restaurant-73893, any update on this?
Hey @white-balloon-205, can you poke @adamant-restaurant-73893 on this? 🙂
w

white-balloon-205

02/06/2019, 11:59 PM
Will do 🙂.
a

adamant-restaurant-73893

02/07/2019, 12:36 AM
Successfully poked - and sorry for the tardy response!
Essentially, we are looking at a 'per user' option for pricing. We have work to do on this both from a packaging perspective, and product/engineering perspective. However, we recognize this might be preferable for certain teams. So... nothing to announce, but if you are serious about purchasing on that basis, then DM me and we can talk in detail on that.