f749c2cb24
<!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This engine change is necessary for correct dependency tracking of properties through transform functions. Unlike other parts of the runtime/provider/engine interface transform functions do not have a property dependencies map sent or returned. Transforms rely entirely on the dependency arrays in output values for their dependency tracking. This change takes the property dependency map and upgrades all the input properties to be output values tracking those same dependencies (if a property doesn't have any dependencies it doesn't need to be upgraded to an output value). This upgrade is only done if we're using transform functions, there's currently no need to do this unless we're using transforms. After running the transforms we downgrade the output values back to plain/secret/computed values if we're registering a custom resource. If we're registering a component resource we just leave all the properties upgraded as output values. We also rebuild the resources dependencies slice and propertyDependency map with the dependencies recorded in the transformed properties. If the transform didn't change the properties this will just be the same data we encoded into the output values in the properties structure. There are a couple of things to keep in mind with this change. Firstly using a transform can cause a property that was being sent to a component provider as just a `resource.NumberProperty` to start being sent as an `OutputProperty` with the `NumberProperty` as its element. Component providers _should_ handle that, but it's feasible that it could break some component code. This is a fairly limited blast radius as it will only happen when that user starts using a transform function. Secondly, we can't know in the engine if a property dependencies are from a top level output value or a nested output. That is SDKs send both of the following property shapes the same way to the engine for custom resources: ``` A) Output(Array([Number(1)]), ["dep"]) --- B) Array([Output(Number(1), ["dep"]) ``` Currently both would get upgraded to `Output(Array([Number(1)]), ["dep"])`. For a component resource the SDK will send output values, and as long as they define a superset of the dependencies in the property map then we don't add the top-level output tracking the same dependency set. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [x] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. --> |
||
---|---|---|
.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.