GitHub Actions help automate tasks within your software development life cycle. At Pulumi, we use GitHub Actions internally as part of every build/release cycle, and we run these tasks many, many times per day. This helps us to automate our CI/CD process and eliminate manual steps. Pulumi and many of our customers also deliver infrastructure resources as part of a CI/CD process: delivering infrastructure and applications in a single, integrated pipeline.
At re:Invent, the AWS team unveiled the new Amazon Elastic Container Registry Public (Amazon ECR Public), creating a new option for users in publishing and pulling public container images. Pulumi fully supports Amazon ECR Public in two ways:
- Official Pulumi container images are available today on Amazon ECR Public.
- Pulumi is the easiest way to package and publish your container images, and we’ll support publishing your container images to Amazon ECR Public very soon.
Most infrastructure projects require working with existing cloud resources, either by building on top of existing resources or adopting existing resources under management with a new and more robust infrastructure provisioning solution.
In June 2019, Pulumi introduced the ability to import existing infrastructure resources to be under Pulumi management no matter how you’ve provisioned these resources — manually in your cloud provider’s console or CLI, using an infrastructure as code tool like Terraform or AWS CloudFormation. Today, we are happy to announce a richer resource import experience.
As of v2.12.0, Pulumi has introduced
pulumi import command. This command will import the cloud resource into the Pulumi state and generate the code
for the user’s Pulumi program in the appropriate language.
Today we are announcing a minor but significant improvement to the Pulumi preview experience.
Customers and users have asked for the ability to change the secrets manager associated with their stacks. This would allow a user to rotate their secrets providers when people leave their organization or even to be able to migrate to another secret manager of their choice. The v2.8.0 release of Pulumi adds support for this specific feature. Let’s have a look at how to change a secrets provider for an existing stack:
Due to the nature of the product we build, the Pulumi team needs to have access to several cloud providers to develop and test the product. An increasing number of cloud providers comes with an associated ever-increasing cost.
In this post, we will talk about the best way to architect your Pulumi applications. We are going to build out the following infrastructure in AWS: AWS Fargate service that does not serve traffic directly AWS ALB as the entry point to the Fargate Service AWS RDS Instance that is stored in a separate network from the Application and does not service traffic directly from the internet To do this, we are going to split the infrastructure into two AWS VPCs.
Pulumi recently added support for managing DigitalOcean resources. This article will show you how to deploy some load balanced Droplets on DigitalOcean using Pulumi.
While some people coming to Pulumi are entirely new to Infrastructure as Code, increasingly teams are moving from other tools - whether cloud-specific in the form of CloudFormation or ARM Templates, or cloud-agnostic tools such as Terraform. In these organizations, new infrastructure provisioned with Pulumi must co-exist with existing resources provisioned with other tools, and often by different teams. For example, it’s common to see an application team deploying into a VPC owned and managed by a network operations team.
this kind of workflow
natively using the
type from the Pulumi SDK. Integration with the most popular
cloud-specific tools have been supported by Pulumi since the earliest
aws.cloudformation.getStack()function can be used to obtain the outputs from a CloudFormation Stack.
We recently added similar support for reading the outputs of a Terraform
state file - both from local
.tfstate files, and from all of the
remote state backends supported by Terraform. This is exposed via the
terraform.state.RemoteStateReference type in the