David Gardiner - Azure

Upgrading Azure Database for PostgreSQL flexible server

2026-02-28T13:00:00.000+10:30

I was working on a project recently that made use of Azure Database for PostgreSQL flexible server. The system had been set up a while ago, and so when I was reviewing the resources in the Azure Portal, I noticed a warning banner for the PostreSQL server:

Your server version will lose standard Azure support on March 31, 2026. Upgrade now to avoid extended support charges starting April 1, 2026.

Terraform was being used for Infrastructure as Code, and it looked similar to this:

resource "azurerm_postgresql_flexible_server" "server" {
  name                              = "psql-postgresql-apps-australiaeast"
  resource_group_name               = data.azurerm_resource_group.rg.name
  location                          = data.azurerm_resource_group.rg.location
  version                           = "11"
  delegated_subnet_id               = azurerm_subnet.example.id
  private_dns_zone_id               = azurerm_private_dns_zone.example.id
  public_network_access_enabled     = false
  administrator_login               = "psqladmin"
  administrator_password_wo         = ephemeral.random_password.postgresql_password.result
  administrator_password_wo_version = 1
  zone                              = "1"

  storage_mb   = 32768
  storage_tier = "P4"

  sku_name   = "B_Standard_B1ms"
  depends_on = [azurerm_private_dns_zone_virtual_network_link.example]
}

As you can see from the code and screenshot above, the PostgreSQL version in use was 11. Doing a bit of research, I found version 11 was first released back in 2018, and the the final minor update 11.22 was released in 2023.

Azure provides standard support for PostgreSQL versions (documented at Azure Database for PostgreSQL version policy). There is also the option of paying for extended support, though in the case of v11 that only gets you to November this year, so just a few extra months.

In my case, I wanted to do a test of the upgrade process first, so I restored a backup of the existing server to a new resource. This essentially creates an exact copy of the server at the same version.

While we are using Infrastructure as Code, I decided to use the Azure Portal to test the upgrade, as I figured if there were any problems, they might be easier to understand, rather than try and interpret weird Terraform/AzureRM errors.

Following the upgrade documentation, I clicked on the Upgrade in the Portal.

This initiates a deployment, which depending on how much data you have and the particular SKU you're running on (eg. how fast the VM you're using is), this may take quite a while. One time it took over an hour (which was important as that may be longer than the default Terraform lifecycle, and also the pipeline job timeouts).

If that succeeds, then you should be good to try the real thing with IaC.

Upgrading with Terraform

To upgrade a major version with Terraform, you need to make a couple of changes to your azurerm_postgresql_flexible_server resource:

The version property should be updated to the desired version
The create_mode property should be set to Update (if it wasn't specified then the default is 'Default')

resource "azurerm_postgresql_flexible_server" "server" {
  name                              = "psql-postgresql-apps-australiaeast"
  resource_group_name               = data.azurerm_resource_group.rg.name
  location                          = data.azurerm_resource_group.rg.location
  version                           = "17"
  delegated_subnet_id               = azurerm_subnet.example.id
  private_dns_zone_id               = azurerm_private_dns_zone.example.id
  public_network_access_enabled     = false
  administrator_login               = "psqladmin"
  administrator_password_wo         = ephemeral.random_password.postgresql_password.result
  administrator_password_wo_version = 1
  zone                              = "1"
  create_mode                       = "Update"

  storage_mb   = 32768
  storage_tier = "P4"

  sku_name   = "B_Standard_B1ms"
  depends_on = [azurerm_private_dns_zone_virtual_network_link.example]
}

The weird thing (which I assume is a side-effect of Terraform state) is that even after you've completed the upgrade, you can't change create_mode back to Default - Terraform will throw an error if you try that. Instead you just need to leave it set to Update, but as long as the version property doesn't change then Terraform will leave it at the same version.

Adjust your timeouts

I was using Azure Pipelines, so I added a timeoutInMinutes property to the job and set it to 90 minutes. Be aware that there are different default and maximum timeouts depending on what kind of build agent you use.

Likewise the Terraform azurerm_postgresql_flexible_server resource has default timeouts. You may want to specify a timeout block to extend those values if necessary.

Gotchas

I hit some compatibility issues with the PostgreSQL instance I was attempting to upgrade. The Portal displayed the following error(s):

The major version upgrade failed precheck. Upgrading shared_preload_libraries library pg_failover_slots from source version 11 to target version 17 is not supported.;
Upgrading shared_preload_libraries library pg_failover_slots from source version 11 to target version 17 is not supported.;
Upgrading shared_preload_libraries library pg_failover_slots from source version 11 to target version 17 is not supported.;
Upgrading shared_preload_libraries library pg_failover_slots from source version 11 to target version 17 is not supported.;
Upgrading shared_preload_libraries library pg_failover_slots from source version 11 to target version 17 is not supported.;
Upgrading with password authentication mode enabled is not allowed from source version MajorVersion11. Please enable SCRAM and reset the passwords prior to retrying the upgrade.

There's two issues here:

The pg_failover_slots shared preloaded library is not supported for upgrading
Legacy MD5 passwords are deprecated in newer versions, and "SCRAM" needs to be enabled

How do we resolve these with Infrastructure as Code? In this case as we're using Terraform, we need to map/import those settings and then we can modify them. We make use of the azurerm_postgresql_flexible_server_configuration resource for this.

The value properties should initially match the existing values (eg. Make sure that Terraform thinks they are unchanged). A trick to get the existing values is to run the Terraform in 'plan' mode and take note of what values it can see from and then copy those into your code.

import {
  to = azurerm_postgresql_flexible_server_configuration.accepted_pasword_auth_method
  id = "${azurerm_resource_group.group.id}/providers/Microsoft.DBforPostgreSQL/flexibleServers/psql-postgresql-apps-australiaeast/configurations/azure.accepted_password_auth_method"
}

resource "azurerm_postgresql_flexible_server_configuration" "accepted_pasword_auth_method" {
  name      = "azure.accepted_password_auth_method"
  server_id = azurerm_postgresql_flexible_server.server.id
  value     = "md5"
}

import {
  to = azurerm_postgresql_flexible_server_configuration.password_encryption
  id = "${azurerm_resource_group.group.id}/providers/Microsoft.DBforPostgreSQL/flexibleServers/psql-postgresql-apps-australiaeast/configurations/password_encryption"
}

resource "azurerm_postgresql_flexible_server_configuration" "password_encryption" {
  name      = "password_encryption"
  server_id = azurerm_postgresql_flexible_server.server.id
  value     = "md5"
}

import {
  to = azurerm_postgresql_flexible_server_configuration.shared_preload_libraries
  id = "${azurerm_resource_group.group.id}/providers/Microsoft.DBforPostgreSQL/flexibleServers/psql-postgresql-apps-australiaeast/configurations/shared_preload_libraries"
}

resource "azurerm_postgresql_flexible_server_configuration" "shared_preload_libraries" {
  name      = "shared_preload_libraries"
  server_id = azurerm_postgresql_flexible_server.server.id
  value     = "anon,auto_explain,pg_cron,pg_failover_slots,pg_hint_plan,pg_partman_bgw,pg_prewarm,pg_stat_statements,pgaudit,pglogical,timescaledb,wal2json"
}

Once you've got those in place then you can make the changes to remove the upgrade block:

resource "azurerm_postgresql_flexible_server_configuration" "accepted_pasword_auth_method" {
  name      = "azure.accepted_password_auth_method"
  server_id = azurerm_postgresql_flexible_server.server.id
  value     = "md5,SCRAM-SHA-256"
}

resource "azurerm_postgresql_flexible_server_configuration" "password_encryption" {
  name      = "password_encryption"
  server_id = azurerm_postgresql_flexible_server.server.id
  value     = "SCRAM-SHA-256"
}

resource "azurerm_postgresql_flexible_server_configuration" "shared_preload_libraries" {
  name      = "shared_preload_libraries"
  server_id = azurerm_postgresql_flexible_server.server.id
  value     = "anon,auto_explain,pg_cron,pg_hint_plan,pg_partman_bgw,pg_prewarm,pg_stat_statements,pgaudit,pglogical,timescaledb,wal2json"
}

This will allow any existing MD5 passwords to continue to work, but any new passwords will use the more modern SCRAM-SHA-256.

For the shared_preload_libraries, we've removed the offending pg_failover_slots from the list.

Tips

Temporarily upgrade your server SKU to beefier hardware so the upgrade goes faster. If you're using IaC then make sure you use that to make the change.
Note that if you change the separate storage performance tier (IOPS), you will need to wait 12 hours before downgrading again.

Completion

If everything goes to plan, you should end up with your PostgreSQL resource upgraded to the version that you specified. Here's my resource upgraded to 17.7. v18 is actually available but I wasn't offered it due to 'regional capacity constraints', which explains why the 'Upgrade' button is now disabled.

I've published source code for a working example of Azure Database for PostgreSQL flexible server with an Azure Container app and using a VNet at https://github.com/flcdrg/terraform-azure-postgresql-containerapps

Passed AI-102

2025-10-15T08:00:00.000+10:30

Another certification to add to my collection. Today I passed exam AI-102, which qualifies me for the certification Microsoft Certified: Azure AI Engineer Associate.

I had not had much experience with most of the Azure AI technology prior to this, so preparing for the certification became a great way to get more familiar with their different capabilities.

I prepared by using the following resources:

Study guide for Exam AI-102: Designing and Implementing a Microsoft Azure AI Solution. Taking note that the exam was updated 30th April 2025. Many of the other resources predate this.
Microsoft Learn Course AI-102T00-A: Develop AI solutions in Azure. Some content (especially the agent module labs) are already using the new Microsoft Agent Framework, whereas the exam is still covering Semantic Kernel and AutoGen. I'm guessing the next update to the exam will fix this.
Pluralsight course Microsoft Certified: Azure AI Engineer Associate (AI-102). Most content is from 2024 or earlier.
John Saville's AI-102 Study Cram - Azure AI Engineer Associate Certification (July 2023)
MeasureUp - Microsoft Practice Test AI-102: Designing and Implementing an Azure AI Solution. Not as useful as I thought it would be.

Most of the Microsoft labs use Python, but I know C# better than Python, so inspired by my colleague Kai, I worked through converting a few of the labs to the equivalent C# code. That was helpful in getting a perspective on all the various different SDKs (bot old and new). I'll write more about that in a future post.

On the day

I ran the Pearson exam software OnVUE's system test a couple of days before I was due to do the exam and I'm glad I did. There were some new issues it threw up which I was able to resolve in plenty of time. Here's my list of things I did to ensure the app no longer detected any issues:

Uninstall NDI Tools (removes virtual camera devices, which were confusing the application when it tried to find my webcam)
Exit Slack and Microsoft Teams
Exit PowerToys
Disable Windows notifications (turn on 'do not disturb'). This actually happened during my previous exam where a Windows notification popup appeared.
Close any other applications in system tray
Disable HyperV. OnVUE kept thinking I was running inside a VM (which I wasn't). Disabling HyperV allowed me to continue.

You're only allowed to have a single monitor in operation. I have a 3-monitor setup, but I knew from previous exams that I would need to disconnect two of the monitors and show the proctor via my webcam that they were disconnected. But this time they also said they needed to see the power cord also disconnected from the wall/powerboard!

Only problem was when I started pulling power cords, I accidentally powered off my dock which disconnected both the network and the webcam and microphone causing the OnVUE app to exit. A frantic couple of minutes getting the correct devices powered again and signing back into the exam and eventually I was cleared to start.

As you can see from the study guide above, the exam covers a lot of content. I did lean a bit on having access to Microsoft Learn. It is a time sink though (and the searching within Learn is not great). You definitely have to pace yourself to ensure you have enough time to get through all the questions in the time allowed.

I was happy to get to the end and finally see the summary page letting me know I've passed!

Import Azure applications into Terraform

2025-05-26T22:00:00.000+09:30

I'm looking forward to presenting at the Adelaide Azure User Group next month about the process of importing a 'brownfield' Azure application into Terraform.

Terraform is a popular infrastructure as code tool. Starting off from scratch with Terraform is pretty straightforward. But what if you've already got your cloud infrastructure deployed but you didn't use Terraform, Bicep or another Infrastructure as Code tool? Maybe you just created resources in the Portal directly, or used the Azure CLI or PowerShell.

This talk steps through this scenario, demonstrating how to use tools to generate Terraform, common issues to watch out for, and hwo to make it work across multiple environments.

Passed AZ-104

2025-05-11T21:30:00.000+09:30

I forgot to mention this a few weeks ago but I passed the AZ-104 - Microsoft Azure Administrator exam, and this means I now have the Microsoft Certified: Azure Administrator Associate certification.

It's been just over 3 years since I took my last Microsoft exam, and this time there was one thing that was a pleasant surprise, that I wasn't even actually aware to start with.

It turns out that back in 2023 it was announced that all role-based exams now provide access to Microsoft Learn content within the exam!

I was already a few questions in when I happened to notice a curious icon on the exam toolbar. That's when I discovered the Learn content. So the exam isn't totally 'open book', but it's a big change. It's also 'sandboxed' - you can only browse the content from the Microsoft Learn website. Nothing outside of that.

Obviously having access to that content is a big change, but you still need to be able to understand the question and interpret the correct answer.

One criticism of a lot of certification-style exams is they just encourage memorising random or obscure facts. I think giving access to Microsoft Learn from within the exam goes some way to dispelling that criticism.

Be aware that you still have the same time limit for an exam, so it's really important to manage your time well.

It would be quite easy to find you've spent 10 minutes trying to confirm the answer to a question, only to then discover that you've run out of time to finish all the questions!

I'd suggest unless you can quickly check a question in under a minute, you're better off selecting an answer but also mark the question for review. Only then if you have time at the end of the section make use of the Learn resources.

I'd been wanting to take this exam for quite a while. I'd been working my way through the self-directed training modules and also reviewed some of the courses on Pluralsight and LinkedIn Learning. I'd also made use of the practise questions.

In the end I figured I just had to take the plunge and have a go. After I'd answered all the questions I really wasn't sure if I'd made it, so it was a pleasant surprise to find that I'd passed 😊🎉

Azure SQL and enabling auditing with Terraform

2025-02-17T08:00:00.000+10:30

Sometimes when you're using Terraform for your Infrastructure as Code with Azure, it's a bit tricky to match up what you can see in the Azure Portal versus the Terraform resources in the AzureRM provider. Enabling auditing in Azure SQL is a great example.

In the Azure Portal, select your Azure SQL resource, then expand the Security menu and select Auditing. You can then choose to Enable Azure SQL Auditing, and upon doing this you can then choose to send auditing data to any or all of Azure Storage, Log Analytics and/or Event Hub.

It's also worth highlighting that usually you'd enable auditing at the server level, but it is also possible to enable it per database.

The two Terraform resources you may have encountered to manage this are mssql_server_extended_auditing_policy and mssql_database_extended_auditing_policy.

It's useful to refer back to the Azure SQL documentation on setting up auditing to understand how to use these.

A couple of points that are worth highlighting:

If you don't use the audit_actions_and_groups property, the default groups of actions that will be audited are:

BATCH_COMPLETED_GROUP SUCCESSFUL_DATABASE_AUTHENTICATION_GROUP FAILED_DATABASE_AUTHENTICATION_GROUP
If you do define auditing at the server level, the policy applies to all existing and newly created databases on the server. If you define auditing at the database level, the policy will apply in addition to any server level settings. So be careful you don't end up auditing the same thing twice unintentionally!

Sometimes it can also be useful to review equivalent the Bicep/ARM definitions Microsoft.Sql/servers/extendedAuditingSettings, as sometimes they can clarify how to use various properties.

You'll see both the Terraform and Bicep have properties to configure using a Storage Account, but while you can see Log Analytics and Event Hub in the Portal UI, it's not obvious how those set up.

The simplest policy you can set is this:

resource "azurerm_mssql_server_extended_auditing_policy" "auditing" {
  server_id = azurerm_mssql_server.mssql.id
}

This enables the server auditing policy, but the data isn't going anywhere yet!

Storage account

When you select an Azure Storage Account for storing auditing data, you will end up with a bunch .xel files created under a sqldbauditlogs blob container.

There are a number of ways to view the .xel files, documented here

Using a storage account for storing auditing has a few variations, depending on how you want to authenticate to the Storage Account.

Access key

resource "azurerm_mssql_server_extended_auditing_policy" "auditing" {
  server_id = azurerm_mssql_server.mssql.id

  storage_endpoint                        = azurerm_storage_account.storage.primary_blob_endpoint
  storage_account_access_key              = azurerm_storage_account.storage.primary_access_key
  storage_account_access_key_is_secondary = false
  retention_in_days                       = 6
}

Normally storage_account_access_key_is_secondary would be set to false, but if you are rotating your storage access keys, then you may choose to switch to the secondary key while you're rotating the primary.

Managed identity

You can also use managed identity to authenticate to the storage account. In this case you don't supply the access_key properties, but you will need to add a role assignment granting the Storage Blob Data Contributor role to the identity of your Azure SQL resource.

resource "azurerm_mssql_server_extended_auditing_policy" "auditing" {
  server_id = azurerm_mssql_server.mssql.id

  storage_endpoint  = azurerm_storage_account.storage.primary_blob_endpoint
  retention_in_days = 6
}

Log analytics workspaces

To send data to a Log Analytics Workspace, the log_monitoring_enabled property needs to be set to true. This is the default.

But to tell it which workspace to send the data to, you need to add a azurerm_monitor_diagnostic_setting resource.

resource "azurerm_monitor_diagnostic_setting" "mssql_server_to_log_analytics" {
  name                       = "example-diagnostic-setting"
  target_resource_id         = "${azurerm_mssql_server.mssql.id}/databases/master"
  log_analytics_workspace_id = azurerm_log_analytics_workspace.la.id

  enabled_log {
    category = "SQLSecurityAuditEvents"
  }
}

Note that for the server policy, you set the target_resource_id to the master database of the server, not the resource id of the server itself.

Here's what the auditing data looks like when viewed in Log Analytics:

Event Hub

Likewise, if you want data to go to an Event Hub, you need to use the azurerm_monitor_diagnostic_setting resource.

resource "azurerm_monitor_diagnostic_setting" "mssql_server_to_event_hub" {
  name                           = "ds_mssql_event_hub"
  target_resource_id             = "${azurerm_mssql_server.mssql.id}/databases/master"
  eventhub_authorization_rule_id = azurerm_eventhub_namespace_authorization_rule.eh.id
  eventhub_name                  = azurerm_eventhub.eh.name

  enabled_log {
    category = "SQLSecurityAuditEvents"
  }
}

Multiple destinations

As is implied by the Azure Portal, you can have one, two or all three destinations enabled for auditing. But it isn't immediately obvious that you should only have one azurerm_monitor_diagnostic_setting for your server auditing - don't create separate azurerm_monitor_diagnostic_setting resources for each destination - Azure will not allow it.

For example, if you're going to log to all three, you'd have a single diagnostic resource like this:

resource "azurerm_monitor_diagnostic_setting" "mssql_server" {
  name                           = "diagnostic_setting"
  target_resource_id             = "${azurerm_mssql_server.mssql.id}/databases/master"
  eventhub_authorization_rule_id = azurerm_eventhub_namespace_authorization_rule.eh.id
  eventhub_name                  = azurerm_eventhub.eh.name

  log_analytics_workspace_id     = azurerm_log_analytics_workspace.la.id
  log_analytics_destination_type = "Dedicated"

  enabled_log {
    category = "SQLSecurityAuditEvents"
  }

Note, this Terraform resource does have a storage_account_id property, but this doesn't seem to be necessary as storage is configured via the azurerm_mssql_server_extended_auditing_policy resource.

You would need separate azurerm_monitor_diagnostic_setting resources if you were configuring auditing per database though.

Common problems

The diagnostic setting can't find the master database

It appears that sometimes the azurerm_mssql_server resource reports it is created, but the master database is not yet ready. The workaround is to add a dependency on another database resource - as by definition the master database must exist before any other user databases can be created.

Diagnostic setting fails to update with 409 Conflict

This error seems to happen to me when I try and set up Storage, Event Hubs and Log Analytics at the same time.

Error: creating Monitor Diagnostics Setting "diagnostic_setting" for Resource "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-terraform-sql-auditing-australiaeast/providers/Microsoft.Sql/servers/sql-terraform-sql-auditing-australiaeast/databases/master": unexpected status 409 (409 Conflict) with response: {"code":"Conflict","message":"Data sink '/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-terraform-sql-auditing-australiaeast/providers/Microsoft.EventHub/namespaces/evhns-terraform-sql-auditing-australiaeast/authorizationRules/evhar-terraform-sql-auditing-australiaeast' is already used in diagnostic setting 'SQLSecurityAuditEvents_3d229c42-c7e7-4c97-9a99-ec0d0d8b86c1' for category 'SQLSecurityAuditEvents'. Data sinks can't be reused in different settings on the same category for the same resource."}

After a lot of trial and error, I've found the solution is to add a depends_on block in your azurerm_mssql_server_extended_auditing_policy resource, so that the azurerm_monitor_diagnostic_setting is created first. (This feels like a bug in the Terraform AzureRM provider)

resource "azurerm_mssql_server_extended_auditing_policy" "auditing" {
  server_id = azurerm_mssql_server.mssql.id

  storage_endpoint  = azurerm_storage_account.storage.primary_blob_endpoint
  retention_in_days = 6

  depends_on = [azurerm_monitor_diagnostic_setting.mssql_server]
}

Switching from Storage access keys to managed identity has no effect

Removing the storage access key properties from azurerm_mssql_server_extended_auditing_policy doesn't currently switch the authentication to managed identity. The problem may relate to the storage_account_subscription_id property. This is an optional property and while you usually don't need to set it if the storage account is in the same subscription, it appears that the AzureRM provider is setting it on your behalf, such that when you remove the other access key properties it doesn't know to set this property to null.

If you know ahead of time that you'll be transitioning from access keys to managed identity, it might be worth setting storage_account_subscription_id first. Then later on, when you remove that and the other access_key properties maybe Terraform will do the right thing?

Solution resource

If you ever hit the Save button on the Azure SQL Auditing page, you may end up with a Solution resource being created for your auditing. This is useful, though it can cause problems if you are trying to destroy your Terraform resources, as it can put locks on the resources and Terraform doesn't know to destroy the solution resource first.

You could try to pre-emptively create the solution resource in Terraform. For example:

resource "azurerm_log_analytics_solution" "example" {
  solution_name         = "SQLAuditing"
  location              = data.azurerm_resource_group.rg.location
  resource_group_name   = data.azurerm_resource_group.rg.name
  workspace_resource_id = azurerm_log_analytics_workspace.la.id
  workspace_name        = azurerm_log_analytics_workspace.la.name

  plan {
    publisher = "Microsoft"
    product   = "SQLAuditing"
  }

  depends_on = [azurerm_monitor_diagnostic_setting.mssql_server]
}

Though it seems that when you use Terraform to create this resource, it names it SQLAuditing(log-terraform-sql-auditing-australiaeast), whereas if you use the portal, it is named SQLAuditing[log-terraform-sql-auditing-australiaeast].

So instead this looks like a good use for the AzApi provider and the azapi_resource

resource "azapi_resource" "symbolicname" {
  type      = "Microsoft.OperationsManagement/solutions@2015-11-01-preview"
  name      = "SQLAuditing[${azurerm_log_analytics_workspace.la.name}]"
  location  = data.azurerm_resource_group.rg.location
  parent_id = data.azurerm_resource_group.rg.id

  tags = {}
  body = {
    plan = {
      name          = "SQLAuditing[${azurerm_log_analytics_workspace.la.name}]"
      product       = "SQLAuditing"
      promotionCode = ""
      publisher     = "Microsoft"
    }
    properties = {
      containedResources = [
        "${azurerm_log_analytics_workspace.la.id}/views/SQLSecurityInsights",
        "${azurerm_log_analytics_workspace.la.id}/views/SQLAccessToSensitiveData"
      ]
      referencedResources = []
      workspaceResourceId = azurerm_log_analytics_workspace.la.id
    }
  }
}

Other troubleshooting tips

The Azure CLI can also be useful in checking what the current state of audit configuration is.

Here's two examples showing auditing configured for all three destinations:

az monitor diagnostic-settings list --resource /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-terraform-sql-auditing-australiaeast/providers/Microsoft.Sql/servers/sql-terraform-sql-auditing-australiaeast/databases/master

gives the following:

[
  {
    "eventHubAuthorizationRuleId": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-terraform-sql-auditing-australiaeast/providers/Microsoft.EventHub/namespaces/evhns-terraform-sql-auditing-australiaeast/authorizationRules/evhar-terraform-sql-auditing-australiaeast",
    "eventHubName": "evh-terraform-sql-auditing-australiaeast",
    "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/rg-terraform-sql-auditing-australiaeast/providers/microsoft.sql/servers/sql-terraform-sql-auditing-australiaeast/databases/master/providers/microsoft.insights/diagnosticSettings/diagnostic_setting",
    "logs": [
      {
        "category": "SQLSecurityAuditEvents",
        "enabled": true,
        "retentionPolicy": {
          "days": 0,
          "enabled": false
        }
      },
      {
        "category": "SQLInsights",
        "enabled": false,
        "retentionPolicy": {
          "days": 0,
          "enabled": false
        }
      },
      {
        "category": "AutomaticTuning",
        "enabled": false,
        "retentionPolicy": {
          "days": 0,
          "enabled": false
        }
      },
      {
        "category": "QueryStoreRuntimeStatistics",
        "enabled": false,
        "retentionPolicy": {
          "days": 0,
          "enabled": false
        }
      },
      {
        "category": "QueryStoreWaitStatistics",
        "enabled": false,
        "retentionPolicy": {
          "days": 0,
          "enabled": false
        }
      },
      {
        "category": "Errors",
        "enabled": false,
        "retentionPolicy": {
          "days": 0,
          "enabled": false
        }
      },
      {
        "category": "DatabaseWaitStatistics",
        "enabled": false,
        "retentionPolicy": {
          "days": 0,
          "enabled": false
        }
      },
      {
        "category": "Timeouts",
        "enabled": false,
        "retentionPolicy": {
          "days": 0,
          "enabled": false
        }
      },
      {
        "category": "Blocks",
        "enabled": false,
        "retentionPolicy": {
          "days": 0,
          "enabled": false
        }
      },
      {
        "category": "Deadlocks",
        "enabled": false,
        "retentionPolicy": {
          "days": 0,
          "enabled": false
        }
      },
      {
        "category": "DevOpsOperationsAudit",
        "enabled": false,
        "retentionPolicy": {
          "days": 0,
          "enabled": false
        }
      }
    ],
    "metrics": [
      {
        "category": "Basic",
        "enabled": false,
        "retentionPolicy": {
          "days": 0,
          "enabled": false
        }
      },
      {
        "category": "InstanceAndAppAdvanced",
        "enabled": false,
        "retentionPolicy": {
          "days": 0,
          "enabled": false
        }
      },
      {
        "category": "WorkloadManagement",
        "enabled": false,
        "retentionPolicy": {
          "days": 0,
          "enabled": false
        }
      }
    ],
    "name": "diagnostic_setting",
    "resourceGroup": "rg-terraform-sql-auditing-australiaeast",
    "type": "Microsoft.Insights/diagnosticSettings",
    "workspaceId": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-terraform-sql-auditing-australiaeast/providers/Microsoft.OperationalInsights/workspaces/log-terraform-sql-auditing-australiaeast"
  }
]

And the Azure SQL audit policy

az sql server audit-policy show -g rg-terraform-sql-auditing-australiaeast -n sql-terraform-sql-auditing-australiaeast

Gives

{
  "auditActionsAndGroups": [
    "SUCCESSFUL_DATABASE_AUTHENTICATION_GROUP",
    "FAILED_DATABASE_AUTHENTICATION_GROUP",
    "BATCH_COMPLETED_GROUP"
  ],
  "blobStorageTargetState": "Enabled",
  "eventHubAuthorizationRuleId": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-terraform-sql-auditing-australiaeast/providers/Microsoft.EventHub/namespaces/evhns-terraform-sql-auditing-australiaeast/authorizationRules/evhar-terraform-sql-auditing-australiaeast",
  "eventHubName": "evh-terraform-sql-auditing-australiaeast",
  "eventHubTargetState": "Enabled",
  "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-terraform-sql-auditing-australiaeast/providers/Microsoft.Sql/servers/sql-terraform-sql-auditing-australiaeast/auditingSettings/Default",
  "isAzureMonitorTargetEnabled": true,
  "isDevopsAuditEnabled": null,
  "isManagedIdentityInUse": true,
  "isStorageSecondaryKeyInUse": null,
  "logAnalyticsTargetState": "Enabled",
  "logAnalyticsWorkspaceResourceId": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-terraform-sql-auditing-australiaeast/providers/Microsoft.OperationalInsights/workspaces/log-terraform-sql-auditing-australiaeast",
  "name": "Default",
  "queueDelayMs": null,
  "resourceGroup": "rg-terraform-sql-auditing-australiaeast",
  "retentionDays": 6,
  "state": "Enabled",
  "storageAccountAccessKey": null,
  "storageAccountSubscriptionId": "00000000-0000-0000-0000-000000000000",
  "storageEndpoint": "https://sttfsqlauditauew0o.blob.core.windows.net/",
  "type": "Microsoft.Sql/servers/auditingSettings"
}

Azure Function posting an RSS feed to Mastodon

2024-01-13T13:00:00.000+10:30

Twitter (or 'X' as it seems to be called now), to my surprise, hasn't died yet. I'm still there, but I must say I'm enjoying the discussions over on Mastodon a lot more (follow me at https://mastodon.online/@DavidRGardiner). But there are a few feeds that I follow on Twitter that I'd like to follow on Mastodon. So I wrote a little Azure Function to do that for me (and anyone else who is interested).

One that is relevant to living in South Australia, especially over the warmer months, given where I live is a bushfire-prone area, is keeping an eye on the updates from the Country Fire Service (known locally as the CFS). They have a Twitter account, but not a Mastodon account. If only there was a way to get their updates on Mastodon!

As it turns out, the CFS publish some RSS feeds. My first attempt was to make use of a service like Mastofeed, which in theory can take an RSS feed and post updates to Mastodon. But as I discovered, the RSS feed from the CFS has a few oddities that seem to prevent this from working correctly - it posted one update but then stopped. Here's an example of the RSS feed:

<?xml version='1.0' ?>
<rss version='2.0' xmlns:atom='http://www.w3.org/2005/Atom'>
  <channel>
    <atom:link href='https://data.eso.sa.gov.au/prod/cfs/criimson/cfs_current_incidents.xml' rel='self' type='application/rss+xml' />
    <ttl>15</ttl>
    <title>Country Fire Service - South Australia - Current Incidents</title>
    <link>https://www.cfs.sa.gov.au/incidents/</link>
    <description>Current Incidents</description>
    <item>
      <link>https://www.cfs.sa.gov.au/incidents/</link>
      <guid isPermaLink='false'>https://data.eso.sa.gov.au/prod/cfs/criimson/1567212.</guid>
      <title>TIERS ROAD, LENSWOOD (Tree Down)</title>
      <identifier>1567212</identifier>
      <description>First Reported: Saturday, 06 Jan 2024 15:41:00&lt;br&gt;Status: GOING&lt;br&gt;Region: 1</description>
      <pubDate>Sat, 06 Jan 2024 16:15:03 +1030</pubDate>
    </item>

There is the identifier element that is non-standard, but I suspect the main issue is the guid element. For some reason, the isPermaLink attribute is set to false. On the face of it, that looks like a mistake. That URI (which incorporates the identifier value) does appear to be unique. With isPermaLink set to false, it hints that the value can't be used as a unique identifier. I'm guessing because of that, Mastofeed had no way to distinguish posts in the RSS feed.

So we're out of luck using the simple option. My next thought was whether there was something that could transform/fix up the RSS on the fly - an 'XSLT proxy' if you like, but I've not found a free offering like that.

Maybe I can write some code to do the job instead. Hosting it in an Azure Function should work, and ideally would be free (or really cheap).

An Azure Function

I ended up writing a relatively simple Azure Function in C# that polls the RSS feed every 15 minutes (as that's the value of the ttl element). It then posts any new items to Mastodon. Here's the code (Link to GitHub repo):

    [Function(nameof(CheckAlerts))]
    public async Task<List<CfsFeedItem>> CheckAlerts([ActivityTrigger] List<CfsFeedItem> oldList)
    {
        var newList = new List<CfsFeedItem>();

        var response = string.Empty;
        try
        {
            using var httpClient = _httpClientFactory.CreateClient();

            response = await httpClient.GetStringAsync(
                "https://data.eso.sa.gov.au/prod/cfs/criimson/cfs_current_incidents.xml");

            var xml = XDocument.Parse(response);

            if (xml.Root.Element("channel") is null)
                throw new InvalidOperationException("No channel element found in feed");

            var xmlItems = xml.Root.Element("channel")?.Elements("item").ToList();

            if (xmlItems is not null)
                foreach (var item in xmlItems)
                {
                    var dateTime = DateTime.Parse(item.Element("pubDate").Value);

                    newList.Add(new CfsFeedItem(
                        item.Element("guid").Value,
                        item.Element("title").Value,
                        item.Element("description").Value,
                        item.Element("link").Value,
                        dateTime
                    ));
                }

            // Find items in newList that are not in oldList
            var newItems = newList.Except(oldList).ToList();

            if (newItems.Any())
            {
                var accessToken = _settings.Token;
                var client = new MastodonClient(_settings.Instance, accessToken);

                foreach (var item in newItems)
                {
                    var message = $"{item.Title}\n\n{item.Description.Replace("<br>", "\n")}\n{item.Link}";

                    _logger.LogInformation("Tooting: {item}", message);

#if RELEASE
                await client.PublishStatus(message, Visibility.Unlisted);
#endif
                }
            }
            else
            {
                _logger.LogInformation("No new items found");
            }
        }
        catch (Exception ex)
        {
            _logger.LogError(ex, "Problems. Data: {data}", response);
        }

        return newList;
    }

We keep a copy of the previous list of items, and then compare it to the new list. If there are any new items, we post them to Mastodon. Because we need to remember the previous run items, we need to use Durable Functions. This was my first time creating a Durable Function, so that also made it a good learning experience. The 'eternal orchestration' pattern is used, where the orchestration function calls itself, passing in the new list of items. Here's the orchestration function code:

    [Function(nameof(MonitorJobStatus))]
    public static async Task Run(
        [OrchestrationTrigger] TaskOrchestrationContext context, List<CfsFeedItem> lastValue)
    {
        var newValue = await context.CallActivityAsync<List<CfsFeedItem>>(nameof(CfsFunction.CheckAlerts), lastValue);

#if RELEASE
        // Orchestration sleeps until this time (TTL is 15 minutes in RSS)
        var nextCheck = context.CurrentUtcDateTime.AddMinutes(15);
#else
        var nextCheck = context.CurrentUtcDateTime.AddSeconds(20);
#endif

        await context.CreateTimer(nextCheck, CancellationToken.None);

        context.ContinueAsNew(newValue);
    }

The Durable Function infrastructure handles serialising and deserialising the list of items automatically. The Function takes a parameter that receives the list from the previous run. When the function completes, it returns the list that will be passed to the next run. The orchestration function passes in the list and sets things up to save the list so that it can be passed to the next run.

One thing about this pattern is you need some way of kickstarting the process. The way I chose was to add a HTTP trigger function that calls the orchestration function. The release pipeline makes a call to the HTTP trigger endpoint after it publishes the function.

Durable + .NET 8 + isolated

The Durable Function targets .NET 8 and uses the isolated model. It was a little challenging figuring out how to get this combination to work, as most of the documentation is either for the in-process model or for earlier versions of .NET. Ensuring that the appropriate NuGet packages were being referenced was tricky, as there are often different packages to use depending on the model and version of .NET. I ended up using the following packages:

    <PackageReference Include="Mastonet" Version="2.3.1" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.20.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.DurableTask" Version="1.1.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http" Version="3.1.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Timer" Version="4.3.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.16.4" />
    <PackageReference Include="Microsoft.Extensions.Configuration.UserSecrets" Version="8.0.0" />

Costs

To keep costs to a minimum, the Azure Function is running on a consumption plan. The intention is to keep it close to or under the free threshold.

As it turns out, so far the Function is not costing very much at all. It's actually the Storage Account that is the most significant. AUD8.30 so far and the total forecast for the month will be AUD17. An Azure Function needs to be linked to a Storage Account. It would be interesting to see if there are any changes I could make to reduce the cost further.

To see the latest posts from the Azure Function, you can go to https://mastodon.online/@CFSAlerts (and if you're on Mastodon, feel free to follow the account!)

Future enhancements

Apart from seeing if I can reduce the cost even more, the other thing that would be useful is to also track the daily fire bans. This data is published as an XML file, so parsing that once a day should be pretty straightforward.

You can find the full source code for the Azure Function in this GitHub repo.

Finding free subnets in an Azure Virtual Network

2023-04-03T08:00:00.000+09:30

An Azure Virtual Network (as the docs say) is "the fundamental building block for your private network in Azure". Often abbreviated to "VNet". When a VNet is created, you specify the available IP address range using CIDR notation. If you create a VNET through the Azure Portal, it defaults to 10.1.0.0/16, which equates to 65536 IP addresses (10.1.0.0 - 10.1.255.255).

A VNet contains one or more subnets, where the IP range for each subnet is assigned from the VNet's allocation. One thing to note - you can't resize a VNet. Once it has been created, that's it. If you use up all the available IP addresses, your only options are to create a new VNet and peer it to the original VNet, or if the newer VNet is larger, migrate all your services over to it (which may not be trivial).

If a VNet has been in use for some time or is used by multiple teams, you can end up with fragmentation - gaps between allocated subnets. This could happen because new subnets are allocated by choosing a 'nice' number to start on (rather than following immediately from the last allocated), or from a previously allocated subnet being deleted. e.g.

In this VNet it turns out we have some gaps. While the temptation might be to allocate the next subnet starting at 10.0.2.0, depending on the size required, we might be able to use one of the available gaps instead.

Now maybe you can read CIDR IP addresses in your sleep and can not only spot the gaps but know intuitively what ranges you could allocate. For the rest of us, I'd either resort to a pencil and paper or (more likely) see if I could script out the answer using PowerShell.

And so I created a PowerShell script to query a VNet and list both the existing subnets and also the available gaps (and CIDR ranges that could use those gaps). I started sharing this script with a few of my SixPivot colleagues, as they were experiencing the same situation. I realised it would be good to make this more widely available, so the result is my first PowerShell module published to the PowerShell Gallery (under the SixPivot name) - SixPivot.Azure, which contains the Find-FreeSubnets function.

Using the Find-FreeSubnets cmdlet

First off, install the module:

Install-Module SixPivot.Azure

If you haven't previously connected to Azure then you'll need to do this:

Connect-AzAccount

Now you can use Find-FreeSubnets. You need to know the resource group and VNET name. eg.

Find-FreeSubnets -ResourceGroup rg-freesubnet-australiaeast -VNetName vnet-freesubnet-australiaeast

This will produce output similar to the following:

VNet Start VNet End     Available      Subnets
---------- --------     ---------      -------
10.0.0.0   10.0.255.255 {48, 8, 65184} {10.0.0.0/24, 10.0.1.0/28, 10.0.1.64/28, 10.0.1.88/29}

The output is structured data. If you assign it to a variable, then you can dig down into the different parts.

$vnet = Find-FreeSubnets -ResourceGroup rg-freesubnet-australiaeast -VNetName

For the VNET itself, you can get the start and end addresses using VNetStart and VNetEnd properties.

$vnet.VNetStart, $vnet.VNetEnd
10.0.0.0
10.0.255.255

You can see the currently allocated subnets via the Subnets property:

$vnet.Subnets

Address space Range start Range end
------------- ----------- ---------
10.0.0.0/24   10.0.0.0    10.0.0.255
10.0.1.0/28   10.0.1.0    10.0.1.15
10.0.1.64/28  10.0.1.64   10.0.1.79
10.0.1.88/29  10.0.1.88   10.0.1.95

And finally, (and this is the good bit!), the available subnets via the Available property

$vnet.Available

Start     End          Size  Available ranges
-----     ---          ----  ----------------
10.0.1.16 10.0.1.63    48    {10.0.1.16/28, 10.0.1.32/27, 10.0.1.32/28, 10.0.1.48/28}
10.0.1.80 10.0.1.87    8
10.0.1.96 10.0.255.255 65184 {10.0.1.96/27, 10.0.1.96/28, 10.0.1.112/28, 10.0.1.128/25…}

For a particular Start and End, you can see potential CIDR ranges with the CIDRAvailable property:

$vnet.Available[0].CIDRAvailable
10.0.1.16/28
10.0.1.32/27
10.0.1.32/28
10.0.1.48/28

$vnet.Available[2].CIDRAvailable
10.0.1.96/27
10.0.1.96/28
10.0.1.112/28
10.0.1.128/25
10.0.1.128/26
10.0.1.128/27
10.0.1.128/28
10.0.1.144/28
...

Possible prefix lengths of 25, 26, 27 or 28 are shown. The output for the second example actually scrolled way off the page, so watch out if the available Size is quite large.

From the first available range, I could use either:

10.0.1.16/28 and 10.0.1.32/27
or 10.0.1.16/28, 10.0.1.32/28 and 10.0.1.48/28

Future enhancements

The cmdlet is useful already, but one feature I'd like to add is to be able to pass in one or more CIDR prefix lengths (eg. 28,28,27) and allow it to find compatible non-overlapping ranges automatically.

Provision an Azure Virtual Machine with Terraform Cloud

2023-01-19T20:30:00.000+10:30

Sometimes I need to spin up a virtual machine to quickly test something out on a 'vanilla' machine, for example, to test out a Chocolatey package that I maintain.

Most of the time I log in to the Azure Portal and click around to create a VM. The addition of the choice to use the Azure Virtual Machine with preset configuration does make it a bit easier, but it's still lots of clicking. Maybe I should try automating this!

There are a few choices for automating, but seeing as I've been using Terraform lately I thought I'd try that out, together with Terraform Cloud. As I'll be putting the Terraform files in a public repository on GitHub, I can use the free tier for Terraform Cloud.

You can find the source for the Terraform files at https://github.com/flcdrg/terraform-azure-vm/.

You'll also need to have both the Azure CLI and Terraform CLI installed. You can do this easily via Chocolatey:

choco install terraform
choco install azure-cli

Setting up Terraform Cloud Workspace with GitHub

Log in (or sign up) to Terraform Cloud at https://app.terraform.io, select (or create) your organisation, then go to Workspaces and click on Create a workspace
Select how you'd like to trigger a workflow. To keep things simple, I chose Version control workflow
Select the version control provider - Github.com.
You will now need to authenticate with GitHub.
Watch out if you get a notification about a pop-up blocker. If you do, then enable pop-ups for this domain
Choose which GitHub account or organisation to use:
Select which repositories should be linked to Terraform Cloud.
If you use multi-factor authentication then you'll need to approve the access.
Now that your GitHub repositories are connected, you need to select the repository that Terraform Cloud will use for this workspace.
Enter a workspace name (and optionally a description)
Now your workspace has been created!

You're now ready to add Terraform files to your GitHub repository. I like to use the Terraform CLI to validate and format my .tf files before I commit them to version control.

After adding versions.tf file that contains a cloud definition (along with any providers), you can run terraform login

terraform {
  cloud {
    organization = "flcdrg"
    hostname     = "app.terraform.io"

    workspaces {
      name = "terraform-azure-vm"
    }
  }

  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "=3.39.1"
    }
    random = {
      source  = "hashicorp/random"
      version = "3.4.3"
    }
  }
}

provider "azurerm" {
  features {}
}

A browser window will launch to allow you to create an API token that you can then paste back into the CLI.

The next thing we need to do is create an Azure service principal that Terraform Cloud can use when deploying to Azure.

In my case, I created a resource group and granted the service principal Contributor access to it (assuming that all the resources you want Terraform to create will live within that resource group). You could also allow the service principal access to the whole subscription if you prefer.

az login
az group create --location westus --resource-group MyResourceGroup
az ad sp create-for-rbac --name <service_principal_name> --role Contributor --scopes /subscriptions/<subscription_id>/resourceGroups/<resourceGroupName>

Now go back to Terraform Cloud, and after selecting the newly created workspace, select Variables.

Under Workspace variables, click Add variable, then select Environment variables. Add a variable for each of the following (for ARM_CLIENT_SECRET also check the Sensitive checkbox), for the value copy the appropriate value from the output from creating the service principal:

ARM_CLIENT_ID - appId
ARM_CLIENT_SECRET - password
ARM_SUBSCRIPTION_ID - id from az account show
ARM_TENANT_ID

With those variables set, you can now push your Terraform files to the GitHub repository.

The Terraform Cloud workspace is configured to evaluate a plan on pull requests, and on pushes or merges to main it will apply those changes.

By default, you need to manually confirm before 'apply' will run (you can change the workspace to auto-approve to avoid this).

After a short wait, all the Azure resources (including the VM) should have been created and ready to use.

Virtual machine password

I'm not hardcoding the password for the virtual machine - rather I'm using the Terraform random_password resource to generate a random password. The password is not displayed in the logs as it is marked as 'sensitive'. But I will actually need to know the password so I can RDP to the VM. It turns out the password value is saved in Terraform state, and you can examine this via the States tab of the workspace.

With that, I'm now able to navigate to the VM resource in the Azure Portal and connect via RDP and do what I need to do.

If you wanted to stick with the CLI, you can also use Azure PowerShell to launch an RDP session.

Extra configuration

If you review the Terraform in the repo, you'll notice I also make use of the azurerm_virtual_machine_extension resource to run some PowerShell that installs Chocolatey. That just saves me from having to do it manually. If you can automate it, why not!

Cleaning up when you're done

For safety, the virtual machine is set to auto shutdown in the evening, which will reduce any costs. To completely remove the virtual machine and any associated storage you can run a "destroy plan"

From the workspace, go to Settings, then Destruction and deletion, and click Queue destroy plan.

Passed AZ-400

2022-02-23T19:30:00.000+10:30

I'm pleased to report that today I passed Microsoft exam AZ-400: Designing and Implementing Microsoft DevOps Solutions, which combined with AZ-201 that I took last year, now qualifies me for the Microsoft Certified: DevOps Engineer Expert certification.

View my verified achievement from Microsoft

The exam is quite broad in the content it covers:

Develop an instrumentation strategy (5-10%)
Develop a Site Reliability Engineering (SRE) strategy (5-10%)
Develop a security and compliance plan (10-15%)
Manage source control (10-15%)
Facilitate communication and collaboration (10-15%)
Define and implement continuous integration (20-25%)
Define and implement a continuous delivery and release management strategy (10-15%)

Some areas I'd been working with for quite a few years, but others were new to me. To help prepare I used a couple of resources:

Nice to get that one dusted.

Azure Resource Namer tool

2021-10-17T16:30:00.000+10:30

If you host anything in Azure, then you've probably had to think about resource naming conventions, even if your convention is not to have one! But any time you start building up a sizable collection of resources, having a naming convention can make it a lot easier to manage.

Microsoft have a suggested convention as part of their Cloud Adoption Framework. It's pretty straightforward, and makes use of their list of recommended abbreviations for resource types.

I thought I'd have a go making a simple tool that could automate generating the name. There's lots of ways I could have built such a tool, but I figured a simple web page should be achievable and make it accessible to most people.

Most of my time is spent working on back-end code, so here was a chance to play around with a frontend framework. I could have chosen one of the big names, but there's one I've been keeping a keen eye on for a long time that I hadn't ever actually used - Aurelia - and this seemed like a nice opportunity to kick the tyres. I was really pleased with the result. This is not a complicated web application, but I do like the way Aurelia works. I used Aurelia v1, but I'll be keen to upgrade to v2 (it's currently in alpha).

You can try out the tool at https://david.gardiner.net.au/azure-resource-namer/, with the source code at https://github.com/flcdrg/azure-resource-namer. I made use of GitHub Pages for the publishing part. Later on I might get a custom domain and maybe run it with something like Azure Static Web Apps, but this does the job for now.

The naming convention consists of concatenating a number of fields together:

The Resource Type and Region fields are drop-down lists.
The Workload and Environment fields are user-editable. The type of resource will determine what characters are allowed here.
The Instance field is numeric. If you set it to zero then it will be excluded.

There are a lot of different resource types. The tool supports all the types listed in the previously mentioned abbreviations page. I'm slowly adding extra validation information for each resource, so that you get extra hints should you use an invalid character, the name ends up being too long, and also where there are particular formatting requirements (eg storage accounts).

The resource types are listed in resources.ts. For example here's how the rules and information for the 'Resource Group' resource type has been defined:

{
    abbrev: 'rg',
    name: 'Resource group',
    minLength: 1,
    maxLength: 90,
    // https://docs.microsoft.com/en-us/rest/api/resources/resource-groups/create-or-update#uri-parameters
    regex: /^[-\w\._\(\)]+$/,
    description: 'Alphanumerics, underscores, parentheses, hyphens, periods, and unicode characters that match the regex documentation. Can\'t end with period.'
}

Once I've got all the resource type rules done, there's probably scope for more customisation options and other enhancements. I've already had one of my SixPivot colleagues Dylan contribute the 'copy to clipboard' button.

Give it a try and let me know what you think in the comments. If you've got some ideas or would like to contribute additional features, head over to the repo!