https://pulumi.com logo
Join Slack
Powered by
Noob soon to be Pulumi user I had a few questions...
# getting-started
m
Noob soon to be Pulumi user I had a few questions about using Pulumi with a self-managed backend (which the docs don't really go super in depth on): • does referencing between projects function if the stacks are in different buckets? or must all projects and stacks be in the same bucket for this to work? ◦ if it must be in the same bucket, is it not super dodgy to have both my PROD and PREPROD project stacks in the same bucket? ◦ in an ideal world I would have the same set of projects (e,g infra, and apps) with a distinct stack for PREPROD and a stack for PROD for each project (with PROD stacks using the PROD bucket and PREPROD using the PREPROD bucket). Is this possible to achieve? • secondly is it possible to allow users to only read a state (therefore allow for a 
pulumi preview
but fail on a 
pulumi up
)? e,g by allowing AWSS3ReadOnlyAccess on a bucket. Or would this run the infra update but just fail to update the state? • finally is there an agreed upon best practice of repo structure (and or component design structure) for Pulumi projects? • is it possible to use the automationAPI with the pulumi k8s operator? If I have missed something painfully obvious in the docs, please feel free to refer me to the docs 🙂
m
The way you distinguish projects and stacks is orthogonal to how Pulumi canonically uses the terms: A stack is an instance of a program, so you'd have a "test", "staging", and "prod" stack. A project is usually associated with a set of programs and comprises many different stacks. (See this example.) You don't need to structure it like this, I've also worked on a project before where we created a new project for each deployment because it made sense in the context (multiple production deployments of the same application managed by completely separated teams). But this is how Pulumi is designed. You can keep multiple project states in the same bucket, it's essentially a collection of JSON files. In Pulumi Cloud, your organization gets the equivalent of one bucket for all projects. What are your concerns here? One typical setup is to have a dedicated infra account with the state bucket, and deploy into separate test/staging/prod accounts. This makes it relatively straightforward to configure permissions through IAM. References between projects will only work within the context of a single bucket, as far as I'm aware you can only be logged into one backend at a time.
• secondly is it possible to allow users to only read a state (therefore allow for a 
pulumi preview
but fail on a 
pulumi up
)? e,g by allowing AWSS3ReadOnlyAccess on a bucket. Or would this run the infra update but just fail to update the state?
As a general rule, you should not rely on Pulumi to protect your infrastructure this way. You'll have to scope your IAM roles and policies so that only authorized users can modify the infrastructure. It is possible to run 
pulumi preview
with infrastructure read permissions. To get a meaningful result, you'll want to refresh your state first (either through 
pulumi refresh
or by running 
pulumi preview --refresh
) so that it reflects the current state of your deployed resources. This requires write permissions for the state file: Pulumi will go through the state as it's currently recorded in the state file and update all resource entries so that they match the resource's actual state.
> finally is there an agreed upon best practice of repo structure (and or component design structure) for Pulumi projects? I'm not aware of a repo structure recommendation. I'd say it depends on how connected your programs are and how many components you have. You could either have a 
programs
and a 
components
(or 
lib
) directory, or a directory per program. If you just have a few programs, you can also just keep them all in the main folder as in the examples repo. Edit: Also check out this recent thread for more ideas and considerations.
> is it possible to use the automationAPI with the pulumi k8s operator? Yes. Think of the Automation API as an alternative to the Pulumi CLI. Instead of running commands like 
pulumi up
from your terminal you'll make these calls from your application code. But the Pulumi programs and everything else stays the same, you can use the same Pulumi programs via the Automation API and with the Pulumi CLI. If you look at the source code for the API, you'll see that it calls out to the Pulumi CLI: https://github.com/pulumi/pulumi/blob/master/sdk/python/lib/pulumi/automation/_cmd.py#L184 The Automation API is helpful if you want to create your own CLI or management application for your infrastructure.
m
Thank you for the responses! > What are your concerns here? Feels very dodgy to have all of the statefiles in a single bucket, as if I have the incorrect stack config flag used, it can impact another stack (in this case PREPROD and PROD). Also access to the bucket is easier to configure at an account level vs path level in a bucket. Can work within this pattern, just wanted to verify if is was possible to use different backends for different environments (where the environment is made up of inter-linked stacks - implementations of projects) > 
pulumi refresh
I assume if we mandate that only changes in IAC is canonical then this command is not required before a 
pulumi preview
? > As a general rule, you should not rely on Pulumi to protect your infrastructure this way. True, but I guess its more about failing fast, if the user attempts to deploy a stack, and has permissions to read state, no permissions to edit infra, and no permissions to write state, then I would hope it fails at the point after comparing changes before attempting to make changes (vs getting a 100 permission denied errors)
m
>> 
pulumi refresh
> I assume if we mandate that only changes in IAC is canonical then this command is not required before a 
pulumi preview
? You'll always want to refresh, even if only to verify that indeed everything is as you left it. In my experience, there's always something disappearing, being re-configured by another service, something auto-restarted to a different configuration... (There's a reason the controller pattern for infrastructure is a thing.) If you want to be sure that your 
pulumi up
goes through and your infrastructure will be in the state you defined in your Pulumi program, you should run a 
pulumi refresh
right before.
> As a general rule, you should not rely on Pulumi to protect your infrastructure this way.
True, but I guess its more about failing fast, if the user attempts to deploy a stack, and has permissions to read state, no permissions to edit infra, and no permissions to write state, then I would hope it fails at the point after comparing changes before attempting to make changes (vs getting a 100 permission denied errors)
This is obviously a case of "it depends" but I would still say that you should not manage this through read/write permissions on Pulumi state files. I can see a good case for someone not being allowed to change the infrastructure but no good case for someone who's allowed to see the infrastructure not being allowed to update the Pulumi state to the current infrastructure state.
>> What are your concerns here? > Feels very dodgy to have all of the statefiles in a single bucket, as if I have the incorrect stack config flag used, it can impact another stack (in this case PREPROD and PROD). Not saying you're wrong, but to counter your argument: if you're logged into the wrong state bucket, you have the same issue. > Also access to the bucket is easier to configure at an account level vs path level in a bucket. With AWS IAM I don't see a big difference here. It's either 
arn:aws:s3:::_amzn-s3-demo-bucket1_/*
or 
arn:aws:s3:::_amzn-s3-demo-bucket1_/my-project-path/*
in the policy. But it depends on how you generally go about managing access for roles/users, of course and I've also encountered situations where it was easier to use separate buckets for separate users/entities. > Can work within this pattern, just wanted to verify if is was possible to use different backends for different environments (where the environment is made up of inter-linked stacks - implementations of projects) You cannot have stack references across backends (as far as I know and understand the architecture) but you can have stack references across projects. Further food for thought: If you have one Pulumi project that contains both preprod and prod stacks, they'll necessarily have to have different names (e.g., 
db-preprod
and 
db-prod
) and nobody gets the idea to give the stacks the same name and someone just typing away 
pulumi stack select db
and 
pulumi up
is accidentally updating prod.
You might also find this blog series helpful, it walks through a canonical Pulumi project setup and evolution: https://www.pulumi.com/blog/iac-recommended-practices-code-organization-and-stacks/
m
Thank you once again for the responses! I will go through them and the reference noted, and work from there. Not opposed to the paradigm, just needed to understand the reasoning and rationale behind the approach to align it with current approaches used. I will for sure have more questions (and perhaps a deeper understanding) once I've played with it a bit more
2 Views
Open in Slack
PreviousNext
Powered by