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.
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:
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
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.
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:
Flaging environment (dev/qa/stage/demo/whatever) can also impact the resources inputs:
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.
Note that GitHub token should has right to operate on Github workflows
You also need to configure Pulumi Automation API. It needs some information as it would have been a standard project:
Now it is finally a time for the main dish.
Lets configure Pulumi to create Web App per our needs.
Lets run the program:
In case you were only playing around , you can delete the resource by:
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.
Top comments (0)