lemon-agent-27707
06/14/2023, 4:21 PMquiet-gold-81036
06/16/2023, 7:56 AMlemon-agent-27707
06/16/2023, 2:56 PMour mono-repo setup does cause some over-provisioningDeployments supports path filters so that certain stacks only get targeted by certain directories in your mono repo. We use it in one of our infrastructure monorepos. There are also some interesting patterns you can put to use with review stacks, such as using mutliple programs to share certain resources across review stacks. https://www.pulumi.com/docs/pulumi-cloud/deployments/review-stacks/#customizing-behavior-with-multiple-pulumi-programs https://www.pulumi.com/docs/pulumi-cloud/deployments/review-stacks/#customizing-behavior-with-path-filters
quiet-gold-81036
06/16/2023, 8:53 PMdry-journalist-60579
06/22/2023, 7:19 PMinfrastructure
mono repo with all our Pulumi projects+stacks. Our application code lives in separate repos (our backends and frontends).
• A Pulumi project per logical grouping of infrastructure—in most cases this maps pretty cleanly to one project per application, though we have a few extra utility projects for managing other shared infrastructure.
• For each Pulumi project we have two categories of stack “setups”
◦ For application-related projects, we generally have a stack for each application “environment” (e.g. development, staging, production). Even though these are “production” and “non-production” application environments, they are all “production” infrastructure.
◦ For other, more utility-related projects, we tend to have a single “production” stack. Confusingly, we don’t have a standard name for this. Sometimes it’s Pulumi.prod.yml, sometimes it’s related to the nature of the project, like Pulumi.ci.yaml or Pulumi.marketing.yaml. Side note: I’d love to come up with a word that isn’t “production” for infra to disambiguate this. Infra environments don’t necessarily correspond to application environments.
• We have a single project that manages all of our Pulumi Deployment resources. We have an entry per project, per stack, but currently the source_context
branch for all of our entries is refs/heads/main
.
• We have adopted a pattern of using a “sandbox” stack to develop new infra and make changes to infra. I think this is our version of review stacks. However, developers stand up and tear down this stack manually during the development process: 1) create a branch, 2) run pulumi up
in the current project targeting the pulumi-sandbox
stack. 3) make changes, run preview/up manually via CLI against the pulumi-sandbox
stack, iterate, repeat. 4) get code review, approval 5) merge the PR and Pulumi deployments will automatically run pulumi up
for the “production” infrastructure 6) manually run pulumi down
to clean up resources.
I guess my question is I’m imagining review stacks eliminates the need for us to manually run up/down with our pulumi-sandbox
stacks. How would I configure this?
This is our code:
def deployment_settings(project: str, stack: str, repo_dir: str):
return pulumiservice.DeploymentSettings(
resource_name=f"Deployment Settings: {project}/{stack}",
executor_context=pulumiservice.DeploymentSettingsExecutorContextArgs(
executor_image="<http://ghcr.io/OUR-ORG/pulumi-deployments-executor:latest|ghcr.io/OUR-ORG/pulumi-deployments-executor:latest>",
),
github=pulumiservice.DeploymentSettingsGithubArgs(
deploy_commits=True,
preview_pull_requests=True,
repository="OUR-ORG/infrastructure",
),
operation_context=pulumiservice.DeploymentSettingsOperationContextArgs(
oidc=pulumiservice.OperationContextOIDCArgs(
aws=pulumiservice.AWSOIDCConfigurationArgs(
duration="45m0s",
role_arn="arn:aws:iam::XXXXXX:role/PulumiOIDC",
session_name="pulumi",
),
),
options=pulumiservice.OperationContextOptionsArgs(
skip_install_dependencies=True,
),
pre_run_commands=["prerun.sh"],
),
organization="OUR-ORG",
project=project,
stack=stack,
source_context=pulumiservice.DeploymentSettingsSourceContextArgs(
git=pulumiservice.DeploymentSettingsGitSourceArgs(
branch="refs/heads/main",
repo_dir=repo_dir,
),
),
)
Usage in our deployments/__main__.py
deployment_settings(
project="app",
stack="dev", # Pulumi.dev.yaml
repo_dir="app",
)
deployment_settings(
project="app",
stack="prod", # Pulumi.prod.yaml
repo_dir="app",
)
deployment_settings(
project="app",
stack="staging", # Pulumi.staging.yaml
repo_dir="app",
)
lemon-agent-27707
06/23/2023, 3:58 PMI guess my question is I’m imagining review stacks eliminates the need for us to manually run up/down with ourYou'll need to create a new stack that acts as a template forstacks.pulumi-sandbox
pulumi-sandbox
, and configure deployment settings on it:
1. Create a new stack called pr
and copy the config from one of your sandbox stacks over to the pr
stack.
2. Create deployment settings for that stack, this should match how you typically configure a pulumi-sandbox
stack
3. set the branch for this stack to refs/heads/main
-- the branch for a review stack must be the branch that pull requests get opened against
4. Set the following values in your deployment settings under the github
key:
deployCommits: false,
previewPullRequests: false,
pullRequestTemplate: true,
This will configure this stack to act as a template stack. When you push commits to main
- these deployment settings will get ignored because deployCommits
is false, but when you open a PR these settings will be used since pullRequestTemplate
is true.
Your pr
stack will never be updated itself, but when a pull request is opened, pulumi deployments will create a new stack, copy the config from pr
into the new stack, copy the deployment settings over, and then run the update for you.dry-journalist-60579
06/23/2023, 4:25 PMThis will configure this stack to act as a template stack. When you push commits to- these deployment settings will get ignored becausemain
is false, but when you open a PR these settings will be used sincedeployCommits
is true.pullRequestTemplate