Pulumi Blog: Daniel Bradley

Faster Secrets in Pulumi IaC

Daniel Bradley — Thu, 13 Mar 2025 01:00:00 -0700

Pulumi now handles secrets more efficiently through optimized encryption and decryption processes, reducing deployment times while maintaining security standards. Users of Pulumi Cloud for state management will notice the most improvement due to new batch API capabilities.

Secrets Management in Pulumi

Pulumi Infrastructure as Code (IaC)’s built-in secrets management encrypts individual secrets within the stack for fine-grained protection. Pulumi Cloud transmits and stores stack state securely, ensuring that sensitive information—such as database passwords, API keys, and access tokens—remains protected even if someone gains access to your stack file. For organizations with more complex secrets management needs, Pulumi also offers Pulumi ESC (Environments, Secrets, and Configuration), which provides centralized secrets management with hierarchical environments and dynamic credential generation.

Beyond simple encryption, Pulumi tracks the transitive use of secrets to prevent accidental exposure of sensitive values. This tracking works across your entire infrastructure definition, ensuring secrets remain protected:

Within the stack state
In CLI output
In the Pulumi Cloud console

When using Pulumi Cloud as your secrets provider, all encryption and decryption operations happen server-side without transmitting the encryption key to the Pulumi program. Combined with Pulumi Cloud’s robust user authorization and SSO integration, this creates a comprehensive security framework that ensures only authorized team members can access sensitive information.

Performance Challenges with Secrets

While security is paramount, performance is equally crucial for developer productivity. Every second spent waiting for encryption or decryption operations is time not spent building and improving your infrastructure.

Previously, when working with stacks containing numerous secrets, users could experience noticeable delays during operations that required encryption or decryption. This was primarily due to:

Individual network requests for each secret operation
Network latency compounding with each separate request

For teams with complex infrastructure containing dozens or hundreds of secrets, these delays could add up to significant wait times.

Our Performance Improvements

We’ve reduced network overhead by batching encryption work into a single request instead of making separate encryption requests for each secret. This batching approach:

Reduces the total number of HTTP requests
Minimizes the impact of network latency
Allows for more efficient server-side processing

This is combined with identifying when no secrets have changed between intermediate deployment steps to bypass the work of re-encrypting all secrets.

Measurable Performance Gains

The performance improvements are particularly noticeable for stacks with many secrets or in environments with higher network latency:

Secrets Count	Network Latency	Typical Time Savings
10	100ms	~1 second
25	150ms	~4 seconds
50+	150ms	10+ seconds
100+	150ms	20+ seconds

The performance improvements are noticeable for stacks with many secrets or in environments with higher network latency. For teams running CI/CD pipelines with frequent deployments, these savings compound throughout the day, potentially saving significant cumulative wait time across your engineering organization.

Getting Started

To benefit from these performance improvements:

Update to Pulumi IaC version 3.155.0 or later
No configuration changes are needed—the optimizations work automatically
Ensure you’re using Pulumi Cloud as your secrets provider for additional speed gains

These improvements maintain complete backward compatibility with existing stacks and secret values. Your existing encrypted secrets will continue to work without any migration steps required.

Conclusion

At Pulumi, we’re committed to providing both robust security and exceptional performance. These secrets management optimizations represent our ongoing effort to improve the developer experience without compromising on security.

By reducing wait times during encryption and decryption operations, we’re helping teams be more productive while maintaining the same high level of protection for sensitive information. This update exemplifies our philosophy that security and performance should complement rather than compete with each other.

Beyond Stack Secrets: Pulumi ESC

While these performance improvements enhance Pulumi’s built-in secrets management, some organizations require more advanced capabilities. If you need secrets to be centrally managed, composable, and reusable across teams and applications, Pulumi ESC (Environments, Secrets, and Configuration) may be a better fit. Pulumi ESC keeps sensitive information out of source control, supports hierarchical environments, and enables dynamic credential generation. It’s designed for organizations that need to share secrets between multiple teams, applications, and infrastructure deployments while maintaining strict access controls and auditability.

Get Started Today

Update to Pulumi IaC 3.155.0 today to experience these performance improvements and let us know what you think!

Pulumi Azure Classic Provider Version 6.0.0

Daniel Bradley — Fri, 27 Sep 2024 12:04:00 +0000

The latest major release of the Azure Classic Pulumi Provider is available now! Our 6.0 release contains the latest upstream changes to keep you up-to-date along with the latest features and improvements from Pulumi.

The Azure Classic provider is derived from the upstream Terraform AzureRM provider and can be used to provision most resources on Azure. The Azure Classic provider can be used to complement the Pulumi Azure Native provider, our recommended provider, which has amazing resource coverage due to being derived directly from the official specifications. The provider is open source and available on GitHub so you can always follow along with current issues and developments, or even open your first pull request.

Here are a few links to help you get started if you are new to Pulumi:

Getting Started - A guided walkthrough for creating your first project
Setup & Install - Instructions on installing the Azure Classic provider
How-to guides - Learn how to use the Azure Classic provider to provision specific resources
Pulumi Neo - Ask Pulumi Neo to create a new project

Looking Back

Since the last major release of this provider, we have continuously shipped improvements to our ecosystem, bringing the latest Pulumi features to your production stack. We have rolled out an improved diffing strategy and fixed state upgrades in the Pulumi Terraform Bridge, removing spurious diffs on preview and increasing confidence when deploying. Additionally we have improved accuracy and coverage for registry documentation, via better example conversion and general docs improvements for bridged providers.

New Modules

Over the last two years, we have added support for several new modules. Among these are:

API Coverage Growth

The below chart shows the growth of this provider by resource, function, and supporting types since Version 5.

Upgrading

You can find our v5 to v6 Migration Guide on the Pulumi Registry.

AWS Lambda SnapStart with Pulumi

Josh Kodroff — Mon, 28 Nov 2022 14:00:00 -0800

As AWS Lambda has matured as a serverless platform, there are two key ways the service has evolved:

New capabilities that extend the platform to support new use cases like Lambda Container support, Lambda URLs and attribute-based access control support.
Performance enhancements that enable Lambda functions to be more responsive and cost-effective such as Tiered compilation, and Graviton2 support are just a few examples of the investments AWS made in this space.

With each advancement, the reasons to deploy a full VM or cluster to support your application get fewer and the time to deliver value in the cloud gets shorter.

One challenge that many teams have faced when adapting their services to take advantage of AWS Lambda’s simple deployment model and attractive economics is cold starts: the latency incurred when the service prepares a new execution environment for your function. There is good analysis on the source of this latency as well as some available optimizations here.

Functions using Java runtimes typically experience significantly longer initialization times than functions using other runtimes.

Lambda creates a fresh execution environment when a function is invoked for the first time or when the function gets scaled to handle a spike in traffic. Initialization requires downloading function code, initializing the runtime, and running any pre-invocation initialization code in your function code. (Examples of pre-invocation code are retrieving secrets from AWS Secrets Manager or initializing database or other network connections.) This initialization process can add seconds of latency to the first invocation of your function.

Reducing Function Latency with AWS Lambda SnapStart

Today, AWS released a major improvement for Java-based functions that specifically addresses the latency incurred from cold starts in Java functions: AWS Lambda SnapStart. SnapStart improves startup performance for latency-sensitive Java applications by up to 10x at no extra cost, and typically with no changes to your function code. With SnapStart, instead of initializing function code on invoke, initialization happens when a function version is published. The way AWS describes this new feature is that the Lambda service will take a Firecracker MicroVM snapshot of the memory and disk state of the function’s fully-initialized execution environment, persist the encrypted snapshot and place it in a cache it for rapid access. On a first invocation or on scaling the function, Lambda resumes new environments using this snapshot.

AWS Lambda further improves invoke times by dividing snapshots into chunks. This means only the chunks required for your function are downloaded from a distributed cache on invoke. In real terms, this process removes several seconds of latency from function execution and scaling times.

The new Lambda Telemetry API works with SnapStart so you can easily track platform metrics related to this new capability.

All of the benefits of SnapStart are a great reason to give this feature a try, and there is no additional cost for enabling SnapStart for your functions. However, there are some considerations to keep in mind before you get started:

SnapStart improvements require the Amazon Corretto 11 runtime - Amazon’s production-ready distribution of OpenJDK.
After 14 days without an invocation, your function version becomes inactive and Lambda will delete the snapshot. If you invoke an inactive function version, Lambda will initialize a new snapshot.
Network connections may not persist when a function is invoked from a snapshot, so, your code should assume connections need to be restored.
Ephemeral data such as temporary credentials created during initialization may expire between the time the snapshot is created and later resumed.
Since snapshots are reused many times to resume execution environments, there are additional requirements to ensure random numbers generated by your function remain unique.

Lambda functions that need to persist network connections, rely on ephemeral data created during initialization, or have strict requirements for randomness will require extra attention. The SnapStart documentation and AWS blog are helpful for understanding the code changes required to support these scenarios. For example, a common mistake is using a Pseudorandom Number Generator (PRNG) such as java.lang.Math.random() when a Cryptographically Secure Pseudorandom Number Generator (CPRNG) such as java.security.SecureRandom() will ensure your application code generates random values as expected with SnapStart.

Configuring Lambda Functions to work with SnapStart in Pulumi

To take advantage of faster cold starts, you must create your function resource with the option to use SnapStart. Note that beyond the previously described requirements to make your function code SnapSafe, no changes need to be made to the function code itself to use SnapStart. In the following example, we use the AWS Cloud Control provider to provision our function with SnapStart. The AWS Cloud Control provider uses the new Cloud Control API behind the scenes and has same-day support for new resources included in Cloud Control API - like SnapStart. This example also uses the AWS provider and the Pulumi Command Provider.

First, we add the necessary imports, create a role for our function to assume, and an S3 bucket to hold our Lambda code. Then we add our function’s zipped code as an object in the bucket. For this example, the Lambda function code is the AWS pet store example in Spring Boot:

import * as pulumi from "@pulumi/pulumi";
import * as awsNative from "@pulumi/aws-native";
import * as aws from "@pulumi/aws";
import * as command from "@pulumi/command";

const role = new aws.iam.Role("role", {
 assumeRolePolicy: JSON.stringify({
 "Version": "2012-10-17",
 "Statement": [{
 "Effect": "Allow",
 "Principal": {
 "Service": "lambda.amazonaws.com",
 },
 "Action": "sts:AssumeRole",
 }],
 }),
});

new aws.iam.RolePolicyAttachment("role-policy-attachment", {
 role: role.name,
 policyArn: "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole",
});

const bucket = new aws.s3.Bucket("snapstart-bucket", {
 versioning: {
 enabled: true,
 }
});

const functionCode = new aws.s3.BucketObject("function-code", {
 bucket: bucket.bucket,
 source: new pulumi.asset.FileArchive("../petstore.zip"),
});

Next, we create our function with SnapStart enabled using the AWS Cloud Control provider, publish a version of our function (a requirement to use SnapStart) via the AWS CLI, and create a function alias for the version we created:

const func = new awsNative.lambda.Function("snapstart-func", {
 code: {
 s3Bucket: functionCode.bucket,
 s3Key: functionCode.key,
 s3ObjectVersion: functionCode.versionId,
 },
 role: role.arn,
 runtime: "java11",

 handler: "com.amazonaws.serverless.sample.springboot2.StreamLambdaHandler::handleRequest",
 memorySize: 1512,
 timeout: 60,
 snapStart: {
 applyOn: "PublishedVersions",
 },
});

const publishVersion = new command.local.Command("publish-version", {
 create: func.arn.apply(arn => `aws lambda publish-version --function-name ${arn}`),
 triggers: [func],
}, {
 dependsOn: func,
});

const aliasName = "v1";

const alias = new aws.lambda.Alias("alias", {
 functionName: func.arn,
 functionVersion: "1",
 name: aliasName,
}, {
 dependsOn: publishVersion,
});

Finally, we create the necessary resources to integrate our function with API Gateway and add our test URL as a stack output. This allows us to access it from outside of our Pulumi program:

const api = new aws.apigatewayv2.Api("snapstart-api", {
 protocolType: "HTTP",
});

const integration = new aws.apigatewayv2.Integration("lambdaIntegration", {
 apiId: api.id,
 integrationType: "AWS_PROXY",
 integrationUri: alias.arn,
 integrationMethod: "GET",
 payloadFormatVersion: "1.0",
 passthroughBehavior: "WHEN_NO_MATCH",
 connectionType: "INTERNET"
});

const route = new aws.apigatewayv2.Route("apiRoute", {
 apiId: api.id,
 routeKey: "$default",
 target: pulumi.interpolate`integrations/${integration.id}`,
});

new aws.apigatewayv2.Stage("apiStage", {
 apiId: api.id,
 name: "$default",
 routeSettings: [
 {
 routeKey: route.routeKey,
 throttlingBurstLimit: 5000,
 throttlingRateLimit: 10000,
 },
 ],
 autoDeploy: true,
}, { dependsOn: [route] });

new aws.lambda.Permission("permission", {
 action: "lambda:InvokeFunction",
 principal: "apigateway.amazonaws.com",
 function: alias.arn,
 sourceArn: api.executionArn.apply(x => `${x}/*/*`),
});

export const apiUrl = pulumi.concat(api.apiEndpoint, "/pets");

Deployment and Performance Testing

To deploy our function, we simply run the pulumi up command:

pulumi up -y

As the command completes, you’ll see output like the following:

Updating (dev)

View Live: https://app.pulumi.com/jkodroff/blog-lambda-snapshots-springboot-snapstart/dev/updates/9

 Type Name Status Info
 + pulumi:pulumi:Stack blog-lambda-snapshots-springboot-snapstart-dev created (4s) 1 warning
 + ├─ aws:iam:Role role created (0.82s)
 + ├─ aws:s3:Bucket snapstart-bucket created (2s)
 + ├─ aws:apigatewayv2:Api snapstart-api created (1s)
 + ├─ aws:iam:RolePolicyAttachment role-policy-attachment created (0.24s)
 + ├─ aws:s3:BucketObject function-code created (13s)
 + ├─ aws-native:lambda:Function snapstart-func created (22s)
 + ├─ command:local:Command publish-version created (3s)
 + ├─ aws:lambda:Alias alias created (0.66s)
 + ├─ aws:lambda:Permission permission created (0.40s)
 + ├─ aws:apigatewayv2:Integration lambdaIntegration created (0.74s)
 + ├─ aws:apigatewayv2:Route apiRoute created (0.54s)
 + └─ aws:apigatewayv2:Stage apiStage created (1s)


Outputs:
 apiUrl: "https://56r9255ey4.execute-api.us-west-2.amazonaws.com/pets"

Resources:
 + 13 created

Duration: 52s

We invoke our function by issuing an HTTP GET request against our stack output:

$ curl $(pulumi stack output apiUrl)
[{"id":"24ecd2bc-5106-46f8-95f2-af7de19cba57","breed":"Bloodhound","name":"Cooper","dateOfBirth":1639148877751},{"id":"caf6e8fa-fc97-4b9c-bfe7-996f14dc7995","breed":"Bloodhound","name":"Zoe","dateOfBirth":1438614477751},{"id":"b3d28309-8c92-4ae8-b7bd-7b656a5ea0bf","breed":"Beagle","name":"Murphy","dateOfBirth":1282489677751},{"id":"3c572757-298a-4343-9ca7-5c0865f9fce1","breed":"Beagle","name":"Winston","dateOfBirth":1410188877751},{"id":"4f8ab29a-760d-4b29-801d-6e35a98c538b","breed":"Dalmatian","name":"Max","dateOfBirth":1619968077751},{"id":"31fe978f-5eb6-4116-9933-ba8d9edc89a8","breed":"Dalmatian","name":"Sasha","dateOfBirth":1615475277751},{"id":"772218c3-cc56-44b7-87be-1db1b46730a3","breed":"Afghan Hound","name":"Lucky","dateOfBirth":1579187277751},{"id":"e994816e-8a6a-448a-bc48-ed404b463e46","breed":"Dalmatian","name":"Roxy","dateOfBirth":1408806477752},{"id":"3987cae6-6db2-48f9-96cb-dcb9812b1ab1","breed":"Bernese Mountain Dog","name":"Bailey","dateOfBirth":1329059277752},{"id":"514c8db6-225e-4fab-8c5b-63acdc88da56","breed":"Bloodhound","name":"Maggie","dateOfBirth":1218812877752}]%

To benchmark performance, use the Apache ab utility which is installed by default on macOS. The following command will run 1000 GET requests against our function:

ab -n 1000 -c 50 $(pulumi stack output apiUrl)

Comparing performance before and after SnapStart

During extensive benchmarking, the Pulumi team tried both a simple “Hello World” function as well as the more complex Spring Boot example above. Invoking this example Lambda function with and without SnapStart over many iterations, the Pulumi team found cold start times for a simple “Hello World” were 40% faster with SnapStart. The team found a much larger performance improvement when deploying the SpringBoot example. Cold starts were more than 10x faster. In real-world usage, this will translate into more responsive applications and services.

Conclusion

Addressing the challenges of cold starts for AWS Lambda functions is a major performance improvement that will enable Lambda functions to be useful in more scenarios that were previously the domain of dedicated VMs and container services. A 10x improvement in latency with common frameworks is a generational leap that we expect many teams to find valuable as they seek to modernize their infrastructure while keeping services responsive for end users.

Check out our GitHub repo with examples to try out Java-based functions with and without SnapStart enabled and see for yourself how these improvements can improve performance.

Happy coding!

Pulumi Crosswalk for AWS 1.0: AWSX, EKS, and AWS API Gateway

Luke Hoban — Mon, 28 Nov 2022 12:00:00 -0700

Portions of this blog post are out of date. See the AWS guides for an updated overview and examples.

We introduced Crosswalk for AWS three years ago as a library of components on top of the core AWS platform to make it easier to get from zero to production on AWS, easier to adopt AWS best practices by default, and easier to evolve your AWS infrastructure as your application needs mature. Since then, we’ve added many new capabilities, expanded the portfolio of libraries, and made these libraries available to all Pulumi languages. We’ve also seen thousands of Pulumi customers, including more than 25% of all Pulumi AWS users, adopting one or more of the Crosswalk for AWS components to aid in delivering their AWS-based applications and services.

Today, we’re excited to deliver the 1.0 releases of the three core libraries that make up Crosswalk for AWS: AWSX 1.0, EKS 1.0 and AWS API Gateway 1.0. These 1.0 releases offer a stable supported foundation, available in all Pulumi languages, for these rich infrastructure components.

Why Crosswalk for AWS?

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 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 - 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.

Crosswalk for AWS 1.0

The 1.0 releases of the awsx, eks and aws-apigateway packages offer a stable and supported foundation, available in all Pulumi languages, for these rich infrastructure components. They are available in the Pulumi Registry, and in all of the supported Pulumi package managers.

Note: For TypeScript users, the 1.0.0 version of the awsx package contains some breaking changes from the 0.40.* versions that were available only in TypeScript. The previously supported APIs are now available in the @pulumi/awsx/classic module inside the TypeScript awsx package. Users migrating from 0.40.* to 1.0.* can choose to either adapt their code and resources to the new APIs (which might require replacement or import of resources), or else to continue to use the classic submodule.

A few of the most significant components and libraries available in Crosswalk for AWS 1.0 are highlighted in the examples below, all available as part of Pulumi’s Architecture Templates.

Containers (ECS)

Amazon Elastic Container Service (ECS) provides foundational services for running containers directly on the AWS platform, both against self-managed EC2 clusters, as well as in AWS Fargate’s managed serverless container platform.

The AWSX 1.0 package provides components that make it incredibly easy to take a container, or even just a folder with a Dockerfile, and run it in a production-ready environment in AWS. And unlike some bespoke solutions for container deployment, with AWSX, configuring networking, load-balancing, secrets, managed databases, or anything else needed is just a few lines of code away.

Our recently released Container Service on AWS template provides a great starting point for leveraging the AWSX 1.0 support for ECS, Fargate, ECR and ALB.

import * as pulumi from "@pulumi/pulumi";
import * as aws from "@pulumi/aws";
import * as awsx from "@pulumi/awsx";

const config = new pulumi.Config();
const containerPort = config.getNumber("containerPort") || 80;
const cpu = config.getNumber("cpu") || 512;
const memory = config.getNumber("memory") || 128;

// An ECS cluster to deploy into
const cluster = new aws.ecs.Cluster("cluster", {});

// An ALB to serve the container endpoint to the internet
const loadbalancer = new awsx.lb.ApplicationLoadBalancer("loadbalancer", {});

// An ECR repository to store our application's container image
const repo = new awsx.ecr.Repository("repo", {});

// Build and publish our application's container image from ./app to the ECR repository
const image = new awsx.ecr.Image("image", {
 repositoryUrl: repo.url,
 path: "./app",
});

// Deploy an ECS Service on Fargate to host the application container
const service = new awsx.ecs.FargateService("service", {
 cluster: cluster.arn,
 assignPublicIp: true,
 taskDefinitionArgs: {
 container: {
 image: image.imageUri,
 cpu: cpu,
 memory: memory,
 essential: true,
 portMappings: [{
 containerPort: containerPort,
 targetGroup: loadbalancer.defaultTargetGroup,
 }],
 },
 },
});

// The URL at which the container's HTTP endpoint will be available
export const url = pulumi.interpolate`http://${loadbalancer.loadBalancer.dnsName}`;

from pulumi import Config, Output, export
import pulumi_aws as aws
import pulumi_awsx as awsx

config = Config()
container_port = config.get_int("containerPort", 80)
cpu = config.get_int("cpu", 512)
memory = config.get_int("memory", 128)

# An ECS cluster to deploy into
cluster = aws.ecs.Cluster("cluster")

# An ALB to serve the container endpoint to the internet
loadbalancer = awsx.lb.ApplicationLoadBalancer("loadbalancer")

# An ECR repository to store our application's container image
repo = awsx.ecr.Repository("repo")

# Build and publish our application's container image from ./app to the ECR repository
image = awsx.ecr.Image(
 "image",
 repository_url=repo.url,
 path="./app")

# Deploy an ECS Service on Fargate to host the application container
service = awsx.ecs.FargateService(
 "service",
 cluster=cluster.arn,
 assign_public_ip=True,
 task_definition_args=awsx.ecs.FargateServiceTaskDefinitionArgs(
 container=awsx.ecs.TaskDefinitionContainerDefinitionArgs(
 image=image.image_uri,
 cpu=cpu,
 memory=memory,
 essential=True,
 port_mappings=[awsx.ecs.TaskDefinitionPortMappingArgs(
 container_port=container_port,
 target_group=loadbalancer.default_target_group,
 )],
 ),
 ))

# The URL at which the container's HTTP endpoint will be available
export("url", Output.concat("http://", loadbalancer.load_balancer.dns_name))

package main

import (
 "github.com/pulumi/pulumi-aws/sdk/v5/go/aws/ecs"
 "github.com/pulumi/pulumi-awsx/sdk/go/awsx/ecr"
 ecrx "github.com/pulumi/pulumi-awsx/sdk/go/awsx/ecr"
 ecsx "github.com/pulumi/pulumi-awsx/sdk/go/awsx/ecs"
 lbx "github.com/pulumi/pulumi-awsx/sdk/go/awsx/lb"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi/config"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 cfg := config.New(ctx, "")
 containerPort := 80
 if param := cfg.GetInt("containerPort"); param != 0 {
 containerPort = param
 }
 cpu := 512
 if param := cfg.GetInt("cpu"); param != 0 {
 cpu = param
 }
 memory := 128
 if param := cfg.GetInt("memory"); param != 0 {
 memory = param
 }

 // An ECS cluster to deploy into
 cluster, err := ecs.NewCluster(ctx, "cluster", nil)
 if err != nil {
 return err
 }

 // An ALB to serve the container endpoint to the internet
 loadbalancer, err := lbx.NewApplicationLoadBalancer(ctx, "loadbalancer", nil)
 if err != nil {
 return err
 }

 // An ECR repository to store our application's container image
 repo, err := ecrx.NewRepository(ctx, "repo", nil)
 if err != nil {
 return err
 }

 // Build and publish our application's container image from ./app to the ECR repository
 image, err := ecrx.NewImage(ctx, "image", &ecr.ImageArgs{
 RepositoryUrl: repo.Url,
 Path: pulumi.String("./app"),
 })
 if err != nil {
 return err
 }

 // Deploy an ECS Service on Fargate to host the application container
 _, err = ecsx.NewFargateService(ctx, "service", &ecsx.FargateServiceArgs{
 Cluster: cluster.Arn,
 AssignPublicIp: pulumi.Bool(true),
 TaskDefinitionArgs: &ecsx.FargateServiceTaskDefinitionArgs{
 Container: &ecsx.TaskDefinitionContainerDefinitionArgs{
 Image: image.ImageUri,
 Cpu: pulumi.Int(cpu),
 Memory: pulumi.Int(memory),
 Essential: pulumi.Bool(true),
 PortMappings: ecsx.TaskDefinitionPortMappingArray{
 &ecsx.TaskDefinitionPortMappingArgs{
 ContainerPort: pulumi.Int(containerPort),
 TargetGroup: loadbalancer.DefaultTargetGroup,
 },
 },
 },
 },
 })
 if err != nil {
 return err
 }

 // The URL at which the container's HTTP endpoint will be available
 ctx.Export("url", pulumi.Sprintf("http://%s", loadbalancer.LoadBalancer.DnsName()))
 return nil
 })
}

using System.Collections.Generic;
using Pulumi;
using Aws = Pulumi.Aws;
using Awsx = Pulumi.Awsx;

return await Deployment.RunAsync(() =>
{
 var config = new Config();
 var containerPort = config.GetInt32("containerPort") ?? 80;
 var cpu = config.GetInt32("cpu") ?? 512;
 var memory = config.GetInt32("memory") ?? 128;
 var cluster = new Aws.Ecs.Cluster("cluster");

 var loadbalancer = new Awsx.Lb.ApplicationLoadBalancer("loadbalancer");

 var repo = new Awsx.Ecr.Repository("repo");

 var image = new Awsx.Ecr.Image("image", new()
 {
 RepositoryUrl = repo.Url,
 Path = "./app",
 });

 var service = new Awsx.Ecs.FargateService("service", new()
 {
 Cluster = cluster.Arn,
 AssignPublicIp = true,
 TaskDefinitionArgs = new Awsx.Ecs.Inputs.FargateServiceTaskDefinitionArgs
 {
 Container = new Awsx.Ecs.Inputs.TaskDefinitionContainerDefinitionArgs
 {
 Image = image.ImageUri,
 Cpu = cpu,
 Memory = memory,
 Essential = true,
 PortMappings = new[]
 {
 new Awsx.Ecs.Inputs.TaskDefinitionPortMappingArgs
 {
 ContainerPort = containerPort,
 TargetGroup = loadbalancer.DefaultTargetGroup,
 },
 },
 },
 },
 });

 return new Dictionary<string, object?>
 {
 ["url"] = loadbalancer.LoadBalancer.Apply(loadBalancer => Output.Format($"http://{loadBalancer.DnsName}")),
 };
});

name: aws-container
description: Containers on AWS
runtime: yaml

config:
 containerPort:
 default: 80
 cpu:
 default: 512
 memory:
 default: 128

resources:
 # An ECS cluster to deploy into
 cluster:
 type: aws:ecs:Cluster
 # An ALB to serve the container endpoint to the internet
 loadbalancer:
 type: awsx:lb:ApplicationLoadBalancer
 # An ECR repository to store our application's container image
 repo:
 type: awsx:ecr:Repository
 # Build and publish our application's container image from ./app to the ECR repository
 image:
 type: awsx:ecr:Image
 properties:
 repositoryUrl: ${repo.url}
 path: ./app
 # Deploy an ECS Service on Fargate to host the application container
 service:
 type: awsx:ecs:FargateService
 properties:
 cluster: ${cluster.arn}
 taskDefinitionArgs:
 container:
 image: ${image.imageUri}
 cpu: ${cpu}
 memory: ${memory}
 essential: true
 portMappings:
 - containerPort: ${containerPort}
 targetGroup: ${loadbalancer.defaultTargetGroup}

outputs:
 # The URL at which the container's HTTP endpoint will be available
 url: http://${loadbalancer.loadBalancer.dnsName}

Kubernetes (EKS)

Amazon Elastic Kubernetes Service (EKS) offers a managed Kubernetes service for standing up a best practices Kubernetes cluster within AWS.

The EKS 1.0 package offers support for configuring the many building blocks needed to configure a complete EKS cluster, across both AWS resources as well as in-cluster Kubernetes resources using Pulumi’s native kubernetes provider. With eks.Cluster, eks.NodeGroup, eks.NodeGroupV2 and eks.ManagedNodeGroup this package makes it easy to configure a cluster using any of the compute options available in AWS in just a few lines of code.

Our recently released Kubernetes Cluster on AWS template provides a great starting point for leveraging the eks 1.0 support for EKS, taking advantage of default support for private networking and EC2-based compute.

import * as pulumi from "@pulumi/pulumi";
import * as awsx from "@pulumi/awsx";
import * as eks from "@pulumi/eks";

// Grab some values from the Pulumi configuration (or use default values)
const config = new pulumi.Config();
const minClusterSize = config.getNumber("minClusterSize") || 3;
const maxClusterSize = config.getNumber("maxClusterSize") || 6;
const desiredClusterSize = config.getNumber("desiredClusterSize") || 3;
const eksNodeInstanceType = config.get("eksNodeInstanceType") || "t2.medium";
const vpcNetworkCidr = config.get("vpcNetworkCidr") || "10.0.0.0/16";

// Create a new VPC
const eksVpc = new awsx.ec2.Vpc("eks-vpc", {
 enableDnsHostnames: true,
 cidrBlock: vpcNetworkCidr,
});

// Create the EKS cluster
const eksCluster = new eks.Cluster("eks-cluster", {
 // Put the cluster in the new VPC created earlier
 vpcId: eksVpc.vpcId,
 // Public subnets will be used for load balancers
 publicSubnetIds: eksVpc.publicSubnetIds,
 // Private subnets will be used for cluster nodes
 privateSubnetIds: eksVpc.privateSubnetIds,
 // Change configuration values to change any of the following settings
 instanceType: eksNodeInstanceType,
 desiredCapacity: desiredClusterSize,
 minSize: minClusterSize,
 maxSize: maxClusterSize,
 // Do not give the worker nodes public IP addresses
 nodeAssociatePublicIpAddress: false,
 // Uncomment the next two lines for a private cluster (VPN access required)
 // endpointPrivateAccess: true,
 // endpointPublicAccess: false
});

// Export some values for use elsewhere
export const kubeconfig = eksCluster.kubeconfig;
export const vpcId = eksVpc.vpcId;

import pulumi
import pulumi_awsx as awsx
import pulumi_eks as eks

# Get some values from the Pulumi configuration (or use defaults)
config = pulumi.Config()
min_cluster_size = config.get_float("minClusterSize", 3)
max_cluster_size = config.get_float("maxClusterSize", 6)
desired_cluster_size = config.get_float("desiredClusterSize", 3)
eks_node_instance_type = config.get("eksNodeInstanceType", "t2.medium")
vpc_network_cidr = config.get("vpcNetworkCidr", "10.0.0.0/16")

# Create a VPC for the EKS cluster
eks_vpc = awsx.ec2.Vpc("eks-vpc",
 enable_dns_hostnames=True,
 cidr_block=vpc_network_cidr)

# Create the EKS cluster
eks_cluster = eks.Cluster("eks-cluster",
 # Put the cluster in the new VPC created earlier
 vpc_id=eks_vpc.vpc_id,
 # Public subnets will be used for load balancers
 public_subnet_ids=eks_vpc.public_subnet_ids,
 # Private subnets will be used for cluster nodes
 private_subnet_ids=eks_vpc.private_subnet_ids,
 # Change configuration values to change any of the following settings
 instance_type=eks_node_instance_type,
 desired_capacity=desired_cluster_size,
 min_size=min_cluster_size,
 max_size=max_cluster_size,
 # Do not give worker nodes a public IP address
 node_associate_public_ip_address=False,
 # Uncomment the next two lines for private cluster (VPN access required)
 # endpoint_private_access=true,
 # endpoint_public_access=false
 )

# Export values to use elsewhere
pulumi.export("kubeconfig", eks_cluster.kubeconfig)
pulumi.export("vpcId", eks_vpc.vpc_id)

package main

import (
 "github.com/pulumi/pulumi-awsx/sdk/go/awsx/ec2"
 "github.com/pulumi/pulumi-eks/sdk/go/eks"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi/config"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 // Get some configuration values or set default values
 cfg := config.New(ctx, "")
 minClusterSize, err := cfg.TryInt("minClusterSize")
 if err != nil {
 minClusterSize = 3
 }
 maxClusterSize, err := cfg.TryInt("maxClusterSize")
 if err != nil {
 maxClusterSize = 6
 }
 desiredClusterSize, err := cfg.TryInt("desiredClusterSize")
 if err != nil {
 desiredClusterSize = 3
 }
 eksNodeInstanceType, err := cfg.Try("eksNodeInstanceType")
 if err != nil {
 eksNodeInstanceType = "t2.medium"
 }
 vpcNetworkCidr, err := cfg.Try("vpcNetworkCidr")
 if err != nil {
 vpcNetworkCidr = "10.0.0.0/16"
 }

 // Create a new VPC, subnets, and associated infrastructure
 eksVpc, err := ec2.NewVpc(ctx, "eks-vpc", &ec2.VpcArgs{
 EnableDnsHostnames: pulumi.Bool(true),
 CidrBlock: &vpcNetworkCidr,
 })
 if err != nil {
 return err
 }

 // Create a new EKS cluster
 eksCluster, err := eks.NewCluster(ctx, "eks-cluster", &eks.ClusterArgs{
 // Put the cluster in the new VPC created earlier
 VpcId: eksVpc.VpcId,
 // Public subnets will be used for load balancers
 PublicSubnetIds: eksVpc.PublicSubnetIds,
 // Private subnets will be used for cluster nodes
 PrivateSubnetIds: eksVpc.PrivateSubnetIds,
 // Change configuration values above to change any of the following settings
 InstanceType: pulumi.String(eksNodeInstanceType),
 DesiredCapacity: pulumi.Int(desiredClusterSize),
 MinSize: pulumi.Int(minClusterSize),
 MaxSize: pulumi.Int(maxClusterSize),
 // Do not give the worker nodes a public IP address
 NodeAssociatePublicIpAddress: pulumi.Bool(false),
 // Uncomment the next two lines for a private cluster (VPN access required)
 // EndpointPrivateAccess: pulumi.Bool(true),
 // EndpointPublicAccess: pulumi.Bool(false),
 })
 if err != nil {
 return err
 }

 // Export some values in case they are needed elsewhere
 ctx.Export("kubeconfig", eksCluster.Kubeconfig)
 ctx.Export("vpcId", eksVpc.VpcId)
 return nil
 })
}

using Pulumi;
using Awsx = Pulumi.Awsx;
using Eks = Pulumi.Eks;
using System.Collections.Generic;

return await Deployment.RunAsync(() =>
{
 // Grab some values from the Pulumi configuration (or use default values)
 var config = new Config();
 var minClusterSize = config.GetInt32("minClusterSize") ?? 3;
 var maxClusterSize = config.GetInt32("maxClusterSize") ?? 6;
 var desiredClusterSize = config.GetInt32("desiredClusterSize") ?? 3;
 var eksNodeInstanceType = config.Get("eksNodeInstanceType") ?? "t2.medium";
 var vpcNetworkCidr = config.Get("vpcNetworkCidr") ?? "10.0.0.0/16";

 // Create a new VPC
 var eksVpc = new Awsx.Ec2.Vpc("eks-vpc", new()
 {
 EnableDnsHostnames = true,
 CidrBlock = vpcNetworkCidr,
 });

 // Create the EKS cluster
 var eksCluster = new Eks.Cluster("eks-cluster", new()
 {
 // Put the cluster in the new VPC created earlier
 VpcId = eksVpc.VpcId,

 // Public subnets will be used for load balancers
 PublicSubnetIds = eksVpc.PublicSubnetIds,

 // Private subnets will be used for cluster nodes
 PrivateSubnetIds = eksVpc.PrivateSubnetIds,

 // Change configuration values to change any of the following settings
 InstanceType = eksNodeInstanceType,
 DesiredCapacity = desiredClusterSize,
 MinSize = minClusterSize,
 MaxSize = maxClusterSize,

 // Do not give the worker nodes public IP addresses
 NodeAssociatePublicIpAddress = false,

 // Uncomment the next two lines for a private cluster (VPN access required)
 // EndpointPrivateAccess = true,
 // EndpointPublicAccess = false,
 });

 // Export some values for use elsewhere
 return new Dictionary<string, object?>
 {
 ["kubeconfig"] = eksCluster.Kubeconfig,
 ["vpcId"] = eksVpc.VpcId,
 };
});

name: aws-kubernetes-cluster
description: Kubernetes Cluster on AWS
runtime: yaml
config:
 minClusterSize:
 default: 3
 maxClusterSize:
 default: 6
 desiredClusterSize:
 default: 3
 eksNodeInstanceType:
 default: t2.medium
 vpcNetworkCidr:
 default: 10.0.0.0/16
resources:
 # Create a VPC for the EKS cluster
 eks-vpc:
 type: awsx:ec2:Vpc
 properties:
 enableDnsHostnames: true
 cidrBlock: ${vpcNetworkCidr}
 # Create the EKS cluster
 eks-cluster:
 type: eks:Cluster
 properties:
 # Put the cluster in the new VPC created earlier
 vpcId: ${eks-vpc.vpcId}
 # Public subnets will be used for load balancers
 publicSubnetIds: ${eks-vpc.publicSubnetIds}
 # Private subnets will be used for cluster nodes
 privateSubnetIds: ${eks-vpc.privateSubnetIds}
 # Change configuration section above to change any of the following settings
 instanceType: ${eksNodeInstanceType}
 desiredCapacity: ${desiredClusterSize}
 minSize: ${minClusterSize}
 maxSize: ${maxClusterSize}
 # Do not give the worker nodes public IP addresses
 nodeAssociatePublicIpAddress: false
 # Uncomment next two lines for private cluster access (VPN access required)
 # endpointPrivateAccess: true
 # endpointPublicAccess: false
outputs:
 # Output the Kubeconfig for the cluster
 kubeconfig: ${eks-cluster.kubeconfig}
 vpcId: ${eks-vpc.vpcId}

Serverless (Lambda, API Gateway)

AWS Lambda and the serverless architectures it enables provide native support for event based compute triggered off of a wide variety of events from within the AWS platform. Coupled with services like AWS API Gateway, this offers simple ways to serve HTTP-based APIs and much, much more.

Pulumi’s built in support for AWS Lambda functions and the new aws-apigateway 1.0 package make it simple to compose these services to build serverless applications and services on AWS in just a few lines of code.

Our recently released AWS Serverless Application template provides a great starting point for leveraging the aws-apigateway 1.0 support for creating a complete API Gateway-based serverless application, serving both static content from Amazon S3 as well as dynamic backend logic from AWS Lambda.

import * as pulumi from "@pulumi/pulumi";
import * as aws from "@pulumi/aws";
import * as apigateway from "@pulumi/aws-apigateway";

// A Lambda function to invoke
const fn = new aws.lambda.CallbackFunction("fn", {
 callback: async (ev, ctx) => {
 return {
 statusCode: 200,
 body: new Date().toISOString(),
 };
 }
})

// A REST API to route requests to HTML content and the Lambda function
const api = new apigateway.RestAPI("api", {
 routes: [
 { path: "/", localPath: "www"},
 { path: "/date", method: "GET", eventHandler: fn },
 ]
});

// The URL at which the REST API will be served.
export const url = api.url;

import json
import pulumi
import pulumi_aws as aws
import pulumi_aws_apigateway as apigateway

# An execution role to use for the Lambda function
role = aws.iam.Role("role",
 assume_role_policy=json.dumps({
 "Version": "2012-10-17",
 "Statement": [{
 "Action": "sts:AssumeRole",
 "Effect": "Allow",
 "Principal": {
 "Service": "lambda.amazonaws.com",
 },
 }],
 }),
 managed_policy_arns=[aws.iam.ManagedPolicy.AWS_LAMBDA_BASIC_EXECUTION_ROLE])

# A Lambda function to invoke
fn = aws.lambda_.Function("fn",
 runtime="python3.9",
 handler="handler.handler",
 role=role.arn,
 code=pulumi.FileArchive("./function"))

# A REST API to route requests to HTML content and the Lambda function
api = apigateway.RestAPI("api",
 routes=[
 apigateway.RouteArgs(path="/", local_path="www"),
 apigateway.RouteArgs(path="/date", method=apigateway.Method.GET, event_handler=fn)
 ])

# The URL at which the REST API will be served.
pulumi.export("url", api.url)

package main

import (
 "encoding/json"

 "github.com/pulumi/pulumi-aws-apigateway/sdk/go/apigateway"
 "github.com/pulumi/pulumi-aws/sdk/v5/go/aws/iam"
 "github.com/pulumi/pulumi-aws/sdk/v5/go/aws/lambda"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 // An execution role to use for the Lambda function
 policy, err := json.Marshal(map[string]interface{}{
 "Version": "2012-10-17",
 "Statement": []map[string]interface{}{
 map[string]interface{}{
 "Action": "sts:AssumeRole",
 "Effect": "Allow",
 "Principal": map[string]interface{}{
 "Service": "lambda.amazonaws.com",
 },
 },
 },
 })
 if err != nil {
 return err
 }

 role, err := iam.NewRole(ctx, "role", &iam.RoleArgs{
 AssumeRolePolicy: pulumi.String(policy),
 ManagedPolicyArns: pulumi.StringArray{
 iam.ManagedPolicyAWSLambdaBasicExecutionRole,
 },
 })
 if err != nil {
 return err
 }

 // A Lambda function to invoke
 fn, err := lambda.NewFunction(ctx, "fn", &lambda.FunctionArgs{
 Runtime: pulumi.String("python3.9"),
 Handler: pulumi.String("handler.handler"),
 Role: role.Arn,
 Code: pulumi.NewFileArchive("./function"),
 })
 if err != nil {
 return err
 }

 // A REST API to route requests to HTML content and the Lambda function
 localPath := "www"
 method := apigateway.MethodGET
 api, err := apigateway.NewRestAPI(ctx, "api", &apigateway.RestAPIArgs{
 Routes: []apigateway.RouteArgs{
 apigateway.RouteArgs{Path: "/", LocalPath: &localPath},
 apigateway.RouteArgs{Path: "/date", Method: &method, EventHandler: fn},
 },
 })
 if err != nil {
 return err
 }

 // The URL at which the REST API will be served
 ctx.Export("url", api.Url)
 return nil
 })
}

using System.Collections.Generic;
using System.Text.Json;
using Pulumi;
using Aws = Pulumi.Aws;
using AwsApiGateway = Pulumi.AwsApiGateway;

return await Deployment.RunAsync(() =>
{
 var role = new Aws.Iam.Role("role", new()
 {
 AssumeRolePolicy = JsonSerializer.Serialize(new Dictionary<string, object?>
 {
 ["Version"] = "2012-10-17",
 ["Statement"] = new[]
 {
 new Dictionary<string, object?>
 {
 ["Action"] = "sts:AssumeRole",
 ["Effect"] = "Allow",
 ["Principal"] = new Dictionary<string, object?>
 {
 ["Service"] = "lambda.amazonaws.com",
 },
 },
 },
 }),
 ManagedPolicyArns = new[]
 {
 "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole",
 },
 });

 var fn = new Aws.Lambda.Function("fn", new()
 {
 Runtime = "python3.9",
 Handler = "handler.handler",
 Role = role.Arn,
 Code = new FileArchive("./function"),
 });

 var api = new AwsApiGateway.RestAPI("api", new()
 {
 Routes =
 {
 new AwsApiGateway.Inputs.RouteArgs
 {
 Path = "/",
 LocalPath = "www",
 },
 new AwsApiGateway.Inputs.RouteArgs
 {
 Path = "/date",
 Method = AwsApiGateway.Method.GET,
 EventHandler = fn,
 },
 },
 });

 return new Dictionary<string, object?>
 {
 ["url"] = api.Url,
 };
});

name: aws-serverless
description: Serverless on AWS
runtime: yaml

resources:
 # An execution role to use for the Lambda function
 role:
 type: aws:iam:Role
 properties:
 assumeRolePolicy:
 fn::toJSON:
 Version: 2012-10-17
 Statement:
 - Action: sts:AssumeRole
 Effect: Allow
 Principal:
 Service: lambda.amazonaws.com
 managedPolicyArns:
 - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole

 # A Lambda function to invoke
 fn:
 type: aws:lambda:Function
 properties:
 runtime: python3.9
 handler: handler.handler
 role: ${role.arn}
 code:
 fn::fileArchive: ./function

 # A REST API to route requests to HTML content and the Lambda function
 api:
 type: aws-apigateway:RestAPI
 properties:
 routes:
 - path: /
 localPath: www
 - path: /date
 method: GET
 eventHandler: ${fn}

outputs:
 # The URL at which the REST API will be served.
 url: ${api.url}

Migration from AWSx 0.x to 1.0

Before version 1, AWSx only supported components in TypeScript. All the existing components from the 0.x releases are now available in the classic namespace. The classic namespace will remain until the next major version release but will only receive updates for critical security fixes.

If you’re currently using v0.x and want to upgrade to v1.x you can:

Change references from @pulumi/awsx to @pulumi/awsx/classic to maintain existing behaviour.
Refactor to replace the classic components with the new top-level components. This may require additional code changes and resource re-creation.

What’s Next?

Crosswalk for AWS is free and open source, and you can get started today.

For more on Crosswalk for AWS see:

Node.js Native Binary Compilation Using vercel/pkg

Daniel Bradley — Tue, 13 Sep 2022 00:00:00 +0000

In Pulumi’s engineering department, we often build and distribute tools as native binaries to avoid the need for additional dependencies on user machines. Most of these tools are written in Go, which has good support for building self-contained binaries that target modern operating systems.

While other Pulumi-supported languages like Node.js, Python, and .NET require additional runtime dependencies, it’s possible to bundle dependencies with the program. In this article, we’ll show you how to do that for a Node.js program.

This is a problem that can be solved using vercel/pkg command line tool. Here’s the summary from their readme.

This command line interface enables you to package your Node.js project into an executable that can be run even on devices without Node.js installed.

Let’s take a look at how to use pkg and some issues we encountered on the way.

Setting up `pkg`

1 - Install

pkg is distributed as an npm package which can be installed into your “devDependencies” using:

npm install -D pkg

yarn add -D pkg

or run without installing with npx:

npx pkg [args]

2 - Set `bin` in `package.json`

pkg will use the bin field from your package.json to find the entry point so you just have to specify a path to the directory containing your package.json.

{
 "name": "my-program"
 "bin": "bin/index.js",
 ...
}

If no target is specified, then a set of defaults will be chosen for you. If the output path is not specified, pkg will infer the name from the package.json “name” field and write to the current working directory.

3 - Execute

The main inputs that pkg needs is:

The entry point to your program for packaging
The target machine to build for
The output path to write the finished binary

Here’s an example of building the project in the current directory using node v18 for macOS ARM architectures:

# pkg [options] <input>
# -t, --targets comma-separated list of targets
# -o, --output output file name or template for several files
pkg -t node18-macos-arm64 -o bin/my-program .

It’s possible to specify multiple targets in a comma-separated list to build them all at the same time, but it does come with the limitation where the output file names follow a fixed pattern. Instead, we chose to just run the pkg command multiple times with different arguments from our makefile in parallel as this fits with our existing workflows well.

Issues encountered

“Inspector Not Available”

As soon as we started executing the provider we started seeing some interesting warnings printed to the console stating “Inspector is not available” (here’s our tracking issue and some pkg discussion). This is because we use the Node.js Inspector API as part of our automatic closure serialization, however this is not available by default when packaging with pkg.

pkg provides an option to fix this by building your own base image with custom Node.js flags set to enable debugging. However, on investigation, these issues were caused by the Pulumi Typescript SDK creating and caching an inspector instance at the point of being imported even though we never actually call this code in our plugin. Therefore, we opted to make this eager singleton creation to be lazy – only created on first use, as we’re not using in our providers at this time.

Unrunnable MacOS ARM binaries

When trying to use the binaries produced by our CI, we found that the binaries weren’t runnable on MacOS ARM architectures - and were forcibly killed by the operating system.

This led me down quite a bit of a rabbit hole investigating signing of binaries, but it was actually resolved by simply installing the ‘ldid’ tool on our linux CI environments. The ldid source is available via git.saurik.com/ldid and binaries are available from various sources. Our solution was to use the “Install Ldid” GitHub Action to install the ldid binary and add it to the PATH in our CI workflow. My learning here is that sometimes reading the warnings in logs more carefully can save you lots of time!

Static Binaries

One adjustment to our configuration came from a community contribution by @afreakk where the provider was being used in a nixos environment. Nixos adds the requirement for all binaries to be static rather than dynamic - so there’s no requirement for the operating system to dynamically map link functions from system libraries at runtime. Statically compiled programs sometimes result in a larger size, but avoid any possible issues with different versions of the libraries it depends on.

To resolve this issue, it’s as simple as changing the ‘linux’ targets to ‘linuxstatic’. E.g. node18-linux-amd64 becomes node18-linuxstatic-amd64.

Build infrastructure with Node.js

Pulumi lets you define, deploy, and manage cloud infrastructure using TypeScript and JavaScript, with the same npm packages and tooling you already rely on. Start building your first stack in Pulumi Cloud.

Get started

Multi-platform builds with a makefile

We use makefiles to build our providers, so here’s a brief outline of how we build for multiple platforms using GNU Make.

# Set the correct pkg TARGET for each binary we build
# when building for linux-amd64, set the pkg target to node18-linuxstatic-x64
bin/linux-amd64/my-program: TARGET := node18-linuxstatic-x64
# output binary file ^ ^ variable ^ pkg target
bin/linux-arm64/my-program: TARGET := node18-linuxstatic-arm64
bin/darwin-amd64/my-program: TARGET := node18-macos-x64
bin/darwin-arm64/my-program: TARGET := node18-macos-arm64
bin/windows-amd64/my-program.exe: TARGET := node18-win-x64

# Wildcard rule to build any of binary outputs
# "To build any bin file, ensure node_modules are up to date..."
bin/%: node_modules
 # "... then run pkg for actual output name & target"
 yarn run pkg . --target ${TARGET} --output $@
 # "TARGET" is the variable defined above, depending on the output
 # "$@" is the current makefile target - e.g. 'bin/linux-amd64/my-program'

# Running `make bins` will build all the listed outputs
bins: bin/linux-amd64/my-program
bins: bin/linux-arm64/my-program
bins: bin/darwin-amd64/my-program
bins: bin/darwin-arm64/my-program
bins: bin/windows-amd64/my-program.exe

# Let Make know that `bins` doesn't really exist (is phony) - it's just a helpful shortcut
.PHONY: bins

In summary the above code does the following:

Define each output file we need
- Set the correct pkg TARGET for each output
Define a rule for building any binary output:
- Ensure module_modules are up-to-date (this is another make target not shown here).
- Run pkg with the $TARGET set in (1) and the name of the current output ($@).
Define bins “phony target” which builds all listed bins.

You might also like:

Recap

I hope this gives you a good overview of the vercel/pkg tool and how you can use it to create standalone programs using Node.js.

Historical Note

We used to do a similar process using the nexe project, but there’s been no releases since 2017 and therefore no support for newer versions of Node.js and we therefore consider this package as unmaintained at this point in time.

Exploring how to solve circular dependencies

Daniel Bradley — Wed, 12 Jan 2022 00:00:00 +0000

This blog post originated from a hackathon and exploratory exercise, and should be considered in that context. None of the solutions exist in the Pulumi SDKs. For more information on this, please view our blog post on Circular Dependencies.

As part of our hackathon near the end of last year, we decided to explore solutions to a common problem when people are using Pulumi for their systems. A question that’s been asked in a few different forms is how to resolve circular dependencies between resources in a Pulumi program.

A simple example of this idea is a modern web application with a static front-end and an API, where the front-end needs to know the URL of the API to be able to call it and the API needs to know the source domain of the front-end to allow it access via CORS. As these two resources rely on one another to be created, they are circular dependencies.

For a deployable example, let’s build a serverless game of ping-pong—two functions that invoke one another until one misses!

const ping = new CallbackFunction("ping", {
 callback: pingPongHandler,
 environment: {
 variables: {
 OPPONENT_FN_NAME: pong.name, // <-- Can't access `pong` yet!
 },
 },
});

const pong = new CallbackFunction("pong", {
 callback: pingPongHandler,
 environment: {
 variables: {
 OPPONENT_FN_NAME: ping.name,
 },
 },
});

Programming languages don’t let us create one object that takes a value from another object that doesn’t yet exist. Therefore, we can’t express a circular dependency in this way.

The simplest workaround for this error is to get a reference to our own stack, which contains the outputs from the previous deployment. Now, we set the reference to pong within ping from the output of the last deployment.

const currentStack = new pulumi.StackReference(
 `acme-org/${pulumi.getProject()}/${pulumi.getStack()}`
);

const ping = new CallbackFunction("ping", {
 callback: pingPongHandler,
 environment: {
 variables: {
 OPPONENT_FN_NAME: currentStack
 .getOutput("pongName")
 .apply((pongName) => pongName ?? ""),
 },
 },
});

const pong = new CallbackFunction("pong", {
 callback: pingPongHandler,
 environment: {
 variables: {
 OPPONENT_FN_NAME: ping.name,
 },
 },
});

export const pingName = ping.name;
export const pongName = pong.name;

The downside of this approach is that we have to deploy twice to reach the desired state because we need the results of the previous deployment, though this approach might be fine for simple one-off circumstances.

How then could we make the process easier and clearer for users who need to resolve this kind of circular dependency regularly? We explored four options as part of the hackathon, so let’s go through each one, getting progressively closer to a possible solution.

Option 1: State

Instead of referencing outputs directly from our stack’s previous deploy and manually deploying twice, we could introduce a special type called “State”.

The State object does 3 tasks:

Read the value from the previous deployment, or provide a default if it’s the first deployment.
Update the value in the stack state using a “set” method.
Automatically triggers another deployment if its value has changed.

const pongName = new pulumi.State("pong-name", {
 initialValue: "",
});

const ping = new CallbackFunction("ping", {
 callback: pingPongHandler,
 environment: {
 variables: {
 OPPONENT_FN_NAME: pongName.value,
 },
 },
});

const pong = new CallbackFunction("pong", {
 callback: pingPongHandler,
 environment: {
 variables: {
 OPPONENT_FN_NAME: ping.name,
 },
 },
});

// Engine re-runs "up" if this changes the value
pongName.set(pong.name);

The first deployment will match the preview, but when triggering the re-deployment, we’re making a change that wasn’t in the first preview. This action could also result in a never-ending loop where every deployment makes another change to the state and triggers another deployment. So let’s explore a different option that might not have this issue.

Option 2: Refs

This option looks almost identical to the “state” concept above, except we’re calling them references (refs):

const pongName = new pulumi.Ref("pong-name", {
 initialValue: "",
});

const ping = new CallbackFunction("ping", {
 callback: pingPongHandler,
 environment: {
 variables: {
 OPPONENT_FN_NAME: pongName.value, // Special type the Pulumi engine will track
 },
 },
});

const pong = new CallbackFunction("pong", {
 callback: pingPongHandler,
 environment: {
 variables: {
 OPPONENT_FN_NAME: ping.name,
 },
 },
});

// Determine affected resources and re-update
pongName.set(pong.name);

The difference between refs and state is that, instead of triggering a whole re-deploy when the value changes, refs would be integrated into the dependency graph similarly to resources. When the value of the ref changes, we could internally work out which resources depend on that ref and change the target state for only those resources. This avoids the possibility of a never-ending update loop.

Both the “state” and “refs” approaches have the downside of not making the final outputs of the updated resource available to the rest of the program. The resource object would still have the values from after it first deployed. This means that other parts of the program might still deploy differently on subsequent deployments. Let’s explore another option that might address that problem.

Option 3: Create patch resources

We could explicitly model the third step by using a new resource type suffixed with “patch”:

const ping = new CallbackFunction("ping", {
 callback: pingPongHandler,
});

const pong = new CallbackFunction("pong", {
 callback: pingPongHandler,
 environment: {
 variables: {
 OPPONENT_FN_NAME: ping.name,
 },
 },
});

const pingPatch = new CallbackFunctionPatch("ping-patch", {
 id: ping.id,
 environment: {
 variables: {
 OPPONENT_FN_NAME: pong.name,
 },
 },
});

The provider presents pseudo-resources for update or patch operations. The patch resource is using the same underlying resource as the original resource. This option is a very flexible approach that could be implemented by providers right now. These patch resources could also be used for resources that exist outside the Pulumi stack. The drawback is that the patch operation has to be implemented in each provider individually, and it significantly increases the overall size of each provider and its associated SDK. We’re still evaluating whether this option would be a good one considering that size increase, which increases download times as an example impact, and the engineering resources to implement the change. We have one more option to consider, as well.

Option 4: Allow a resource to update its goal state

When using the SDK, we could write something like the following code to create then update a little later on:

const ping = new CallbackFunction("ping", {
 callback: pingPongHandler,
});

const pong = new CallbackFunction("pong", {
 callback: pingPongHandler,
 environment: {
 variables: {
 OPPONENT_FN_NAME: ping.name,
 },
 },
});

const updatedPing = ping.update({
 environment: {
 variables: {
 OPPONENT_FN_NAME: pong.name,
 },
 },
});

When declaring a resource in a Pulumi program, you’re essentially saying, “This is the state I want my resource to be in.” The update method returns a whole new copy of the resource with new properties containing the outputs of the update.

What’s next?

The final option is quite close to a fully working solution, but there still remains a few tasks to complete before we could release it as a feature:

Finalise what the internal messages between the Pulumi’s internal components should look like.
Keep a record of circular dependencies in the stack state without causing knock-on issues elsewhere in Pulumi’s internal workings.
Decide what should happen if an update triggers a replacement—if this is potentially valid behaviour or not. We should be able to generate the set of properties which are able to be updated without causing replacement and provide these properties to the user as the arguments for the update method to avoid these issues before execution of the program.

Some other ideas that would be interesting to explore in the future are as follows:

How could we utilise patching of resources where a provider can support it?
Could we delete a resource that was created earlier in the program to allow the creation of temporary resources?

This hackathon project has opened up a number of new pathways for us to explore. If you want to participate, we always welcome contributions in our open-source repos at https://github.com/pulumi. We hope you have enjoyed this dive into how our team explored this concept as part of the hackathon. We’ll be exploring more of the hackathon projects soon on the blog!

Pulumi Blog: Daniel Bradley

Faster Secrets in Pulumi IaC

Secrets Management in Pulumi

Performance Challenges with Secrets

Our Performance Improvements

Measurable Performance Gains

Getting Started

Conclusion

Beyond Stack Secrets: Pulumi ESC

Get Started Today

Pulumi Azure Classic Provider Version 6.0.0

Looking Back

New Modules

API Coverage Growth

Upgrading

AWS Lambda SnapStart with Pulumi

Reducing Function Latency with AWS Lambda SnapStart

Configuring Lambda Functions to work with SnapStart in Pulumi

Deployment and Performance Testing

Comparing performance before and after SnapStart

Conclusion

Pulumi Crosswalk for AWS 1.0: AWSX, EKS, and AWS API Gateway

Why Crosswalk for AWS?

Crosswalk for AWS 1.0

Containers (ECS)

Kubernetes (EKS)

Serverless (Lambda, API Gateway)

Migration from AWSx 0.x to 1.0

What’s Next?

Node.js Native Binary Compilation Using vercel/pkg

Setting up pkg

1 - Install

2 - Set bin in package.json

3 - Execute

Issues encountered

“Inspector Not Available”

Unrunnable MacOS ARM binaries

Static Binaries

Multi-platform builds with a makefile

Recap

Historical Note

Exploring how to solve circular dependencies

Option 1: State

Option 2: Refs

Option 3: Create patch resources

Option 4: Allow a resource to update its goal state

What’s next?

Setting up `pkg`

2 - Set `bin` in `package.json`