Pulumi and .NET Interactive (I)
Tags: csharp, pulumi, dotnet, iac
Published: 2022-09-13 14:06:00

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ba67um1upa05xf1l7xyc.png)

In this post, I will explain how to provision **_Azure Static WebApp_** with .NET Interactive (Visual Studio Code) and Pulumi Automation API. 

In the follow-up post, I will extend the notebook to cover frequent web app dependencies like API app function, custom domains, etc.

I'm using the React _preset_ (with plain _dist_), but you can easily adjust the notebook to other static websites build flavors.

You can download the full notebook [here](https://fsharptours.blob.core.windows.net/notebooks/post.zip).

To run the notebook you need to have a basic knowledge of Pulumi  (CLI must be installed and Pulumi Access Token set)


**About IaC**

Learning Infrastructure as a Code (Pulumi, Terraform, Bicep, Arm templates,...) is an investment. 

As with any code, **IaC** is a liability that we must maintain. Also, the underlying architecture must be clear for each team member who touches it. The decision to use it is not an easy tradeoff.

Often we deploy to the cloud only pretty simple resources. It could be significantly easier to create them via portal and just ... forget. We can think about potential growth and security aspects when it happens. It is all good.

However, IaC is not only about automation (speed & robustness). It is about disaster recovery too. Let's first talk about the subject we do cover.

**Azure Static Web App**

Azure Static WebApp is one of the best options in regards to cost and involved operations to host a web application. It also leverages DevOps well by supporting GitHub actions. 

It means that by creating a resource we also seamlessly run a  workflow to deploy the code from the repository in one shot.

It is a fast process and doing it via portal requires just a few fields:

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/l7ddkjci6f3fvs61c1ac.png)

Of course, to get a more grained set up you have to add proper settings after the provisioning (custom domain, API,...)

So unless our web app is not a part of a wider solution, using the IaC may be overkill for those who need to learn it first.

**Automation Provisioning = Disaster Recovery**

Unfortunately despite all of these static web app benefits, I do often encounter troubles with github actions after the initial application deployment. I'm getting completely unclear messages and in order to apply new code changes (which may be critical) I have to reprovision this Azure resource. 

It is not as easy as it sounds when web app is connected to API or uses networking. Deleting all dependencies may be a burden, especially if we want to keep the same namings.

In such situations, I would like to recreate it by running a program/notebook with a language I know well.

**.NET Interactive & Pulumi Automation API**

With .NET Interactive we can run C# (F#, Powershell, Kusto, SQL) from the notebook which makes the process nice, clean and composable with other actions that we can do earlie or later.

Obviously, Pulumi does not come with .NET Interactive, however to use it we only need to load some nuget packages


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/0kze7iwj2ikuth0pkiaa.png)

While working with Pulumi (or Terraform), I tend to write a code as I would have had many subscriptions in place for each environment (even if I only have one subscription and I start with one environment). It always pays me off later.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xrwixm9wm044b4t14112.png)

Pulumi enables (at least) two ways to name the resources
1) Automated
2) Manual

The first one helps with name conflicts, soft-deletion, zero-downtime deployments (to name a few) but as a side effect produces enigmatic names. It is not always only a personal decision to select proper naming (can be enforced by Enterprise Architectures or so on) however I tend to use the second option.

In order to use it clearly, all my namings are built up similar to:


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/c6snpahpnqpbl5r5pxya.png)


Flaging environment (dev/qa/stage/demo/whatever) can also impact the resources inputs:


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7k4nd3d1sf2g48vopkw2.png)


For Static WebApp we need GitHub credentials which can be kept in a notebook or workspace, depending on where you keep/store the notebook etc.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/yz47jp18xiveu8jobde2.png)

Note that GitHub token should has right to operate on Github workflows

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/dvczwmw74uafum3vk8xu.png)



You also need to configure Pulumi Automation API. It needs some information as it would have been a standard project:

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vug6h25plxanm6i7ftks.png)

Now it is finally a time for the main dish. 
Lets configure Pulumi to create Web App per our needs.



![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/q7nl3dmqbq4zzdg329xg.png)

Lets run the program:


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/of54jucc17gq16ptvwyt.png)

In case you were only playing around , you can delete the resource by:


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/50ne54tvf3xpycfkai14.png)

**Summary**

After reading this post you may consider using .NET Interactive & Pulumi API for your ad-hoc provisioning needs or to enable users of your (open source) project to create needed infrastructure and host a copy of the product.