0001

App Service, App Settings, and Container Registry with Managed Identity

Managed Identities in Azure are a wonderful thing. No passwords to change, no keys to rotate. The biggest shame is that frequently they seem to be implemented as an afterthought.

One example I recently ran into was the use of an App Service Managed Identity to pull a container from Azure Container Registry. While you can configure an App Service to pull from ACR with a Managed Identity, what the documentation doesn’t tell you is that you still need the DOCKER_REGISTRY_SERVER_USERNAME and DOCKER_REGISTRY_SERVER_PASSWORD App Settings to be configured on the App Service. It doesn’t matter what values you put in these, the point is they must exist. If they don’t, the container will fail to pull with a credential error.

Automatic Virtual Network CIDR Assignments with Azure IPAM and Bicep

Recently Microsoft announced a public preview of native IP Address Management in Azure, powered by Virtual Network Manager. Being new technology, and with a new landing zone to build, I decided to test and see if we could use it to make IP management simpler.

The starting point was to completely miss the documentation and try and work it out myself. Sadly, the API documentation has yet to be updated to cover the new properties, and tracing the portal requests didn’t help either, since it uses a slightly different flow (sigh!).

Azure Virtual WAN Route Maps and Reflected Routes

Microsoft have make controlling routing within a Virtual WAN much easier thanks to a combination of Routing Intent and Route Maps (in preview at time of writing). Route Maps work in the same manner (at least theoretically) to route map configuratons network administrators are used to in on-premises equipment.

In testing tehm out for a customer, I ran straight into a problem. I like to keep things tidy, and when I looked at the output of the outbound route map configuration for a site to site VPN with AWS, I didn’t like that it showed all my AWS routes being published back out to the VPN. So I configured a route map rule to drop reflected routes.

Deploy a Flex Consumption Function App with Terraform

In May 2024 Microsoft released the Public Preview of the new Flex Consumption Azure Functions. This is an exciting release, primarily because it finally allows a consumption Function App to be VNet integrated. Before the release of Flex Consumption Function Apps, we had to either decide to use a consumption plan or allow access to internal resources (and pay 24/7 for the privilege). While there have been workarounds (e.g. run a Function App in Container Apps) none were ideal.

Logic App (Standard) and API Connections

I have recently had the pleasure (You keep using that word. I do not think it means what you think it means.) of deploying Logic App workflows on a Logic App (Standard) instance. For those not familiar with Logic App (Standard), they are the single-tenant instance of Logic Apps. They provide the ability to host your workflows within a virtual network, something that cannot be done with a consumption Logic App. Under the hood, standard Logic Apps are a completely different beast to consumption Logic Apps. Consumption apps can only have a single Workflow in the app (which makes sense when you consider you also pay by the execution), while standard apps are deployed into an App Service plan and can therefore have multiple workflows in a single Logic App.

Self-Hosted GitHub Runners FOR FREE!

I recently had the privilege of opening the New Zealand GitHub User Group with a presentation on using Azure Container Apps for self-hosted GitHub Actions Runners. The recording of the session is available on YouTube.

<div style="position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden;">
  <iframe allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen="allowfullscreen" loading="eager" referrerpolicy="strict-origin-when-cross-origin" src="https://www.youtube.com/embed/vVTpss4WpOA?autoplay=0&controls=1&end=0&loop=0&mute=0&start=0" style="position: absolute; top: 0; left: 0; width: 100%; height: 100%; border:0;" title="YouTube video"
  ></iframe>
</div>

Using Table Storage as an Alternative to Remote State

Terraform is a fantastic tool for Infrastructure as Code. From the YAML-like HCL syntax (no JSON!), to importing files (linting JSON files FTW!), to retrieving the results of previous runs to link resources, Terraform has made a massive difference in my work. However, like all technologies, it is not without its weaknesses. Terraform uses state files to keep track of what the world looked like when it last ran, which is wonderful for identifying drift. The default pattern is to use these state files for passing data between Terraform modules. But this is actually an anti-pattern, for HashiCorp recommend not using remote state for passing data, in large part because to read the outputs from a state file the caller must have full access to read the entire remote state file, which include secrets they probably shouldn’t be allowed to access.