Migrating My Infrastructure From Terraform to Pulumi
Pulumi community member Erik Näslund shares his thoughts on how to migrate from Terraform to Pulumi. Read on to learn all the details of his experience!
Pulumi community member Erik Näslund shares his thoughts on how to migrate from Terraform to Pulumi. Read on to learn all the details of his experience!
Update Plans now no longer require the PULUMI_EXPERIMENTAL environment variable. For the most up-to-date information about using Update Plans, please see the Update Plans documentation.
Pulumi’s previews are an important part of any workflow where you want to see the changes that will be made to your infrastructure before actually making the changes (with pulumi up). However, today there is no guarantee that the pulumi up operation will do only what was previewed; if the program, or your infrastructure, changes between the preview and the update, the update might make additional changes to bring your infrastructure back in line with what’s defined in your program. We’ve heard from many of you that you need a strong guarantee about exactly which changes an update will make to your infrastructure, especially in critical and production environments.
Back in September 2021 we announced public preview for the Helm Release resource in Pulumi’s Kubernetes provider. Over the last few months, we have had a very encouraging uptake in usage and several meaningful discussions with users in the community that have helped shape improvements to this resource. Thanks to this collaboration, we are now pleased to announce that the Helm Release resource is now GA (generally available) starting in v3.15.0 of the Pulumi Kubernetes Provider and SDK in all Pulumi supported languages. We are excited to offer yet another tool to Pulumi users to effectively manage their Kubernetes footprint.
We recently announced in our release blog (66) a new package: Command. In this article, I want to show you a practical application of this that will allow us to deploy k3s to a DigitalOcean Kubernetes droplet. We’ll then leverage the Command package to run a remote command to fetch the kubeconfig, generated on the VM, and pull it down to create a Kubernetes provider to deploy nginx.
So, let’s get started by deploying our DigitalOcean droplet.
Over the holidays we have been releasing new features and improvements. Read on to learn about what’s new in this release!
As a reader of this blog, you’ve probably heard of the Pulumi Service, the default state-management backend of the Pulumi CLI, and if that’s the case, there’s a good chance you’ve also heard of many of its key features. But did you know we’re adding new features to the Service all the time—some of which are incredibly easy to miss? In this post, we’ll highlight a few of those lesser-known features that we think make it even easier to manage your infrastructure with Pulumi.
Pulumi community member Kay Plößer spent some time digging into setting up observability of a Pulumi deployment using Honeycomb. Read more to find out all the details on configuring Honeycomb and Pulumi together, with a side dish of Automation API!
If you’ve spent any time with Amazon API Gateway, you know it’s all about making it easier to manage a serverless REST API. But did you know you can do more with API Gateway than just invoke Lambdas? In this post, you’ll learn how to use Pulumi to connect API Gateway with EventBridge, Amazon’s serverless event bus, to build loosely coupled, scalable and maintainable apps and systems.
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.
Recently, Pulumi community member Josh Graham decided to bootstrap a simple application using a serverless approach, with a focus on using good engineering practices and being able to run the application locally. Given that Josh is the (OG) SaaS architect of Atlassian and an AWS user, LocalStack was a natural choice.