f1e4b4ff94
Presently, the behaviour of diffing during refresh steps is incomplete, returning only an "output diff" that presents the changes in outputs. This commit changes refresh steps so that: * they compute a diff similar to the one that would be computed if a `preview` were run immediately after the refresh, which is more typically what users expect and want; and * `IgnoreChanges` resource options are respected when performing the new desired-state diffs, so that property additions or changes reported by a refresh can be ignored. In particular, `IgnoreChanges` can now be used to acknowledge that part or all of a resource may change in the provider, but the user is OK with this and doesn't want to be notified about it during a refresh. Importantly, this means that the diff won't be reported, but also that the changes won't be applied to state. The implementation covers the following: * A diff is computed using the inputs from the program and then inverting the result, since in the case of a refresh the diff is being driven by the provider side and not the program. This doesn't change what is stored back into the state, but it does produce a diff that is more aligned with the "true changes to the desired state". * `IgnoreChanges` resource options are now stored in state, so that this information can be used in refresh operations that do not have access to/run the program. * In the context of a refresh operation, `IgnoreChanges` applies to *both* input and output properties. This differs from the behaviour of a normal update operation, where `IgnoreChanges` only considers input properties. * The special `"*"` value for `IgnoreChanges` can be used to ignore all properties. It _also_ ignores the case where the resource cannot be found in the provider, and instead keeps the resource intact in state with its existing input and output properties. Because the program is not run for refresh operations, `IgnoreChanges` options must be applied separately before a refresh takes place. This can be accomplished using e.g. a `pulumi up` that applies the options prior to a refresh. We should investigate perhaps providing a `pulumi state set ...`-like CLI to make these sorts of changes directly to a state. For use cases relying on the legacy refresh diff provider, the `PULUMI_USE_LEGACY_REFRESH_DIFF` environment variable can be set, which will disable desired-state diff computation. We only need to perform checks in `RefreshStep.{ResultOp,Apply}`, since downstream code will work correctly based on the presence or absence of a `DetailedDiff` in the step. ### Notes - https://github.com/pulumi/pulumi/issues/16144 affects some of these cases - though its technically orthogonal - https://github.com/pulumi/pulumi/issues/11279 is another technically orthogonal issue that many providers (at least TFBridge ones) - do not report back changes to input properties on Read when the input property (or property path) was missing on the inputs. This is again technically orthogonal - but leads to cases that appear "wrong" in terms of what is stored back into the state still - though the same as before this change. - Azure Native doesn't seem to handle `ignoreChanges` passed to Diff, so the ability to ignore changes on refresh doesn't currently work for Azure Native. ### Fixes * Fixes #16072 * Fixes #16278 * Fixes #16334 * Not quite #12346, but likely replaces the need for that Co-authored-by: Will Jones <will@sacharissa.co.uk> |
||
---|---|---|
.devcontainer | ||
.github | ||
.gitpod | ||
.vscode | ||
build | ||
changelog | ||
cmd/pulumi-test-language | ||
coverage | ||
developer-docs | ||
docker | ||
pkg | ||
proto | ||
scripts | ||
sdk | ||
tests | ||
.dockerignore | ||
.envrc.template | ||
.gitignore | ||
.gitpod.yml | ||
.golangci.yml | ||
.goreleaser.yml | ||
.readthedocs.yaml | ||
.yarnrc | ||
CHANGELOG.md | ||
CODE-OF-CONDUCT.md | ||
CONTRIBUTING.md | ||
LICENSE | ||
Makefile | ||
README.md | ||
codecov.yml | ||
youtube_preview_image.png |
README.md
Pulumi's Infrastructure as Code SDK is the easiest way to build and deploy infrastructure, of any architecture and on any cloud, using programming languages that you already know and love. Code and ship infrastructure faster with your favorite languages and tools, and embed IaC anywhere with Automation API.
Simply write code in your favorite language and Pulumi automatically provisions and manages your resources on AWS, Azure, Google Cloud Platform, Kubernetes, and 120+ providers using an infrastructure-as-code approach. Skip the YAML, and use standard language features like loops, functions, classes, and package management that you already know and love.
For example, create three web servers:
const aws = require("@pulumi/aws");
const sg = new aws.ec2.SecurityGroup("web-sg", {
ingress: [{ protocol: "tcp", fromPort: 80, toPort: 80, cidrBlocks: ["0.0.0.0/0"] }],
});
for (let i = 0; i < 3; i++) {
new aws.ec2.Instance(`web-${i}`, {
ami: "ami-7172b611",
instanceType: "t2.micro",
vpcSecurityGroupIds: [sg.id],
userData: `#!/bin/bash
echo "Hello, World!" > index.html
nohup python -m SimpleHTTPServer 80 &`,
});
}
Or a simple serverless timer that archives Hacker News every day at 8:30AM:
const aws = require("@pulumi/aws");
const snapshots = new aws.dynamodb.Table("snapshots", {
attributes: [{ name: "id", type: "S", }],
hashKey: "id", billingMode: "PAY_PER_REQUEST",
});
aws.cloudwatch.onSchedule("daily-yc-snapshot", "cron(30 8 * * ? *)", () => {
require("https").get("https://news.ycombinator.com", res => {
let content = "";
res.setEncoding("utf8");
res.on("data", chunk => content += chunk);
res.on("end", () => new aws.sdk.DynamoDB.DocumentClient().put({
TableName: snapshots.name.get(),
Item: { date: Date.now(), content },
}).promise());
}).end();
});
Many examples are available spanning containers, serverless, and infrastructure in pulumi/examples.
Pulumi is open source under the Apache 2.0 license, supports many languages and clouds, and is easy to extend. This
repo contains the pulumi
CLI, language SDKs, and core Pulumi engine, and individual libraries are in their own repos.
Welcome
-
Get Started with Pulumi: Deploy a simple application in AWS, Azure, Google Cloud, or Kubernetes using Pulumi.
-
Learn: Follow Pulumi learning pathways to learn best practices and architectural patterns through authentic examples.
-
Examples: Browse several examples across many languages, clouds, and scenarios including containers, serverless, and infrastructure.
-
Docs: Learn about Pulumi concepts, follow user-guides, and consult the reference documentation.
-
Registry: Find the Pulumi Package with the resources you need. Install the package directly into your project, browse the API documentation, and start building.
-
Pulumi Roadmap: Review the planned work for the upcoming quarter and a selected backlog of issues that are on our mind but not yet scheduled.
-
Community Slack: Join us in Pulumi Community Slack. All conversations and questions are welcome.
-
GitHub Discussions: Ask questions or share what you're building with Pulumi.
Getting Started
See the Get Started guide to quickly get started with Pulumi on your platform and cloud of choice.
Otherwise, the following steps demonstrate how to deploy your first Pulumi program, using AWS Serverless Lambdas, in minutes:
-
Install:
To install the latest Pulumi release, run the following (see full installation instructions for additional installation options):
$ curl -fsSL https://get.pulumi.com/ | sh
-
Create a Project:
After installing, you can get started with the
pulumi new
command:$ mkdir pulumi-demo && cd pulumi-demo $ pulumi new hello-aws-javascript
The
new
command offers templates for all languages and clouds. Run it without an argument and it'll prompt you with available projects. This command created an AWS Serverless Lambda project written in JavaScript. -
Deploy to the Cloud:
Run
pulumi up
to get your code to the cloud:$ pulumi up
This makes all cloud resources needed to run your code. Simply make edits to your project, and subsequent
pulumi up
s will compute the minimal diff to deploy your changes. -
Use Your Program:
Now that your code is deployed, you can interact with it. In the above example, we can curl the endpoint:
$ curl $(pulumi stack output url)
-
Access the Logs:
If you're using containers or functions, Pulumi's unified logging command will show all of your logs:
$ pulumi logs -f
-
Destroy your Resources:
After you're done, you can remove all resources created by your program:
$ pulumi destroy -y
To learn more, head over to pulumi.com for much more information, including tutorials, examples, and details of the core Pulumi CLI and programming model concepts.
Platform
Languages
Language | Status | Runtime | Versions | |
---|---|---|---|---|
JavaScript | Stable | Node.js | Current, Active and Maintenance LTS versions | |
TypeScript | Stable | Node.js | Current, Active and Maintenance LTS versions | |
Python | Stable | Python | Supported versions | |
Go | Stable | Go | Supported versions | |
.NET (C#/F#/VB.NET) | Stable | .NET | Supported versions | |
Java | Public Preview | JDK | 11+ | |
YAML | Stable | n/a | n/a |
EOL Releases
The Pulumi CLI v1 and v2 are no longer supported. If you are not yet running v3, please consider migrating to v3 to continue getting the latest and greatest Pulumi has to offer! 💪
- To migrate from v2 to v3, please see our v3 Migration Guide.
Clouds
Visit the Registry for the full list of supported cloud and infrastructure providers.
Contributing
Visit CONTRIBUTING.md for information on building Pulumi from source or contributing improvements.