Pulumi Blog: Dotnet

Six Live Kubernetes Recommendations: AKS, Cilium, Rate Limiting, and More

Adam Gordon Bell — Mon, 15 Jun 2026 12:00:00 +0000

On June 10th, Engin and I ran a live workshop building an AKS cluster, an Azure Container Registry, and a random-cat web app from scratch in C#. This is the writeup, including the parts we didn’t get to live.

Live demos keep you honest. On June 10th my AKS workshop went a little sideways. Partway through, Docker Hub rate-limited my image pull and we had to adapt the content on the fly. The original plan was to stand up an AKS cluster with Cilium, an Azure Container Registry with the cluster’s pull permission wired in code, and a random-cat web app, then split the infrastructure from the workload into separate Pulumi stacks. Live, we didn’t make it through all of that, but we had some fun tangents and it turned out to be a great session. So here are my six recommendations for working with Kubernetes on Azure from this recent workshop.

1. Pick the language your team already uses

I opened the session by asking the room what language they prefer to work in, with one caveat from me: “Hopefully, it’s not PowerShell because this is not in PowerShell.” We got some C# answers and zero requests for PowerShell, which works out, because the whole workshop is in ~~PowerShell~~ C#.

I chose C# because, first, I genuinely love the language. I spent the early part of my career as a C# developer, and on Azure it just makes sense. Second, an Azure workshop tends to draw a big turnout of C# devs, and if they aren’t C# devs themselves, they often work somewhere the backend team uses C#. Pulumi lets you bring that language to your infrastructure rather than learn a new DSL.

AI coding assistants also came up. LLMs have substantially more C# and Go in their training data than HCL or Bicep. As I put it live: “If you’re working in HCL, well, there’s not that much out there in the training set, but there’s lots of C#. There’s lots of Go.” I co-authored parts of the workshop code with Claude.

Pick the language your team already writes.

Pulumi runs on the language your backend engineers know, and that language has more AI assistant training data behind it too.

Aside: everyone’s path ran through Docker Swarm

We also had some fun historical conversations about orchestrators. I asked Engin: “Did you use anything before Kubernetes became popular? Like Mesosphere or any of those other interesting solutions of the heyday?”

Engin had walked the same road most of us did.

Engin: “We used the classical Ansible powered provisioning of VMs… And then we switched to Consul to have a little bit more control… And then we had a short intermezzo with Docker Swarm… So Docker Swarm with Portainer was really goated. And Kubernetes then took over.”

My own history rhymed with his.

Adam: “I worked at a place where we used a bunch of shell scripts to have like JVM services, like a red green deploy… And then it was Docker Swarm for a little bit. And then it was Kubernetes.”

No single tool won. Teams picked what fit their existing skills and shifted gradually as the ecosystem matured.

2. Use Cilium on AKS if you can

By default, Kubernetes on AKS doesn’t turn on Cilium. My strong recommendation is to turn it on. The option is called Azure CNI Powered by Cilium, and it takes one config block:

NetworkProfile = new ACI.ContainerServiceNetworkProfileArgs
{
 NetworkDataplane = "cilium",
 NetworkPlugin = "azure",
 NetworkPluginMode = "overlay",
 NetworkPolicy = "cilium",
 PodCidr = "192.168.0.0/16",
},

This buys you eBPF networking instead of kube-proxy and iptables. eBPF lets you run sandboxed programs inside the Linux kernel itself, so packet handling and NetworkPolicy enforcement happen down in the kernel instead of up in userspace. You also get Hubble flow visibility built in, the same technology as GKE’s Dataplane V2. As I said live, “this is very easy to set up on Azure. You just network data plane, set it to Cilium. Network policy, set it to Cilium.”

Self-hosted, Cilium is helm install cilium with a dozen flags and a lifecycle you own forever. On AKS, it’s these five lines and Azure runs it. On a getting-started cluster, I’ll take the managed version every time. Owning that lifecycle yourself buys you nothing here.

Full code: 01-cluster/Program.cs

On managed Kubernetes, complexity you’d self-host becomes a field you set.

AKS gives you the managed version of eBPF networking. Pulumi makes the configuration code instead of portal clicks.

3. Debugging Kubernetes is easier when your tools have the full context

The rate limit wasn’t even the first failure of the hour. That honor went to Azure, which refused to provision the cluster on the first pulumi up. I was running in Canada Central, and Pulumi Neo read the error and diagnosed it:

Neo: “Capacity constraints in the selected region. We might need to change our location.”

Adam: “Maybe this Canadian Azure instance is not all it’s cracked up to be.”

Engin: “East US is always a good bet.”

We switched the region to East US, and the cluster came up. That is the kind of diagnosis a stack-aware assistant is good at, reading the actual provisioning error instead of leaving me to guess.

Then the image step hit. The workshop’s original flow pulled the cat app image into ACR with az acr import --source docker.io/agbell/my-random-cat, and Docker Hub rate-limited me, even though I was the only person in the room running the code. So how do you blow through an anonymous pull limit all by yourself? The trick is that az acr import runs server-side. Azure does the pull from Docker Hub, not my laptop, and it goes out over an egress IP shared by who-knows-how-many other Azure tenants. Docker Hub counts anonymous pulls per IP address, so all of that shared traffic lands in one bucket. It flagged me at the worst possible moment: “I just got flagged by Docker Hub. That is awesome. That will be a challenge for this demo.”

Nothing focuses a workshop like watching your own demo get rate-limited in front of a live audience.

Live, I asked Neo to route around it: “we’re using Neo. And Neo is going to switch us out to a nice Hello World project.” Neo could see the whole stack, down to the failing image reference, and it swapped the workload over to a standard hello-world image hosted on Azure, so the deploy no longer depended on Docker Hub. A few minutes later: “we should have a Hello World container running here. It’s way less fun than my image… just a bunch of random cats. But here we can see that this is working.” I won’t oversell it. The cat was gone, and we didn’t get through every planned stage. But the cluster was up with a workload deployed, and the session kept moving.

That’s the case for a stack-aware assistant over a chatbot. A general chatbot can tell you that Docker Hub has rate limits and that you should host images closer to home. Neo was working with the actual program state, so the workaround it proposed was already wired to my resources. Engin put it this way: “for me, Pulumi Neo, the subcommand is the new Pulumi app.” When something breaks mid-demo, the tool that can read your stack is the one that helps.

The long-term fix was switching to az acr build, building the image in ACR from source, so the app image never has to come from Docker Hub at all. Every stage in the repo now builds the cat image this way, from source shipped in each stage’s app/ folder:

az acr build --registry <your-acr> --image my-random-cat:latest app

No local Docker, and the app image never touches Docker Hub. The only Docker Hub dependency left is the base image (python:3.9-slim), pulled server-side by ACR’s build instead of by an import you re-run every time.

Full code: 02-app/Program.cs

An assistant that can read your stack beats one that can’t.

A general chatbot knows Docker Hub has rate limits. Neo could see the deployment and the failing image reference, and that context is what turned advice into a working fix mid-session.

4. You don’t have to abandon Terraform to start

One attendee, Martin, had been using Terraform for eight-plus years. His question, put directly: “I’m using TF for eight plus years. Why should I consider Pulumi? Where is the strength?… It seems unnecessary to TF for me. At least from what I’m seeing now.”

Fair question, and the honest answer is you don’t have to abandon your modules. Pulumi has first-class Terraform module support, so you can reference existing modules from a Pulumi program. Python ML teams can import infrastructure modules, and platform teams can wrap them in typed abstractions. The portfolio doesn’t change. The programs that use it just get more capable.

The sharper reason is about edges. HCL and Bicep are purpose-built DSLs, and when you hit what they can’t express, there’s no escape hatch inside the language. With a general-purpose language you can always drop to the SDK or shell out. The edges still exist. They’re just further out, and that’s the whole difference once a project gets past the basics.

You don’t have to rip and replace.

Pulumi can reference existing Terraform modules. Move what makes sense now. The DSL/language tradeoff shows up at the edges, not the basics.

5. Split slow infrastructure from fast workloads

Once we had the cluster up and the app running, the single program had grown: cluster, ACR, AcrPull, image build, deployment, service. Every new workload meant editing the file that also declares the cluster. We had planned this turn in the session in advance. I posed the problem and Engin had the recommendation ready:

Adam: “What do you think the problem is with my code here, Engin? … The problem is like every time I want to add a new service to my Kubernetes cluster, I have to go into this file that declares the cluster and all its infrastructure. I think I would prefer to split it.”

Engin: “Create other stacks which are then referencing each other to get the values out. Actually, I highly recommend.”

Adam: “Yes, I totally agree with you, Engin. We should split these out into two separate stacks.”

So that’s what we did. The infrastructure stack exports the kubeconfig and registry URL. The workload stack references those outputs via StackReference. The slow-moving infra and the fast-moving app become independent deployment units. The infra team and the app team can ship on their own cadences, without fighting over one file.

// workload/Program.cs — pulls cluster outputs, never touches cluster resources
var clusterStack = new StackReference(cfg.Require("clusterStack"));
var kubeconfig = clusterStack.GetOutput("kubeconfig");
var acrLoginServer = clusterStack.GetOutput("acrLoginServer");

The tricky part is one we didn’t cover live, which is how you split a running workload without taking down the running services. The real answer is migrating the stack state, moving resources between stacks instead of destroying and recreating them. As I noted in the session: “now we are just removing the service from our project. If this was actual production stuff, I don’t think I’d be just shutting down the service… You can actually just make changes to the state rather than tearing them down.”

For the workshop, a simpler move kept the Kubernetes cluster up and the demo moving: keep the project name. Pulumi identifies stacks as org/project/stack, so if you move the cluster code into aks-cluster/ while keeping the project name kube-kitties, Pulumi still sees org/kube-kitties/dev. Same stack, nothing recreated. Rename the project and you get a second cluster.

In stage four of the demo, I showed how to extend this pattern to work with existing YAML manifests: ConfigGroup drives raw Kubernetes YAML through the Pulumi provider, giving you previews and dependency ordering without rewriting files. One transformation swaps the Docker Hub image reference for the ACR copy, so manifests stay portable and pods pull from your private registry.

Code: 03-split/ and 04-split-yaml/

Keep the project name when you split, and the cluster doesn’t move.

Pulumi identifies stacks as org/project/stack. Same project name means the same stack. Rename it and you spin up a new cluster.

Run Kubernetes on AKS with code

Provision your AKS cluster, container registry, and workloads in C#, then split infrastructure from apps into separate stacks so each ships on its own cadence.

Get started

6. GitOps is the way

The final stage of the workshop is left as homework, and it’s a great one to pick up. GitOps is the standard way to run Kubernetes at this point, the One True Way™ depending on who you ask. My position from the call: “I think I’m on team GitOps.”

The take-home is the 05-gitops folder. We didn’t demo it live, but the code is real and verified: Pulumi stands up the cluster, installs Argo CD, and registers the cat as an Argo Application. From there, changes are git push.

To see Kubernetes and GitOps worked through end to end, watch the video above. Engin also recently ran a GCP workshop with great examples of GitOps with Pulumi, using Flux.

Let Pulumi stand up the cluster, then let GitOps run the apps.

Pulumi installs Argo CD or Flux as part of the infrastructure. From there, workload changes are a git push. Stage 5 of the workshop repo is a complete Argo CD example.

Try it yourself

That’s the whole workshop, six recommendations and two live failures that ended with a cat app running on AKS. To run it yourself, clone the repo. There’s a DEMO.md with every step of this session, and the stage folders mirror the arc above. 01-cluster is the infrastructure checkpoint, 02-app adds the cat app built into your own registry, 03-split and 04-split-yaml separate infrastructure from workload, and 05-gitops is the homework.

Pick a stage and bring it up:

git clone https://github.com/pulumi/workshops
cd workshops/az-getting-started-aks/02-app
pulumi up
curl http://$(pulumi stack output catServiceIp)/

Expect 5 to 8 minutes waiting on cluster create. That’s just how long AKS takes. And since each folder is a complete, runnable checkpoint with its own stack, run pulumi destroy before moving to the next stage, or you’ll have several clusters billing at once.

You’ll need an Azure subscription, the Pulumi CLI, and the .NET SDK. Basic Kubernetes familiarity helps. For more on the building blocks, see the Azure Native provider and the Kubernetes provider in the Pulumi Registry.

The full workshop code lives at github.com/pulumi/workshops under az-getting-started-aks. Check out our upcoming sessions on the workshop page, or subscribe to the newsletter to hear what’s coming up.

If there’s a seventh recommendation hiding in here, it’s the one I learned the hard way: never pull from Docker Hub live again. I’ll be keeping my images on a paid cloud registry from now on.

Engin and I will be doing more of these, and we’d love to see you at the next one.

Parts of the workshop code were authored by Claude and Pulumi Neo, and parts of this writeup got help from both as well.

Preview of .NET resource providers

Fraser Waters — Wed, 18 Jan 2023 00:00:00 +0000

Today we are pleased to announce the Preview of .NET support for custom resource providers. This means you can build custom providers using your favorite .NET language, including C#, F#, and VB.NET.

This is a first look preview release of the provider interface for .NET. It has minimal documentation but is feature complete. We hope to gather early feedback to refine the API and quickly bring this to a production quality release.

You will need to use version 3.52.0 to access the new APIs. You can install this in your project with:

dotnet add package Pulumi --version 3.52.0

You can see an example of using the new provider interface in the dotnet integration tests directory. This has replaced the old test provider that was written in Go.

Please view the provider interface and raise issues and discussions on GitHub or our Community Slack in the #dotnet channel — we can’t wait to hear what you think!

Improved Pulumi Experience with .NET 6

Zaid Ajaj — Fri, 22 Jul 2022 00:00:00 +0000

In this blog post, we will talk about how Pulumi is now using .NET 6, the latest Long-Term Support version of .NET, as our default across the ecosystem. We will discuss the changes applied to templates, program structure and code generation. We also explain how Pulumi C# projects can benefit from the latest features in .NET 6 and how it simplifies your programs overall. Let’s dive in, shall we?

Templates

We updated all of our .NET templates to use net6.0 as the target framework. This means that projects created with pulumi new require at least the .NET 6 SDK to build and run the projects. The templates also simplified the program structure quite a bit and not longer use MyStack classes to define resources in case of C# and VB.NET templates. F# templates didn’t change that much because these already didn’t use the class approach to define infrastructure.

Simplified program structure

Let us examine a new C# template. Create a new project using pulumi new aws-csharp in a new directory and notice that there is no longer a MyStack.cs file, only Program.cs. Open the latter in an editor and you should see the following:

using Pulumi;
using Pulumi.Aws.S3;
using System.Collections.Generic;

return await Deployment.RunAsync(() =>
{
 // Create an AWS resource (S3 Bucket)
 var bucket = new Bucket("my-bucket");

 // Export the name of the bucket
 return new Dictionary<string, object?>
 {
 ["bucketName"] = bucket.Id
 };
});

This is how a stack with resource definitions and outputs now looks. The Get Started guide has been updated to follow this pattern as well.

Targeting .NET 6 means that we can use features from C# 10 and here we see them in action: using top-level statements that greatly simplify the entry point of the project and reduce it down to a single function call to Deployment.RunAsync. Inside this function is where we define our resources and return outputs for the stack. Top-level statements also allow us to await asynchronous functions without having an explicit Main(string[] args) function or a Program class.

Notice how you no longer have to define the types of your stack outputs upfront. Instead, you simply return a dictionary of key-valued outputs. In fact, the function Deployment.RunAsync is very flexible. When you don’t want to return outputs, don’t!

return await Deployment.RunAsync(() =>
{
 var bucket = new Bucket("my-bucket");
});

Moreover, when you want to await asynchronous functions alongside your resource definitions, just mark the lambda as async. Here is an example where we await function invokes and work with their results.

using Pulumi;
using Pulumi.Aws;
using Pulumi.Aws.Ec2;
using System.Linq;

return await Deployment.RunAsync(async() =>
{
 var vpc = await GetVpc.InvokeAsync(new()
 {
 Default = true
 });

 var zones = await GetAvailabilityZones.InvokeAsync();

 foreach (var range in zones.Names.Select((zone, index) => new { Value = zone, Key = index }))
 {
 var subent = new Subnet($"vpcSubnet-{range.Key}", new()
 {
 AssignIpv6AddressOnCreation = false,
 VpcId = vpc.Id,
 MapPublicIpOnLaunch = true,
 CidrBlock = $"10.100.{range.Key}.0/24",
 AvailabilityZone = range.Value,
 Tags =
 {
 ["Name"] = $"pulumi-sn-{range.Value}",
 },
 });
 }
});

The cherry on top is that you can use target-typed new expressions when instantiating resource or function invoke argument types. Basically instead of writing new Bucket("my-bucket", new BucketArgs { ... }), you can write new Bucket("my-bucket", new () { ... }).

Backward-compatibility

It is worth mentioning that although the new templates and the accompanying getting-started guides are updating to .NET 6, the main Pulumi SDK NuGet package and cloud provider packages are still targeting netcoreapp3.1. This mean that if users are still using .NET SDK v3.1 or v5.0 to build and run your projects, everything will continue to work as always.

Code generation

Pulumi provides tools to translate from several IaC languages. These tools will generate Pulumi programs in any of our supported languages. This includes:

Translating Pulumi YAML with the Pulumi CLI using pulumi convert
Translating Azure Resource Manager (ARM) templates using arm2pulumi
Translating Terraform code with the Pulumi CLI using pulumi convert --from terraform
Translating Kubernetes YAML using kube2pulumi

These tools take their source language as input, convert it into the Pulumi intermediate language, then translate it into one of our supported languages. In the case of C#, the code generation has been updated to produce code that uses the latest features from .NET 6. We’ve also fixed minor issues that were present in the translation logic.

The code generation update has landed in the Pulumi CLI and pulumi convert, the other tools however will pick up these updates soon.

Let us take an example from Pulumi YAML and convert it to C#.

Generate a new Pulumi YAML project using pulumi new azure-yaml, it should give you this YAML program:

name: azure-yaml
runtime: yaml
description: A minimal Azure Native Pulumi YAML program

resources:
 # Create an Azure Resource Group
 resourceGroup:
 type: azure-native:resources:ResourceGroup
 # Create an Azure resource (Storage Account)
 storageAccount:
 type: azure-native:storage:StorageAccount
 properties:
 resourceGroupName: ${resourceGroup.name}
 sku:
 name: Standard_LRS
 kind: StorageV2

variables:
 storageAccountKeys:
 Fn::Invoke:
 Function: azure-native:storage:listStorageAccountKeys
 Arguments:
 resourceGroupName: ${resourceGroup.name}
 accountName: ${storageAccount.name}

outputs:
 # Export the primary key of the Storage Account
 primaryStorageKey: ${storageAccountKeys.keys[0].value}

Now you can take this program and convert it to C# using

pulumi convert --language csharp --out csharp-from-yaml

This command generates a full C# project from the YAML program into the directory ./csharp-from-yaml, then restores the dependencies and builds the project. Now if you examine Program.cs, it contains the converted program and follows the succinct C# 10 syntax that targets .NET 6:

using System.Collections.Generic;
using Pulumi;
using AzureNative = Pulumi.AzureNative;

return await Deployment.RunAsync(() =>
{
 var resourceGroup = new AzureNative.Resources.ResourceGroup("resourceGroup");

 var storageAccount = new AzureNative.Storage.StorageAccount("storageAccount", new()
 {
 ResourceGroupName = resourceGroup.Name,
 Sku = new AzureNative.Storage.Inputs.SkuArgs
 {
 Name = "Standard_LRS",
 },
 Kind = "StorageV2",
 });

 var storageAccountKeys = AzureNative.Storage.ListStorageAccountKeys.Invoke(new()
 {
 ResourceGroupName = resourceGroup.Name,
 AccountName = storageAccount.Name,
 });

 return new Dictionary<string, object?>
 {
 ["primaryStorageKey"] = storageAccountKeys.Apply(listStorageAccountKeysResult => listStorageAccountKeysResult.Keys[0]?.Value),
 };
});

Summary

.NET 6 is the latest Long-Term Support version in the Microsoft ecosystem. Our new .NET 6 support makes for simpler and easier to write Pulumi programs. You can give it a try by installing .NET 6 and using one of the templates with pulumi new, then follow our updated Get Started guide to get up and running quickly. Our code generation tools have been upgraded to emit code that targets the latest features of C# and fixes minor correctness issues in the translation logic.

Enhanced static-code analysis for C# projects

Zaid Ajaj — Fri, 15 Jul 2022 00:00:00 +0000

When I started using Pulumi for the first time, I used C# as my language of choice for defining infrastructure. I start by creating resources and providing their parameters through argument objects. The IDE helps me out with auto-completions and type errors as I go but the compiler didn’t always detect some of the errors I eventually came across.

Consider the following piece of code:

var resourceGroup = new ResourceGroup("resourceGroup");
var storageAccount = new StorageAccount("storageAccount", new StorageAccountArgs
{
 ResourceGroupName = resourceGroup.Name,
 Sku = new SkuArgs { Name = SkuName.Standard_LRS }
});

In this snippet, I create a resource group in Azure, then create a storage account that belongs to that resource group. Pretty simple stuff! The IDE tells me that the code is good and doesn’t report any errors but just to be sure everything is as it should be, I build the project and the code compiles successfully. Now I am confident and ready to deploy the infrastructure.

I run pulumi preview and to my surprise, it fails. The C# program throws an exception at runtime:

Diagnostics:
pulumi:pulumi:Stack (AzureExample-dev):
error: Running program '/Users/zaid/projects/AzureExample/bin/Debug/net6.0/AzureExample.dll' failed with an unhandled exception:
System.ArgumentNullException: [Input] Pulumi.AzureNative.Storage.StorageAccountArgs.Kind is required but was not given a value (Parameter 'Kind')

What happened? It turns out I didn’t provide a required property Kind when instantiating the type StorageAccountArgs for the StorageAccount.

This is an unfortunate result because I had expected that when my program compiled, that it was valid and ready to deploy.

In this case, the fix is simple:

var storageAccount = new StorageAccount("storageAccount", new StorageAccountArgs
{
 ResourceGroupName = resourceGroup.Name,
 Sku = new SkuArgs { Name = SkuName.Standard_LRS },
 // adding this property
 Kind = Kind.StorageV2
});

There is a bigger problem in the API of the resource creation. The compiler should tell you at compile-time that you missed a required property. The underlying cause is because we are using property initializers for StorageAccountArgs with a parameterless constructor. This is the case when creating any resource across the cloud providers available in the Pulumi ecosystem.

See Pulumi #3808 for more details and discussion on this issue.

What can we do to fix the problem?

First solution that comes to mind is to fix the generated .NET API for each cloud provider available with Pulumi: adding the required parameters as part of the constructor of arguments type and removing the parameterless constructor.

This however means introducing a breaking change for each and every existing C# program running with Pulumi using the empty constructor. Here at Pulumi, we want to ensure that changes to our APIs are backward-compatible, so this is a no-go.

The problem above looks like the compiler could have detected if it somehow knew which properties were required or and which were optional. In the case of the generated APIs, this requiredness information is only encoded on properties with a special attribute [Input("propertyName", required: true)] which unfortunately is Pulumi-specific and the compiler has no way of detecting it and reporting an error or a warning to the developer at compile-time.

Solution

What do we do? Static code analysis to the rescue! If the compiler can’t do it, we can build an extension and have detect these types of errors for the developers.

Enter PulumiCSharpAnalyzer: a Roslyn-based code analyzer that adds compile-time checks to your Pulumi code and reports it as part of the build.

Available today as a NuGet package, you can install the analyzer into your project as follows:

dotnet add package PulumiCSharpAnalyzer

Now your IDE, whether that is Rider, Visual Studio or VS Code with OmniSharp should report the error inside the IDE like any compile error or warning. Here is for example how it looks like inside Rider:

Not just your IDE, it integrates into your build pipeline too. When you dotnet build your project, the detected errors will show up there:

> dotnet build
Microsoft (R) Build Engine version 17.2.0+41abc5629 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

 Determining projects to restore...
 All projects are up-to-date for restore.
/Users/zaid/projects/AzureExample/Program.cs(11,63): warning MissingRequiredProperty: Missing required property Kind when initializing properties of type StorageAccountArgs [/Users/zaid/projects/AzureExample/AzureExample.csproj]
 AzureExample -> /Users/zaid/projects/AzureExample/bin/Debug/net6.0/AzureExample.dll

Build succeeded.

Besides detecting missing properties when creating resources, the analyzer also detects missing properties for function invokes which follow a similar pattern:

Finally, an anti-pattern that the analyzer can detect is creating resources within an .Apply(...) call:

We always recommend developers to avoid creating resources inside .Apply(...) calls because the execution plan of Pulumi will be different during the pulumi preview and pulumi up phase.

The reason is that when we have an instance of Output<T> from which we call Apply, the value of the instance is most likely unknown during pulumi preview since it is only computed when Pulumi actually performs the deployment plan against APIs of cloud providers.

Limitations

With the current features of the analyzer, it is already usable across all cloud provider SDKs. That said, there are limitations to the way the analyzer works. At the moment, when determining the missing properties, the logic only detects initialized properties when creating the object and diffs those against the required properties from the schema. This means that if you happened to use property setters instead of property initializers, they are considered “not provided” and will report a warning. For example, the following piece of code will produce a false-positive warning…

var storageAccountArgs = new StorageAccountArgs();
storageAccountArgs.ResourceGroupName = resourceGroup.Name;
storageAccountArgs.Kind = Kind.StorageV2;
storageAccountArgs.Sku = new SkuArgs { Name = SkuName.Standard_LRS };

…even though it is logically equivalent to

new StorageAccountArgs
{
 ResourceGroupName = resourceGroup.Name,
 Kind = Kind.StorageV2,
 Sku = new SkuArgs
 {
 Name = SkuName.Standard_LRS
 }
};

This is something I will be working on in the near future and the fix is relatively doable, but it is just a heads-up that the analyzer is not perfect at the moment.

Conclusion

Install the analyzer today in your C# Pulumi projects and get better static-code analysis in your Pulumi projects. Keep in the mind the limitations outlined above and let us know if you encounter issues that we didn’t take into account before.

Automate Your Infrastructure with Automation API and C#

Joshua Studt — Mon, 08 Mar 2021 00:00:00 +0000

Joshua Studt is a Solutions Architect at Financial Independence Group and a Pulumi Community member who contributed the C# package for Automation API.

Currently available in public preview, Pulumi’s Automation API enables you to provision your infrastructure programmatically using the Pulumi engine. Today, we are excited to announce C# support for Automation API, enabling .NET developers to automate infrastructure deployments, create complex orchestration workflows, build custom ops tooling, and build cloud frameworks. Read more about the Automation API here.

Using Automation API in .NET

The Pulumi.Automation NuGet package exposes a LocalWorkspace for creating and managing Pulumi Stacks, and a WorkspaceStack that is a programmatic representation of a Stack for updating, refreshing, previewing, and destroying cloud resources. The Automation API makes it trivial to run Pulumi programs inline:

var program = PulumiFn.Create(() =>
{
 var bucket = new Pulumi.Aws.S3.Bucket("s3-website-bucket");

 return new Dictionary<string, object?>
 {
 ["bucket_name"] = bucket.BucketName,
 };
});

var stackArgs = new InlineProgramArgs("projectName", "stackName", program);
using var stack = await LocalWorkspace.CreateOrSelectStackAsync(stackArgs);

await stack.Workspace.InstallPluginAsync("aws", "v3.30.1");
var result = await stack.UpAsync();
var bucketName = result.Outputs["bucket_name"];

You can use your existing Pulumi projects and invoke them from the Automation API:

var stackArgs = new LocalProgramArgs("stackName", "C:\path\to\pulumi\project\dir");
using var stack = await LocalWorkspace.CreateOrSelectStackAsync(stackArgs);

await stack.UpAsync();

Since the Automation API can be invoked and debugged like any other code, it enables you to put together complex deployment workflows such as a blue-green deployment model:

using var workspace = await LocalWorkspace.CreateAsync(new LocalWorkspaceOptions
{
 Program = PulumiFn.Create<ApplicationStack>(), // use your existing Pulumi.Stack implementation
 ProjectSettings = new ProjectSettings("projectName", ProjectRuntimeName.Dotnet),
});

// your "blue" production code is already running

var green = await WorkspaceStack.SelectAsync("green", workspace);
await green.UpAsync();

// do your cutover to "green" logic
// and then teardown "blue"

var blue = await WorkspaceStack.SelectAsync("blue", workspace);
await blue.DestroyAsync();

See full Automation API examples in C#. Let us know if you’re using Automation API on Twitter or in our Community Slack.

Create Amazon EKS clusters in your favorite language

Levi Blackstone — Thu, 04 Feb 2021 00:00:00 +0000

Check out version 3.0 of the Pulumi EKS Provider.

Pulumi’s infrastructure as code tooling combines the programming languages and tools you already know with the full power of cloud infrastructure. But until now, some Pulumi components for cloud infrastructure, like our popular EKS package for Amazon’s Elastic Kubernetes Service, were only available in a subset of the languages supported by Pulumi.

Now, you can use the EKS package–previously only available for TypeScript–in all four Pulumi languages: TypeScript, Python, .NET, and Go. Regardless of the language you choose, you can manage EKS clusters with Pulumi, starting with the v0.22.0 release. Check out our Modern Infrastructure Wednesday video to see it in action:

Making components available in every language

Pulumi’s EKS package is made up of Pulumi components. A component is a collection of Pulumi resources that provides an easy way to package best practices for using cloud resources, even if those best pratices span individual resources or even entire cloud providers. Until now though, components could only be used in Pulumi programs written in the same language as the component.

To change that, we’re creating “multi-language components”. With multi-language components, anyone will be able to author a component in one language and automatically compile it to all other languages supported by Pulumi. This means anyone in the worldwide Pulumi community will be able to take advantage of any component, even if it’s written in a different language. Right now, unless a component author is willing to write code in all four Pulumi languages, their component is only able to reach Pulumi users using the same language SDK.

In addition to expanding the library of publicly available components, this work will also enable organizations to write Pulumi components in the right programming language, or languages, for each team and each product. Infrastructure or platform teams will be able to write components in Go and share them with a webapp team using TypeScript, write components in .NET and share them with a machine learning team using Python, and any other combination that suits their business.

The next step in the story is a seamless authoring experience that enables component creators to write, build, and publish multi-language components. That will be in public preview soon, and we’re excited for you to try it out. If you’d like, subscribe to the multi-language components issue for updates.

Next steps

If you haven’t yet, try out the new pulumi-eks package with this walkthrough.

Announcing Cross-Language Enum Support

Komal Ali — Tue, 15 Dec 2020 00:00:00 +0000

Here at Pulumi, we believe in leveraging the best features of programming languages to create a delightful development experience for our users. Today, we continue our contributions in this area by announcing cross-language support for enum types in our provider SDKs, available in all Pulumi languages - Python, TypeScript, .NET and Go.

Enum types explained

An enum (short for enumerated) type is a data type consisting of a set of named values. In the Pulumi resource model, a property is an enum type when its value can only be set to a finite number of predetermined values.

For instance, consider a simple S3 bucket.

import * as pulumi from "@pulumi/pulumi";
import { s3 } from "@pulumi/aws";

const myBucket = new s3.Bucket("myBucket", { acl: "private" });

import pulumi
from pulumi_aws import s3

my_bucket = s3.Bucket("myBucket", acl="private")

using Pulumi;
using S3 = Pulumi.Aws.S3;

class MyStack : Stack
{
 public MyStack()
 {
 var myBucket = new S3.Bucket("myBucket", new S3.BucketArgs
 {
 Acl = "private",
 });
 }
}

package main

import (
 "github.com/pulumi/pulumi-aws/sdk/v3/go/aws/s3"
 "github.com/pulumi/pulumi/sdk/v2/go/pulumi"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 myBucket, err := s3.NewBucket(ctx, "myBucket", &s3.BucketArgs{
 Acl: pulumi.String("private"),
 })
 if err != nil {
 return err
 }
 return nil
 })
}

In the above code, the S3 Bucket resource has a property called acl, where we pass in the string private to indicate that this is a private bucket.

If we look at the resource docs, we can see that the acl property can only be set to one of a few different values: private, public-read, public-read-write, aws-exec-read, authenticated-read, and log-delivery-write. The acl property is the perfect candidate for an enum type and is emitted as one, so you can use the following code instead.

import * as pulumi from "@pulumi/pulumi";
import { s3 } from "@pulumi/aws";

const myBucket = new s3.Bucket("myBucket", { acl: s3.CannedAcl.Private });

import pulumi
from pulumi_aws import s3

my_bucket = s3.Bucket("myBucket", acl=s3.CannedAcl.PRIVATE)

using Pulumi;
using S3 = Pulumi.Aws.S3;

class MyStack : Stack
{
 public MyStack()
 {
 var myBucket = new S3.Bucket("myBucket", new S3.BucketArgs
 {
 Acl = S3.CannedAcl.Private,
 });
 }
}

package main

import (
 "github.com/pulumi/pulumi-aws/sdk/v3/go/aws/s3"
 "github.com/pulumi/pulumi/sdk/v2/go/pulumi"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 myBucket, err := s3.NewBucket(ctx, "myBucket", &s3.BucketArgs{
 Acl: s3.CannedAclPrivate,
 })
 if err != nil {
 return err
 }
 return nil
 })
}

IDE Superpowers

Enum properties provide discoverable and normalized constants that can be used in place of raw strings, allowing you to move faster with the added boosts of IDE tooling like type hints and autocomplete.

Using the provided constants, you can avoid referring back to the documentation to remember the valid values and save precious moments in the development cycle that would be lost to debugging errors caused by typos.

Optimized for flexibility

While some properties make sense as “strict” enums (i.e., the input value must be one of the enumerated values), there are times when it would be beneficial to have constants for commonly used values without restricting the input to only those values. We call this second category “relaxed” enums, and we model them a little differently in our SDKs.

“Strict” enums

A property is a “strict” enum when the input value must be one of the enumerated values. In this case, the property type is specified as the enum type.

We will use “strict” enums when we are sure that the enum will include all legal values, such as when a provider is auto-generated from a cloud provider specification (like our Azure-Native or Kubernetes providers).

export class StorageAccount extends pulumi.CustomResource {
 constructor(name: string, args: StorageAccountArgs, opts?: pulumi.CustomResourceOptions) {...}
}

export interface StorageAccountArgs {
 readonly accessTier?: pulumi.Input<enums.storage.latest.AccessTier>;
 ...
}

class StorageAccount(pulumi.CustomResource):
 def __init__(__self__,
 resource_name: str,
 access_tier: Optional[pulumi.Input['AccessTier']] = None,
 ...):
 ...

namespace Pulumi.AzureNative.Storage
{
 public partial class StorageAccount : Pulumi.CustomResource
 {
 public StorageAccount(string name, StorageAccountArgs args, ...)
 {
 }
 }

 public sealed class StorageAccountArgs : Pulumi.ResourceArgs
 {
 [Input("accessTier")]
 public Input<Pulumi.AzureNative.Storage.AccessTier>? AccessTier { get; set; }

 ...
 }
}

func NewStorageAccount(ctx *pulumi.Context,
name string, args *StorageAccountArgs, ...) (*StorageAccount, error) {
 ...
}

type StorageAccountArgs struct {
 AccessTier AccessTier
 ...
}

When using TypeScript, “strict” enums will accept both the constant (AccessTier.Cool) or the literal string ("Cool"). If there is an accidental spelling error in the literal, you are immediately alerted to the issue rather than having to wait until runtime.

“Relaxed” enums

When a property is a “relaxed” enum, the property type is specified as the Union of the enum type and the underlying primitive type. This means that you have the convenience of using the enum constants (i.e., s3.CannedAcl.Private), but you may also pass in the raw string (i.e., "private").

In the AWS provider (and other Terraform-based providers), we have opted for only using “relaxed” enums. The reasoning is twofold. Allowing the primitive type maintains backward compatibility and also allows users to use values that may not yet be represented in the Pulumi schema (e.g., a new Managed Policy ARN, EC2 Instance type, etc.).

export class Bucket extends pulumi.CustomResource {
 constructor(name: string, args?: BucketArgs, opts?: pulumi.CustomResourceOptions) {...}
}

export interface BucketArgs {
 readonly acl?: pulumi.Input<string | enums.s3.CannedAcl>;
 ...
}

class Bucket(pulumi.CustomResource):
 def __init__(__self__,
 resource_name: str,
 acl: Optional[pulumi.Input[Union[str, 'CannedAcl']]] = None,
 ...):
 ...

namespace Pulumi.Aws.S3
{
 public partial class Bucket : Pulumi.CustomResource
 {
 public Bucket(string name, BucketArgs? args = null, ...)
 {
 }
 }

 public sealed class BucketArgs : Pulumi.ResourceArgs
 {
 [Input("acl")]
 public InputUnion<string, Pulumi.Aws.S3.CannedAcl>? Acl { get; set; }

 ...
 }
}

func NewBucket(ctx *pulumi.Context,
name string, args *BucketArgs, ...) (*Bucket, error) {
 ...
}

// In Go, relaxed enums retain the type of the underlying primitive.
// However, the CannedAcl constants may still be passed in, as they are
// of the same underlying type.
type BucketArgs struct {
 Acl pulumi.StringPtrInput
 ...
}

Try them out!

You can find enum types integrated into v3.19.0 of the AWS provider and v0.7.1 of the Azure-Native provider, and we will be adding enums to other providers in the coming weeks and months.

Azure-Native: In the native Azure provider, all properties labeled as enums in the OpenAPI spec are represented as such. In all, there are over 1300 enums provided in the SDKs. The native Azure provider uses both “strict” and “relaxed” enums since the OpenAPI specification explicitly defines its properties as such.

AWS: The AWS provider enums are manually identified and maintained as part of the provider schema. We’ve already added many that you might find useful, such as Lambda Runtimes, EC2 Instance Types, and IAM Managed Policies, and will continue to add more in the coming months.

Take the new providers for a spin and let us know what you think in the Community Slack! If there are properties that you would like to see represented as enums, let us know. Or even better, submit a PR like this one to add them to the schema!

Deploy a Serverless RabbitMQ Cluster on Azure with .NET

Itay Podhajcer — Thu, 16 Jul 2020 00:00:00 +0000

Itay Podhajcer is Chief Architect at Velocity Career Labs and a highly experienced software development and technology professional, consultant, architect & project manager. He shared his article on building an Azure serverless cluster for deploying RabbitMQ with C#. The original article was published here.

Pulumi, an open source cloud development platform that supports multiple languages and platforms, allows programming and managing cloud environments using a consistent model and the power of full programming languages.

One of those supported languages is C#, which we will be using to deploy a geo-redundant serverless cluster of the well-known messaging solution RabbitMQ. To run the cluster, we will be using three regions, in which we will be deploying:

Two peered virtual networks, one internal for the containers, and one external for connecting to the other regions. Two networks are required because (at least at the writing of this article) Azure Container Instances only support one peered network, so to overcome that, we will be peering the network with the containers with an additional network in the region, which in turn, connects with the external networks from the other regions.
A RabbitMQ node using Azure Container Instances that will be deployed in the internal virtual network.
An Azure Firewall, which will be deployed in the external virtual network, acting as a network virtual appliance (NVA) with rules for forwarding traffic between the internal node and the other regions.
Route tables with routes that will enable the inter-network transfer of data.
A storage account with file shares for maintaining the node’s state.

Additionally, as we will be using RabbitMQ’s DNS based cluster peer discovery mechanism, we will also be deploying at the global level:

DNS zone for the node’s A records and the discovery record required by RabbitMQ.
A reverse DNS zone for the PTR records of the nodes required by RabbitMQ.

Geo-redundant serverless RabbitMQ cluster

Prerequisites

As we will be using Pulumi for .NET to deploy to Azure, we will need the following installed on our workstation:

Azure CLI: installation guide is available here.
.N ET Core SDK: download is available here.
Pulumi: installation guide is available here.

Example Repository

The complete example of deploying the RabbitMQ cluster can be downloaded or cloned for the following GitHub repository:

When running pulumi up you will be asked to create a stack (you can use whatever you here like Example) and set a passphrase (you can leave it empty and press enter as there are no stored secrets in this stack).

Setup the Project

After all the required tools are installed, we can start by creating the empty Pulumi project running pulumi new azure-csharp inside an empty folder. Set a name for the project (like Example), a description (like RabbitMQ Serverless Cluster), a stack name (like Example), a passphrase (you can use an empty one and just press enter as we won’t be storing secrets in the stack) and an Azure location (just use the default).

Now that we have an initial project, we will also add the Pulumi.Random package to the project by running the command dotnet add package Pulumi.Random, as we will be using it to generate the cluster sec, And rename the MyStack class and file to ExampleStack (it also needs to be changed inside Program.cs which holds the code that triggers the deployment of the stack).

Lastly, we call dotnet restore to also download the Pulumi.Azure package that was included in the project when it was created.

Writing the Stack

We will start by defining a few constants, the constructor, an empty method called Stack(), which will be called by the constructor to start creating the resources and a property named Cookie, which will hold the cluster’s secret, decorated with the Output attribute to let Pulumi know that the value needs to be printed out once the deployment is complete:

Now that we have our initial class, we can start writing methods for the resources we will be creating:

Resource groups:
Private DNS zone:

Private reverse DNS zone:

Random string for the RabbitMQ cluster secret:

DNS zone links:

RabbitMQ node container:

Note that we are overriding RabbitMQ docker image’s default command with `{ “/bin/bash”, “-c”, $”(sleep {ContainerStartupDelay} && docker-entrypoint.sh rabbitmq-server) & wait” }` to delay the startup of the container, but still keep it responsive. More on this later.

Container mounted volumes:

Storage accounts:

File shares:

Container ports:

Virtual networks:

Internal virtual network subnets:

Note that we are creating it with the Microsoft.Storage service endpoint to allow access to storage accounts and the Microsoft.ContainerInstance/containerGroups delegation, which is required for deploying containers into virtual networks.

Network profiles, also required for deploying containers into virtual networks:

External virtual network subnets:

Internal and external virtual networks peering:

External virtual network firewalls:

Internal and external virtual networks routing:

RabbitMQ nodes DNS records:

RabbitMQ nodes reverse DNS records:

Reversing the IP address as required by a reverse PTR record:

Firewall IP forwarding rules:

RabbitMQ’s discovery DNS record:

Global peering of the external virtual networks:

Global routes for the virtual networks:

Firewall virtual appliance routes:

Internet outbound routes:

Now that we can create all the necessary resources, it is time to put it all together inside the empty Stack() method we created earlier:

Note that we are using two loops to create the required resources. The first one creates most of the resources (storage, firewall, networks, container, etc.) and the second one creates the DNS A records of the nodes. The second loop combined with the custom container startup command helps us ensure that the nodes will start without failing only when the entire infrastructure is ready.

This workaround is required because (at the writing of the article) Azure Container Instances do not allow manual allocation of private IP address, and because RabibtMQ’s discovery record requires those IPs which are available only after the containers are created, we end up in a chicken-and-the-egg situation. To overcome that, we need to allow the containers to start, but delay the execution of RabbitMQ’s startup script without blocking the container and use to our advantage the fact that RabbitMQ doesn’t start when it can‘t resolve its own hostname (that is why we create those DNS records last).

Deploying the Stack

Once the script is complete, we can call pulumi up --yes to deploy it, where the --yes argument just skips the question whether to deploy or not once Pulumi has built the deployment app and discovered all the resources.

Remember that you need to call Azure CLI to login to your subscription, so that Pulumi can execute the deployment. You can call az login to login to the Azure portal in an interactive manner. Checking the Cluster

Checking the Cluster

To check that all nodes have managed to join the cluster we will connect to one of the nodes using az container exec to stream a shell from within that container (see more on the exec command here).

Once the shell is connected, you can call rabbitmqctl cluster_status and you should see all three nodes in the printed information.

Conclusion

The example in this article can be used as a base for a complete solution, which includes additional containers and managed services provided by Azure. Also, the code for deploying the example, in a real-world scenario, would be better split off to smaller files, as looking at all the code in one large file is overwhelming, therefore harder to maintain.

Unit Testing Cloud Deployments with .NET

Mikhail Shilkov — Thu, 21 May 2020 00:00:00 +0000

Because Pulumi uses general-purpose programming languages to provision cloud resources, you can take advantage of native tools and perform automated tests of your infrastructure. The full power of each language is available, including access to libraries and frameworks for testing.

This blog post takes a deeper dive into mock-based unit testing of Pulumi programs written in C# and F#.

How Unit Testing Works in Pulumi

Let’s start with a picture showing how Pulumi components interact during a typical deployment process.

Whenever a new resource is instantiated in code, the program makes a remote call to the engine. The engine receives the resource’s input values, validates them, and translates the request to an invocation of a cloud API. The API returns some data, which are translated to resource outputs and sent back to the program.

The remote calls may be slow, unreliable, and non-deterministic, which makes testing of these interactions hard.

Our testing guide outlines several testing methods, but today I want to focus on unit testing.

The Pulumi SDK provides a hook to replace all the remote calls with mocks. Mocks run in the same process and can respond immediately with hard-coded or calculated on-the-fly data.

We can write fully deterministic and blazingly fast automated tests as all remote calls and uncertainty are eliminated. There is no cloud to respond to resource creation, so it’s a developer’s responsibility to mimic the cloud behavior with mocks adequately.

This blog post walks you through an example of unit testing and mocking with the .NET SDK.

Define the Base Structure

In this article, I build a program that deploys a static website to Azure. I use TDD to add new tests and deployment components bit-by-bit.

Let’s start with an empty project—go ahead and create a .NET Core Console Application with the .NET CLI or your favorite IDE.

Install NuGet packages

You are free to choose your unit testing frameworks, mocking and assertions libraries. I’m using NUnit with FluentAssertions, and my program tests Azure resources, so this is my project file:

<Project Sdk="Microsoft.NET.Sdk">

 <PropertyGroup>
 <OutputType>Exe</OutputType>
 <TargetFramework>netcoreapp3.1</TargetFramework>
 <Nullable>enable</Nullable>
 </PropertyGroup>

 <ItemGroup>
 <PackageReference Include="FluentAssertions" Version="5.10.2" />
 <PackageReference Include="Microsoft.NET.Test.Sdk" Version="16.5.0" />
 <PackageReference Include="NUnit" Version="3.12.0" />
 <PackageReference Include="NUnit3TestAdapter" Version="3.16.1" />
 <PackageReference Include="Pulumi.Azure" Version="3.*" />
 </ItemGroup>

</Project>

<Project Sdk="Microsoft.NET.Sdk">

 <PropertyGroup>
 <OutputType>Exe</OutputType>
 <TargetFramework>netcoreapp3.1</TargetFramework>
 <Nullable>enable</Nullable>
 </PropertyGroup>

 <ItemGroup>
 <PackageReference Include="FluentAssertions" Version="5.10.2" />
 <PackageReference Include="Microsoft.NET.Test.Sdk" Version="16.5.0" />
 <PackageReference Include="NUnit" Version="3.12.0" />
 <PackageReference Include="NUnit3TestAdapter" Version="3.16.1" />
 <PackageReference Include="Pulumi.Azure" Version="3.*" />
 <PackageReference Include="Pulumi.FSharp" Version="2.*" />
 </ItemGroup>

 <ItemGroup>
 <Compile Include="Testing.fs" />
 <Compile Include="WebsiteStack.fs" />
 <Compile Include="WebsiteStackTests.fs" />
 </ItemGroup>

</Project>

Stack

A Pulumi stack is the “unit” of our testing. Every test instantiates a stack, retrieves the resources that the stack defines, and makes assertions about them.

Here is my starting point in WebsiteStack file:

using System.IO;
using Pulumi;
using Pulumi.Azure.Core;
using Storage = Pulumi.Azure.Storage;

public class WebsiteStack : Stack
{
 public WebsiteStack()
 {
 // <-- Cloud resources go here
 }
}

namespace UnitTesting

open Pulumi
open Pulumi.FSharp
open Pulumi.Azure.Core

type WebsiteStack() =
 inherit Stack()

 // <-- Cloud resources go here

This class is precisely what Pulumi expects to start deploying your resources to the cloud. Once the test suite is ready and green, you can deploy the stack with pulumi up.

Mocks

As I explained above, unit tests replace the real Pulumi engine with mocks. Mocks get all calls and respond with predefined values.

A mock class has to implement two methods of Pulumi.Testing.IMocks interface. NewResourceAsync is called whenever a new resource is defined, while CallAsync is invoked when our program retrieves information about existing cloud resources. We’ll focus on the former in this post, but we still need to define both.

While you are free to use your favorite mocking library, I’ll keep it simple and define the mocks as a plain class.

using System.Collections.Immutable;
using System.Threading.Tasks;
using Pulumi;
using Pulumi.Testing;

namespace UnitTesting
{
 class Mocks : IMocks
 {
 public Task<(string id, object state)> NewResourceAsync(
 string type, string name, ImmutableDictionary<string, object> inputs, string? provider, string? id)
 {
 var outputs = ImmutableDictionary.CreateBuilder<string, object>();

 // Forward all input parameters as resource outputs, so that we could test them.
 outputs.AddRange(inputs);

 // <-- We'll customize the mocks here

 // Default the resource ID to `{name}_id`.
 id ??= $"{name}_id";
 return Task.FromResult((id, (object)outputs));
 }

 public Task<object> CallAsync(string token, ImmutableDictionary<string, object> inputs, string? provider)
 {
 // We don't use this method in this particular test suite.
 // Default to returning whatever we got as input.
 return Task.FromResult((object)inputs);
 }
 }
}

namespace UnitTesting

open System
open System.Collections.Immutable
open System.Threading.Tasks
open Pulumi.Testing

type Mocks() =
 interface IMocks with
 member this.NewResourceAsync(typeName: string, name: string, inputs: ImmutableDictionary<string, obj>, provider: string, id: string): Task<ValueTuple<string,obj>> =
 // Forward all input parameters as resource outputs, so that we could test them.
 let dict = inputs.ToImmutableDictionary() :> obj

 // <-- We'll customize the mocks here

 // Default the resource ID to `{name}_id`.
 let id = if id = null then sprintf "%s_id" name else id
 Task.FromResult(struct (id, outputs :> obj))

 member this.CallAsync(token: string, inputs: ImmutableDictionary<string, obj>, provider: string): Task<obj> =
 // We don't use this method in this particular test suite.
 // Default to returning whatever we got as input.
 Task.FromResult(null :> obj)

Both methods receive several parameters and need to return a result. Notably, they get the list of inputs—the arguments that our program defined for the given resource. The goal of the mocks is to return the list of outputs, similarly to what a cloud provider would do.

My default implementation returns the outputs that include all the inputs and nothing else. That’s a sensible default: usually, real outputs are a superset of inputs. We’ll extend this behavior as we need later on.

Test Fixture

The next class to add is the container for my future unit tests. I named the file WebsiteStackTests.cs and it defines a test container, called a “test fixture” in NUnit:

using System.Linq;
using System.Threading.Tasks;
using FluentAssertions;
using NUnit.Framework;
using Pulumi;
using Pulumi.Azure.Core;
using Storage = Pulumi.Azure.Storage;

namespace UnitTesting
{
 [TestFixture]
 public class WebserverStackTests
 {
 // <-- Tests go here

 private static Task<ImmutableArray<Resource>> TestAsync()
 {
 return Deployment.TestAsync<WebsiteStack>(new Mocks(), new TestOptions {IsPreview = false});
 }
 }
}

namespace UnitTesting

open System
open System.Collections.Immutable
open System.Threading.Tasks
open NUnit.Framework
open FluentAssertions
open Pulumi
open Pulumi.Azure.Core
open Pulumi.Azure.Storage
open Pulumi.Testing

[<TestFixture>]
type WebserverStackTests() =
 let runTest(): ImmutableArray<Resource> =
 let options = new TestOptions(IsPreview = Nullable<bool> false)
 Deployment.TestAsync<WebsiteStack>(new Mocks(), options)
 |> Async.AwaitTask
 |> Async.RunSynchronously

 // <-- Tests go here

I defined a helper method TestAsync that points Pulumi’s Deployment.TestAsync to our stack and mock classes.

As we progress through the article, I will add tests to this class one-by-one.

Retrieve output values

Finally, I need a small extension method to extract values from outputs. Every Pulumi resource returns values wrapped inside an Output<T> container. While the real engine runs, those values may be known or unknown, but my mock-based tests always return known values. It’s safe to get those values and convert them to a Task<T>:

public static class TestingExtensions
{
 public static Task<T> GetValueAsync<T>(this Output<T> output)
 {
 var tcs = new TaskCompletionSource<T>();
 output.Apply(v => { tcs.SetResult(v); return v; });
 return tcs.Task;
 }
}

let getValue(output: Output<'a>): 'a =
 let tcs = new TaskCompletionSource<'a>()
 output.Apply(fun v -> tcs.SetResult(v); v) |> ignore
 tcs.Task.Result

To learn more about outputs, read this article.

First Test

The setup is done, time to write my first unit test! True to the TDD spirit, I write the tests before I define any resources.

Every Azure resource has to live inside a resource group, so my first test checks that a new resource group is defined.

[Test]
public async Task SingleResourceGroupExists()
{
 var resources = await TestAsync();

 var resourceGroups = resources.OfType<ResourceGroup>().ToList();
 resourceGroups.Count.Should().Be(1, "a single resource group is expected");
}

[<Test>]
member this.SingleResourceGroupExists() =
 let resources = runTest()

 let resourceGroupCount = resources.OfType<ResourceGroup>() |> Seq.length
 resourceGroupCount.Should().Be(1, "a single resource group is expected") |> ignore

This code is great to illustrate the overall structure of each test:

Call the TestAsync method to evaluate the stack.
Find the target resource in the collection of created resources.
Assert a property of the target resource.

In this case, the test validates that there is one and only one resource group defined.

I can run dotnet test and see the expected test failure:

$ dotnet test
...
X SingleResourceGroupExists [238ms]
Error Message:
Expected resourceGroups.Count to be 1 because a single resource group is expected, but found 0.
...
Total tests: 1
Failed: 1
Total time: 0.9270 Seconds

I go ahead and add the following definition to the WebsiteStack constructor.

var resourceGroup = new ResourceGroup("www-prod-rg");

let resourceGroup = new ResourceGroup("www-prod-rg")

This change is enough to make the tests green!

$ dotnet test
...
Test Run Successful.
Total tests: 1
Passed: 1
Total time: 0.8462 Seconds

Storage Account

It’s time to add a test for a second resource in the stack: a Storage Account. To make things more interesting, I want to check that the storage account belongs to our resource group.

There’s no direct link between a storage account object and a resource group object. Instead, we need to check the ResourceGroupName property of the account. The test below expects the account to belong to a resource group called www-prod-rg.

[Test]
public async Task StorageAccountBelongsToResourceGroup()
{
 var resources = await TestAsync();
 var storageAccount = resources.OfType<Storage.Account>().SingleOrDefault();
 storageAccount.Should().NotBeNull("Storage account not found");

 var resourceGroupName = await storageAccount.ResourceGroupName.GetValueAsync();
 resourceGroupName.Should().Be("www-prod-rg");
}

[<Test>]
member this.StorageAccountBelongsToResourceGroup() =
 let resources = runTest()
 let storageAccount = resources.OfType<Account>() |> Seq.tryHead |> Option.toObj
 storageAccount.Should().NotBeNull("Storage account not found") |> ignore

 let resourceGroupName = getValue storageAccount.ResourceGroupName
 resourceGroupName.Should().Be("www-prod-rg", null) |> ignore

Of course, the test fails. I try to fix it with what I think is the minimal change to make the test pass by adding a new resource to the stack and pointing it to the resource group.

var storageAccount = new Storage.Account("wwwprodsa", new Storage.AccountArgs
{
 ResourceGroupName = resourceGroup.Name,
});

let storageAccount =
 new Account(
 "wwwprodsa",
 new AccountArgs(ResourceGroupName = io resourceGroup.Name))

However, when I rerun the test suite, all three tests fail. They complain about the missing required properties AccountReplicationType and AccountTier on the storage account, so I have to add those.

var storageAccount = new Storage.Account("wwwprodsa", new Storage.AccountArgs
{
 ResourceGroupName = resourceGroup.Name,
 AccountTier = "Standard",
 AccountReplicationType = "LRS",
 StaticWebsite = new Storage.Inputs.AccountStaticWebsiteArgs
 {
 IndexDocument = "index.html"
 }
});

let storageAccount =
 new Account(
 "wwwprodsa",
 new AccountArgs(
 ResourceGroupName = io resourceGroup.Name,
 AccountTier = input "Standard",
 AccountReplicationType = input "LRS",
 StaticWebsite = input (new AccountStaticWebsiteArgs(IndexDocument = input "index.html"))))

I defined the StaticWebsite property as well: I’ll leave testing these values as an exercise for the reader.

Two resource group tests are back to green again, but the storage account test fails with a new error message.

X StorageAccountBelongsToResourceGroup [84ms]
Error Message:
Expected resourceGroupName to be "www-prod-rg", but found <null>.

What’s going on, and why is it null?

I defined the account name like this: ResourceGroupName = resourceGroup.Name. However, if we look closely, the resourceGroup resource doesn’t have an input property Name defined. www-prod-rg is a logical name for Pulumi deployment, not the physical name of the resource.

Under normal circumstances, the Pulumi engine would use the logical name to produce the physical name of the resource group automatically (see resource names for details). However, my mocks don’t do that.

That’s a good reason to change the Mocks implementation. I add the following lines to the NewResourceAsync method.

// Set the name to resource name if it's not set explicitly in inputs.
if (!inputs.ContainsKey("name"))
 outputs.Add("name", name);

let inputKVs = inputs |> Seq.map(fun kv -> kv.Key, kv.Value) |> Seq.toList
let nameKVs = if inputs.ContainsKey("name") then [] else [("name", name :> obj)]

let outputs = [inputKVs; nameKVs] |> Seq.concat |> Seq.map KeyValuePair
let dict = outputs.ToImmutableDictionary() :> obj

Note that mocks operate on weakly-typed dictionaries, so I need to get the property name right. Pulumi SDKs are open source, so I looked here to double-check the exact value.

After this change in Mocks, my tests go green again.

Test Run Successful.
Total tests: 3
Passed: 3

Website Files

The next step is to upload some files to the static website. Well, instead, to write an automated test that validates the upload with mocks.

I create a wwwroot folder with two HTML files in it and copy the folder to the build’s output. Here is my change in the project file.

<ItemGroup>
 <None Update="wwwroot\**\*.*">
 <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
 </None>
</ItemGroup>

Now, the test is straightforward: it expects two Blob resources in the stack.

[Test]
public async Task UploadsTwoFiles()
{
 var resources = await TestAsync();
 var files = resources.OfType<Storage.Blob>().ToList();
 files.Count.Should().Be(2, "Should have uploaded files from `wwwroot`");
}

[<Test>]
member this.UploadsTwoFiles() =
 let resources = runTest()
 let filesCount = resources.OfType<Blob>() |> Seq.length
 filesCount.Should().Be(2, "Should have uploaded files from `wwwroot`") |> ignore

As intended, the test fails immediately.

X UploadsTwoFiles [95ms]
Error Message:
Expected files.Count to be 2 because Should have uploaded files from `wwwroot`, but found 0.

I extend my stack with the following loop that navigates through the files and creates a storage blob for each of them.

var files = Directory.GetFiles("wwwroot");
foreach (var file in files)
{
 var blob = new Storage.Blob(file, new Storage.BlobArgs
 {
 ContentType = "application/html",
 Source = new FileAsset(file),
 StorageAccountName = storageAccount.Name,
 StorageContainerName = "$web",
 Type = "Block"
 });
}

let files =
 let fileNames = Directory.GetFiles("wwwroot")
 fileNames
 |> Seq.map(fun file ->
 new Blob(
 file,
 new BlobArgs(
 ContentType = input "application/html",
 Source = input (new FileAsset(file) :> AssetOrArchive),
 StorageAccountName = io storageAccount.Name,
 StorageContainerName = input "$web",
 Type = input "Block")))
 |> List.ofSeq

However, this change breaks the stack and all tests in the suite:

Error Message:
Pulumi.RunException : Running program failed with an unhandled exception:
System.InvalidOperationException: Unsupported value when converting to protobuf: Pulumi.FileAsset
at Pulumi.Serialization.Serializer.CreateValue(Object value)
...

Once again, our mocks fail to represent the behavior of the engine accurately. The Pulumi engine knows about the FileAsset class pointing to a file on the disk and how to convert it to an uploaded blob. But, the engine doesn’t copy this property to outputs. I need to adjust the mocks again.

I’m not particularly interested in testing the binary contents of the files now, so I’ll change the Mocks class to ignore the source property and not to include it into the output dictionary.

if (type == "azure:storage/blob:Blob")
{
 // Assets can't directly go through the engine.
 // We don't need them in the test, so blank out the property for now.
 outputs.Remove("source");
}

let outputs =
 [inputKVs; nameKVs]
 |> Seq.concat
 |> Seq.filter (fun (k, _) -> typeName <> "azure:storage/blob:Blob" || k <> "source")
 |> Seq.map KeyValuePair

This change makes my test suite happy again.

Test Run Successful.
Total tests: 4
Passed: 4

Validate Website URL

So far, I’ve been validating the input parameters of resources. What if I want to test something that is usually done by the cloud provider?

For instance, when Azure creates a static website, it automatically assigns a public endpoint. The endpoint is then available in the PrimaryWebEndpoint property after the Pulumi program ran and resources are created. I may want to export this value from stack outputs and validate it in a unit test.

[Test]
public async Task StackExportsWebsiteUrl()
{
 var resources = await TestAsync();
 var stack = resources.OfType<WebsiteStack>().First();

 var endpoint = await stack.Endpoint.GetValueAsync();
 endpoint.Should().Be("https://wwwprodsa.web.core.windows.net");
}

[<Test>]
member this.StackExportsWebsiteUrl() =
 let resources = runTest()
 let stack = resources.OfType<WebsiteStack>() |> Seq.head

 let endpoint = getValue stack.Endpoint
 endpoint.Should().Be("https://wwwprodsa.web.core.windows.net", null) |> ignore

This test doesn’t even compile yet, so I have to define the Endpoint property and assign a value to it. Here is the complete implementation of the stack with the output property defined at the end.

public class WebsiteStack : Stack
{
 public WebsiteStack()
 {
 var resourceGroup = new ResourceGroup("www-prod-rg", new ResourceGroupArgs
 {
 Tags = { { "Environment", "production" } }
 });

 var storageAccount = new Storage.Account("wwwprodsa", new Storage.AccountArgs
 {
 ResourceGroupName = resourceGroup.Name,
 AccountTier = "Standard",
 AccountReplicationType = "LRS",
 StaticWebsite = new Storage.Inputs.AccountStaticWebsiteArgs
 {
 IndexDocument = "index.html"
 }
 });

 var files = Directory.GetFiles("wwwroot");
 foreach (var file in files)
 {
 var blob = new Storage.Blob(file, new Storage.BlobArgs
 {
 ContentType = "application/html",
 Source = new FileAsset(file),
 StorageAccountName = storageAccount.Name,
 StorageContainerName = "$web",
 Type = "Block"
 });
 }

 this.Endpoint = storageAccount.PrimaryWebEndpoint;
 }

 [Output] public Output<string> Endpoint { get; set; }
}

type WebsiteStack() =
 inherit Stack()

 let resourceGroup =
 new ResourceGroup(
 "www-prod-rg",
 new ResourceGroupArgs(Tags = inputMap(["Environment", input "production"])))

 let storageAccount =
 new Account(
 "wwwprodsa",
 new AccountArgs(
 ResourceGroupName = io resourceGroup.Name,
 AccountTier = input "Standard",
 AccountReplicationType = input "LRS",
 StaticWebsite = input (new AccountStaticWebsiteArgs(IndexDocument = input "index.html"))))

 let files =
 let fileNames = Directory.GetFiles("wwwroot")
 fileNames
 |> Seq.map(fun file ->
 new Blob(
 file,
 new BlobArgs(
 ContentType = input "application/html",
 Source = input (new FileAsset(file) :> AssetOrArchive),
 StorageAccountName = io storageAccount.Name,
 StorageContainerName = input "$web",
 Type = input "Block")))
 |> List.ofSeq

 [<Output>]
 member val Endpoint = storageAccount.PrimaryWebEndpoint with get, set

Now, the test compiles but fails when executed:

X StackExportsWebsiteUrl [85ms]
Error Message:
Expected endpoint to be "https://wwwprodsa.web.core.windows.net", but found <null>.

That’s because there is no call to Azure to populate the endpoint. It’s time to make the last change to my Mocks class to emulate that assignment.

// For a Storage Account...
if (type == "azure:storage/account:Account")
{
 // ... set its web endpoint property.
 // Normally this would be calculated by Azure, so we have to mock it.
 outputs.Add("primaryWebEndpoint", $"https://{name}.web.core.windows.net");
}

let endpointKVs =
 if typeName = "azure:storage/account:Account"
 then ["primaryWebEndpoint", sprintf "https://%s.web.core.windows.net" name :> obj]
 else []

let outputs =
 [inputKVs; nameKVs; endpointKVs]
// ...

And that’s it! My static website is ready and tested!

Test Run Successful.
Total tests: 5
Passed: 5
Total time: 0.9338 Seconds

Note that it still takes less than a second to run my test suite so that I can iterate very quickly.

Get Started

The tests above cover the basics of unit testing with Pulumi .NET SDK. You can take it from here and apply the techniques and practices that you use while testing the application code. You may also try more advanced practices like property-based testing or behavior-driven development—we believe that the mocks enable many testing styles.

Here are several useful pointers to get started with testing in Pulumi:

Testing Guide
Full code for this blog post: C#, F#.
Another example of unit testing in C#

Managing Kubernetes Infrastructure with .NET and Pulumi

Luke Hoban — Tue, 10 Dec 2019 00:00:00 +0000

Last month, we announced .NET support for Pulumi, including support for AWS, Azure, GCP, and many other clouds. One of the biggest questions we heard was about Kubernetes — “can I use Pulumi to manage Kubernetes infrastructure in C#, F#, and VB.NET as I can already in TypeScript and Python today?” With last week’s release of Pulumi.Kubernetes on NuGet, you can now also deploy Kubernetes infrastructure using your favorite .NET languages.

Using .NET to build our Kubernetes infrastructure offers several benefits:

Strong Typing: Unlike YAML, C# and F# offer a rich type system with quick feedback on potential errors.
Rich IDE Support: Use the rich features of IDEs like Visual Studio, Visual Studio Code, and Rider to develop your Kubernetes infrastructure—completion lists, refactoring, IntelliSense, and more.
Familiar Languages and APIs: Apply all the features of C#, F#, and VB.NET to your Kubernetes infrastructure—loops, variables, and the entire ecosystem of .NET Core libraries from System to everything in NuGet.
Components and Classes: Instead of copy/pasting pages of YAML between projects, .NET code can abstract common functionality into classes and libraries for code re-use and clean infrastructure design.

Together, these benefits provide a more familiar experience for working with Kubernetes than using YAML or Helm (a mix of YAML and Go templates) for .NET developers.

Tour of Kubernetes with .NET

We can see a simple example in practice - deploying an Nginx pod into a Kubernetes cluster.

var pod = new Pod("pod", new PodArgs
{
 Spec = new PodSpecArgs
 {
 Containers =
 {
 new ContainerArgs
 {
 Name = "nginx",
 Image = "nginx",
 },
 },
 },
});

We can deploy this with pulumi up.

$ pulumi up
Previewing update (luke-dev):
Type Name Plan
+ pulumi:pulumi:Stack basic_dotnet_kubernetes-luke-dev create
+ └─ kubernetes:core:Pod pod create
Resources:
+ 2 to create
Do you want to perform this update? yes
Updating (luke-dev):
Type Name Status
+ pulumi:pulumi:Stack basic_dotnet_kubernetes-luke-dev created
+ └─ kubernetes:core:Pod pod created
Resources:
+ 2 created
Duration: 11s

As always, Pulumi programs describe the desired state of our infrastructure, instead of an imperative process to construct that infrastructure. If we change our program, Pulumi will compute the minimal delta to apply to our Kubernetes cluster to transition to this new desired state. This almost feels like using Edit-and-Continue on our deployed Kubernetes resources—modifying our Kubernetes resources in place inside the cluster.

We can add a label to our Pod:

 var pod = new Pod("pod", new PodArgs
 {
+ Metadata = new ObjectMetaArgs
+ {
+ Labels = { { "app", "nginx" } },
+ },
 Spec = new PodSpecArgs
 {
 Containers =
 {
 new ContainerArgs
 {
 Name = "nginx",
 Image = "nginx",
 },
 },
 },
});

And then see that this updates the pod in place with this new label.

$ pulumi up
Previewing update (luke-dev):
Type Name Plan Info
pulumi:pulumi:Stack basic_dotnet_kubernetes-luke-dev
~ └─ kubernetes:core:Pod pod update [diff: ~metadata]
Resources:
~ 1 to update
1 unchanged
Do you want to perform this update? details
pulumi:pulumi:Stack: (same)
[urn=urn:pulumi:luke-dev::basic_dotnet_kubernetes::pulumi:pulumi:Stack::basic_dotnet_kubernetes-luke-dev]
~ kubernetes:core/v1:Pod: (update)
[id=default/pod-wyjq31t3]
[urn=urn:pulumi:luke-dev::basic_dotnet_kubernetes::kubernetes:core/v1:Pod::pod]
[provider=urn:pulumi:luke-dev::basic_dotnet_kubernetes::pulumi:providers:kubernetes::default_1_4_0::127c0c24-8b12-4010-a544-5f5390f91e4e]
~ metadata: {
~ labels: {
+ app: "nginx"
}
}
Do you want to perform this update? yes
Updating (luke-dev):
Type Name Status Info
pulumi:pulumi:Stack basic_dotnet_kubernetes-luke-dev
~ └─ kubernetes:core:Pod pod updated [diff: ~metadata]
Resources:
~ 1 updated
1 unchanged
Duration: 3s

The real benefits of .NET come when we extract common code into a reusable component. We can do that to create a new component like a ServiceDeployment, which includes both a Kubernetes Service and Deployment using opinionated defaults. With this, we can describe entire Kubernetes applications (100s of lines of YAML), in a short and semantically meaningful snippet of C#:

var config = new Config();
var isMiniKube = config.GetBoolean("isMiniKube") ?? false;

var redisMaster = new ServiceDeployment("redis-master", new ServiceDeploymentArgs
{
 Image = "k8s.gcr.io/redis:e2e",
 Ports = { 6379 },
});

var redisReplica = new ServiceDeployment("redis-slave", new ServiceDeploymentArgs
{
 Image = "gcr.io/google_samples/gb-redisslave:v1",
 Ports = { 6379 },
});

var frontend = new ServiceDeployment("frontend", new ServiceDeploymentArgs
{
 Replicas = 3,
 Image = "gcr.io/google-samples/gb-frontend:v4",
 Ports = { 80 },
 AllocateIPAddress = true,
 ServiceType = isMiniKube ? "ClusterIP" : "LoadBalancer",
});

return new Dictionary<string, object?>{
 { "frontendIp", frontend.IpAddress },
};

You can check out the implementation of this ServiceDeployment component in the Guestbook example in the Pulumi Examples repo on GitHub.

Building Docker Images for Kubernetes with .NET

In the examples so far, we have specified the Docker image to deploy as part of our Kubernetes Deployments by referring to an image already in the DockerHub or Google Container Registry. But what if we wanted to push our own custom Docker image built from our own application’s source code, and use that in our Kubernetes Pod or Deployment? This is easy to do as well with the Pulumi.Docker package. For example, we can deploy a customized Docker image derived from Nginx with the following:

var image = new Image("nginx", new ImageArgs
{
 ImageName = "my-username/my-nginx",
 Build = "./app",
});

var pod = new Pod("pod", new PodArgs
{
 Spec = new PodSpecArgs
 {
 Containers =
 {
 new ContainerArgs
 {
 Name = "nginx",
 Image = image.ImageName,
 },
 },
 },
});

Instead of using the default nginx image on DockerHub, we can use our own Dockerfile from the app folder in our Pulumi project, for instance, including the following in our Dockerfile to deploy some customized files in the app/content folder to our Nginx server:

FROM nginx
COPY content /usr/share/nginx/html

When we deploy this with Pulumi, the Docker file will be build locally, pushed to DockerHub, then the image name in DockerHub referenced from the Pod in Kubernetes. All of this happens automatically, allowing you to seamlessly deploy and version both your application code and infrastructure together with a simple pulumi up.

If we wanted to push to another Docker container registry (like ACR, GCR, ECR or others), we can easily do that too using additional parameters on the Pulumi.Docker.ImageArgs class.

Cloud + Kubernetes with .NET

Because Pulumi lets you work with both Kubernetes and cloud (AWS, Azure, GCP, and more), you can also create and manage the infrastructure that builds both a managed Kubernetes cluster as well as deploying applications and services into the cluster. Using a single familiar programming model, we have access to all these various cloud technologies at our fingertips.

For example, we can deploy a managed Kubernetes cluster on DigitalOcean, and then deploy a Pod into it:

var cluster = new KubernetesCluster("do-cluster", new KubernetesClusterArgs
{
 Region = "sfo2",
 Version = "latest",
 NodePool = new KubernetesClusterNodePoolArgs
 {
 Name = "default",
 Size = "s-2vcpu-2gb",
 NodeCount = nodeCount,
 },
});

var k8sProvider = new Pulumi.Kubernetes.Provider("do-k8s", new Pulumi.Kubernetes.ProviderArgs
{
 KubeConfig = cluster.KubeConfigs.Apply(array => array[0].RawConfig)
});

var app = new Pulumi.Kubernetes.Apps.V1.Deployment("do-app-dep", new DeploymentArgs
{
 Spec = new DeploymentSpecArgs
 {
 Selector = new LabelSelectorArgs
 {
 MatchLabels = new InputMap<string>
 {
 {"app", "app-nginx"},
 },
 },
 Replicas = appReplicaCount,
 Template = new PodTemplateSpecArgs
 {
 Metadata = new ObjectMetaArgs
 {
 Labels = new InputMap<string>
 {
 {"app", "app-nginx"},
 },
 },
 Spec = new PodSpecArgs
 {
 Containers = new ContainerArgs()
 {
 Name = "nginx",
 Image = "nginx",
 },
 },
 },
 },
},
new CustomResourceOptions { Provider = k8sProvider });

var appService = new Pulumi.Kubernetes.Core.V1.Service("do-app-svc", new ServiceArgs {
 Spec = new ServiceSpecArgs() {
 Type = "LoadBalancer",
 Selector = app.Spec.Apply(spec => spec.Template.Metadata.Labels),
 Ports = new ServicePortArgs {
 Port = 80,
 }
 }
}, new CustomResourceOptions {
 Provider = k8sProvider
});

var ingressIp = appService.Status.Apply(status => status.LoadBalancer.Ingress[0].Ip);

if (!string.IsNullOrWhiteSpace(domainName)) {
 var domain = new Domain("do-domain", new DomainArgs() {
 Name = domainName,
 IpAddress = ingressIp,
 });

 var cnameRecord = new DnsRecord("do-domain-cname", new DnsRecordArgs {
 Domain = domain.Name,
 Type = "CNAME",
 Name = "www",
 Value = "@",
 });
}

Note that this example deploys resources first into DigitalOcean (a Kubernetes Cluster), then into Kubernetes itself (Deployment and Service via a Pulumi.Kubernetes.Provider configured to connect to the Kubernetes cluster in Digital Ocean), then optionally also more resources in DigitalOcean dependent on the Kubernetes Service (Domain and DnsRecord). This example is a complex infrastructure deployment, all in a few dozen lines of declarative and strongly typed C# code.

Check out the full DigitalOcean Kubernetes Cluster in C# example for more details.

Conclusion

Kubernetes support is one of several significant new additions to the Pulumi .NET support, and many more improvements are in progress over the coming weeks. Get started with Kubernetes and .NET today, and let us know what you think!

Infrastructure as Code with .NET and Pulumi

Sophia Parafina — Wed, 13 Nov 2019 11:23:04 -0600

This post announces .NET Core in preview, which is now fully supported. Pulumi now supports newer .NET versions beyond .NET Core 3.1 mentioned in this article. For the most up-to-date information about using .NET with Pulumi, please see the .NET documentation. With the release of Pulumi for .NET preview, we’ve open the doors to infrastructure as code to even more developers and operators. Millions of .NET developers can now use their favorite languages and open source ecosystems to build modern, cloud native applications. We’ve added support for C#, F#, and Visual Basic. Because .NET Core is available on Windows, Linux, and macOS, you have a choice of platforms to use.

You can create cloud resources by writing Microsoft .NET Core programs to build and deploy cloud resources to a wide variety of clouds, including Azure, AWS, GCP and more. On Azure, you can manage resources like AKS Clusters, Functions, Azure App Services, Virtual Machines, Cosmos DBs, KeyVaults, and much, much more. Let’s take a first look at Pulumi for .NET by deploying an application on Azure.

What Does Pulumi Enable?

With Pulumi, .NET developers can create, deploy and manage cloud infrastructure using C#, F#, or Visual Basic .NET. This results in increased productivity for developers because they can use the features of their IDEs such as auto-completion, error checking with red markers, build error messages, refactoring tools, and package managers. Developers can reference any NuGet library compatible with .NET Core 3.1.

Operators can use the pulumi CLI or CI/CD integrations to maintain and version infrastructure in a repository resulting in predictable and reliable deployments. Regardless of your cloud architecture, whether it includes containers, serverless function or static websites, Pulumi lets you build modern, reliable, and scalable applications. Your pipeline is part of your product.

You can accomplish all of this without having to learn a JSON or YAML DSL or script low-level CLI commands. With Pulumi, developers and operators have a shared foundation for building modern applications.

How Pulumi for .NET Works

Pulumi is declarative even though it uses general purpose programming languages. It does this by specifying a set of resources, and the Pulumi engine orchestrates the CRUD operations to build and deploy infrastructure.

A Pulumi project uses a .NET Core console application to build infrastructure. To illustrate how this is accomplished, let’s create an Azure App Service with an SQL database. The first step is to make sure that your environment meets the prerequisites:

Prerequisites

Get the Examples

Pulumi provides a repository of examples to get you started. Clone the examples from GitHub.

$ git clone https://github.com/pulumi/examples/
$ cd examples/

Create a New Stack

Change the directory to azure-cs-appservice directory

$ cd azure-cs-appservice

There are four files in the Pulumi project, the Azure.Appservice.csproj which sets the .NET SDK and the Pulumi packages for the project. Pulumi.yaml holds project parameters such as name and runtime. The Pulumi.dev.yaml file holds the database password. SharedAccessSignature.cs contains a helper function to generate storage blob access URLs with SAS tokens in them. It demonstrates that you can add custom code inside your Pulumi program. Program.cs is the main program for declaring resources.

Create a new stack:
```
$ pulumi stack init dev
```
Login to Azure CLI (you will be prompted to do this during deployment if you forget this step):
```
$ az login
```
Configure the location to deploy the resources to:
```
$ pulumi config set azure:location centralus
```
Define the SQL Server password (make it complex enough to satisfy Azure policy):
```
pulumi config set --secret sqlPassword <value>
```

Run pulumi up. Pulumi will display a preview of the updates to the stack and ask if you would like to deploy by updating.

$ pulumi up
Previewing changes:
...

Performing changes:
...
info: 10 changes performed:

 + 10 resources created

Update duration: 1m14.59910109s

NOTE:

If you are using a free Azure account, some regions do not allow creating services if they are too busy. You might have to try a different Azure location. You must tear down the stack resources to update the project’s location information.

Test Your Stack

The endpoint is one of the outputs that the stack returns. Check the deployed website endpoint by querying the stack and using curl to retrieve the web page.

$ pulumi stack output endpoint
https://azpulumi-as0ef47193.azurewebsites.net

$ curl "$(pulumi stack output endpoint)"
<html>
 <body>
 <h1>Greetings from Azure App Service!</h1>
 </body>
</html>

From there, feel free to experiment. Simply making edits and running pulumi up will incrementally update your stack. Once finished, tear down your stack’s resources by destroying and removing it:

$ pulumi destroy --yes
$ pulumi stack rm --yes

Code Review

In this post, we’ve shown how to use Pulumi to deploy a modern application to Azure. The example code performs a number of tasks.

First, we created a resource group, a storage account, and an application service plan for our application:

var resourceGroup = new ResourceGroup("appservice-rg");

var storageAccount = new Account("sa", new AccountArgs
{

 ResourceGroupName = resourceGroup.Name,
 AccountReplicationType = "LRS",
 AccountTier = "Standard",

});

var appServicePlan = new Plan("asp", new PlanArgs
{

 ResourceGroupName = resourceGroup.Name,
 Kind = "App",
 Sku = new PlanSkuArgs
 {
 Tier = "Basic",
 Size = "B1",
 },

});

The wwwroot directory containing the index.html page into is added to the storage account we created previously. The SharedAccessSignature.cs code is a helper function to generate storage blob access URLs with SAS tokens. This shows how you can add custom code inside your Pulumi program.

var container = new Container("zips", new ContainerArgs
{
 StorageAccountName = storageAccount.Name,
 ContainerAccessType = "private",
});

var blob = new ZipBlob("zip", new ZipBlobArgs
{
 StorageAccountName = storageAccount.Name,
 StorageContainerName = container.Name,
 Type = "block",
 Content = new FileArchive("wwwroot"),
});

var codeBlobUrl = SharedAccessSignature.SignedBlobReadUrl(blob, storageAccount);

Using the configuration we set with the Pulumi CLI, the program creates a SQL Server deployment.

var config = new Config();
var username = config.Get("sqlAdmin") ?? "pulumi";
var password = config.RequireSecret("sqlPassword");
var sqlServer = new SqlServer("sql", new SqlServerArgs
{
 ResourceGroupName = resourceGroup.Name,
 AdministratorLogin = username,
 AdministratorLoginPassword = password,
 Version = "12.0",
});

var database = new Database("db", new DatabaseArgs
{
 ResourceGroupName = resourceGroup.Name,
 ServerName = sqlServer.Name,
 RequestedServiceObjectiveName = "S0",
});

We deploy the App Service which includes the website and the connection to the SQL Server instance.

var app = new AppService("app", new AppServiceArgs
{
 ResourceGroupName = resourceGroup.Name,
 AppServicePlanId = appServicePlan.Id,
 AppSettings =
 {
 { "WEBSITE_RUN_FROM_PACKAGE", codeBlobUrl },
 },
 ConnectionStrings =
 {
 new AppServiceConnectionStringsArgs
 {
 Name = "db",
 Type = "SQLAzure",
 Value = Output.Tuple<string, string, string>(sqlServer.Name, database.Name, password).Apply(t =>
 {
 (string server, string database, string pwd) = t;
 return $"Server= tcp:{server}.database.windows.net;initial catalog={database};userID={username};password={pwd};Min Pool Size=0;Max Pool Size=30;Persist Security Info=true;";
 }),
 },
 },
});

Summary

In this example, we declared resources for a website and a database using C# and the Pulumi engine deployed them to Azure. To get started with infrastructure as code, download Pulumi to build and deploy modern applications using .NET Core.

Pulumi 💜 .NET Core

Joe Duffy — Mon, 11 Nov 2019 00:00:00 +0000

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.

This is a heartwarming milestone for the entire Pulumi team. It’s no secret that several of our founding members had a hand in shaping the early .NET project over a decade ago. In fact, before leaving Microsoft to found Pulumi, I had the privilege of helping to kick off the .NET Core effort to take .NET open source and add macOS and Linux support alongside Windows. It’s truly wonderful to build on top of this amazing and vibrant ecosystem, and reconnect with old friends!

Please head on over to the .NET blog to read more, or check out our new .NET Core landing page if you can’t wait to dive in.

True to the spirit of Pulumi, our .NET support and the associated libraries are open source on GitHub. We are releasing .NET support in preview first so we can gather feedback over the next few weeks and make sure everything is just right. Join us in our Community Slack — we can’t wait to hear what you think!