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