From 6046be5133a369a878ac28694e427994f80be961 Mon Sep 17 00:00:00 2001 From: workprentice <257153108+workprentice@users.noreply.github.com> Date: Sat, 22 Aug 2026 12:54:15 +0000 Subject: [PATCH] Fix internal links to old /docs/concepts/ URLs (redirect-hop cleanup) Several docs, blog, and tutorial pages still link to the pre-restructure /docs/concepts/... URLs, which now 301 (some via a double hop) to their current /docs/iac/concepts/..., /docs/esc/concepts/, or /docs/reference/glossary/ locations. Updated 79 files (154 link occurrences, both root-relative markdown links and fully-qualified https://www.pulumi.com/... links) to point directly at the final destination, verified live against the current redirect map. Every fragment (#anchor) and the handful of double-hop cases (missing trailing slash -> slash -> new path) were preserved/collapsed correctly. One additional file with the same pattern (content/blog/why-choose-pulumi-over-terraform/index.md) was intentionally left untouched because it already has open PRs (#21062, #21066) touching it today; filed a follow-up board card to catch it separately. --- .../blog/advanced-aws-networking-part-1/index.md | 4 ++-- .../blog/advanced-aws-networking-part-2/index.md | 2 +- .../blog/advanced-typescript-type-ftw/index.md | 2 +- .../index.md | 2 +- .../index.md | 2 +- .../index.md | 2 +- .../architecture-as-code-kubernetes/index.md | 2 +- .../architecture-as-code-serverless/index.md | 2 +- content/blog/automation-api-as-platform/index.md | 2 +- content/blog/aws-serverless-analytics/index.md | 4 ++-- content/blog/command-provider-ga/index.md | 2 +- content/blog/community-aws-iam-package/index.md | 2 +- .../index.md | 2 +- .../index.md | 2 +- content/blog/crosswalk-for-aws-1-0/index.md | 2 +- .../index.md | 2 +- .../deploy-aws-static-website-with-yaml/index.md | 2 +- content/blog/dynamic-providers/index.md | 2 +- .../index.md | 2 +- content/blog/faster-secrets-management/index.md | 2 +- .../index.md | 2 +- .../index.md | 2 +- content/blog/functions-accept-outputs/index.md | 2 +- content/blog/go-sdk-road-to-2/index.md | 2 +- .../index.md | 2 +- .../index.md | 2 +- .../index.md | 2 +- .../index.md | 2 +- .../infrastructure-testing-concepts/index.md | 2 +- content/blog/intro-to-step-functions/index.md | 2 +- content/blog/jamstack-with-pulumi/index.md | 2 +- .../keep-your-secrets-secure-by-default/index.md | 10 +++++----- content/blog/kubernetes-yaml-v2/index.md | 4 ++-- .../index.md | 2 +- .../index.md | 4 ++-- .../index.md | 10 +++++----- .../index.md | 2 +- .../index.md | 4 ++-- .../next-level-iac-breakpoint-debugging/index.md | 8 ++++---- .../index.md | 16 ++++++++-------- .../next-level-iac-pulumi-runtime-logic/index.md | 6 +++--- content/blog/nx-monorepo/index.md | 2 +- .../organizing-aws-accounts-with-pulumi/index.md | 2 +- content/blog/p3-some-assembly-required/index.md | 6 +++--- content/blog/pulumi-3-0/index.md | 2 +- content/blog/pulumi-and-localstack/index.md | 2 +- content/blog/pulumi-loves-python/index.md | 4 ++-- content/blog/pulumi-release-notes-85/index.md | 6 +++--- content/blog/pulumi-release-notes-m60/index.md | 4 ++-- content/blog/pulumi-release-notes-m64/index.md | 2 +- content/blog/redis-cloud-provider/index.md | 2 +- content/blog/refactoring-iac/index.md | 2 +- content/blog/remediation-policies/index.md | 2 +- content/blog/run-your-own-rss-server/index.md | 2 +- content/blog/safe-lambda-secrets/index.md | 2 +- .../index.md | 2 +- .../six-things-about-pulumi-service/index.md | 4 ++-- content/blog/stack-readme/index.md | 2 +- content/blog/testing-in-practice/index.md | 2 +- .../testing-pulumi-programs-with-jest/index.md | 2 +- .../blog/tour-pulumi-equinix-provider/index.md | 4 ++-- .../index.md | 2 +- .../docs/deployments/operations/permissions.md | 2 +- .../docs/iac/concepts/inputs-outputs/apply.md | 10 +++++----- content/docs/iac/concepts/projects/_index.md | 2 +- .../docs/iac/guides/migration/import/_index.md | 14 +++++++------- content/docs/iac/guides/testing/unit.md | 4 ++-- .../yaml/yaml-component-reference.md | 2 +- .../yaml/yaml-language-reference.md | 2 +- .../building-with-pulumi/secrets/index.md | 2 +- .../tutorials/creating-resources-aws/index.md | 2 +- .../tutorials/creating-resources-azure/index.md | 2 +- .../tutorials/creating-resources-gcp/index.md | 2 +- .../creating-resources-kubernetes/index.md | 2 +- .../tutorials/inspecting-infrastructure/index.md | 2 +- .../create-a-pulumi-project/index.md | 6 +++--- .../tutorials/stack-outputs-refs-aws/index.md | 10 +++++----- .../tutorials/stack-outputs-refs-azure/index.md | 6 +++--- .../tutorials/stack-outputs-refs-gcp/index.md | 6 +++--- 79 files changed, 133 insertions(+), 133 deletions(-) diff --git a/content/blog/advanced-aws-networking-part-1/index.md b/content/blog/advanced-aws-networking-part-1/index.md index 196e37ad1c9c..f666c9ee19ba 100644 --- a/content/blog/advanced-aws-networking-part-1/index.md +++ b/content/blog/advanced-aws-networking-part-1/index.md @@ -137,7 +137,7 @@ The code samples in this section are not exhaustive. That is, they do not contai Now that you've added some foundational Transit Gateway resources, you can create your inspection VPC. -The inspection VPC is implemented as a [Pulumi component resource](https://www.pulumi.com/docs/concepts/resources/components/). While we do not need to create multiple inspection VPCs in this codebase, implementing the inspection VPC as a component resource enhances the readability of both the code and the output by grouping all resources that belong to the inspection VPC in the output of `pulumi up`. You can also improve the component's readability by placing its code in a separate file (in this case, `inspection.py`). +The inspection VPC is implemented as a [Pulumi component resource](https://www.pulumi.com/docs/iac/concepts/components/). While we do not need to create multiple inspection VPCs in this codebase, implementing the inspection VPC as a component resource enhances the readability of both the code and the output by grouping all resources that belong to the inspection VPC in the output of `pulumi up`. You can also improve the component's readability by placing its code in a separate file (in this case, `inspection.py`). When you create a component resource in Python, it's helpful to create a class that contains the arguments to the component resource. This allows you to pass the arguments to the component resource as a single object, which makes the code easier to read and understand. You can create a terse and easily readable arguments class in Python with the [`@dataclass` decorator](https://docs.python.org/3/library/dataclasses.html): @@ -247,7 +247,7 @@ for subnet_id in public_subnet_ids: ) ``` -You need to create both sets of these routes within an [apply](https://www.pulumi.com/docs/concepts/inputs-outputs/#apply) because of the need to access the raw values of each of the subnet ids. Apply can be conceptually difficult for beginners in Pulumi to grasp, but it essentially means "once you know all of the values that needed, pass them on to this function". +You need to create both sets of these routes within an [apply](https://www.pulumi.com/docs/iac/concepts/inputs-outputs/#apply) because of the need to access the raw values of each of the subnet ids. Apply can be conceptually difficult for beginners in Pulumi to grasp, but it essentially means "once you know all of the values that needed, pass them on to this function". ## Final steps diff --git a/content/blog/advanced-aws-networking-part-2/index.md b/content/blog/advanced-aws-networking-part-2/index.md index 496bea6d9baf..18b3f1390aab 100644 --- a/content/blog/advanced-aws-networking-part-2/index.md +++ b/content/blog/advanced-aws-networking-part-2/index.md @@ -55,7 +55,7 @@ In [AWS Advanced Networking Part 1](https://pulumi.com/blog/advanced-aws-network 1. Learned about the benefits of a hub-and-spoke network architecture with centralized egress. 1. Created the shared [AWS Transit Gateway](https://aws.amazon.com/transit-gateway/) resources to be shared among our spoke VPCs and inspection VPC. -1. Defined your inspection VPC as a Pulumi [component resource](https://www.pulumi.com/docs/concepts/resources/components/). +1. Defined your inspection VPC as a Pulumi [component resource](https://www.pulumi.com/docs/iac/concepts/components/). Now, to finish the architecture, you will need to: diff --git a/content/blog/advanced-typescript-type-ftw/index.md b/content/blog/advanced-typescript-type-ftw/index.md index b48a67df28e7..d6c33f5902b5 100644 --- a/content/blog/advanced-typescript-type-ftw/index.md +++ b/content/blog/advanced-typescript-type-ftw/index.md @@ -12,7 +12,7 @@ typechecking – making for a more productive inner loop and helping to find err how this works for infrastructure as code can be fascinating! -A core part of the Pulumi [programming model](/docs/concepts/) is that we allow people to express complex +A core part of the Pulumi [programming model](/docs/iac/concepts/) is that we allow people to express complex [dependency data](/docs/iac/concepts/inputs-outputs/) that may _eventually_ be available. Traditional JavaScript programming might expose that as a Promise, but we’ve taken that one step further by introducing a type we call: diff --git a/content/blog/ai-slack-bot-adding-data-to-pinecone-using-s3-embedchain-and-pulumi-on-aws/index.md b/content/blog/ai-slack-bot-adding-data-to-pinecone-using-s3-embedchain-and-pulumi-on-aws/index.md index 821aec12e226..e04ae8b940d2 100644 --- a/content/blog/ai-slack-bot-adding-data-to-pinecone-using-s3-embedchain-and-pulumi-on-aws/index.md +++ b/content/blog/ai-slack-bot-adding-data-to-pinecone-using-s3-embedchain-and-pulumi-on-aws/index.md @@ -281,7 +281,7 @@ app_event_lambda = aws.lambda_.Function( ) ``` -If you're new to Pulumi, you might be wondering what's going on with the `lambda_environment`, why isn't `app_bucket.id` referenced directly, and what is [pulumi.Output.all](https://www.pulumi.com/docs/concepts/inputs-outputs/all/)? Simply put, this tells Pulumi to wait until the bucket is created before trying to use its name in a string we're building. This is an important core feature of Pulumi that largely happens [by nesting Outputs](https://www.pulumi.com/docs/concepts/inputs-outputs/apply/#accessing-nested-output-values). To learn more, see [Inputs & Outputs](https://www.pulumi.com/docs/concepts/inputs-outputs/). +If you're new to Pulumi, you might be wondering what's going on with the `lambda_environment`, why isn't `app_bucket.id` referenced directly, and what is [pulumi.Output.all](https://www.pulumi.com/docs/iac/concepts/inputs-outputs/all/)? Simply put, this tells Pulumi to wait until the bucket is created before trying to use its name in a string we're building. This is an important core feature of Pulumi that largely happens [by nesting Outputs](https://www.pulumi.com/docs/iac/concepts/inputs-outputs/apply/#accessing-nested-output-values). To learn more, see [Inputs & Outputs](https://www.pulumi.com/docs/iac/concepts/inputs-outputs/). ## Triggering the data loader diff --git a/content/blog/announcing-infrastructure-as-code-with-java-and-pulumi/index.md b/content/blog/announcing-infrastructure-as-code-with-java-and-pulumi/index.md index 0639b694a9ca..834e90131c69 100644 --- a/content/blog/announcing-infrastructure-as-code-with-java-and-pulumi/index.md +++ b/content/blog/announcing-infrastructure-as-code-with-java-and-pulumi/index.md @@ -117,7 +117,7 @@ There you will find several instructions on installing and getting started with - [Getting started with Pulumi](https://www.pulumi.com/docs/get-started/) -- [General Pulumi overview (concepts and architecture)](https://www.pulumi.com/docs/concepts/) +- [General Pulumi overview (concepts and architecture)](https://www.pulumi.com/docs/iac/concepts/) Although Pulumi for Java is listed in "preview" status, it supports all of the most essential Pulumi programming model features (and the rest is on its way). Our goal is to gather feedback over the next few weeks, and we will be working hard to improve the Java experience across the board, including more examples and better documentation. diff --git a/content/blog/applying-attribute-based-access-controls-to-aws-lambda-functions/index.md b/content/blog/applying-attribute-based-access-controls-to-aws-lambda-functions/index.md index 012666e82a9a..f82b2855c496 100644 --- a/content/blog/applying-attribute-based-access-controls-to-aws-lambda-functions/index.md +++ b/content/blog/applying-attribute-based-access-controls-to-aws-lambda-functions/index.md @@ -557,7 +557,7 @@ Resources: Duration: 7s ``` -For the purposes of testing, we are now going to create a specific [AWS Provider resource](https://www.pulumi.com/docs/concepts/resources/providers/) that we can pass the IAM Role details to assume. +For the purposes of testing, we are now going to create a specific [AWS Provider resource](https://www.pulumi.com/docs/iac/concepts/providers/) that we can pass the IAM Role details to assume. {{< chooser language "typescript,csharp,python,go,yaml" >}} {{% choosable language typescript %}} diff --git a/content/blog/architecture-as-code-kubernetes/index.md b/content/blog/architecture-as-code-kubernetes/index.md index e086fe9521e3..5e7db0f38526 100644 --- a/content/blog/architecture-as-code-kubernetes/index.md +++ b/content/blog/architecture-as-code-kubernetes/index.md @@ -101,6 +101,6 @@ Using this example, you can quickly build any of the Kubernetes architectural pa ## Conclusion -Deploying modern applications is complex. Any one of the architectures we’ve examined -- virtual machines, microservices, serverless and Kubernetes -- require deploying and configuring multiple resources. For many reasons, including security, compliance, and cost management, we want to reuse resources consistently. In a sense, architecture as code is the logical progression of the DevOps principle of ["cattle not pets"](https://medium.com/@Joachim8675309/devops-concepts-pets-vs-cattle-2380b5aab313). Infrastructure as code is the tool that enables this by bringing standard development practices, such as code review, CI/CD, and testing to infrastructure. Learn how to build reusable infrastructure components with Pulumi’s [programming model](/docs/concepts/), [API reference for cloud service providers](/registry), and [examples](https://github.com/pulumi/examples). +Deploying modern applications is complex. Any one of the architectures we’ve examined -- virtual machines, microservices, serverless and Kubernetes -- require deploying and configuring multiple resources. For many reasons, including security, compliance, and cost management, we want to reuse resources consistently. In a sense, architecture as code is the logical progression of the DevOps principle of ["cattle not pets"](https://medium.com/@Joachim8675309/devops-concepts-pets-vs-cattle-2380b5aab313). Infrastructure as code is the tool that enables this by bringing standard development practices, such as code review, CI/CD, and testing to infrastructure. Learn how to build reusable infrastructure components with Pulumi’s [programming model](/docs/iac/concepts/), [API reference for cloud service providers](/registry), and [examples](https://github.com/pulumi/examples). Want to know more? Listen to the [New Stack Context podcast](https://thenewstack.io/pulumi-program-the-infrastructure-with-an-actual-programming-language/) on the Pulumi 2.0 release and Architecture as Code. diff --git a/content/blog/architecture-as-code-serverless/index.md b/content/blog/architecture-as-code-serverless/index.md index 2702330f7e5e..4dc988d9cfaf 100644 --- a/content/blog/architecture-as-code-serverless/index.md +++ b/content/blog/architecture-as-code-serverless/index.md @@ -102,7 +102,7 @@ rpa = aws.iam.RolePolicyAttachment('task-exec-policy', ) ``` -To learn more about creating [reusable components](/docs/concepts/resources#components), read about Pulumi's programming model, which shows how to author components. +To learn more about creating [reusable components](/docs/iac/concepts/resources/#components), read about Pulumi's programming model, which shows how to author components. ## Polyglot applications diff --git a/content/blog/automation-api-as-platform/index.md b/content/blog/automation-api-as-platform/index.md index ec881ba8b5b4..8d0880cf5758 100644 --- a/content/blog/automation-api-as-platform/index.md +++ b/content/blog/automation-api-as-platform/index.md @@ -23,7 +23,7 @@ This example demonstrates how to create infrastructure with Automation API and t ### Infrastructure as a function -We use an `inline` Pulumi program that doesn't require a separate package with `index.ts` and `Pulumi.yaml` files, although they can be authored in an `index.ts` file or imported from another package. The example deploys an AWS S3 website with the context and deployment automation defined in a function. Functions can be [components](/docs/concepts/resources#components), in this case, a static S3 website. However, they can be more complex, such as a Kubernetes cluster with accompanying containers and AWS resources. +We use an `inline` Pulumi program that doesn't require a separate package with `index.ts` and `Pulumi.yaml` files, although they can be authored in an `index.ts` file or imported from another package. The example deploys an AWS S3 website with the context and deployment automation defined in a function. Functions can be [components](/docs/iac/concepts/resources/#components), in this case, a static S3 website. However, they can be more complex, such as a Kubernetes cluster with accompanying containers and AWS resources. ```typescript const projectName = "pulumi_over_http"; diff --git a/content/blog/aws-serverless-analytics/index.md b/content/blog/aws-serverless-analytics/index.md index 1cefdd772a4e..63e91e3ee237 100644 --- a/content/blog/aws-serverless-analytics/index.md +++ b/content/blog/aws-serverless-analytics/index.md @@ -127,7 +127,7 @@ export const impressionInputStream = impressionsInputStream.name; export const clickInputStream = clicksInputStream.name; ``` -In a dozen lines of code, we’ve provisioned two of our desired tables, “clicks” and “impressions”, using our serverless streaming input architecture. It takes care of everything, including implicitly creating an arrival time [partition scheme](https://docs.aws.amazon.com/athena/latest/ug/partitions.html) with the key “inserted_at”. We export our Kinesis input streams as [stack outputs](/docs/concepts/stack#outputs) that can be referenced in other projects, such as the instrumentation within our ad server or consumer-facing web app. +In a dozen lines of code, we’ve provisioned two of our desired tables, “clicks” and “impressions”, using our serverless streaming input architecture. It takes care of everything, including implicitly creating an arrival time [partition scheme](https://docs.aws.amazon.com/athena/latest/ug/partitions.html) with the key “inserted_at”. We export our Kinesis input streams as [stack outputs](/docs/iac/concepts/stacks/#outputs) that can be referenced in other projects, such as the instrumentation within our ad server or consumer-facing web app. While on the surface this Pulumi component is described imperatively, it produces a declarative output in the form of a [state file](/docs/iac/concepts/state-and-backends/) that can be managed locally, in an object store like S3, or by the Pulumi Service backend. Running a ‘pulumi up’ shows that we’ve created 45 AWS resources, and lists our stack outputs to the console. @@ -457,7 +457,7 @@ While Lambda’s limits restrict the utility of this method, the concept is powe Developing software is an activity in seeking a specific state. For functions with simple inputs and outputs, this is a matter of well-factored code and unit test coverage. You can and should write this sort of test in your Pulumi applications. But often, the state that you’re seeking can’t be validated in unit tests. It raises many questions such as, “Am I stitching these cloud services together in a valid way? Will data flow from input service through to output destination? If I try to tighten down this IAM role, will everything still work?” -Our workflow is to make a change, run a pulumi up, and then verify that data ingested into Kinesis is read out the other end by Athena. A simple shell script using [stack outputs](/docs/concepts/stack#outputs) and a query in the AWS console are enough to get started here: +Our workflow is to make a change, run a pulumi up, and then verify that data ingested into Kinesis is read out the other end by Athena. A simple shell script using [stack outputs](/docs/iac/concepts/stacks/#outputs) and a query in the AWS console are enough to get started here: ```bash #/bin/sh diff --git a/content/blog/command-provider-ga/index.md b/content/blog/command-provider-ga/index.md index b7207f15a973..d9df3445fd8b 100644 --- a/content/blog/command-provider-ga/index.md +++ b/content/blog/command-provider-ga/index.md @@ -393,7 +393,7 @@ The 1.0 release of the Command provider marks a stable API for the 1.x series. R - The API documentation in the Pulumi registry has [examples in all Pulumi languages](https://github.com/pulumi/pulumi-command/issues/196) and is expanded. - Capturing stdout and stderr of commands can now [be switched off](https://github.com/pulumi/pulumi-command/pull/451), which is useful when they might contain secrets or are very noisy. - Environment handling for remote commands [has better error handling and is better documented](https://github.com/pulumi/pulumi-command/pull/395). -- The `CopyFile` resource is [superseded](https://github.com/pulumi/pulumi-command/pull/423) by the new `CopyToRemote` resource. It can copy whole directories in addition to individual files. The source of the copy is now a [Pulumi asset or archive](https://www.pulumi.com/docs/concepts/assets-archives/) which provides full interoperability with the Pulumi ecosystem. The use of assets and archives also makes Pulumi run copy operations only if the source has changed. For an easy transition, the previous `CopyFile` resource will remain available with a deprecation notice until the next major version. +- The `CopyFile` resource is [superseded](https://github.com/pulumi/pulumi-command/pull/423) by the new `CopyToRemote` resource. It can copy whole directories in addition to individual files. The source of the copy is now a [Pulumi asset or archive](https://www.pulumi.com/docs/iac/concepts/assets-archives/) which provides full interoperability with the Pulumi ecosystem. The use of assets and archives also makes Pulumi run copy operations only if the source has changed. For an easy transition, the previous `CopyFile` resource will remain available with a deprecation notice until the next major version. Here’s an example of copying a directory to a remote host. For brevity, the remote server is assumed to exist, but it could also be provisioned in the same Pulumi program. diff --git a/content/blog/community-aws-iam-package/index.md b/content/blog/community-aws-iam-package/index.md index c940f00aabed..39043a5d69ff 100644 --- a/content/blog/community-aws-iam-package/index.md +++ b/content/blog/community-aws-iam-package/index.md @@ -421,4 +421,4 @@ A few of the other use cases support by the Community AWS IAM package are: If you want to learn more about Pulumi and the Community AWS IAM package, here are a few links you might find interesting: - Read the [AWS IAM documentation](/registry/packages/aws-iam/) to learn more about the package, how to [install and configure](/registry/packages/aws-iam/installation-configuration/) it and use its APIs. -- If you’re interested in learning more about Pulumi concepts, try the [Concepts](/docs/concepts/) page. +- If you’re interested in learning more about Pulumi concepts, try the [Concepts](/docs/iac/concepts/) page. diff --git a/content/blog/controlling-aws-costs-with-lambda-and-pulumi/index.md b/content/blog/controlling-aws-costs-with-lambda-and-pulumi/index.md index 341779277f0f..bb6e84a871cd 100644 --- a/content/blog/controlling-aws-costs-with-lambda-and-pulumi/index.md +++ b/content/blog/controlling-aws-costs-with-lambda-and-pulumi/index.md @@ -310,7 +310,7 @@ You can continue adding new segments to the cleanup lambda to help cleanup your ## Deploying To Multiple Regions We want to ensure that all of our regions are cleaned up; therefore, we need to change the structure of the code. We can -take advantage of [explicit provider configuration](/docs/concepts/resources#explicit-provider-configuration) +take advantage of [explicit provider configuration](/docs/iac/concepts/resources/#explicit-provider-configuration) to allow us to target the deployment of a resource to a specific region. Let's assume we want to deploy our application to `us-east-1`, `us-east-2`, `eu-west-1`, `eu-west-2` and `us-west-2`. We can diff --git a/content/blog/create-eks-clusters-in-your-favorite-language/index.md b/content/blog/create-eks-clusters-in-your-favorite-language/index.md index ae9c45ffc529..8da73bde5bc6 100644 --- a/content/blog/create-eks-clusters-in-your-favorite-language/index.md +++ b/content/blog/create-eks-clusters-in-your-favorite-language/index.md @@ -62,5 +62,5 @@ If you haven't yet, try out the new pulumi-eks package with [this walkthrough]. [manage EKS clusters]: /blog/easily-create-and-manage-aws-eks-kubernetes-clusters-with-pulumi/ [multi-language components]: https://github.com/pulumi/pulumi/issues/2430 [this walkthrough]: https://www.pulumi.com/blog/easily-create-and-manage-aws-eks-kubernetes-clusters-with-pulumi/ -[resources]: https://www.pulumi.com/docs/concepts/resources/ +[resources]: https://www.pulumi.com/docs/iac/concepts/resources/ diff --git a/content/blog/crosswalk-for-aws-1-0/index.md b/content/blog/crosswalk-for-aws-1-0/index.md index 1612c72dc290..1f00d7af2112 100644 --- a/content/blog/crosswalk-for-aws-1-0/index.md +++ b/content/blog/crosswalk-for-aws-1-0/index.md @@ -47,7 +47,7 @@ Today, we’re excited to deliver the 1.0 releases of the three core libraries t Pulumi provides access to 100 providers (and counting!) for working with a wide variety of cloud and SaaS platforms. But since the very beginning of our work on Pulumi, [AWS](https://www.pulumi.com/registry/packages/aws/) has been the most used platform, both by the number of organizations using the provider, and by the average number of cloud resources managed per organization. -One of our guiding lights for Pulumi has always been to help organizations to scale up the complexity, capability, and richness of what they can build in the cloud, and in specific on the AWS platform. AWS offers an enormous number of powerful building block services, and organizations can stitch those building blocks together in countless ways to accomplish their needs. Pulumi brings a variety of software engineering tools to bear to help with this - rich programming languages, IDE productivity, testing, policy, and fast iteration. But none is more important than Pulumi’s focus on enabling the creation of [reusable infrastructure components](https://www.pulumi.com/docs/concepts/resources/components/) - higher level components that provide their own API interface built from the powerful building blocks of the underlying cloud resources. +One of our guiding lights for Pulumi has always been to help organizations to scale up the complexity, capability, and richness of what they can build in the cloud, and in specific on the AWS platform. AWS offers an enormous number of powerful building block services, and organizations can stitch those building blocks together in countless ways to accomplish their needs. Pulumi brings a variety of software engineering tools to bear to help with this - rich programming languages, IDE productivity, testing, policy, and fast iteration. But none is more important than Pulumi’s focus on enabling the creation of [reusable infrastructure components](https://www.pulumi.com/docs/iac/concepts/components/) - higher level components that provide their own API interface built from the powerful building blocks of the underlying cloud resources. The Crosswalk for AWS libraries offer components that help address many of the most common use cases we’ve seen AWS users need to tackle - configuring the many components of their VPC network setup, running containers on Amazon ECS and Fargate, configuring a fully featured and production ready Amazon EKS Cluster, and setting up the infrastructure and functions needed as part of a serverless architecture. All with just a few lines of code that offers AWS best practices out of the box, while offering the ability to scale up into the full features of the AWS platform. diff --git a/content/blog/deploy-aws-static-website-with-angular-components/index.md b/content/blog/deploy-aws-static-website-with-angular-components/index.md index 958fd17c026f..d7f3e6c47761 100644 --- a/content/blog/deploy-aws-static-website-with-angular-components/index.md +++ b/content/blog/deploy-aws-static-website-with-angular-components/index.md @@ -114,5 +114,5 @@ If you want to learn more about Pulumi and the AWS Static Website component, her * If you want to learn about other Pulumi components, the [registry](/registry/) page catalogs them all. * If you want to view more examples of how to use Pulumi, go to the Pulumi [examples](https://github.com/pulumi/examples) repo. * If you want to delve deeper into Pulumi, the [Getting Started](/docs/get-started/) guide is a good first step. -* If you’re interested in learning more about Pulumi concepts, try the [Concepts](/docs/concepts/) page. +* If you’re interested in learning more about Pulumi concepts, try the [Concepts](/docs/iac/concepts/) page. * If you want to learn more about Angular, see their [Getting Started](https://angular.io/start) docs. diff --git a/content/blog/deploy-aws-static-website-with-yaml/index.md b/content/blog/deploy-aws-static-website-with-yaml/index.md index 96304cb69c6c..fdd6cbf0ae2b 100644 --- a/content/blog/deploy-aws-static-website-with-yaml/index.md +++ b/content/blog/deploy-aws-static-website-with-yaml/index.md @@ -199,7 +199,7 @@ If you’re curious and want to learn more about Pulumi and the AWS Static Websi * If you want to learn about other Pulumi components, take a look at the [registry page](/registry/), which catalogs them all. * If you want to view more examples of how to use Pulumi, take a look at the Pulumi [examples](https://github.com/pulumi/examples) repo. * If you want to delve deeper into Pulumi, the [Getting Started](/docs/get-started/) guide is a good first step. -* If you’re interested in learning more about Pulumi concepts, try the [Concepts](/docs/concepts/) page. +* If you’re interested in learning more about Pulumi concepts, try the [Concepts](/docs/iac/concepts/) page. ## Install Pulumi diff --git a/content/blog/dynamic-providers/index.md b/content/blog/dynamic-providers/index.md index 297727bdbeac..9696a78b9b9c 100644 --- a/content/blog/dynamic-providers/index.md +++ b/content/blog/dynamic-providers/index.md @@ -27,7 +27,7 @@ A resource provider is made up of two different pieces: A resource provider is an extension of the API exposed by the respective cloud providers. As such, it can be the limiting factor. Thankfully, there is a solution to this. Since the Pulumi engine works with life-cycle callbacks handing control to the provider at appropriate times, it is easy to write a provider that implements custom logic in those callbacks. -Learn more about how Pulumi works [here](https://www.pulumi.com/docs/concepts/how-pulumi-works/). +Learn more about how Pulumi works [here](https://www.pulumi.com/docs/iac/guides/basics/how-pulumi-works/). ## Dynamic Resource Provider diff --git a/content/blog/enhanced-search-intuitive-navigation-new-docs-experience/index.md b/content/blog/enhanced-search-intuitive-navigation-new-docs-experience/index.md index 96a0953d04d0..b4ce4d3a1228 100644 --- a/content/blog/enhanced-search-intuitive-navigation-new-docs-experience/index.md +++ b/content/blog/enhanced-search-intuitive-navigation-new-docs-experience/index.md @@ -48,7 +48,7 @@ The [Pulumi cloud get started tutorials](/docs/integrations/clouds/) are for peo ### Concept docs -The [Pulumi concept docs](/docs/concepts/) are where you can dive into Pulumi concepts. Learn how they work together and how to effectively use them to ship infrastructure. +The [Pulumi concept docs](/docs/iac/concepts/) are where you can dive into Pulumi concepts. Learn how they work together and how to effectively use them to ship infrastructure. ![Pulumi concept docs](imgs/concepts.png) diff --git a/content/blog/faster-secrets-management/index.md b/content/blog/faster-secrets-management/index.md index 0503dbaff068..f41688fa90dd 100644 --- a/content/blog/faster-secrets-management/index.md +++ b/content/blog/faster-secrets-management/index.md @@ -18,7 +18,7 @@ social: linkedin: "Pulumi Infrastructure as Code now processes stack secrets more efficiently, reducing deployment times while maintaining robust security. Our latest update optimizes encryption and decryption operations through intelligent batching and smart change detection, eliminating unnecessary processing during updates. For stacks with many secrets, these improvements can save up to 10 seconds per operation, which adds up to significant time savings across your deployment pipeline. Update to version 3.155.0 today to experience these performance improvements without any configuration changes required." --- -Pulumi now handles [secrets](https://www.pulumi.com/docs/concepts/secrets/) more efficiently through optimized encryption and decryption processes, reducing deployment times while maintaining security standards. Users of [Pulumi Cloud](https://app.pulumi.com/signin) for state management will notice the most improvement due to new batch API capabilities. +Pulumi now handles [secrets](https://www.pulumi.com/docs/iac/concepts/secrets/) more efficiently through optimized encryption and decryption processes, reducing deployment times while maintaining security standards. Users of [Pulumi Cloud](https://app.pulumi.com/signin) for state management will notice the most improvement due to new batch API capabilities. diff --git a/content/blog/full-access-to-helm-features-through-new-helm-release-resource-for-kubernetes/index.md b/content/blog/full-access-to-helm-features-through-new-helm-release-resource-for-kubernetes/index.md index 93d13ebb9552..e160edb3bc22 100644 --- a/content/blog/full-access-to-helm-features-through-new-helm-release-resource-for-kubernetes/index.md +++ b/content/blog/full-access-to-helm-features-through-new-helm-release-resource-for-kubernetes/index.md @@ -26,7 +26,7 @@ The existing [Helm Chart](/registry/packages/kubernetes/api-docs/helm/v3/chart/) ## How is Helm Release resource different? -Pulumi's Helm Chart integration was implemented as a [Component Resource](/docs/concepts/resources#components) which effectively extracts the corresponding Kubernetes resources' manifests from the chart and installs them as if they were individually specified in the Pulumi user program. This allowed users to install community developed Helm charts, while providing fine-grained control over the respective Kubernetes resources installed in the process. For instance, the installed resources are subject to all policies specified through Policy-as-Code policy packs registered with Pulumi. Other users have used Pulumi's powerful transformation support to manipulate Helm charts to fit their desired needs before installing them in their environment. +Pulumi's Helm Chart integration was implemented as a [Component Resource](/docs/iac/concepts/resources/#components) which effectively extracts the corresponding Kubernetes resources' manifests from the chart and installs them as if they were individually specified in the Pulumi user program. This allowed users to install community developed Helm charts, while providing fine-grained control over the respective Kubernetes resources installed in the process. For instance, the installed resources are subject to all policies specified through Policy-as-Code policy packs registered with Pulumi. Other users have used Pulumi's powerful transformation support to manipulate Helm charts to fit their desired needs before installing them in their environment. In contrast, the new Helm Release resource uses the Helm SDK, bringing the full feature set of Helm directly to Pulumi users. This provides the following advantages: diff --git a/content/blog/full-coverage-of-azure-resources-with-azure-native/index.md b/content/blog/full-coverage-of-azure-resources-with-azure-native/index.md index 4add709cf089..4404d77f1670 100644 --- a/content/blog/full-coverage-of-azure-resources-with-azure-native/index.md +++ b/content/blog/full-coverage-of-azure-resources-with-azure-native/index.md @@ -196,7 +196,7 @@ Pass an explicit value to the `resourceGroupName` property if you want to contro However, suppose you create a sub-resource, e.g., a container under a storage account, a database under a database account, or a slot under a web app. In that case, Pulumi will not append a random suffix because those resources names don’t have to be globally unique. -You can also apply [transformations](https://www.pulumi.com/docs/concepts/resources/#transformations) to define your own naming schemas: see [this example](https://github.com/matwilko/Pulumi.AzureNextGen.Ambient/blob/434c4beccffdd8d1180e385ff5fe298867a285af/AutoNaming.cs) from our community. +You can also apply [transformations](https://www.pulumi.com/docs/iac/concepts/resources/#transformations) to define your own naming schemas: see [this example](https://github.com/matwilko/Pulumi.AzureNextGen.Ambient/blob/434c4beccffdd8d1180e385ff5fe298867a285af/AutoNaming.cs) from our community. ### Auto-Location diff --git a/content/blog/functions-accept-outputs/index.md b/content/blog/functions-accept-outputs/index.md index 814f2a7c7f4b..b92460d0c32d 100644 --- a/content/blog/functions-accept-outputs/index.md +++ b/content/blog/functions-accept-outputs/index.md @@ -88,7 +88,7 @@ registry. - Because the ECR registry ID is only known once the actual repository is provisioned in the cloud, the registryId property of the ecr.Repository resource has the type `Output` rather than - string (see [Inputs and Outputs](https://www.pulumi.com/docs/concepts/inputs-outputs/)). + string (see [Inputs and Outputs](https://www.pulumi.com/docs/iac/concepts/inputs-outputs/)). In the code below, note how `getCredentialsOutput` now accepts `appRepo.registryId` directly: diff --git a/content/blog/go-sdk-road-to-2/index.md b/content/blog/go-sdk-road-to-2/index.md index 79f5d4880b82..b59f1127f905 100644 --- a/content/blog/go-sdk-road-to-2/index.md +++ b/content/blog/go-sdk-road-to-2/index.md @@ -55,7 +55,7 @@ Although this code looks remarkably similar to using your cloud's Go SDK to impe Making Go a first-class citizen is a goal for the Pulumi 2.0 release. We especially wanted Go to have more idiomatic and stronger typing than `interface{}`. -Pulumi’s [programming model](/docs/concepts/) is inherently asynchronous. Consider creating a new AWS SecurityGroup, and using it to provision an EC2 instance. The EC2 instance must wait for the Group to finish provisioning, and the Pulumi engine must track this dependency. While two resources, modern cloud deployments commonly manage hundreds of resources. Pulumi models these resources using promise-like wrappers referred to as Inputs and Outputs allowing us to build a dependency graph, and parallelize cloud resource provisioning where possible. +Pulumi’s [programming model](/docs/iac/concepts/) is inherently asynchronous. Consider creating a new AWS SecurityGroup, and using it to provision an EC2 instance. The EC2 instance must wait for the Group to finish provisioning, and the Pulumi engine must track this dependency. While two resources, modern cloud deployments commonly manage hundreds of resources. Pulumi models these resources using promise-like wrappers referred to as Inputs and Outputs allowing us to build a dependency graph, and parallelize cloud resource provisioning where possible. Inputs, Outputs, and functions that operate over them ([All](/docs/iac/concepts/inputs-outputs/#all), [Apply](/docs/iac/concepts/inputs-outputs/#apply), [Sprintf](/docs/iac/concepts/inputs-outputs/#outputs-and-strings)) must be compatible with raw type primitives (string, integer, list, map, boolean), and user-defined structs. In other words, we must support polymorphism in a language that doesn’t have generics. We hide the gritty details behind a rich, strongly-typed API that we were able to iterate on easily thanks to the utilization of [code generation](https://github.com/pulumi/pulumi/blob/master/sdk/go/pulumi/types_builtins.go). diff --git a/content/blog/iac-best-practices-enabling-developer-stacks-git-branches/index.md b/content/blog/iac-best-practices-enabling-developer-stacks-git-branches/index.md index cdbea0c12898..a82c22cecfe6 100644 --- a/content/blog/iac-best-practices-enabling-developer-stacks-git-branches/index.md +++ b/content/blog/iac-best-practices-enabling-developer-stacks-git-branches/index.md @@ -54,7 +54,7 @@ The deployment process is still a bit more manual than the team would like --- b A few more details worth noting out about Team Zephyr's current setup: -* Both of the project's stack-configuration files, `Pulumi.dev.yaml` and `Pulumi.prod.yaml`, are checked into version control. This is safe and considered good practice (even with [secrets](https://www.pulumi.com/docs/concepts/secrets/)) because it allows the team to review or change the configuration of a given stack easily by viewing or editing the code in each file. +* Both of the project's stack-configuration files, `Pulumi.dev.yaml` and `Pulumi.prod.yaml`, are checked into version control. This is safe and considered good practice (even with [secrets](https://www.pulumi.com/docs/iac/concepts/secrets/)) because it allows the team to review or change the configuration of a given stack easily by viewing or editing the code in each file. * The `main` branch is the only long-lived branch in the repository; all others (e.g., developers' feature branches) are deleted once they're merged into `main`. diff --git a/content/blog/iac-best-practices-understanding-code-organization-stacks/index.md b/content/blog/iac-best-practices-understanding-code-organization-stacks/index.md index a6a0acd01fce..24bbec99d09c 100644 --- a/content/blog/iac-best-practices-understanding-code-organization-stacks/index.md +++ b/content/blog/iac-best-practices-understanding-code-organization-stacks/index.md @@ -79,7 +79,7 @@ In the case of Zephyr, their team felt like a monorepo approach (storing Pulumi The second question Zephyr encountered is how to handle the need for multiple instances of their application. In addition to a production instance---which is the instance behind Zephyr's public-facing online store---Zephyr also felt they needed an environment for the developers to use in testing changes to the online store. -This use case---needing to have multiple, separate instances of the infrastructure and applications created by a single Pulumi program---is exactly what [Pulumi stacks](https://www.pulumi.com/docs/concepts/stack/) were designed to address. Each stack is a separate instance of the resources created by a Pulumi program within a project. Further, each stack has its own independent state, and each stack has its own configuration values. Stacks can be short-lived (meaning the associated resources are also short-lived), or stacks can be long-lived. Aside from the cloud resources created by the Pulumi program, stacks are lightweight and simple to create or delete. +This use case---needing to have multiple, separate instances of the infrastructure and applications created by a single Pulumi program---is exactly what [Pulumi stacks](https://www.pulumi.com/docs/iac/concepts/stacks/) were designed to address. Each stack is a separate instance of the resources created by a Pulumi program within a project. Further, each stack has its own independent state, and each stack has its own configuration values. Stacks can be short-lived (meaning the associated resources are also short-lived), or stacks can be long-lived. Aside from the cloud resources created by the Pulumi program, stacks are lightweight and simple to create or delete. Zephyr decided to initially start with two stacks: a production stack (named "prod") and a development stack (named "dev"). As you'll observe throughout this series, this is a decision that is easily adjusted over time as your organization's requirements change. diff --git a/content/blog/if-you-liked-ksonnet-youll-love-pulumi/index.md b/content/blog/if-you-liked-ksonnet-youll-love-pulumi/index.md index a005270f9623..7f02b3ef3ee1 100644 --- a/content/blog/if-you-liked-ksonnet-youll-love-pulumi/index.md +++ b/content/blog/if-you-liked-ksonnet-youll-love-pulumi/index.md @@ -150,7 +150,7 @@ resources to check out: [Azure AKS](https://github.com/pulumi/examples/tree/master/classic-azure-ts-aks-mean) - Tutorial: [Operate and deploy to a Kubernetes cluster](/registry/packages/kubernetes/how-to-guides/exposed-deployment/) - Docs: [Pulumi docs](/docs/), including an - [overview of the programming model](/docs/concepts/) + [overview of the programming model](/docs/iac/concepts/) - Video: In February, we were honored to have Joe Beda [show where Pulumi fits in on his TGIK livestream](https://www.youtube.com/watch?v=ILMK65YVSKw), highlighting how to use your favorite language and consistent workflows to create, diff --git a/content/blog/improving-kubernetes-management-with-pulumis-await-logic/index.md b/content/blog/improving-kubernetes-management-with-pulumis-await-logic/index.md index 2b0b62dceb0b..1c2dca943e56 100644 --- a/content/blog/improving-kubernetes-management-with-pulumis-await-logic/index.md +++ b/content/blog/improving-kubernetes-management-with-pulumis-await-logic/index.md @@ -122,7 +122,7 @@ resources to check out: [Azure AKS](https://github.com/pulumi/examples/tree/master/classic-azure-ts-aks-mean) - Tutorial: [Operate and deploy to a Kubernetes cluster](/registry/packages/kubernetes/how-to-guides/exposed-deployment/) - Docs: [Pulumi docs](/docs/), including an - [overview of the programming model](/docs/concepts/) + [overview of the programming model](/docs/iac/concepts/) - Video: [Watch Joe Beda take Pulumi for a spin in last week's TGIK](https://www.youtube.com/watch?v=ILMK65YVSKw) As always, you can check out our code diff --git a/content/blog/infrastructure-testing-concepts/index.md b/content/blog/infrastructure-testing-concepts/index.md index 3e9fd899e716..bfc06c962774 100644 --- a/content/blog/infrastructure-testing-concepts/index.md +++ b/content/blog/infrastructure-testing-concepts/index.md @@ -82,7 +82,7 @@ Finally, there are several ways to run property tests against any cloud environm Integration tests validate whether services or modules in an application work as specified. Unlike unit tests, they use actual dependencies instead of mock objects, and they provide less precise feedback than unit or property tests. Because integration uses actual dependencies, they require that services be complete and functioning. Tests are run in a strict order to ensure that modules or services are instantiated before the test. Developers are less likely to write and run integration tests, leaving it to SRE experts in specialties such as chaos engineering and pipeline automation to write tests run in a CI/CD system. -In cloud engineering, an infrastructure integration test uses infrastructure deployed in an [ephemeral environment](https://about.gitlab.com/blog/kubecon-na-2019-are-you-about-to-break-prod/). As an example, we can use the Pulumi CLI to deploy the ephemeral environment as a [stack](/docs/concepts/stack/) that builds a dependency graph based on [inputs and outputs](/docs/concepts/inputs-outputs#inputs-and-outputs) that ensures the required resources are instantiated and available before the integration test. +In cloud engineering, an infrastructure integration test uses infrastructure deployed in an [ephemeral environment](https://about.gitlab.com/blog/kubecon-na-2019-are-you-about-to-break-prod/). As an example, we can use the Pulumi CLI to deploy the ephemeral environment as a [stack](/docs/iac/concepts/stacks/) that builds a dependency graph based on [inputs and outputs](/docs/iac/concepts/inputs-outputs/#inputs-and-outputs) that ensures the required resources are instantiated and available before the integration test. Once the resources are deployed, the integration test retrieves the stack outputs, which is often a public IP address or resource name. The test can be as complex as a suite of application-level tests between the various services or components or as simple as a health check that expects an HTTP 200 status return from an endpoint. The primary advantage of integration tests is that they use the same cloud infrastructure used in production to return actual values. diff --git a/content/blog/intro-to-step-functions/index.md b/content/blog/intro-to-step-functions/index.md index adb5bf59705c..74f50d5b8809 100644 --- a/content/blog/intro-to-step-functions/index.md +++ b/content/blog/intro-to-step-functions/index.md @@ -134,7 +134,7 @@ nice_fn = lambda_.Function('niceFunction', ) ``` -Finally, we need to update the state machine with a new workflow that includes our new function. The state machine takes three arguments, a name, an IAM role, and the workflow as a JSON document. The code to get the ARN names is Pulumi specific and requires an explanation if you are not familiar with the [Pulumi programming model](/docs/concepts/). +Finally, we need to update the state machine with a new workflow that includes our new function. The state machine takes three arguments, a name, an IAM role, and the workflow as a JSON document. The code to get the ARN names is Pulumi specific and requires an explanation if you are not familiar with the [Pulumi programming model](/docs/iac/concepts/). Instance properties of a resource are called outputs, which behave much like [promises](https://en.wikipedia.org/wiki/Futures_and_promises). This method is necessary because outputs may not be fully available until a resource is fully provisioned. To get the value of a resource, Pulumi has the `apply` method, which has a call back that receives the raw value and computes a new output. `Apply` is how we get the lambda ARN names in the workflow document. The [Output.all](/docs/iac/concepts/inputs-outputs/) method joins a list of Outputs that we can apply to a Python lambda. diff --git a/content/blog/jamstack-with-pulumi/index.md b/content/blog/jamstack-with-pulumi/index.md index 2367a922a8d8..5be1e5ae58f5 100644 --- a/content/blog/jamstack-with-pulumi/index.md +++ b/content/blog/jamstack-with-pulumi/index.md @@ -162,7 +162,7 @@ $ pulumi stack init website-testing $ pulumi config set aws:region us-east-1 ``` -1. Install [dependencies](https://www.pulumi.com/docs/concepts/how-pulumi-works/) for our Pulumi program. +1. Install [dependencies](https://www.pulumi.com/docs/iac/guides/basics/how-pulumi-works/) for our Pulumi program. {{< chooser language "typescript,python" >}} {{% choosable language typescript %}} diff --git a/content/blog/keep-your-secrets-secure-by-default/index.md b/content/blog/keep-your-secrets-secure-by-default/index.md index 9b4671436d9d..b7e6ecae0a3d 100644 --- a/content/blog/keep-your-secrets-secure-by-default/index.md +++ b/content/blog/keep-your-secrets-secure-by-default/index.md @@ -17,24 +17,24 @@ An unauthorized user gaining access to your infrastructure can be catastrophic: ## Pulumi’s built-in secret storage -Pulumi takes these risks seriously. That’s why we built the Pulumi platform to be secure by default. It protects all secret data using Pulumi’s built-in [secret storage](https://www.pulumi.com/docs/concepts/secrets/). This secret store “just works”, regardless of whether you use our hosted [Pulumi Service](https://www.pulumi.com/product/#teams), the [Self-Hosted Pulumi Service](https://www.pulumi.com/docs/pulumi-cloud/self-hosted/), or the [self-managed backend](https://www.pulumi.com/docs/iac/concepts/state-and-backends/#backends). The Pulumi Service protects secrets automatically when you create a stack with `pulumi new` or `pulumi stack init`. If you use a self-managed backend like AWS S3 or Google Cloud Storage, secrets are protected by a passphrase that you choose when you start a new stack with `pulumi new`. In all cases, every Pulumi [stack](https://www.pulumi.com/docs/concepts/stack/) gets a unique encryption key. +Pulumi takes these risks seriously. That’s why we built the Pulumi platform to be secure by default. It protects all secret data using Pulumi’s built-in [secret storage](https://www.pulumi.com/docs/iac/concepts/secrets/). This secret store “just works”, regardless of whether you use our hosted [Pulumi Service](https://www.pulumi.com/product/#teams), the [Self-Hosted Pulumi Service](https://www.pulumi.com/docs/pulumi-cloud/self-hosted/), or the [self-managed backend](https://www.pulumi.com/docs/iac/concepts/state-and-backends/#backends). The Pulumi Service protects secrets automatically when you create a stack with `pulumi new` or `pulumi stack init`. If you use a self-managed backend like AWS S3 or Google Cloud Storage, secrets are protected by a passphrase that you choose when you start a new stack with `pulumi new`. In all cases, every Pulumi [stack](https://www.pulumi.com/docs/iac/concepts/stacks/) gets a unique encryption key. ## What secrets are protected Pulumi protects all of the [`state`](https://www.pulumi.com/docs/iac/concepts/state-and-backends/) metadata that it knows about your infrastructure with encryption: encryption in transit when it’s sent to your backend and encryption at rest (if you’re using the hosted or self-hosted Pulumi Service). This base layer of protection applies to all state, including both non-secret and secret metadata. Secret storage is the next level of protection. It ensures that secret values are never exposed in plaintext in any file that Pulumi writes to your disk. Secrets are identified in a few ways: - All Pulumi providers—both native providers like [`azure-native`](https://github.com/pulumi/pulumi-azure-native/) and Terraform-based providers like [Datadog](https://github.com/pulumi/terraform-provider-datadog)—know which of their outputs should be secret and mark them as such. This ensures that you're secure by default when you start using a new provider. There's no need to pick which outputs are secret or worry that you’ve missed one. -- You can mark other Pulumi outputs [as secret](https://www.pulumi.com/docs/concepts/secrets/#explicitly-marking-resource-outputs-as-secrets). -- In addition to Pulumi inputs and outputs, you can also mark Pulumi configuration values [as secret](https://www.pulumi.com/docs/concepts/secrets/#secrets). +- You can mark other Pulumi outputs [as secret](https://www.pulumi.com/docs/iac/concepts/secrets/#explicitly-marking-resource-outputs-as-secrets). +- In addition to Pulumi inputs and outputs, you can also mark Pulumi configuration values [as secret](https://www.pulumi.com/docs/iac/concepts/secrets/#secrets). Any secret identified by you or by Pulumi is fully protected in the secret storage and not stored in plaintext on disk. This prevents leaks of secrets when files are committed to a source code repository or uploaded to a continuous integration and delivery system. ## Integration with other secret stores -For smaller organizations, the secret storage built into Pulumi is usually sufficient. In larger organizations however, it’s likely that a centralized secret management system is already in use, like [AWS Key Management System](https://aws.amazon.com/kms/), [Azure Key Vault](https://azure.microsoft.com/en-us/services/key-vault/), [Google Cloud Key Management](https://cloud.google.com/security-key-management), or [Hashicorp Vault](https://www.vaultproject.io/). Pulumi integrates with each of these systems to make it easy to [protect secrets](https://www.pulumi.com/docs/concepts/secrets/#initializing-a-stack-with-alternative-encryption) in the way required by the organization. +For smaller organizations, the secret storage built into Pulumi is usually sufficient. In larger organizations however, it’s likely that a centralized secret management system is already in use, like [AWS Key Management System](https://aws.amazon.com/kms/), [Azure Key Vault](https://azure.microsoft.com/en-us/services/key-vault/), [Google Cloud Key Management](https://cloud.google.com/security-key-management), or [Hashicorp Vault](https://www.vaultproject.io/). Pulumi integrates with each of these systems to make it easy to [protect secrets](https://www.pulumi.com/docs/iac/concepts/secrets/#initializing-a-stack-with-alternative-encryption) in the way required by the organization. ## Next steps It’s easy to get started with secrets management in Pulumi, because there’s nothing extra you need to do. Begin with any one of our [get started tutorials](https://www.pulumi.com/docs/get-started/) and Pulumi will automatically protect your secrets along the way. -[Learn more about Pulumi’s secret storage in our docs](https://www.pulumi.com/docs/concepts/secrets/) +[Learn more about Pulumi’s secret storage in our docs](https://www.pulumi.com/docs/iac/concepts/secrets/) diff --git a/content/blog/kubernetes-yaml-v2/index.md b/content/blog/kubernetes-yaml-v2/index.md index 47df0a45c083..283dde192b28 100644 --- a/content/blog/kubernetes-yaml-v2/index.md +++ b/content/blog/kubernetes-yaml-v2/index.md @@ -49,7 +49,7 @@ The `ConfigGroup` resource accepts the following input properties: | `skipAwait` | Skips over the readiness checks on the child resources. | Note that all objects defined within the manifest must have a `metadata.name` field; -Pulumi [autonaming](https://www.pulumi.com/docs/concepts/resources/names/#autonaming) is not supported. +Pulumi [autonaming](https://www.pulumi.com/docs/iac/concepts/resources/names/#autonaming) is not supported. See the [API Reference documentation](/registry/packages/kubernetes/api-docs/yaml/v2/configgroup/) for more information. @@ -143,7 +143,7 @@ For resources in the “core” group, the empty string is used instead (for exa ### Resource Prefixes The purpose of the resource prefix is to ensure the uniqueness -of child resource names, as described in [Pulumi: Resource Names](https://www.pulumi.com/docs/concepts/resources/names/#urns). +of child resource names, as described in [Pulumi: Resource Names](https://www.pulumi.com/docs/iac/concepts/resources/names/#urns). The best practice is to use the component name as a prefix, and now that's the default behavior. Note that the resource prefix is __not__ applied to the Kubernetes object names. diff --git a/content/blog/managing-aws-credentials-on-cicd-part-2/index.md b/content/blog/managing-aws-credentials-on-cicd-part-2/index.md index bdbb2a7a540d..a443faf820b0 100644 --- a/content/blog/managing-aws-credentials-on-cicd-part-2/index.md +++ b/content/blog/managing-aws-credentials-on-cicd-part-2/index.md @@ -144,7 +144,7 @@ With the mechanics of updating an AWS access key out of the way, the next step i systems. The following snippet shows how the `CredentialPusher` is configured in the key rotator app. We load a Travis CI access token from the -[Pulumi stack's configuration](https://www.pulumi.com/docs/concepts/config/), and hard-code the specific set of projects and encrypted environment variables to +[Pulumi stack's configuration](https://www.pulumi.com/docs/iac/concepts/config/), and hard-code the specific set of projects and encrypted environment variables to store the new access key. ```typescript diff --git a/content/blog/managing-aws-credentials-on-cicd-part-3/index.md b/content/blog/managing-aws-credentials-on-cicd-part-3/index.md index 49f29c391cbf..154331e53c66 100644 --- a/content/blog/managing-aws-credentials-on-cicd-part-3/index.md +++ b/content/blog/managing-aws-credentials-on-cicd-part-3/index.md @@ -267,7 +267,7 @@ along with the source code for a stack, so that builds and stack updates are rep However, what if those configuration settings contain secrets? Like you need to store an API key to use a 3rd party API. -Pulumi supports [encrypting sensitive configuration data](https://www.pulumi.com/docs/concepts/config/#secrets). +Pulumi supports [encrypting sensitive configuration data](https://www.pulumi.com/docs/iac/concepts/config/#secrets). You just need to add the `--secret` flag. ```bash @@ -284,7 +284,7 @@ is safe to check into your source tree, since it cannot be copied/decrypted for Pulumi keeps track of your cloud resources in a something called a [checkpoint file](/docs/iac/concepts/state-and-backends/), and that too might contain sensitive information. For example, a Pulumi resource might have a `"password"` output property. -Pulumi [has support](/docs/concepts/resources#additionalsecretoutputs) to mark that resource +Pulumi [has support](/docs/iac/concepts/resources/#additionalsecretoutputs) to mark that resource output as "secret" and make sure that it is encrypted within the checkpoint file. (So if you were to look at the checkpoint file contents via [`pulumi stack export`](/docs/iac/cli/commands/pulumi_stack_export/), you would not be able to recover the data. diff --git a/content/blog/migrating-my-infrastructure-from-terraform-to-pulumi/index.md b/content/blog/migrating-my-infrastructure-from-terraform-to-pulumi/index.md index bfb532f22763..0ef2e556f1d2 100644 --- a/content/blog/migrating-my-infrastructure-from-terraform-to-pulumi/index.md +++ b/content/blog/migrating-my-infrastructure-from-terraform-to-pulumi/index.md @@ -49,8 +49,8 @@ You might already know a bit of Pulumi, but here's a very quick overview plus so - Pulumi allows you to write your IaC using TypeScript, Javascript, Python, Go or C#. - You define *resources* which have *inputs* and *outputs*. As an example, a resource could be an RDS database Instance. One of it's inputs would be the database version to use. One of the outputs would be the hostname / address of the server. - The outputs are lazily evaluated, and their exact value is often not known until after you've executed your code. I.e. you wouldn't have the `db_instance.address` until the instance had been created. Think of outputs as promises / futures. -- You can use [component resources](https://www.pulumi.com/docs/concepts/resources/#components) to group your resources into logical groups - similar to how Terraform modules work. If you don't do this there's a high risk you'll end up with a very messy setup further down the line. -- Read Pulumi's own [overview](https://www.pulumi.com/docs/concepts/) and [naming](https://www.pulumi.com/docs/concepts/resources/#autonaming) docs before attempting to use Pulumi yourself. I'd say that's the most important bit to know about. +- You can use [component resources](https://www.pulumi.com/docs/iac/concepts/resources/#components) to group your resources into logical groups - similar to how Terraform modules work. If you don't do this there's a high risk you'll end up with a very messy setup further down the line. +- Read Pulumi's own [overview](https://www.pulumi.com/docs/iac/concepts/) and [naming](https://www.pulumi.com/docs/iac/concepts/resources/#autonaming) docs before attempting to use Pulumi yourself. I'd say that's the most important bit to know about. - Pulumi are using the [open core](https://en.wikipedia.org/wiki/Open-core_model) model where most features are free, but some extra goodies are on a paid tier. You can use the open source version and do state management yourself, but you miss out on certain features. So what does Pulumi code look like? Below is a minimal extract of some of the Python code I've written (slightly altered). @@ -129,7 +129,7 @@ Once I had everything migrated to Pulumi I set up a Gitlab CI/CD flow which allo #### Use component resources to group resources -When your infrastructure starts growing it becomes hard to manage unless you group your resources. Pulumi's solution to this are the so called [component resources](https://www.pulumi.com/docs/concepts/resources/#components). They are "logical components" which you define yourself. +When your infrastructure starts growing it becomes hard to manage unless you group your resources. Pulumi's solution to this are the so called [component resources](https://www.pulumi.com/docs/iac/concepts/resources/#components). They are "logical components" which you define yourself. ```shell $ pulumi stack @@ -150,7 +150,7 @@ It might seem like a small thing, but it *really* helps to have a logical grou #### Importing a resource that has a parent was a bit confusing at first -Each resource in pulumi has a globally unique [URN](https://www.pulumi.com/docs/concepts/resources/#urns). You can show the URNs for the infrastructure you've codeified in pulumi by issuing `pulumi stack --show-urns` +Each resource in pulumi has a globally unique [URN](https://www.pulumi.com/docs/iac/concepts/resources/#urns). You can show the URNs for the infrastructure you've codeified in pulumi by issuing `pulumi stack --show-urns` ```shell $ pulumi stack --show-urns @@ -331,7 +331,7 @@ policy=( The `.apply` method can also be useful for troubleshooting when you need to access the particular value of an output. -This might seem tricky at first, but digest this for a bit, then have a look at the docs for [Inputs and Outputs](https://www.pulumi.com/docs/concepts/inputs-outputs/) and I'm sure it'll all make sense. +This might seem tricky at first, but digest this for a bit, then have a look at the docs for [Inputs and Outputs](https://www.pulumi.com/docs/iac/concepts/inputs-outputs/) and I'm sure it'll all make sense. ### Don't name resources unless you really have to diff --git a/content/blog/mlops-huggingface-llm-aws-sagemaker-python/index.md b/content/blog/mlops-huggingface-llm-aws-sagemaker-python/index.md index d8819ceed38d..205275289c72 100644 --- a/content/blog/mlops-huggingface-llm-aws-sagemaker-python/index.md +++ b/content/blog/mlops-huggingface-llm-aws-sagemaker-python/index.md @@ -98,7 +98,7 @@ mkdir newSageMaker && cd newSageMaker pulumi new sagemaker-aws-python ``` -While creating a new project from the `sagemaker-aws-python` Pulumi template, you will be prompted for a [project](https://www.pulumi.com/docs/concepts/projects/) name, description, [stack](https://www.pulumi.com/docs/concepts/stack/) name, and Amazon Web Service [Region](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/). You can proceed with defaults, or supply your own. +While creating a new project from the `sagemaker-aws-python` Pulumi template, you will be prompted for a [project](https://www.pulumi.com/docs/iac/concepts/projects/) name, description, [stack](https://www.pulumi.com/docs/iac/concepts/stacks/) name, and Amazon Web Service [Region](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/). You can proceed with defaults, or supply your own. After responding to all prompts, the `pulumi new` command will proceed to setup a [Python Virtual Environment] (venv) and download all dependencies into the [venv]. diff --git a/content/blog/multicloud-with-kubernetes-and-pulumi/index.md b/content/blog/multicloud-with-kubernetes-and-pulumi/index.md index 68cdfc0a531e..47198e145b38 100644 --- a/content/blog/multicloud-with-kubernetes-and-pulumi/index.md +++ b/content/blog/multicloud-with-kubernetes-and-pulumi/index.md @@ -31,7 +31,7 @@ Please find the [repository with the full version of the code here.](https://git ## Part One: Create a component -A [Component Resource](https://www.pulumi.com/docs/concepts/resources/components/) is an abstraction on top of +A [Component Resource](https://www.pulumi.com/docs/iac/concepts/components/) is an abstraction on top of other Pulumi packages, often combining a few different providers into something that fits your infrastructure needs precisely. @@ -50,7 +50,7 @@ In our example, we are using three separate clouds, one of these being a local K Go and Nodejs._ Gather access tokens for Linode and Civo, if using, and set them in the environment or as -[secrets](https://www.pulumi.com/docs/concepts/secrets/#using-configuration-and-secrets-in-code). +[secrets](https://www.pulumi.com/docs/iac/concepts/secrets/#using-configuration-and-secrets-in-code). ### Start by writing the code for each cloud diff --git a/content/blog/next-level-iac-breakpoint-debugging/index.md b/content/blog/next-level-iac-breakpoint-debugging/index.md index cc21917d3134..b669a5f85622 100644 --- a/content/blog/next-level-iac-breakpoint-debugging/index.md +++ b/content/blog/next-level-iac-breakpoint-debugging/index.md @@ -349,10 +349,10 @@ The Pulumi Cloud is a fully managed service that helps you adopt Pulumi’s open [debugging]: https://en.wikipedia.org/wiki/Debugging [printf-debugging]: https://www.cs.colostate.edu/~fsieker/misc/debug/DEBUG.html [repl]: https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop -[input-docs]: https://www.pulumi.com/docs/concepts/inputs-outputs/#inputs -[output-docs]: https://www.pulumi.com/docs/concepts/inputs-outputs/#outputs -[apply-docs]: https://www.pulumi.com/docs/concepts/inputs-outputs/apply/ -[all-docs]: https://www.pulumi.com/docs/concepts/inputs-outputs/all/ +[input-docs]: https://www.pulumi.com/docs/iac/concepts/inputs-outputs/#inputs +[output-docs]: https://www.pulumi.com/docs/iac/concepts/inputs-outputs/#outputs +[apply-docs]: https://www.pulumi.com/docs/iac/concepts/inputs-outputs/apply/ +[all-docs]: https://www.pulumi.com/docs/iac/concepts/inputs-outputs/all/ [code-spelunking]: https://queue.acm.org/detail.cfm?id=945136 [vs-code-debug-repl]: https://code.visualstudio.com/docs/editor/debugging#_debug-console-repl [vs-code-launch-configs]: https://code.visualstudio.com/docs/editor/debugging#_launch-configurations diff --git a/content/blog/next-level-iac-briding-the-declarative-gap/index.md b/content/blog/next-level-iac-briding-the-declarative-gap/index.md index 626390eb9e3b..a4b2fdff9e0d 100644 --- a/content/blog/next-level-iac-briding-the-declarative-gap/index.md +++ b/content/blog/next-level-iac-briding-the-declarative-gap/index.md @@ -177,14 +177,14 @@ The Pulumi Cloud is a fully managed service that helps you adopt Pulumi’s open [yaml-wiki]: https://en.wikipedia.org/wiki/YAML [fsharp-example]: https://github.com/pulumi/examples/blob/master/aws-fs-s3-folder/Program.fs [pulumi-static-website-example]: https://www.pulumi.com/registry/packages/aws/how-to-guides/s3-website/ -[pulumi-declarative-imperative-docs]: https://www.pulumi.com/docs/concepts/how-pulumi-works/#declarative-and-imperative-approach -[pulumi-program-docs]: https://www.pulumi.com/docs/concepts/glossary/#program -[pulumi-engine-docs]: https://www.pulumi.com/docs/concepts/how-pulumi-works/#deployment-engine -[pulumi-providers-docs]: https://www.pulumi.com/docs/concepts/how-pulumi-works/#resource-providers -[input-docs]: https://www.pulumi.com/docs/concepts/inputs-outputs/#inputs -[output-docs]: https://www.pulumi.com/docs/concepts/inputs-outputs/#outputs -[apply-docs]: https://www.pulumi.com/docs/concepts/inputs-outputs/apply/ -[all-docs]: https://www.pulumi.com/docs/concepts/inputs-outputs/all/ +[pulumi-declarative-imperative-docs]: https://www.pulumi.com/docs/iac/guides/basics/how-pulumi-works/#declarative-and-imperative-approach +[pulumi-program-docs]: https://www.pulumi.com/docs/reference/glossary/#program +[pulumi-engine-docs]: https://www.pulumi.com/docs/iac/guides/basics/how-pulumi-works/#deployment-engine +[pulumi-providers-docs]: https://www.pulumi.com/docs/iac/guides/basics/how-pulumi-works/#resource-providers +[input-docs]: https://www.pulumi.com/docs/iac/concepts/inputs-outputs/#inputs +[output-docs]: https://www.pulumi.com/docs/iac/concepts/inputs-outputs/#outputs +[apply-docs]: https://www.pulumi.com/docs/iac/concepts/inputs-outputs/apply/ +[all-docs]: https://www.pulumi.com/docs/iac/concepts/inputs-outputs/all/ [futures-wiki]: https://en.wikipedia.org/wiki/Futures_and_promises [base64-wiki]: https://en.wikipedia.org/wiki/Base64 [next-level-iac-package-ecosystems]: https://www.pulumi.com/blog/next-level-iac-package-ecosystems/ diff --git a/content/blog/next-level-iac-pulumi-runtime-logic/index.md b/content/blog/next-level-iac-pulumi-runtime-logic/index.md index 4b828babe10c..20c4c3c95842 100644 --- a/content/blog/next-level-iac-pulumi-runtime-logic/index.md +++ b/content/blog/next-level-iac-pulumi-runtime-logic/index.md @@ -116,7 +116,7 @@ homepage = aws.s3.BucketObject( {{% /choosable %}} -Running processes like these synchronously, as above, means they'll complete before Pulumi starts [registering resources](https://www.pulumi.com/docs/concepts/how-pulumi-works) --- important here because the `BucketObject` resource needs that `public` folder to exist for the deployment to succeed. Fortunately it does, so all is well: +Running processes like these synchronously, as above, means they'll complete before Pulumi starts [registering resources](https://www.pulumi.com/docs/iac/guides/basics/how-pulumi-works/) --- important here because the `BucketObject` resource needs that `public` folder to exist for the deployment to succeed. Fortunately it does, so all is well: ``` $ pulumi up @@ -290,7 +290,7 @@ function createInvalidation(id: string) { cdn.id.apply(id => createInvalidation(id)); ``` -The relevant code is the call to [`process.on("beforeExit")`](https://nodejs.org/api/process.html#event-beforeexit), which registers a function to be invoked just before the program exits using the resolved ID of the distribution. (For more on how the `apply()` method works, see [Inputs and Outputs](https://www.pulumi.com/docs/concepts/inputs-outputs/).) The function returns early for Pulumi previews --- no sense clearing the cache if the site hasn't changed --- and uses the [AWS SDK for JavaScript](https://aws.amazon.com/sdk-for-javascript/) to submit the invalidation request to CloudFront, naming it uniquely with a timestamp and logging the result to the console: +The relevant code is the call to [`process.on("beforeExit")`](https://nodejs.org/api/process.html#event-beforeexit), which registers a function to be invoked just before the program exits using the resolved ID of the distribution. (For more on how the `apply()` method works, see [Inputs and Outputs](https://www.pulumi.com/docs/iac/concepts/inputs-outputs/).) The function returns early for Pulumi previews --- no sense clearing the cache if the site hasn't changed --- and uses the [AWS SDK for JavaScript](https://aws.amazon.com/sdk-for-javascript/) to submit the invalidation request to CloudFront, naming it uniquely with a timestamp and logging the result to the console: {{% /choosable %}} @@ -328,7 +328,7 @@ def create_invalidation(id): cdn.id.apply(lambda id: atexit.register(lambda: create_invalidation(id))) ``` -The relevant code is the call to [`atexit.register()`](https://docs.python.org/3/library/atexit.html), which registers a function to be invoked just before the program exits using the resolved ID of the distribution. (For more on how the `apply()` method works, see [Inputs and Outputs](https://www.pulumi.com/docs/concepts/inputs-outputs/).) The function returns early for Pulumi previews --- no sense clearing the cache if the site hasn't changed --- and uses [Boto3](https://boto3.amazonaws.com/v1/documentation/api/latest/index.html) to submit the invalidation request to CloudFront, naming it uniquely with a timestamp and logging the result to the console: +The relevant code is the call to [`atexit.register()`](https://docs.python.org/3/library/atexit.html), which registers a function to be invoked just before the program exits using the resolved ID of the distribution. (For more on how the `apply()` method works, see [Inputs and Outputs](https://www.pulumi.com/docs/iac/concepts/inputs-outputs/).) The function returns early for Pulumi previews --- no sense clearing the cache if the site hasn't changed --- and uses [Boto3](https://boto3.amazonaws.com/v1/documentation/api/latest/index.html) to submit the invalidation request to CloudFront, naming it uniquely with a timestamp and logging the result to the console: {{% /choosable %}} diff --git a/content/blog/nx-monorepo/index.md b/content/blog/nx-monorepo/index.md index bf2d3acffa0b..cf316dc3d91f 100644 --- a/content/blog/nx-monorepo/index.md +++ b/content/blog/nx-monorepo/index.md @@ -46,7 +46,7 @@ In the Node.js ecosystem, we've seen an explosion of great tooling over the last While it has always been possible to apply these tools to Pulumi Node.js projects in TypeScript or JavaScript just like any other Node.js project, we've recently made [a](https://github.com/pulumi/pulumi/issues/15436) [number](https://github.com/pulumi/pulumi/issues/2661) [of](https://github.com/pulumi/pulumi/issues/7168) [enhancements](https://github.com/pulumi/pulumi/issues/3013) [and](https://github.com/pulumi/pulumi/issues/15455) [fixes](https://github.com/pulumi/examples/issues/1605) to make sure that Pulumi works truly seamlessly with these tools. -In this post, we'll show how you can build a seamless development workflow by integrating Pulumi code level abstractions, such as [Component Resources](https://www.pulumi.com/docs/concepts/resources/components/), with a monorepo-based build system like [Nx](https://nx.dev). +In this post, we'll show how you can build a seamless development workflow by integrating Pulumi code level abstractions, such as [Component Resources](https://www.pulumi.com/docs/iac/concepts/components/), with a monorepo-based build system like [Nx](https://nx.dev). diff --git a/content/blog/organizing-aws-accounts-with-pulumi/index.md b/content/blog/organizing-aws-accounts-with-pulumi/index.md index 9f54e4f59444..30c10e89fa0d 100644 --- a/content/blog/organizing-aws-accounts-with-pulumi/index.md +++ b/content/blog/organizing-aws-accounts-with-pulumi/index.md @@ -84,7 +84,7 @@ const devAccount = new aws.organizations.Account( // This flag tells Pulumi to protect this resource from being deleted // during a `pulumi destroy` operation. It also means you need to // first unprotect it if you do wish to delete it using Pulumi. - // https://www.pulumi.com/docs/concepts/options/protect/ + // https://www.pulumi.com/docs/iac/concepts/resources/options/protect/ { protect: true } ); ``` diff --git a/content/blog/p3-some-assembly-required/index.md b/content/blog/p3-some-assembly-required/index.md index e52cfaab62c6..0666720a7f19 100644 --- a/content/blog/p3-some-assembly-required/index.md +++ b/content/blog/p3-some-assembly-required/index.md @@ -75,11 +75,11 @@ Next, in Pulumi Cloud, create an organization ***with exactly the same name*** a {{< figure src="teams-gh-pulumi.png" caption="Figure: Mapping GitHub orgs, teams, and roles to Pulumi">}} -Finally, you can [map teams to stacks](https://www.pulumi.com/docs/pulumi-cloud/access-management/teams/#granting-access-to-stacks-within-teams) to grant access at specific permission levels. If you’re not familiar with [Pulumi Stacks](https://www.pulumi.com/docs/concepts/stack/), a stack is a materialized instance of a specific set of cloud resources, as defined in a Pulumi program. +Finally, you can [map teams to stacks](https://www.pulumi.com/docs/pulumi-cloud/access-management/teams/#granting-access-to-stacks-within-teams) to grant access at specific permission levels. If you’re not familiar with [Pulumi Stacks](https://www.pulumi.com/docs/iac/concepts/stacks/), a stack is a materialized instance of a specific set of cloud resources, as defined in a Pulumi program. ## Pulumi ESC: Managing credentials, configuration, and other secrets -In order to deploy a stack you will need secrets such as cloud credentials and other configuration values that are provided to the deployment engine. Pulumi ESC is a secure system for managing secrets. They are organized by *[environments](https://www.pulumi.com/docs/concepts/environments/)*. +In order to deploy a stack you will need secrets such as cloud credentials and other configuration values that are provided to the deployment engine. Pulumi ESC is a secure system for managing secrets. They are organized by *[environments](https://www.pulumi.com/docs/esc/concepts/)*. An example set of environments might look something like this: @@ -201,7 +201,7 @@ Some other great features of Crossguard are the ability to [version policies](ht ## Multi-Language Components (MLC) -In Pulumi, a *[component resource](https://www.pulumi.com/docs/concepts/resources/components/)* is something that your developers can import in their Pulumi program, instantiate and modify. These are made available via a *[provider](https://www.pulumi.com/docs/concepts/resources/providers/)*, which is in turn, made available to Pulumi via a *[provider package](https://www.pulumi.com/docs/using-pulumi/pulumi-packages/)*. There are many of these already available in the [Pulumi Registry](https://www.pulumi.com/registry/). However, in a custom internal developer platform you can define your own components, and bake appropriate settings/configuration directly into the underlying code. +In Pulumi, a *[component resource](https://www.pulumi.com/docs/iac/concepts/components/)* is something that your developers can import in their Pulumi program, instantiate and modify. These are made available via a *[provider](https://www.pulumi.com/docs/iac/concepts/providers/)*, which is in turn, made available to Pulumi via a *[provider package](https://www.pulumi.com/docs/using-pulumi/pulumi-packages/)*. There are many of these already available in the [Pulumi Registry](https://www.pulumi.com/registry/). However, in a custom internal developer platform you can define your own components, and bake appropriate settings/configuration directly into the underlying code. A *multi-language component (MLC)* is even more useful. You can author your component in your language of choice and then generate a SDK that surfaces that component into all of the languages that Pulumi supports. For example, your platform team might be comfortable writing in Python, but the developers that write your microservices might use Go, and the developers who write the front-end apps might use Node.js. Both teams might need to deploy apps and infrastructure into your Kubernetes cluster. With multi-language components you can write a component in Python that abstracts away all the details of your custom Kubernetes cluster, and make that available to both teams, in both Go, Node.js, and any other language that Pulumi supports. diff --git a/content/blog/pulumi-3-0/index.md b/content/blog/pulumi-3-0/index.md index 8325f8c2b494..541699420fd9 100644 --- a/content/blog/pulumi-3-0/index.md +++ b/content/blog/pulumi-3-0/index.md @@ -61,7 +61,7 @@ Today, we’re also excited to be releasing a preview of the new Google Cloud Na -Pulumi Packages are the core technology that enables cloud infrastructure resource provisioning to be defined once, and made available to users in all languages supported by Pulumi. If you’ve ever used a cloud provider in Pulumi, you’ve used a Pulumi Package. With Pulumi 3.0, we are extending Pulumi Packages to also support building and packaging [Pulumi Components](/docs/concepts/resources#components): higher-level abstractions over cloud infrastructure patterns described as normal Pulumi programs. This makes it easy to take a Pulumi program that defines a collection of resources and turn it into something reusable: a Pulumi Package that can be published and used by all Pulumi users, across all languages supported by Pulumi. +Pulumi Packages are the core technology that enables cloud infrastructure resource provisioning to be defined once, and made available to users in all languages supported by Pulumi. If you’ve ever used a cloud provider in Pulumi, you’ve used a Pulumi Package. With Pulumi 3.0, we are extending Pulumi Packages to also support building and packaging [Pulumi Components](/docs/iac/concepts/resources/#components): higher-level abstractions over cloud infrastructure patterns described as normal Pulumi programs. This makes it easy to take a Pulumi program that defines a collection of resources and turn it into something reusable: a Pulumi Package that can be published and used by all Pulumi users, across all languages supported by Pulumi. One example of building and packaging Pulumi Components as a Pulumi Package is the [Pulumi EKS](https://github.com/pulumi/pulumi-eks/) package. We originally released a component for easily building and managing production-ready EKS clusters nearly two years ago, but it was only available for Node.js users of Pulumi as an npm package. This component has been incredibly popular, as it abstracts away a lot of complexity in all the moving pieces that need to be managed to stand up an EKS cluster across both AWS resources and in-cluster Kubernetes resources. Recently, we turned this component into a Pulumi Package, making it available to users in Python, Go, and .NET as well, with just a single implementation. Pulumi EKS is just the first example of applying this technology; there’s a lot more in the works here in the coming months! diff --git a/content/blog/pulumi-and-localstack/index.md b/content/blog/pulumi-and-localstack/index.md index a9ad16a9c78a..58f6265cb16b 100644 --- a/content/blog/pulumi-and-localstack/index.md +++ b/content/blog/pulumi-and-localstack/index.md @@ -62,7 +62,7 @@ There's probably a good reason most samples that show how to use Pulumi are one Despite the documentation, it can be quite confusing and becomes even more so when you deviate from the "one big file". It can become positively baffling when, as this application does, the infrastructure code is aware of the application code and performs the deployment of the application as part of the infrastructure update. I wanted to test the application logic separately from having to run Pulumi, so that separation of code was essential. -The big thing to remember is that a Pulumi "output" value [is not known until after the infrastructure has been fully provisioned](https://www.pulumi.com/docs/concepts/inputs-outputs/). They are a promise of a future value. If you want to refer to the value in other infrastructure code, Pulumi creates a dependency graph to be able to resolve the value at the right time. If, however, you want to refer to the value at runtime and you want to define that runtime code in a modular way, you have to be very clear about how that value is presented by Pulumi to that runtime code. +The big thing to remember is that a Pulumi "output" value [is not known until after the infrastructure has been fully provisioned](https://www.pulumi.com/docs/iac/concepts/inputs-outputs/). They are a promise of a future value. If you want to refer to the value in other infrastructure code, Pulumi creates a dependency graph to be able to resolve the value at the right time. If, however, you want to refer to the value at runtime and you want to define that runtime code in a modular way, you have to be very clear about how that value is presented by Pulumi to that runtime code. Our infrastructure code provisions a DynamoDB table and an AWS Lambda. That Lambda needs to know the name of that table at runtime in order to query it. Because the *actual* name of the table isn't known until provisioning is underway (Pulumi creates many infrastructure resources based on the logical name but with suffixes to avoid naming collisions), we need a way to get the "output" table name from Pulumi's `aws.dynamodb.Table` [API](https://www.pulumi.com/registry/packages/aws/api-docs/dynamodb/table/#example-usage) to the Lambda we'll create with the "simpler" way to create a Lambda using Pulumi's `cloud.API` [API](https://www.pulumi.com/docs/reference/pkg/nodejs/pulumi/cloud/#API). diff --git a/content/blog/pulumi-loves-python/index.md b/content/blog/pulumi-loves-python/index.md index 92221285a112..eef745521d5b 100644 --- a/content/blog/pulumi-loves-python/index.md +++ b/content/blog/pulumi-loves-python/index.md @@ -40,7 +40,7 @@ The result has been strong and steady growth of Python Pulumi usage. This has b Pulumi has long had support to create and manage virtual environments using Python's builtin package manager [pip](https://pip.pypa.io/en/stable/). With the [latest release of Pulumi](https://github.com/pulumi/pulumi/releases/tag/v3.121.0), we are excited to announce that we now support [Poetry](https://python-poetry.org) as well. Poetry is a popular Python dependency management tool that allows you to declare your dependencies in a simple and concise way and manage your virtual environment with ease. -When creating a new Pulumi project, the Pulumi CLI will now ask you if you want to use Poetry to manage your dependencies. If you choose to use Poetry, the Pulumi CLI will automatically create a new Poetry project for you and install the necessary dependencies. To opt-in to using Poetry for an existing Pulumi project, set the [`toolchain` runtime option](https://www.pulumi.com/docs/concepts/projects/project-file/#runtime-options) to `poetry` and run `pulumi install`. +When creating a new Pulumi project, the Pulumi CLI will now ask you if you want to use Poetry to manage your dependencies. If you choose to use Poetry, the Pulumi CLI will automatically create a new Poetry project for you and install the necessary dependencies. To opt-in to using Poetry for an existing Pulumi project, set the [`toolchain` runtime option](https://www.pulumi.com/docs/iac/concepts/projects/project-file/#runtime-options) to `poetry` and run `pulumi install`. ```yaml name: python-and-poetry-are-best-friends @@ -54,7 +54,7 @@ runtime: Pulumi Python SDKs include type hints compatible with type checkers such as [MyPy](https://www.mypy-lang.org) and [Pyright](https://microsoft.github.io/pyright/#/). In the latest release of Pulumi, you can ask Pulumi to run your typechecker of choice for you as part of Pulumi operations and fail if there are any type errors. This can help you catch type errors earlier and ensure that your Pulumi programs are type-safe. -Add the typechecker of your choice to [your dependencies](https://www.pulumi.com/docs/languages-sdks/python/#packages) and set the [`typechecker` runtime option](https://www.pulumi.com/docs/concepts/projects/project-file/#runtime-options) in your project file to `mypy` or `pyright` to enable automatic type checking. +Add the typechecker of your choice to [your dependencies](https://www.pulumi.com/docs/languages-sdks/python/#packages) and set the [`typechecker` runtime option](https://www.pulumi.com/docs/iac/concepts/projects/project-file/#runtime-options) in your project file to `mypy` or `pyright` to enable automatic type checking. ```yaml name: python-with-typechecking diff --git a/content/blog/pulumi-release-notes-85/index.md b/content/blog/pulumi-release-notes-85/index.md index 22dec7b2698a..11d04cd2e904 100644 --- a/content/blog/pulumi-release-notes-85/index.md +++ b/content/blog/pulumi-release-notes-85/index.md @@ -135,7 +135,7 @@ While a plugin is being installed, the CLI downloads the necessary archive and s ### "Yes, using Update Plans" prompt removed -[Update Plans](https://www.pulumi.com/docs/concepts/update-plans/) is a preview feature to constrain the update only to the operations that were planned during preview. To get extra feedback from our users, we experimented with showing an extra option "yes, using Update Plans" at the update prompt. The experiment is now complete, so we removed the option. +[Update Plans](https://www.pulumi.com/docs/iac/operations/stack-management/update-plans/) is a preview feature to constrain the update only to the operations that were planned during preview. To get extra feedback from our users, we experimented with showing an extra option "yes, using Update Plans" at the update prompt. The experiment is now complete, so we removed the option. Lean more in the [Remove the "yes, using Update Plans" prompt issue](https://github.com/pulumi/pulumi/issues/11894). @@ -143,7 +143,7 @@ Lean more in the [Remove the "yes, using Update Plans" prompt issue](https://git ### Output methods to serialize and deserialize JSON -Building JSON from values and parsing strings into JSON are two of the most common operations in Pulumi programs. All programming languages have built-in libraries to do so. However, quite often JSON operations need to be combined with Pulumi [Inputs and Outputs](https://www.pulumi.com/docs/concepts/inputs-outputs/), which required writing a cumbersome combination of `Apply` and serialization method calls. +Building JSON from values and parsing strings into JSON are two of the most common operations in Pulumi programs. All programming languages have built-in libraries to do so. However, quite often JSON operations need to be combined with Pulumi [Inputs and Outputs](https://www.pulumi.com/docs/iac/concepts/inputs-outputs/), which required writing a cumbersome combination of `Apply` and serialization method calls. To streamline this experience, Pulumi SDKs shipped helper serialization and deserialization functions that understand the type `Output` natively. Here is a simple usage example in Python, where `table.arn` is an output coming from another resource: @@ -167,7 +167,7 @@ policy = iam.Policy( ### Retrieve stack reference outputs as plain values -You can read outputs from one stack in another stack's program using [Stack References](https://www.pulumi.com/docs/concepts/stack/#stackreferences). In the past, the resulting values were always wrapped inside an `Output` container in order to preserve secret values (when needed). +You can read outputs from one stack in another stack's program using [Stack References](https://www.pulumi.com/docs/iac/concepts/stacks/#stackreferences). In the past, the resulting values were always wrapped inside an `Output` container in order to preserve secret values (when needed). With recent SDKs, we shipped an alternative method `StackReference.getOutputDetails`. This method returns a plain object with two fields: `value` and `secretValue`. At most one of these fields is set, depending on whether the stack reference output is a secret or not. diff --git a/content/blog/pulumi-release-notes-m60/index.md b/content/blog/pulumi-release-notes-m60/index.md index 0416fc749a3c..eb3619999646 100644 --- a/content/blog/pulumi-release-notes-m60/index.md +++ b/content/blog/pulumi-release-notes-m60/index.md @@ -45,13 +45,13 @@ In this milestone, we shipped Pulumi versions [3.9.0](https://github.com/pulumi/ ### Methods for Pulumi Component Packages -[Pulumi Components](/docs/concepts/resources#components) often have methods that provide additional functionality associated with an instance of a component. Previously, when [authoring a Pulumi Component Package](/docs/iac/guides/building-extending/providers/debugging-providers/), you couldn't make a component's methods available in all languages. Now, with updates to the [Pulumi Packages schema](/docs/iac/guides/building-extending/packages/schema/) and `Provider` interface, you can! We'll have a dedicated blog post out soon with more details on how to use methods in your Pulumi Component Package. +[Pulumi Components](/docs/iac/concepts/resources/#components) often have methods that provide additional functionality associated with an instance of a component. Previously, when [authoring a Pulumi Component Package](/docs/iac/guides/building-extending/providers/debugging-providers/), you couldn't make a component's methods available in all languages. Now, with updates to the [Pulumi Packages schema](/docs/iac/guides/building-extending/packages/schema/) and `Provider` interface, you can! We'll have a dedicated blog post out soon with more details on how to use methods in your Pulumi Component Package. [Learn more in this GitHub issue](https://github.com/pulumi/pulumi/issues/7072) ### `dependsOn` now works for Pulumi Component Packages, and more -The [`dependsOn` option](/docs/concepts/resources#dependson) creates a list of explicit dependencies between resources, which can be useful when you need to explicitly specify additional dependencies that Pulumi doesn’t know about but must still respect. Previously, `dependsOn` worked differently depending on the language your Pulumi code was written in or when referencing a component inside a Pulumi Component Package. Now, depending on a Pulumi Component Package's component will always wait on all of that component's children, regardless of language. Additionally, you can now pass `Input`s and `Output`s to `dependsOn`, which can be especially useful in Kubernetes and Helm workflows where you need to depend on the output of a resource created by a Helm chart. +The [`dependsOn` option](/docs/iac/concepts/resources/#dependson) creates a list of explicit dependencies between resources, which can be useful when you need to explicitly specify additional dependencies that Pulumi doesn’t know about but must still respect. Previously, `dependsOn` worked differently depending on the language your Pulumi code was written in or when referencing a component inside a Pulumi Component Package. Now, depending on a Pulumi Component Package's component will always wait on all of that component's children, regardless of language. Additionally, you can now pass `Input`s and `Output`s to `dependsOn`, which can be especially useful in Kubernetes and Helm workflows where you need to depend on the output of a resource created by a Helm chart. To see this work in action, check out the [Staged App Rollout Gated by Prometheus Checks](https://github.com/pulumi/examples/tree/ca40203279f393c0c159dadcadc97c6007122997/kubernetes-ts-staged-rollout-with-prometheus) example, where we create a staged rollout (from 3-replica canary -> 10-replica staging) gated by confirming that the P90 response time reported by Prometheus is less than some amount. The relevant code is the last line of this snippet, which lets your Kubernetes deployment depend on a Prometheus resource: diff --git a/content/blog/pulumi-release-notes-m64/index.md b/content/blog/pulumi-release-notes-m64/index.md index 4fc4dbb085b0..39b601709573 100644 --- a/content/blog/pulumi-release-notes-m64/index.md +++ b/content/blog/pulumi-release-notes-m64/index.md @@ -33,7 +33,7 @@ It's been another exciting few weeks here at Pulumi! We've caught our breath fro ### `dependsOn` can now await a fully-deployed Helm `Chart` resource -Pulumi's [`dependsOn` option](/docs/concepts/resources#dependson) enables you to write programs that deploy resources in a specific order. Previously, using this option with a Helm `Chart` resource could be confusing because Pulumi would consider the resource ready once it had registered the chart, even if Helm was still deploying some of the resources defined by the chart. Now, you can depend on a new `ready` attribute that will ensure that none of the dependent resources are deployed until the chart is deployed. For example, the code sample below creates an NGINX Ingress Controller and then creates a Kubernetes `ConfigMap` that depends on the controller being fully deployed. +Pulumi's [`dependsOn` option](/docs/iac/concepts/resources/#dependson) enables you to write programs that deploy resources in a specific order. Previously, using this option with a Helm `Chart` resource could be confusing because Pulumi would consider the resource ready once it had registered the chart, even if Helm was still deploying some of the resources defined by the chart. Now, you can depend on a new `ready` attribute that will ensure that none of the dependent resources are deployed until the chart is deployed. For example, the code sample below creates an NGINX Ingress Controller and then creates a Kubernetes `ConfigMap` that depends on the controller being fully deployed. ```typescript import * as k8s from "@pulumi/kubernetes"; diff --git a/content/blog/redis-cloud-provider/index.md b/content/blog/redis-cloud-provider/index.md index f4c94fd36144..298aabf47ae4 100644 --- a/content/blog/redis-cloud-provider/index.md +++ b/content/blog/redis-cloud-provider/index.md @@ -185,7 +185,7 @@ vpc.privateSubnetIds.apply(ids => { ``` {{% notes type="info" %}} -If you are unfamiliar with the call to `apply()`, you can learn more about why this is necessary in [Inputs and Outputs](https://www.pulumi.com/docs/concepts/inputs-outputs/#apply). Creating resources within `apply` is usually not necessary, but this is one of the few cases where it is. +If you are unfamiliar with the call to `apply()`, you can learn more about why this is necessary in [Inputs and Outputs](https://www.pulumi.com/docs/iac/concepts/inputs-outputs/#apply). Creating resources within `apply` is usually not necessary, but this is one of the few cases where it is. {{% /notes %}} Now, deploy the infrastructure using the `pulumi up` command: diff --git a/content/blog/refactoring-iac/index.md b/content/blog/refactoring-iac/index.md index a40ee382b97f..4b206589bc6e 100644 --- a/content/blog/refactoring-iac/index.md +++ b/content/blog/refactoring-iac/index.md @@ -24,7 +24,7 @@ A major difference between refactoring application and infrastructure code is th In cases where an object’s ID changes -- due to a rename, reparenting to a new component, or otherwise -- Pulumi provides [aliases](/docs/iac/concepts/resources/#aliases). An `Alias` accepts a list of identifiers that can include old `Alias` objects or old resource URNs. When a resource is annotated with an alias, Pulumi can connect the old to the new object state, and the resource can be updated in place. -A similar situation occurs with [`component resources`](/docs/concepts/resources#components), i.e., a logical grouping of related resources such as `VPC` with subnets pre-configured. When you change a parent resource of a component resource, the identity of the component resource also changes. Pulumi provides a [`parent`](/docs/concepts/resources#components) option to tie a child resource to the parent resource. The combination of `alias` and `parent` arguments to resources +A similar situation occurs with [`component resources`](/docs/iac/concepts/resources/#components), i.e., a logical grouping of related resources such as `VPC` with subnets pre-configured. When you change a parent resource of a component resource, the identity of the component resource also changes. Pulumi provides a [`parent`](/docs/iac/concepts/resources/#components) option to tie a child resource to the parent resource. The combination of `alias` and `parent` arguments to resources lets you refactor infrastructure while preserving existing resources. Let's examine how to apply refactoring to infrastructure. diff --git a/content/blog/remediation-policies/index.md b/content/blog/remediation-policies/index.md index 07e4edb88bec..a0d5812a4712 100644 --- a/content/blog/remediation-policies/index.md +++ b/content/blog/remediation-policies/index.md @@ -441,7 +441,7 @@ Both Azure and Kubernetes have ways to automatically remediate policy problems a In some ways, remediation policies are reminiscent of [Aspect Oriented Programming (AOP)](https://en.wikipedia.org/wiki/Aspect-oriented_programming), a popular technique in the Java community in the 2000s. Generally speaking, AOP was seen as too "magical" for widespread use. However, for targeted compliance scenarios like those discussed earlier, this approach strikes the right balance. Furthermore, we took great steps to ensure you can always find out precisely when and why a remediation changed things. -Finally, Pulumi has always had [transformations](https://www.pulumi.com/docs/concepts/options/transformations/) to perform in-memory modifications of resources as they get registered, either one at a time or across the whole stack. These run within a process and can hook resource registrations and mutate their state. The reason remediation policies are so different and interesting, however, is that they can be applied to programs without the program itself even having to opt-in. This is precisely what enables cross-organization enforcement. +Finally, Pulumi has always had [transformations](https://www.pulumi.com/docs/iac/concepts/resources/options/transformations/) to perform in-memory modifications of resources as they get registered, either one at a time or across the whole stack. These run within a process and can hook resource registrations and mutate their state. The reason remediation policies are so different and interesting, however, is that they can be applied to programs without the program itself even having to opt-in. This is precisely what enables cross-organization enforcement. ## Winding Down diff --git a/content/blog/run-your-own-rss-server/index.md b/content/blog/run-your-own-rss-server/index.md index 962c6f578f62..0aa23137a63b 100644 --- a/content/blog/run-your-own-rss-server/index.md +++ b/content/blog/run-your-own-rss-server/index.md @@ -227,6 +227,6 @@ And with that, you should now be able to browse your RSS server securely: ## Finishing Up -In this post, we've seen how easy it is to run a container as a service connected to an RDS database with Pulumi, and to expose that container securely on the web. If we wanted, we could go even farther --- we could refactor the program into Pulumi [Components](/docs/concepts/resources#components), perhaps (one for the service, one for the database), package it up for sharing on npm, and so on. +In this post, we've seen how easy it is to run a container as a service connected to an RDS database with Pulumi, and to expose that container securely on the web. If we wanted, we could go even farther --- we could refactor the program into Pulumi [Components](/docs/iac/concepts/resources/#components), perhaps (one for the service, one for the database), package it up for sharing on npm, and so on. But we'll leave those improvements for another day. For now, let's enjoy what we've created! And start catching up on all that reading we've missed. diff --git a/content/blog/safe-lambda-secrets/index.md b/content/blog/safe-lambda-secrets/index.md index d3006dcdf603..d3adc231f698 100644 --- a/content/blog/safe-lambda-secrets/index.md +++ b/content/blog/safe-lambda-secrets/index.md @@ -10,7 +10,7 @@ tags: category: tutorials --- -The subject of how to make use of secrets in Lambda Functions comes up a fair bit, and although there seems to be a lot of discussion on where you _should_ store them, the one thing that comes up is that **you should never store the plain text values of secrets in the Lambda Function's environment variables**. One such discussion I was having with a customer made me think about how it should be possible to take the secrets that you've got on your [stack config file](https://www.pulumi.com/docs/concepts/config) and then use them to configure your Lambda Function, with the plain text values going into the Function's environment variables and the encrypted secret values going into AWS' Secrets Manager. +The subject of how to make use of secrets in Lambda Functions comes up a fair bit, and although there seems to be a lot of discussion on where you _should_ store them, the one thing that comes up is that **you should never store the plain text values of secrets in the Lambda Function's environment variables**. One such discussion I was having with a customer made me think about how it should be possible to take the secrets that you've got on your [stack config file](https://www.pulumi.com/docs/iac/concepts/config/) and then use them to configure your Lambda Function, with the plain text values going into the Function's environment variables and the encrypted secret values going into AWS' Secrets Manager. diff --git a/content/blog/scaling-apps-across-multiple-regions/index.md b/content/blog/scaling-apps-across-multiple-regions/index.md index 4d6231ab5bba..208b39e1f0c9 100644 --- a/content/blog/scaling-apps-across-multiple-regions/index.md +++ b/content/blog/scaling-apps-across-multiple-regions/index.md @@ -41,7 +41,7 @@ Although multi-region deployments are needed for scaling, availability, and perf ## The Pulumi solution -A stack is a distinct deployment target within a Pulumi project. Stacks enable you to organize, version, and manage your infrastructure code effectively. They are flexible enough to do more than merely plan deployments across different stages of development. You may better control infrastructure orchestration with them as an adaptable tool for managing deployments in a variety of circumstances. Each stack represents a separate instance of your infrastructure, allowing you to deploy and manage your resources in different environments or configurations. To learn more about stacks, you can read [this](https://www.pulumi.com/docs/concepts/stack/). +A stack is a distinct deployment target within a Pulumi project. Stacks enable you to organize, version, and manage your infrastructure code effectively. They are flexible enough to do more than merely plan deployments across different stages of development. You may better control infrastructure orchestration with them as an adaptable tool for managing deployments in a variety of circumstances. Each stack represents a separate instance of your infrastructure, allowing you to deploy and manage your resources in different environments or configurations. To learn more about stacks, you can read [this](https://www.pulumi.com/docs/iac/concepts/stacks/). Consider how Pulumi Stacks can be used effectively in the following ways: diff --git a/content/blog/six-things-about-pulumi-service/index.md b/content/blog/six-things-about-pulumi-service/index.md index 4754fcf8d677..7ed9f9664325 100644 --- a/content/blog/six-things-about-pulumi-service/index.md +++ b/content/blog/six-things-about-pulumi-service/index.md @@ -21,7 +21,7 @@ tags: category: product --- -As a reader of this blog, you've probably heard of the [Pulumi Service](/product/pulumi-service/), the default state-management [backend](/docs/iac/concepts/state-and-backends/) of the Pulumi CLI. If that's the case, there's also a good chance you've heard of a number of the Service's key features, like helping you organize your [projects and stacks](/docs/iac/concepts/stacks/), collaborate with others with the help of [organizations](/docs/administration/organizations-teams/organizations/), or handle sensitive data securely with built-in support for [encrypted secrets](https://www.pulumi.com/docs/concepts/secrets/). +As a reader of this blog, you've probably heard of the [Pulumi Service](/product/pulumi-service/), the default state-management [backend](/docs/iac/concepts/state-and-backends/) of the Pulumi CLI. If that's the case, there's also a good chance you've heard of a number of the Service's key features, like helping you organize your [projects and stacks](/docs/iac/concepts/stacks/), collaborate with others with the help of [organizations](/docs/administration/organizations-teams/organizations/), or handle sensitive data securely with built-in support for [encrypted secrets](https://www.pulumi.com/docs/iac/concepts/secrets/). What you might not know, though, is that we're adding new features to the Pulumi Service all the time, and that some of these features can be fairly easy to miss. So in this post, we'll highlight a handful of the features you might _not_ be aware of, and that we think make it even easier to manage your infrastructure with Pulumi. @@ -93,7 +93,7 @@ However, in order to see the expanded resource graph, click the Graph View butto ![All resources in a stack, rendered as a graph](https://user-images.githubusercontent.com/274700/150619812-e32419b9-db31-489f-b132-df59b4da2c9f.png) -Notice here that the resources that are part of a [_component_](https://www.pulumi.com/docs/concepts/resources/#components) are grouped together. Also, you can double click on those nodes in the graph to expand or collapse them! +Notice here that the resources that are part of a [_component_](https://www.pulumi.com/docs/iac/concepts/resources/#components) are grouped together. Also, you can double click on those nodes in the graph to expand or collapse them! ## Feature 6: Drilling into Resource Properties diff --git a/content/blog/stack-readme/index.md b/content/blog/stack-readme/index.md index 6add81a1829c..9baddb75f0fc 100644 --- a/content/blog/stack-readme/index.md +++ b/content/blog/stack-readme/index.md @@ -46,7 +46,7 @@ Each Pulumi Stack you deploy manages a key set of cloud infrastructure for your A README is a text file that introduces and explains a project. A Pulumi Service Stack README can contain documentation and common links for the Stack. The key difference between a source control README, such as a GitHub README, and a Pulumi Service Stack README, is that it is dynamically populated with details from your stack outputs. It does this by interpolating output variables on the stack (`${outputs.instances[0].ARN}`) so that each stack can construct links to dashboards, shell commands, and other pieces of documentation. All of this content stays up to date as you stand up new stacks, rename resources, and refactor your infrastructure. -There are a lot of operational activities that happen around [Pulumi Stacks](https://www.pulumi.com/docs/concepts/stack), but critical information is spread across many tools. We have heard from our users that it can be time consuming switching from different tools and web apps to manage their deployments- from their cloud Console, to the Pulumi Service User Interface (UI), to the CLI, and so on. By collecting resource outputs in the Pulumi Service UI, we are reducing this friction and keeping relevant Stack information in one place so that is kept up to date automatically. +There are a lot of operational activities that happen around [Pulumi Stacks](https://www.pulumi.com/docs/iac/concepts/stacks/), but critical information is spread across many tools. We have heard from our users that it can be time consuming switching from different tools and web apps to manage their deployments- from their cloud Console, to the Pulumi Service User Interface (UI), to the CLI, and so on. By collecting resource outputs in the Pulumi Service UI, we are reducing this friction and keeping relevant Stack information in one place so that is kept up to date automatically. README templates can reference Stack outputs and resource properties, for example `${outputs.vpc.ARN}`. To walk you through a tangible example, a user can deploy an RDS instance and then use a variable in their README template to link to their CloudWatch dashboard to keep an eye on operational metrics. This CloudWatch dashboard link will dynamically update when deployments happen. You can use the same README template across dev, testing and production and have the correct dashboard links for each Stack. Learn more in the [Stack READMEs documentation page](https://www.pulumi.com/docs/pulumi-cloud/projects-and-stacks/#stack-readme). diff --git a/content/blog/testing-in-practice/index.md b/content/blog/testing-in-practice/index.md index fb95c7a612b6..fcaf43998c56 100644 --- a/content/blog/testing-in-practice/index.md +++ b/content/blog/testing-in-practice/index.md @@ -128,7 +128,7 @@ In this simple example, we'll use Automation API to create an S3 bucket and perf - delete the file - delete the stack with the bucket -The following code sets up the Pulumi [stack](/docs/concepts/) and S3 bucket with Automation API. It's interesting to note that the tests don't import the Pulumi AWS SDK and uses a combination of Python's built-in `unittest` framework and Amazon's [`boto3`](https://aws.amazon.com/sdk-for-python/) Python library. This illustrates the extensibility and flexibility of [infrastructure as code](/what-is/what-is-infrastructure-as-code/) by letting developers choose the tools and SDKs. +The following code sets up the Pulumi [stack](/docs/iac/concepts/) and S3 bucket with Automation API. It's interesting to note that the tests don't import the Pulumi AWS SDK and uses a combination of Python's built-in `unittest` framework and Amazon's [`boto3`](https://aws.amazon.com/sdk-for-python/) Python library. This illustrates the extensibility and flexibility of [infrastructure as code](/what-is/what-is-infrastructure-as-code/) by letting developers choose the tools and SDKs. ```python import os diff --git a/content/blog/testing-pulumi-programs-with-jest/index.md b/content/blog/testing-pulumi-programs-with-jest/index.md index f5c96645eff9..44cd4b79dcc4 100644 --- a/content/blog/testing-pulumi-programs-with-jest/index.md +++ b/content/blog/testing-pulumi-programs-with-jest/index.md @@ -541,7 +541,7 @@ export const timeURL = new aws.lambda.FunctionUrl("time-url", { export const audioURL = timeURL.functionUrl; ``` -Finally, open `index.ts` (which should still be empty) and add a couple of lines to import the `resources` module and export the function URL as a Pulumi [stack output](/docs/concepts/stack#outputs): +Finally, open `index.ts` (which should still be empty) and add a couple of lines to import the `resources` module and export the function URL as a Pulumi [stack output](/docs/iac/concepts/stacks/#outputs): ```typescript import "./resources"; diff --git a/content/blog/tour-pulumi-equinix-provider/index.md b/content/blog/tour-pulumi-equinix-provider/index.md index 6b610be7c0e5..c0aeb7c353e5 100644 --- a/content/blog/tour-pulumi-equinix-provider/index.md +++ b/content/blog/tour-pulumi-equinix-provider/index.md @@ -85,7 +85,7 @@ kubectl get pods --all-namespaces ## Deploying a workload with the Pulumi Kubernetes provider -Now that your cluster is provisioned, you can deploy a workload (or any other Kubernetes or Helm resource) using the [Pulumi Kubernetes provider](https://www.pulumi.com/registry/packages/kubernetes/). In order to deploy Kubernetes resources to your cluster, you need to first declare an explicit provider. The explicit provider is needed because you are _creating the cluster and deploying workloads to that cluster in the same Pulumi program_. (For more details on default and explicit providers, see [Resource providers](https://www.pulumi.com/docs/concepts/resources/providers/).) Configure the provider to use the [Kubeconfig](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) of your newly created cluster: +Now that your cluster is provisioned, you can deploy a workload (or any other Kubernetes or Helm resource) using the [Pulumi Kubernetes provider](https://www.pulumi.com/registry/packages/kubernetes/). In order to deploy Kubernetes resources to your cluster, you need to first declare an explicit provider. The explicit provider is needed because you are _creating the cluster and deploying workloads to that cluster in the same Pulumi program_. (For more details on default and explicit providers, see [Resource providers](https://www.pulumi.com/docs/iac/concepts/providers/).) Configure the provider to use the [Kubeconfig](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) of your newly created cluster: {{% chooser language "typescript,python" / %}} @@ -110,7 +110,7 @@ k8s_provider = k8s.Provider( {{% /choosable %}} -You can then add resources to the cluster by specifying your explicit provider as a [resource option](https://www.pulumi.com/docs/concepts/options/): +You can then add resources to the cluster by specifying your explicit provider as a [resource option](https://www.pulumi.com/docs/iac/concepts/resources/options/): {{% chooser language "typescript,python" / %}} diff --git a/content/blog/unit-testing-cloud-deployments-with-dotnet/index.md b/content/blog/unit-testing-cloud-deployments-with-dotnet/index.md index 8cfe502bc56b..9641676b3ce4 100644 --- a/content/blog/unit-testing-cloud-deployments-with-dotnet/index.md +++ b/content/blog/unit-testing-cloud-deployments-with-dotnet/index.md @@ -326,7 +326,7 @@ let getValue(output: Output<'a>): 'a = {{% /choosable %}} -To learn more about outputs, read [this article](/docs/concepts/stack#outputs). +To learn more about outputs, read [this article](/docs/iac/concepts/stacks/#outputs). ## First Test diff --git a/content/docs/deployments/operations/permissions.md b/content/docs/deployments/operations/permissions.md index 7f8511fce4e6..838d28763654 100644 --- a/content/docs/deployments/operations/permissions.md +++ b/content/docs/deployments/operations/permissions.md @@ -31,7 +31,7 @@ By default, the permissions that are granted to a deployment depend on how the d The permission model has the following practical implications: -- If your organization has default stack permissions set to `NONE`, then any deployment created by a `git push` or a pull request will not be able to access any [Stack References](https://www.pulumi.com/docs/concepts/stack/#stackreferences), and will fail if it tries to do so. +- If your organization has default stack permissions set to `NONE`, then any deployment created by a `git push` or a pull request will not be able to access any [Stack References](https://www.pulumi.com/docs/iac/concepts/stacks/#stackreferences), and will fail if it tries to do so. - If your organization has default environment permissions set to `NONE`, then any deployment created by a `git push` or a pull request will not be able to access any [ESC Environments](https://www.pulumi.com/docs/esc/concepts/environments/) that are listed in the stack's configuration file. diff --git a/content/docs/iac/concepts/inputs-outputs/apply.md b/content/docs/iac/concepts/inputs-outputs/apply.md index 523951ca7ca8..23bc5f45e403 100644 --- a/content/docs/iac/concepts/inputs-outputs/apply.md +++ b/content/docs/iac/concepts/inputs-outputs/apply.md @@ -146,7 +146,7 @@ Diagnostics: Calling __str__ on an Output[T] is not supported. To get the value of an Output[T] as an Output[str] consider: 1. o.apply(lambda v: f"prefix{v}suffix") - See https://www.pulumi.com/docs/concepts/inputs-outputs for more details. + See https://www.pulumi.com/docs/iac/concepts/inputs-outputs/ for more details. This function may throw in a future version of Pulumi. ``` @@ -173,7 +173,7 @@ Diagnostics: To get the value of an Output as an Output consider: 1. o.Apply(v => $"prefix{v}suffix") 2. Output.Format($"prefix{hostname}suffix"); - See https://www.pulumi.com/docs/concepts/inputs-outputs for more details. + See https://www.pulumi.com/docs/iac/concepts/inputs-outputs/ for more details. This function may throw in a future version of Pulumi. ``` @@ -474,10 +474,10 @@ Returning to the certificate validation example from the previous section, you c ### Outputs and strings -Outputs that return to the engine as strings cannot be used directly in operations such as string concatenation until the output value has returned to Pulumi. In these scenarios, you'll need to wait for the value to return using [`apply`](/docs/concepts/inputs-outputs/apply/). +Outputs that return to the engine as strings cannot be used directly in operations such as string concatenation until the output value has returned to Pulumi. In these scenarios, you'll need to wait for the value to return using [`apply`](/docs/iac/concepts/inputs-outputs/apply/). {{% notes type="info" %}} -For the common case of building a string from output values, Pulumi's [output helpers](/docs/concepts/inputs-outputs/helpers/#string-interpolation) provide a more concise alternative that doesn't require calling `apply` directly. +For the common case of building a string from output values, Pulumi's [output helpers](/docs/iac/concepts/inputs-outputs/helpers/#string-interpolation) provide a more concise alternative that doesn't require calling `apply` directly. {{% /notes %}} For example, the following code creates an HTTPS URL from the DNS name (the plain value) of a virtual machine (in this case an EC2 instance): @@ -581,7 +581,7 @@ The returned value of the call to {{< pulumi-apply >}} is a new `pulumi.Output}} -All resources have a required [`name`](https://www.pulumi.com/docs/concepts/resources/names/) argument. Each resource has both a [logical name](https://www.pulumi.com/docs/concepts/resources/names/#logicalname) and a [physical name](https://www.pulumi.com/docs/concepts/resources/names/#autonaming). +All resources have a required [`name`](https://www.pulumi.com/docs/iac/concepts/resources/names/) argument. Each resource has both a [logical name](https://www.pulumi.com/docs/iac/concepts/resources/names/#logicalname) and a [physical name](https://www.pulumi.com/docs/iac/concepts/resources/names/#autonaming). The logical name is how the resource is known inside Pulumi. This is the value provided to the required `name` argument. diff --git a/content/tutorials/creating-resources-azure/index.md b/content/tutorials/creating-resources-azure/index.md index 2d05ab93e329..88282436079b 100644 --- a/content/tutorials/creating-resources-azure/index.md +++ b/content/tutorials/creating-resources-azure/index.md @@ -189,7 +189,7 @@ The [Pulumi Registry](/registry/) provides the documentation for all of the Pulu {{% /choosable %}} -All resources have a required [`name`](https://www.pulumi.com/docs/concepts/resources/names/) argument. Each resource has both a [logical name](https://www.pulumi.com/docs/concepts/resources/names/#logicalname) and a [physical name](https://www.pulumi.com/docs/concepts/resources/names/#autonaming). The **logical name** is how the resource is known inside Pulumi. This is the value provided to the required `name` argument. The **physical name** is the name used for the resource in the cloud provider that a Pulumi program is deploying to. It is a combination of the logical name plus a random suffix which helps to prevent resource naming collisions. +All resources have a required [`name`](https://www.pulumi.com/docs/iac/concepts/resources/names/) argument. Each resource has both a [logical name](https://www.pulumi.com/docs/iac/concepts/resources/names/#logicalname) and a [physical name](https://www.pulumi.com/docs/iac/concepts/resources/names/#autonaming). The **logical name** is how the resource is known inside Pulumi. This is the value provided to the required `name` argument. The **physical name** is the name used for the resource in the cloud provider that a Pulumi program is deploying to. It is a combination of the logical name plus a random suffix which helps to prevent resource naming collisions. In the above example, the logical name for our `ResourceGroup` resource is **"website-resource-group"**, and the physical name might typically look something like **"website-resource-group-d7c2fa0"**. diff --git a/content/tutorials/creating-resources-gcp/index.md b/content/tutorials/creating-resources-gcp/index.md index f5e05d1ba1e6..b4dca0b70870 100644 --- a/content/tutorials/creating-resources-gcp/index.md +++ b/content/tutorials/creating-resources-gcp/index.md @@ -210,7 +210,7 @@ The first resource you will create will be virtual machine that will host the we {{% /choosable %}} -All resources have a required [`name`](https://www.pulumi.com/docs/concepts/resources/names/) argument. Each resource has both a [logical name](https://www.pulumi.com/docs/concepts/resources/names/#logicalname) and a [physical name](https://www.pulumi.com/docs/concepts/resources/names/#autonaming). The **logical name** is how the resource is known inside Pulumi. This is the value provided to the required `name` argument. The **physical name** is the name used for the resource in the cloud provider that a Pulumi program is deploying to. It is a combination of the logical name plus a random suffix which helps to prevent resource naming collisions. +All resources have a required [`name`](https://www.pulumi.com/docs/iac/concepts/resources/names/) argument. Each resource has both a [logical name](https://www.pulumi.com/docs/iac/concepts/resources/names/#logicalname) and a [physical name](https://www.pulumi.com/docs/iac/concepts/resources/names/#autonaming). The **logical name** is how the resource is known inside Pulumi. This is the value provided to the required `name` argument. The **physical name** is the name used for the resource in the cloud provider that a Pulumi program is deploying to. It is a combination of the logical name plus a random suffix which helps to prevent resource naming collisions. In the above example, the logical name for our `instance` resource is **"website-server"**, and the physical name might typically look something like **"website-server-d7c2fa0"**. diff --git a/content/tutorials/creating-resources-kubernetes/index.md b/content/tutorials/creating-resources-kubernetes/index.md index 1084df6b2e6e..c12c09383ba8 100644 --- a/content/tutorials/creating-resources-kubernetes/index.md +++ b/content/tutorials/creating-resources-kubernetes/index.md @@ -246,7 +246,7 @@ The first resource you will create will be a Kubernetes deployment. The [Pulumi {{% /choosable %}} -All resources have a required [`name`](https://www.pulumi.com/docs/concepts/resources/names/) argument. Each resource has both a [logical name](https://www.pulumi.com/docs/concepts/resources/names/#logicalname) and a [physical name](https://www.pulumi.com/docs/concepts/resources/names/#autonaming). The **logical name** is how the resource is known inside Pulumi. This is the value provided to the required `name` argument. The **physical name** is the name used for the resource in the cloud provider that a Pulumi program is deploying to. It is a combination of the logical name plus a random suffix which helps to prevent resource naming collisions. +All resources have a required [`name`](https://www.pulumi.com/docs/iac/concepts/resources/names/) argument. Each resource has both a [logical name](https://www.pulumi.com/docs/iac/concepts/resources/names/#logicalname) and a [physical name](https://www.pulumi.com/docs/iac/concepts/resources/names/#autonaming). The **logical name** is how the resource is known inside Pulumi. This is the value provided to the required `name` argument. The **physical name** is the name used for the resource in the cloud provider that a Pulumi program is deploying to. It is a combination of the logical name plus a random suffix which helps to prevent resource naming collisions. In the above example, the logical name for our `deployment` resource is **"nginx"**, and the physical name might typically look something like **"nginx-d7c2fa0"**. diff --git a/content/tutorials/inspecting-infrastructure/index.md b/content/tutorials/inspecting-infrastructure/index.md index 5b142dda126d..fcd0fc06ad5f 100644 --- a/content/tutorials/inspecting-infrastructure/index.md +++ b/content/tutorials/inspecting-infrastructure/index.md @@ -71,7 +71,7 @@ In this section, you will run a number of commands in the Pulumi CLI that will e ### pulumi stack -The [pulumi stack](/docs/iac/cli/commands/pulumi_stack/) command is used to provide a quick overview of the current stack's status and configuration. Running this command will list the management details, resources, and [output](/docs/concepts/inputs-outputs/#outputs) names and values of the current stack. +The [pulumi stack](/docs/iac/cli/commands/pulumi_stack/) command is used to provide a quick overview of the current stack's status and configuration. Running this command will list the management details, resources, and [output](/docs/iac/concepts/inputs-outputs/#outputs) names and values of the current stack. Run the `pulumi stack` command as shown below: diff --git a/content/tutorials/pulumi-fundamentals/create-a-pulumi-project/index.md b/content/tutorials/pulumi-fundamentals/create-a-pulumi-project/index.md index 19d00b45b8d8..d18194972116 100644 --- a/content/tutorials/pulumi-fundamentals/create-a-pulumi-project/index.md +++ b/content/tutorials/pulumi-fundamentals/create-a-pulumi-project/index.md @@ -147,8 +147,8 @@ Feel free to explore the other files as well. Now let's move on to creating your first real bit of infrastructure with Pulumi: some Docker images! - - - + + + {{< tutorials/stepper >}} diff --git a/content/tutorials/stack-outputs-refs-aws/index.md b/content/tutorials/stack-outputs-refs-aws/index.md index 21802b7cdd56..783dc7a7fce5 100644 --- a/content/tutorials/stack-outputs-refs-aws/index.md +++ b/content/tutorials/stack-outputs-refs-aws/index.md @@ -241,7 +241,7 @@ name: s3-writer ### Export resource values -Now that you have your project resources defined, you can [export the values](/docs/concepts/stack/#outputs) of various resource properties from your program. The `export` syntax is as follows: +Now that you have your project resources defined, you can [export the values](/docs/iac/concepts/stacks/#outputs) of various resource properties from your program. The `export` syntax is as follows: {{< chooser language "javascript,typescript,python,go,csharp,yaml" / >}} @@ -429,7 +429,7 @@ The AWS CLI will run AWS commands with the `default` profile by default. If you You will want to replace `` with the actual name of your S3 bucket. While you can manually provide the name of your bucket, you can also programmatically reference your bucket name via the stack outputs. -You'll do this by using the [`pulumi stack output`](/docs/concepts/stack/#outputs) command and provide the name of your desired output as shown below: +You'll do this by using the [`pulumi stack output`](/docs/iac/concepts/stacks/#outputs) command and provide the name of your desired output as shown below: ```bash aws s3api list-objects-v2 --bucket $(pulumi stack output bucketName) @@ -485,7 +485,7 @@ For this section, you are going to create a new Pulumi program that will access Let's start by making a new Pulumi project in a new directory. In this new program, you need to add the code that will reference the values from your first program. -This can be done using Pulumi's [Stack Reference functionality](/docs/concepts/stack/#stackreferences). You'll need to pass in the fully qualified name of the stack as an argument. This name is comprised of the [organization](/docs/pulumi-cloud/admin/organizations/), project, and stack names in the format of `//` +This can be done using Pulumi's [Stack Reference functionality](/docs/iac/concepts/stacks/#stackreferences). You'll need to pass in the fully qualified name of the stack as an argument. This name is comprised of the [organization](/docs/pulumi-cloud/admin/organizations/), project, and stack names in the format of `//` For example, if the name of your organization is `my-org`, the name of your first program is `my-first-program`, and the name of your stack is `dev`, then your fully qualified name will be `my-org/my-first-program/dev`. @@ -764,5 +764,5 @@ You exported Lambda properties into stack outputs, and referenced those outputs To learn more about creating and managing resources in Pulumi, take a look at the following resources: - Learn more about creating resources in the [Creating Resources on AWS tutorial](/tutorials/creating-resources-aws/). -- Learn more about [stack outputs and references](/docs/concepts/stack/#stackreferences) in the Pulumi documentation. -- Learn more about [Pulumi inputs and outputs](/docs/concepts/inputs-outputs/) in the Pulumi documentation. +- Learn more about [stack outputs and references](/docs/iac/concepts/stacks/#stackreferences) in the Pulumi documentation. +- Learn more about [Pulumi inputs and outputs](/docs/iac/concepts/inputs-outputs/) in the Pulumi documentation. diff --git a/content/tutorials/stack-outputs-refs-azure/index.md b/content/tutorials/stack-outputs-refs-azure/index.md index adccee02c9c1..8ec9f2156c89 100644 --- a/content/tutorials/stack-outputs-refs-azure/index.md +++ b/content/tutorials/stack-outputs-refs-azure/index.md @@ -343,7 +343,7 @@ Stack references allow you to access the outputs of one stack from another stack ### Reference resource group name -Start by making a new Pulumi project in a new directory. In this new program, you will need to add the code that will reference an output value from your first program. This can be done using Pulumi's [Stack Reference functionality](/docs/concepts/stack/#stackreferences). When defining a stack reference in code, you will need to pass in the fully qualified name of the stack as an argument. This name is comprised of the [organization](/docs/pulumi-cloud/organizations/), [project](/docs/iac/concepts/projects/), and [stack](/docs/iac/concepts/stacks/) names in the format of `//` +Start by making a new Pulumi project in a new directory. In this new program, you will need to add the code that will reference an output value from your first program. This can be done using Pulumi's [Stack Reference functionality](/docs/iac/concepts/stacks/#stackreferences). When defining a stack reference in code, you will need to pass in the fully qualified name of the stack as an argument. This name is comprised of the [organization](/docs/pulumi-cloud/organizations/), [project](/docs/iac/concepts/projects/), and [stack](/docs/iac/concepts/stacks/) names in the format of `//` For example, if the name of your organization is `acmecorp`, the name of your first program is `infra`, and the name of your stack is `dev`, then your fully qualified name will be `acmecorp/infra/dev`. @@ -825,5 +825,5 @@ In this tutorial, you created an Azure Blob Storage and Container resource. You To learn more about creating and managing resources in Pulumi, take a look at the following resources: - Learn more about creating resources in the [Creating Resources on Azure tutorial](/tutorials/creating-resources-azure/). -- Learn more about [stack outputs and references](/docs/concepts/stack/#stackreferences) in the Pulumi documentation. -- Learn more about [Pulumi inputs and outputs](/docs/concepts/inputs-outputs/) in the Pulumi documentation. +- Learn more about [stack outputs and references](/docs/iac/concepts/stacks/#stackreferences) in the Pulumi documentation. +- Learn more about [Pulumi inputs and outputs](/docs/iac/concepts/inputs-outputs/) in the Pulumi documentation. diff --git a/content/tutorials/stack-outputs-refs-gcp/index.md b/content/tutorials/stack-outputs-refs-gcp/index.md index 65152cf4eff0..a66d7ca22407 100644 --- a/content/tutorials/stack-outputs-refs-gcp/index.md +++ b/content/tutorials/stack-outputs-refs-gcp/index.md @@ -338,7 +338,7 @@ Stack references allow you to access the outputs of one stack from another stack ### Reference resource group name -Start by making a new Pulumi project in a new directory. In this new program, you will need to add the code that will reference an output value from your first program. This can be done using Pulumi's [Stack Reference functionality](/docs/concepts/stack/#stackreferences). When defining a stack reference in code, you will need to pass in the fully qualified name of the stack as an argument. This name is comprised of the [organization](/docs/pulumi-cloud/organizations/), [project](/docs/iac/concepts/projects/), and [stack](/docs/iac/concepts/stacks/) names in the format of `//` +Start by making a new Pulumi project in a new directory. In this new program, you will need to add the code that will reference an output value from your first program. This can be done using Pulumi's [Stack Reference functionality](/docs/iac/concepts/stacks/#stackreferences). When defining a stack reference in code, you will need to pass in the fully qualified name of the stack as an argument. This name is comprised of the [organization](/docs/pulumi-cloud/organizations/), [project](/docs/iac/concepts/projects/), and [stack](/docs/iac/concepts/stacks/) names in the format of `//` For example, if the name of your organization is `acmecorp`, the name of your first program is `infra`, and the name of your stack is `dev`, then your fully qualified name will be `acmecorp/infra/dev`. @@ -817,5 +817,5 @@ In this tutorial, you created a Google Cloud Storage Bucket and custom IAM role. To learn more about creating and managing resources in Pulumi, take a look at the following resources: - Learn more about creating resources in the [Creating Resources on Google Cloud tutorial](/tutorials/creating-resources-gcp/). -- Learn more about [stack outputs and references](/docs/concepts/stack/#stackreferences) in the Pulumi documentation. -- Learn more about [Pulumi inputs and outputs](/docs/concepts/inputs-outputs/) in the Pulumi documentation. +- Learn more about [stack outputs and references](/docs/iac/concepts/stacks/#stackreferences) in the Pulumi documentation. +- Learn more about [Pulumi inputs and outputs](/docs/iac/concepts/inputs-outputs/) in the Pulumi documentation.