Joe Duffy
β
Today we are excited to announce the Preview of .NET Core support for all of your modern infrastructure as code needs. This means you can create, deploy, and manage your infrastructure, on any cloud, using your favorite .NET language, including C#, F#, and VB.NET.
Sophia Parafina
β
We are always excited when people join the Infrastructure as Code community and write about their experiences. Pulumi can be used for a range of common tasks such as standardizing VPC builds, building VSphere virtual machines, or deploying your infrastructure from a CI/CD pipeline. Whether it’s TypeScript, JavaScript, or Python you can build your infrastructure with your language and tools of choice. Here are three new blog posts that show how to use Pulumi with code examples to perform these tasks.
Sophia Parafina
β
Continuous delivery is about making changes in your application and getting them into production securely, quickly, and consistently. Pulumi’s infrastructure as code approach uses source code to model cloud resources, making it ideal for continuous delivery. Your infrastructure code can share the same process as your application code including running unit and integration tests, performing code reviews via Pull Requests, and examining your infrastructure using linters or static analysis tools. Like your application, your cloud infrastructure can be validated and tested before deploying to production. Pulumi can integrate into any CI/CD system (such as Jenkins, Azure DevOps, CircleCI, TravisCI, Codefresh, and others), so let’s take a look at how to implement a deployment server, using Octopus as an example.
Paul Stack
β
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:
To do this, we are going to split the infrastructure into two AWS VPCs. One VPC will be used for the application based resources (e.g Fargate Service, ALB) and the other VPC will be for the database resources. The VPCs will be peered to allow communication between them so that the application can communicate with the database securely.
Mikhail Shilkov
β
Azure Functions is a managed service for serverless applications in the Azure cloud. More broadly, Azure Functions is a runtime with multiple hosting possibilities. KEDA (Kubernetes-based Event-Driven Autoscaling) is an emerging option to host this runtime in Kubernetes.
In the first part of this post, I compare KEDA with cloud-based scaling and outline the required components. In the second part, I define infrastructure as code to deploy a sample KEDA application to an Azure Kubernetes Service (AKS) cluster.
The result is a fully working example and a high-level idea of how it works. Kubernetes expertise is not required!
Joe Duffy
β
We recently partnered with DigitalOcean to publish a new tutorial, How to Manage DigitalOcean and Kubernetes Infrastructure with Pulumi. This short tutorial walks you through provisioning a new DigitalOcean Kubernetes cluster, deploying an application to it, and then assigninging a stable domain name to your application’s load balancer β all in a handful of lines of infrastructure as code.
By using infrastructure as code to provision and update your infrastructure, it’s easy to create new environments, modify or scale existing ones, or automate your deployments using continuous delivery. This approach also ensures that deployments are reliable and repeatable, and can even standardize how you deploy code to different cloud providers, including DigitalOcean, AWS, Azure, GCP, and others.
Mikhail Shilkov
β
In a previous blog post, I shared how easy it is to create a globally distributed, highly-available, low-latency application with Azure Functions, Azure Cosmos DB, and Pulumi.
Today, I want to show how the same approach can be generalized for any cloud compute service, including containers, virtual machines, and serverless functions.
It’s been a few years since Google shut down Google Reader, and while a number of nice commercial alternatives have sprung in its wake, none of them has ever been quite the right fit for me personally.
So a while back, after far too much time spent wandering the blogsphere manually, typing URLs into address bars by hand, I decided to go looking to see whether the universe had produced an open-source solution to this problem — and to my surprise and delight, it had! Miniflux is an excellent little open-source RSS server and reader, written in Go and backed by PostgreSQL, that also happens to be packaged as a Docker container. So in this post, I’ll show how easy it is to deploy a Miniflux server of your own on AWS, using only Pulumi and a few lines of TypeScript.
Eric Rudder
β
“What’s in a name? That which we call a rose by any other name would smell as sweet.” William Shakespeare’s oft repeated quote was used to help Juliet explain that a “Montague” is worthy of love. Juliet may have underestimated the importance of a name, however, since things didn’t work out so well for everyone in Verona! Many customers have questions about “names” in Pulumi – and in an effort to make sure that things work out better for them than they did for Romeo, here’s a quick note on naming!
Joe Duffy
β
This blog post announces Pulumi 1.0, which has been superseded by newer versions. For information about the latest Pulumi release, please refer to the current documentation and recent release notes.
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 siginificant milestone for us, our community, and our customers, and signals completeness, stability, and compatibility.
