Today we are excited to announce the general availability of Pulumi 1.0. Pulumi is a modern infrastructure as code tool that lets you declare infrastructure using familiar, general-purpose languages, with a SaaS management console for configuring identities, organizations, and related policies. By using familiar languages, developers and operators are able to work better together, sharing and reusing best practices, accomplishing new levels of automation, and unlocking access to ecosystems of existing tools. The 1.0 release is a significant milestone for us, our community, and our customers, and signals completeness, stability, and compatibility.

Read more →

In this post, we’ll take a look at 10 “pearls”—bite-sized code snippets—that demonstrate using Pulumi to build serverless applications with Azure Functions and infrastructure as code. These pearls are organized into four categories, each demonstrating a unique scenario:

• Function App Deployment: Deploy an existing Azure Functions application using infrastructure as code.
• HTTP Functions as Callbacks: Mix JavaScript or TypeScript functions with your infrastructure definition to produce strongly-typed, self-contained, serverless HTTP endpoints.
• Cloud Event Handling: Leverage a variety of event sources available to Azure Functions with lightweight event handlers.
• Data Flows with Function Bindings: Take advantage of function bindings—declarative connectors to Azure services.

Read more →

We are very excited to announce that we have partnered with GitHub to offer our users better protection for their Pulumi Access Tokens.

By default, Pulumi users manage the state of their cloud infrastructure deployments using https://app.pulumi.com. This service provides state storage, concurrency control, audit history and access controls for both individuals and teams working with Pulumi. Each user and service account can generate one or more Pulumi Access Tokens to be used to authenticate with this service. These access tokens can be used on both local development machines, as well as in CI/CD systems for automated infrastructure deployments. These access tokens are sensitive secrets which should never be shared publicly, and in particular should never be committed to source control.

Read more →

Most cloud infrastructure projects involve working with existing cloud resources — either building on top of existing resources or adopting existing resources under management with a new and more robust infrastructure provisioning solution.

Whether you are adopting resources that were deployed manually using your cloud provider’s console or CLI — or migrating existing infrastructure from tools like Terraform or CloudFormation — Pulumi makes it easy to adopt and manage your existing resources.

Read more →

Kubernetes clusters from the managed platforms of AWS Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), and GCP Google Kubernetes Engine (GKE) all vary in configuration, management, and resource properties. This variance creates unnecessary complexity in cluster provisioning and application deployments, as well as for CI/CD and testing.

Additionally, if you wanted to deploy the same app across multiple clusters for specific use cases or test scenarios across providers, subtleties such as LoadBalancer outputs and cluster connection settings can be a nuisance to manage.

In this post, we’ll see how to use Pulumi to deploy the kuard app across EKS, AKS, GKE and a local Kubernetes cluster, such as Docker Desktop or a self-managed cluster. We’ll spin up the clusters in each provider, launch the app, and manage both cluster and app using the TypeScript programming language.

Read more →

Every non-trivial application relies on configuration values that may depend on the current execution environment. Some of these values contain sensitive information that shouldn’t be shared publicly. In general, the fewer parties that have access to those secret values, the safer the application will be—in fact, in an ideal world, no one would be granted direct access to those secrets.

Read more →

Managed Kubernetes offerings greatly reduce the overhead required in administering Kubernetes. However, the cluster is only one of the components under management, as app lifecycles are self-driven tasks that vary by workloads.

In Kubernetes, node groups are a useful mechanism for creating pools of resources that can enforce scheduling requirements. They also provide a utility for shifting workloads around during cluster management and updates.

In this post, we’ll see how to use Pulumi for Day 2 Kubernetes administration. We’ll spin up a new EKS cluster with two node groups and a given workload. Then we’ll add one more node group with an updated configuration, and migrate the workload over to it with zero downtime using code and kubectl.

Read more →

Pulumi recently added support for managing DigitalOcean resources. This article will show you how to deploy some load balanced Droplets on DigitalOcean using Pulumi.

Read more →

Last Wednesday, we invited members of our local Seattle community to Pulumi HQ for the July Pulumi Up meetup. The evening began with some networking time wherein our guests met some Pulumi engineers and users they may have only ever interacted with over Pulumi’s Community Slack while enjoying free pizza and beverages. This month’s meetup featured two talks by Pulumi engineers.

Application code isn’t the only code that can have APIs

Unfortunately, due to travel issues, Paul Stack wasn’t able to join us in person, but graciously agreed to present remotely… from Europe… at 4:00 in the morning. He presented “Application code isn’t the only code that can have APIs” and went over how programming languages help in building the best infrastructure code. During the talk, he presented a simple Pulumi program for creating an RDS instance and walked through the simple programming constructs he utilized to help create APIs that anyone could code against. Here’s a recording of his talk, with the video also available on the Pulumi TV YouTube Channel.

Read more →

The Amazon Elastic File System Container Storage Interface (CSI) Driver implements the CSI specification for container orchestrators to manage the lifecycle of Amazon EFS filesystems. The CSI specification defines an interface along with the minimum operational and packaging recommendations for a storage provider to implement a CSI compatible plugin. The interface declares the RPCs that a plugin must expose. The CSI drivers are the right mechanism to work with, when using a cloud storage component with Kubernetes workloads. Amazon Elastic File System (Amazon EFS) provides parallel shared access through a standard file system interface to Amazon EC2 instances and Linux-based workloads without disrupting your applications. EFS is a regional service storing data across multiple Availability Zones (AZs) for high availability and durability.

Read more →