The Ops Community ⚙️: Sarah Lean

How to use Terraform to generate secrets

Sarah Lean — Tue, 22 Jul 2025 09:58:48 +0000

Managing secrets like passwords or encryption keys is a critical part of deploying and managing a secure infrastructure. Doing it manually is risky and time-consuming and also can be error-prone.

In this blog post, I’ll walk you through how you can automatically generate a secure password, set an expiry date, and then store it safely in Azure Key Vault all via Terraform.

Let’s dive in.

Pre-requisites

Before we start, make sure you have the following:

Terraform v1.10.0 or later
Access to an Azure subscription
An existing Azure Key Vault
Basic familiarity with Terraform and Azure resources

What we're building

In this blog post we’re going to do the following:

Generate a secure 20-character password
Store the password in Azure Key Vault as a secret
Sets an expiry date on the password when stored within Azure Key Vault

Terraform random module

The Terraform random provider is a handy tool for generating unpredictable values during your infrastructure deployments.

It’s often used to create random strings, passwords, or unique names — which is perfect for when you need something secure or something that is non-repeating.

In this example, we’re going to use the random_password resource to generate a strong 20-character password with a mix of upper-case letters, numbers, and special characters. It’s a simple but effective way to automate credential creation without hardcoding anything sensitive.

Terraform code to generate a secret

Let’s break it down step-by-step. We start by setting the minimum version for the providers to ensure compatibility and stability:

terraform {
  required_version = ">= 1.10.0"
  required_providers {
    azurerm = {
      source = "hashicorp/azurerm"
      version = ">= 3.71, < 5.0.0"
    }
    random = {
      source = "hashicorp/random"
      version = ">= 3.5.1, < 4.0.0"
    }
    azapi = {
      source = "Azure/azapi"
      version = ">= 2.2.0, < 3.0.0"
    }
    time = {
      source = "hashicorp/time"
      version = "~> 0.9"
    }
  }
}

We then configure the AzureRM and Azure AzAPI providers:

provider "azapi" {
  # Configuration options
}

provider "azurerm" {
  features {}
  subscription_id = "XXXX-XXXX-XXXX-XXXX"
}

Next we need to start to pull in some useful data about our existing Azure Key Vault which is going to store our generated secret. This helps Terraform understand which Azure Key Vault to use and who the current Azure user is.

data "azurerm_key_vault" "key_vault" {
  name = var.key_vault_name
  resource_group_name = var.key_vault_rg
}

Next we create the resource, or strong password using the Random module. This will create a random 20-character password that includes special characters, numbers and uppercase letters.

# Generate a random password
resource "random_password" "password" {
  length = 20
  special = true
  upper = true
  numeric = true
  sensitive = true
}

So the secret doesn’t live forever, we give them a 30-day expiry. This code generates a date 30 days from now in RFC3339 format, perfect for use in Azure Key Vault.

resource "time_offset" "expiry" {
  offset_days = 30
}

And lastly we want to store the secret we’ve generated in the Azure Key Vault. This code ensures the secret is stored security, will automatically expire and can be managed centrally in Azure Key Vault.

# Store the generated password in the Key Vault
resource "azurerm_key_vault_secret" "passwordstorage" {
  name = "generated-password"
  value = random_password.password.result
  key_vault_id = data.azurerm_key_vault.key_vault.id
  expiration_date = time_offset.expiry.rfc3339
}

I also have a variables.tf file to store some variables with this Terraform code:


##
# Variables
##

variable "key_vault_rg" {
  description = "The resource group name of the key vault"
  type = string
  default = "rg-rk77"
}

variable "key_vault_name" {
  description = "The name of the key vault"
  type = string
  default = "kv-rk77"
}

Best practices

When you are working with secrets within your code it’s important to strike the right balance between automation and security.

Within your Terraform code you want to make sure you mark any sensitive values like generated passwords as sensitive within outputs or variables. This prevents Terraform from accidentally printing them within the CLI output or logs during pipeline runs.

Also, remember that Terraform state files store everything, including secret values. Using a secure remote backend, like an Azure Storage Account with encryption and access controls, is a must to avoid exposing credentials.

Avoid using terraform output to pass secrets to other systems. Instead, ensure applications securely retrieve secrets directly from Azure Key Vault, that’s ultimately what it’s designed for.

Lastly, ensure you define an expiry date for your secrets and keys. In this example, I used a 30-day offset, but it’s important to build in a regular rotation process too. That could mean rerunning Terraform on a schedule or triggering updates via your CI/CD tool.

These small steps can help keep your automation secure, scalable and production-ready.

Wrapping Up

Automating your secret creation and management with Terraform helps to reduce manual effort and improve security.

By generating secure passwords, applying sensible expiry policies and using something like Azure Key Vault to store those passwords in you are building a strong foundation for managing your sensitive data in the cloud.

This is just one example of how infrastructure as code can help build in those secure and repeatable patterns from here you can introduce rotation policies or even integrate with Azure services, happy automation!

What the terraform providers command tells you

Sarah Lean — Thu, 10 Jul 2025 06:17:59 +0000

When working with Terraform, especially on complex projects, you can end up managing a lot of Azure services and knowing which Terraform providers you are using, how they are sourced and version can be key to ensuring you have Terraform code that is maintainable, easy to debug and easy to collaborate on.

One of the simplest yet most powerful commands in your Terraform toolkit is:

terraform providers

But what does it actually do? Let’s break it down.

What is a Terraform provider?

Before diving into the command, a quick refresher: Terraform providers are plugins that let Terraform interact with APIs of various platforms like Azure, AWS, GitHub, or Kubernetes. They define the resources you can create and manage.

I have a Terraform file that deploys Azure Communication Services and at the start of the code I have these providers defined:

terraform {
  required_version = ">= 1.10.0"
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = ">= 3.71, < 5.0.0"
    }
    random = {
      source  = "hashicorp/random"
      version = ">= 3.5.1, < 4.0.0"
    }
    azapi = {
      source  = "Azure/azapi"
      version = ">= 2.2.0, < 3.0.0"
    }
  }
}

What does the command terraform providers do?

Running: terraform providers will list:

All the providers used in your configuration.
Which modules (if any) use which providers.
Which versions are actually being used.
Where the source of the provider is (e.g. hashicorp/azurerm).

This is incredibly helpful when:

Debugging provider version mismatches
Auditing a repo for compliance
Understanding inherited providers in large or multi-module environments

Example output from your configuration

Using the Azure Communication Services Terraform code, if I run terraform init and then terraform providers, this is the output I get.

Terraform providers command

Terraform returns a structured view showing which providers your configuration and state currently rely on.

In my view, I have two sections, the first is the providers required by configuration sections tells us what providers are currently declared within my Terraform code.

azapi: Used to interact with Azure REST APIs
azurerm: The main provider for deploying Azure resources such as resource groups, etc.
random: I use this within my code to help randomise the Azure region I use.
module.naming: This module also uses the random provider independently, which is why it's listed under the module.

Within my code, I have set a version range for each provider. This helps me safe within tested versions and avoid unexpected breaking changes when new versions are released.

The section section is the providers required by state section which shows which providers are currently in use in the actual Terraform state file—that is, what has already been deployed.

Ideally, what’s in your configuration and what’s in your state should match. In your case, they do, which means your project is in a healthy, expected state. If they didn’t match, it might mean:

You removed a provider from the config, but the resources it created are still managed in state.
You updated a module or version but haven’t run terraform apply yet.

Why This Matters in Real-Life Projects

At first glance, the output from terraform providers might seem like just a list of technical details — something you could ignore once your infrastructure is up and running. But in real-world projects, especially as they grow in complexity or involve multiple teams, understanding this output becomes essential.

One of the key benefits of this command is clarity. It gives you a precise view of which Terraform providers your configuration is depending on, and more importantly, what’s actually in use within your state file. This becomes particularly valuable when you're troubleshooting.

By running terraform providers, you get a clear picture of all dependencies, even the ones nested inside modules. This visibility helps you avoid version conflicts or issues where one part of your infrastructure behaves differently because it relies on a slightly older or newer version of a provider.

In Summary

The terraform providers command isn’t just for show — it’s a core part of understanding and controlling your project’s dependencies. Whether you're building advanced configurations or managing simpler infrastructure, this command gives you visibility into your project's backbone.

Azure Local Solution Categories explained: Validated Nodes, Integrated Systems, and Premier Solutions

Sarah Lean — Wed, 07 May 2025 07:07:31 +0000

Microsoft launched Azure Local (formerly Azure Stack HCI) in December 2020, the launch marked a new operating system (OS) specifically designed for hyper-converged infrastructure (HCI) enabling organisations to run virtualisation workloads on-premises while integrating Azure services for hybrid cloud capabilities.

The rename from Azure Stack HCI to Azure Local happened in November 2024.

When evaluating an Azure Local deployment, it’s important to understand the three main solution categories available: Validated Nodes , Integrated Systems , and Premier Solutions. Each offers different levels of integration, flexibility, and support.

In this article, we’ll break down the differences to help you choose the best fit for your environment.

What is Azure Local?

Azure Local is a hybrid infrastructure solution that allows you to run virtual machines and container workloads on-premises while seamlessly connecting to Azure services.

It’s built on a purpose-specific operating system designed for hyper-converged infrastructure (HCI), enabling organisations to modernise their data centres, extend their cloud capabilities, and maintain control over data locality.

Whether you're running workloads in a branch office, data centre, or edge environment, Azure Local helps bridge the gap between on-premises and the cloud.

Azure Local

Understanding Azure Local’s Solution Categories: Premier, Integrated, and Validated

When you look at purchasing Azure Local there are three distinct solution categories to suit different needs and levels of integration: premier solutions, integrated systems or validated nodes.

While they all provide a path to hybrid infrastructure, they differ in how much is pre-integrated, how updates are managed and how flexible your deployment can be.

What are validated nodes for Azure Local?

Validated nodes give you the most flexibility. You can choose to purchase a complete setup from a hardware vendor, or build your own using individual components from the validated list. For example, if you have a spare server sitting in a cupboard but the network card isn’t on the Azure Local validated component list, you can simply swap it out for one that is. Once all components meet the requirements, you’ve got yourself a validated node ready for an Azure Local deployment.

You're in full control with a validated node, the hardware, deploying the software, managing firmware, driver updates and keeping the Azure Local operating system up to date.

For some end users this option might be daunting but for experienced IT teams or service providers who want a tailored experience this is a great option.

What are integrated systems for Azure Local?

With integrated systems you have hardware that has been validated by the hardware vendor and Microsoft as being compatible and working with Azure Local. And this validation happens anywhere between 2 and 4 times a year.

You get a solution that is tested and supported, but you may need to do a bit more work to apply firmware or driver updates for the hardware before applying any software updates.

One of the advantages of the integrated system is the integrated support queues between Microsoft and the hardware vendor. This means if you have an issue with your Azure Local deployment you can log a ticket with Microsoft who will help to triage it, and if it’s a hardware fault they will work with you and the hardware vendor. And vice versa you could log the ticket with your hardware vendor and if they discover the issue is software related they can work with you and Microsoft to resolve it. This avoids the need for you to log two tickets.

The integrated system option gives you the reassurance of a validated setup but one still gets you some flexibility.

What are Premier Solutions for Azure Local?

With the premier solutions you are getting the most integrated, streamlined path to deploy and manage Azure Local.

There is a close partnership with the hardware vendors and Microsoft from the operating system, drivers, firmware and management tools. The two teams are constantly talking and ensuring everything works together seamlessly.

Updates for hardware and software are delivered in a coordinated way, reducing the risk of compatibility issues and also ensuring it’s a straightforward one step process to deploy those updates.

The premier solution also has the advantage of the integrated support queues between Microsoft and the hardware vendor.

You also have proactive call-home support services available which could automatically alert Microsoft or the hardware vendor of faults.

Microsoft partners already offer more than 100 Azure Local solutions in the Azure Local catalog.

Choosing the right solution category

It’s important to pick the right solution category for your needs and budget. In very simplified terms you can look at the three options like this:

Validated = DIY and customisable
Integrated = Balance of control and support
Premier = Turnkey, enterprise-ready solution

You can compare the different solution categories here.

Azure Local solution categories

Conclusion

Azure Local offers a flexible and modern path to hybrid infrastructure, and choosing the right solution category is key to a successful deployment and experience. Whether you need full control or a balanced approach or a full turnkey solution there is an option to suit your business goals, skills and budget.

Take time to explore the Azure Local catalog and speak to your hardware partner or Microsoft representative to explore options and find the right fit for you.

Terraform depends_on: What it is, When to use it, and Best Practices

Sarah Lean — Wed, 07 May 2025 07:01:07 +0000

When working with Terraform, managing resource dependencies effectively is key to avoiding deployment issues. Terraform is great at automatically determining the order of resource creation, but sometimes it needs a little help, this is where depends_on comes in.

In this guide, we’ll explain Terraform depends_on, how to use it, when to use it, and best practices for writing clean and efficient Terraform code.

What is Terraform depends_on?

Terraform’s depends_on is a meta-argument that allows you to specify an explicit relationship between resources. When you use it you can enforce an order in which resources should be created or updated.

When you configure Terraform, it analyses its dependency graph to understand the relationships between different resources. This graph helps Terraform determine the order in which resources should be created, updated, or destroyed. But, this might not always be enough when you are dealing with complex or non-obvious relationships between resources.

This is where the Terraform depends_on meta-argument can be used to add explicit dependencies.

How to use depends_on in Terraform

Using the depends_on meta-argument in Terraform is straightforward. Here is an example of syntax:


resource "azure_resource_type" "resource_name" {
  #resource configuration

  depends_on = [azure_resource_type.dependent_resource_name]
}

A bit more of a working example would be:


resource "azurerm_resource_group" "example" {
  name = "example-rg"
  location = "East US"
}

resource "azurerm_storage_account" "example" {
  name = "examplestoracct"
  resource_group_name = azurerm_resource_group.example.name
  location = azurerm_resource_group.example.location
  account_tier = "Standard"
  account_replication_type = "LRS"
}

resource "azurerm_virtual_machine" "example" {
  name = "example-vm"
  resource_group_name = azurerm_resource_group.example.name
  location = azurerm_resource_group.example.location
  network_interface_ids = []

  vm_size = "Standard_B1s"

  depends_on = [azurerm_storage_account.example]
}

Now in the example above you don't necessarily need to ensure the storage account to be created before the virtual machine, but you may have a specific use case for doing this.

Remember that the depends_on meta-argument will accept a list of resources, enabling you to tell the Terraform code that multiple dependencies exist.

When to use depends_on in Terraform

You should only really use the depends_on within your Terraform code when the implicit dependencies are not enough.

Here are some situations where the depends_on will make sense:

Sometimes resources take a long time to fully provision, you can use the depends_on to help you manage this timing issue.
When working with Terraform provisioners (like local-exec and remote-exec) run scripts or commands during deployment. Terraform doesn’t track script execution state so depends_on may help ensure things are deployed in the correct order.
Terraform modules may not always recognise dependencies between separate module calls, you can use depend_on to force execution order.

Best practices for Terraform depends_on

The depends_on meta-argument is a powerful tool, however, overuse or incorrect use of it can lead to complications in your Terraform configurations. Here are some best practices to consider when working with it:

Rely on implicit dependencies whenever possible, only resort to depends_on when there is no other viable option.
When you do use the depends_on option, make sure you document why so other team members, or you at a later date understand why it’s there and can avoid adding in unintended complexity.
Be sure to check during version upgrades or providers or modules if any changes affect the implicit or explicit dependencies, as sometimes updates can lead to unexpected behaviour in your code.
Best sure to test any dependencies you implement into your code and ensure it causes no issues.

Conclusion

Terraform’s depends_on meta-argument is a useful tool when implicit dependencies aren’t enough, ensuring that resources are created in the right order.

By following best practices, such as relying on implicit dependencies where possible, documenting explicit dependencies, and testing your configurations, you can keep your Terraform code clean, efficient, and maintainable.

Use depends_on wisely, and your Terraform deployments will be more reliable and predictable—helping you avoid unnecessary complexity and troubleshooting headaches.

Terraform Dependencies: Implicit vs. Explicit Explained

Sarah Lean — Tue, 29 Apr 2025 09:25:53 +0000

When you are creating resources through Infrastructure as Code (IaC) either you or our coding tool have to understand how each resource needs to be created. Which order to deploy them in so they all deploy correctly. There are two ways of handling this challenge, implicit and explicit dependencies. In this blog post we’ll define what those two types of dependencies are, show you examples and share some best practices and common pitfalls.

What are Terraform dependencies?

In Terraform, dependencies define the order in which resources should be created, updated, or destroyed. Since many infrastructure components rely on others (e.g., a virtual machine needing a network to connect to), Terraform must understand these relationships to deploy resources in the correct order.

Terraform has a built-in dependency management system that automatically determines the correct order for most resources. However, sometimes Terraform needs additional guidance, which is where explicit dependencies come into play.

There are two types of dependencies in Terraform:

Implicit Dependencies – Automatically detected when a resource references another resource’s attributes.
Explicit Dependencies – Manually defined using the depends_on meta-argument when Terraform cannot infer dependencies correctly.

Implicit dependencies in Terraform

An implicit dependency within Terraform is when Terraform automatically detects dependencies when a resource references another resource’s attributes.

In the example below Terraform automatically understands that there is a dependency that the resource group needs to be greeted before the virtual network because we’ve referenced the resource group name in our virtual network configuration.

resource "azurerm_resource_group" "example" {
  name = "rg-example"
  location = "UK South"
}

resource "azurerm_virtual_network" "example" {
  name = "networking"
  resource_group_name = azurerm_resource_group.example.name
  location = azurerm_resource_group.example.location
  address_space = ["10.0.0.0/16"]
}

Explicit dependencies in Terraform

An explicit dependency within Terraform is when Terraform doesn’t detect dependencies correctly and you need to use the depends_on meta-argument to ensure resources are created in the correct order.

In the example below we are making sure Terraform makes absolutely sure that things are created in the right order with our depends_on. Even though Terraform should be able to figure it out from other references we’re making it crystal clear.

resource "azurerm_netapp_account" "example" {
  name = "example-netapp-account"
  location = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name
}

resource "azurerm_netapp_pool" "example" {
  name = "example-netapp-pool"
  location = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name
  account_name = azurerm_netapp_account.example.name
  service_level = "Premium"
  size_in_tb = 4

  depends_on = [azurerm_netapp_account.example]
}

resource "azurerm_netapp_volume" "example" {
  name = "example-netapp-volume"
  location = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name
  account_name = azurerm_netapp_account.example.name
  pool_name = azurerm_netapp_pool.example.name
  volume_path = "examplevolume"
  service_level = "Premium"
  subnet_id = azurerm_subnet.example.id
  protocol = "NFSv4.1"

  depends_on = [
    azurerm_netapp_account.example,
    azurerm_netapp_pool.example
  ]
}

Common pitfalls and best practices

Implicit dependencies should be your first port of call in Terraform since they are automatically detected and Terraform handles the ordering and deployment for you. To minimise potential issues:

Always document why you’ve included an explicit dependency in your code so others looking at your code can understand why it was included.
Try to use implicit dependencies as much as possible and avoid over use of explicit dependencies as it can add in complexity when it is not needed.
Think about how you write your code, sometimes organising your resources into modules can help management dependencies more efficiently.
Remember to run terraform plan before applying changes as this can help detect any misconfigurations around dependencies.

Conclusion

Terraform can automatically handle dependencies based on resource references but sometimes it needs help and you have to manually build dependencies into your code using the depends_on meta-argument.

However, if you understand the concepts of implicit and explicit dependencies you can help to build smoother Terraform deployments and more robust infrastructure.

Microsoft Defender for Storage: Threat Detection & Protection for Your Data

Sarah Lean — Mon, 21 Apr 2025 10:07:00 +0000

Ensuring your environment is secure goes beyond just installing an anti-virus security product on your servers. You need to think about protecting your storage, your apps, containers, databases, identity and much more… And you need to pick the right product to protect those workloads.

In this article, we’ll explore how Defender for Storage works, its key features, pricing, and how to enable it within the Azure portal.

What is Microsoft Defender for Storage?

Microsoft Defender for Storage is a cloud-native security solution that is designed to protect Azure Storage accounts from various threats. It provides threat detection by analysing data access patterns, scanning for malware and leveraging Microsoft’s threat intelligence.

Defender for Storage supports Azure Blob Storage, Azure Files, Azure Data Lake Storage and Azure Queues and Tables.

Defender for Storage integrates with Microsoft Defender for Cloud, ensuring you receive security alerts and recommendations to enhance your cloud security posture.

How Defender for Storage works

Defender for Storage provides multiple layers of protection. One of the layers is malware scanning. It scans any files uploaded to Azure Blob storage for known threats and also uses Microsoft’s threat intelligence database to detect and prevent malware distribution.

Another layer of protection is anomaly detection. Defender for Storage will identify any unusual access patterns that might indicate an insider threat or a cyberattack. It will look for anomalies such as massive file downloads, data exfiltration or repeated failed access attempts.

The other area of protection Defender for Storage offers is threat intelligence integration , where it leverages Microsoft’s global security insights to detect threats. An example would be if a known malicious IP tries to interact with a storage account.

The generated alerts or recommendations are displayed within Microsoft Defender for Cloud and can be integrated into Microsoft Sentinel for automated security responses if necessary.

Defender for Storage pricing

Defender for Storage can be enabled at the resource level or at the subscription level and you do have the ability to exclude specific storage accounts from being included if you wish.

Defender for Storage is charged per storage account per month. Currently, the price is $10 per storage account per month (US Dollars).

It’s worth noting that malware scanning is an add-on and is charged at $0.15/GB of data scanned. But you can configure a monthly cap so that costs are predictable.

Enable Defender for Storage with the Azure portal

You can enable Defender for Storage at the subscription level or at an individual storage account level. It is recommended you enable it at the subscription level to ensure full coverage within your environment.

To enable it at the subscription level follow these steps:

Sign in to the Azure portal.
Navigate to Microsoft Defender for Cloud management blade.
Expand Management then select Environment settings.

Microsoft Defender for Cloud

Select the subscription for which you want to enable Defender for Storage.
Select the three dots on the right and then choose the Edit settings option.

Microsoft Defender for Cloud environment settings

On the Defender plans page, locate Storage in the list and select On and Save.

Microsoft Defender for Cloud environment settings

Defender for Storage is now enabled across your subscription, including the malware protection. You can turn this off by going back into settings and turning it off.

Any storage accounts that are created after enabling Defender for Storage will be protected up to 24 hours after creation.

Conclusion

Securing your environment requires a well-thought-out strategy and goes beyond traditional anti-virus solutions. Microsoft Defender for Storage provides a cloud-native solution to detect threats, prevent malware, and leverage Microsoft’s threat intelligence to keep your Azure Storage accounts secure.

In today’s landscape, choosing the right security tools is essential, and Defender for Storage is a powerful addition to your overall security strategy.

Dev Container Setup for Hugo

Sarah Lean — Fri, 18 Apr 2025 10:06:29 +0000

Imagine a development environment where you never have to worry about mismatched library versions, missing dependencies, or spending hours setting up a new project. Dev containers in Visual Studio Code (VS Code) are here to make that a reality. These Docker-powered environments are tailored to your codebase, ensuring everything runs smoothly, consistently, and with minimal setup.

In this guide, I’ll walk you through the process of setting up a dev container from scratch and setting it up for your Hugo project. Let’s get started!

What are Dev containers in VS Code?

Development containers, or dev containers within Visual Studio Code (VS Code), are Docker containers configured to provide a fully featured development environment you can work within.

What is the point of Dev containers?

Dev containers can configured to run an application, to have separate tools, libraries runtimes, dependencies, or whatever is needed to run your codebase.

How many times have you worked on a project and had problems trying to set up your laptop to have the right version of a library or runtime and had trouble and wasted hours? If you set up a dev container you can be sure the environment is set up for that codebase, and better yet you can share the dev container with colleagues making their life easier to work on that codebase as well.

Prerequisites

Whether you are a macOS user or a Windows user, you need to have the following installed:

Visual Studio Code (VS Code)
Dev Containers extension installed

_I have prepared this guide as a Windows user, steps may be different for macOS users. _

Dev Container Setup

In the bottom left-hand corner of VS Code click on the container button.

VS Code dev container setup

The setup wizard will pop up at the top of your screen.

When it does click on New Dev Container

VS Code dev container setup

The setup wizard will check if Docker is already installed, if it’s not it will ask if you want to install Docker within WSL , say Install , as this will install Docker within the Windows Subsystem for Linux.

VS Code dev container setup

Once the installation has been completed, restart your laptop and relaunch VS Code.

Click on the button in the button in the left-hand corner of VS Code again.

VS Code dev container setup

The setup wizard will pop up at the top of your screen.

When it does click on New Dev Container

VS Code dev container setup

The next step is to select the template you would like to use. In this case, I am going to select the Ubuntu configuration template. This template already has Git installed.

VS Code dev container setup

The container will launch and start to set up the necessary parts for it to be usable.

When it finishes loading click on the container button in the left-hand corner again. This will pop up the menu again. Be sure to select Configure Container Features. We are now going to install Hugo and Go.

VS Code dev container setup

Search for Go. There are several options, but I use the official dev containers version. Click *OK. *

VS Code dev container setup

You’ll be asked how you want to configure this installation, select *Keep Defaults. *

Next search for Hugo. There should only be one option, select it and click *OK. *

This time you want to select *Configure options. *

Select the version you want to install, I always go for the latest. Next, you will be asked if you want to install the extended version of Hugo or not, again I always select yes to this as some themes need it.

VS Code dev container setup

When you’ve selected these options, VS Code will alert you that your container configuration has changed and needs to be rebuilt. Be sure to rebuild it.

(adsbygoogle = window.adsbygoogle || []).push({});

Create Hugo website

First of all, we have to create a new site. In the root folder then run:

hugo new site . --force

In the project I have created, I have installed Hugo bigspring-light theme. Let’s see how.

In the root folder run:

git clone https://github.com/gethugothemes/bigspring-light-hugo themes/bigspring-light

And the last step, let’s copy the example content located in mynewsite/themes/bigspring-light/exampleSite/.

cp -r themes/bigspring-light/exampleSite/* .

We are now ready to build and serve our new site. Let’s run:

hugo server

The VS Code dev container will automatically configure any port forwarding for you. It’s worth noting that this Hugo theme shows the example website at https://ipadress:port/bigspring/site

If we want to automate the building and the serving actions, we can add a postStartCommand property, with Hugo server set, to the devcontainer.json file.

{
    "name": "Ubuntu",
    // Or use a Dockerfile or Docker Compose file. More info: https://containers.dev/guide/dockerfile
    "image": "mcr.microsoft.com/devcontainers/base:jammy",
    "features": {
        "ghcr.io/devcontainers/features/go:1": {
            "version": "latest"
        },
        "ghcr.io/devcontainers/features/hugo:1": {
            "extended": true,
            "version": "latest"
        }
    },
    "postStartCommand": "hugo server"
}

In this way, the next time you start the container again, the hugo server command will be run automatically.

Wrap Up

Dev containers in VSCode can be a game changer for engineers working on multiple projects as it offers a consistent, reliable and shareable environment for your individual project. By following this guide, you’ve learned how to set up a dev container from scratch, configure it for a Hugo project, and even automate tasks like building and serving your site.

Whether you’re working on a team or solo, dev containers eliminate the headaches of environment mismatches and setup struggles. Plus, the ability to share your container configuration ensures everyone can hit the ground running.

Happy coding!

What Are Dev Containers?

Sarah Lean — Wed, 26 Mar 2025 08:08:31 +0000

With modern development it can be complex, Engineers and developers juggle multiple projects, each with unique tools, dependencies, and configurations. Switching between these environments or collaborating with others often leads to frustration and wasted time.

This is where Dev Containers can play a huge role. In this article, we’ll explore what Dev Containers are, why they’re worth using, and how they can simplify your workflow while boosting collaboration and productivity.

What Are Dev Containers?

Have you ever heard the phrase, “It works on my machine”?, it’s a common frustration among software developers, or anyone who works within development environments.

Maintaining a development environment that works for all your projects can be a frustrating and never-ending battle.

This is where Dev Containers can help, no matter what machine you are working on.

Dev Containers are portable, lightweight environments configured using Docker containers. They allow engineers to define and share their development environment through configuration files.

With Dev Containers your entire environment - all the dependencies, tools, and extensions are defined within code and that means it’s easy to spin up a container and reproduce that environment and share it with colleagues to ensure consistency. So we can stop hearing that “it works on my machine” phrase.

Why Use Dev Containers?

Beyond the consistency reason to use Dev Containers there are a number of benefits you can see if you start to work with them.

Solve dependency issues: We’ve all faced it. Mismatched library versions or incompatible runtime environments. When we encapsulate our environment all inside a Dev Container those issues don’t exist, you can spend time working on the code instead of trying to find the right library to install.
Portability: Maybe you have a Windows laptop and a MacBook you work on. Dev Containers work on either, you can switch between those two machines, fire up your Dev Container and have a consistent environment to work on, regardless of the hardware you are using or the operating system.
Experimentation without risk: If you want to try a new tool or new library or framework, you can spin up a Dev Container and try it without breaking your local environment. Experiment without causing issues is a great way of learning.
Seamless integration with tools : Dev Containers work seamlessly with tools like Visual Studio Code (VS Code), if you install the Dev Containers extension within VS Code it will automatically detect the Dev Containers configuration file and sets up the environment for you.  (adsbygoogle = window.adsbygoogle || []).push({});  ### Best Practices for Using Dev Containers

When you are running Dev Containers there are some best practices you should follow:

Include your .devcontainer folder in your version control system, this ensures that everyone on your team can access the same configuration and changes to it are tracked.
Only include tools and dependencies you actually need, don’t make it to complex.
When you are creating your devcontainer.json configuration file make sure you add in comments so that others can understand the setup and stay informed of any changes to it.
Containers can sometimes introduce performance overhead, particularly on systems with limited resources. Optimize your Docker settings and ensure that your base image is lightweight.

Conclusion

Dev Containers can be game changers to ensure that everyone has a consistent and reliable workspace to develop within.

Whether you are collaborating with a large team, working on open-source projects, or even just looking for a cleaner way to manage your development environment, Dev Containers are work exploring.

Visualising data with KQL

Sarah Lean — Thu, 13 Mar 2025 08:34:32 +0000

Ever struggled to make sense of endless rows of raw data? With Kusto Query Language (KQL), you don’t have to. Built-in data visualisation tools allow you to turn complex datasets into intuitive charts and graphs, making insights easier to grasp and share. Read on to explore how to harness these features and take your data storytelling to the next level.

What is data visualisation in KQL

Kusto Query Language (KQL) has data visualisation capabilities built into the language. So you can turn raw data into graphical representations. This can include charts, graphs, and other visual formats that make the data more comprehensible and actionable.

With this feature, it means you can start to build out Azure Monitor workbooks or Azure Dashboards visualisations to help make the raw data more accessible to a wider audience and easier to understand at a quick glance.

KQL Render Operator

The render operator within the KQL language has eleven different options for rendering your data.

Anomaly Chart
Area Chart
Bar Chart
Card
Column Chart
Line Chart
Pie Chart
Scatter Chart
Stacked Area Chart
Table
Time Chart

The render operator should be the last operator used in any of your queries. It can only be used with queries that produce a single tabular data stream result. The render operator doesn’t modify the data; instead, it injects a visualisation into the query result’s extended properties.

An example query would be:

StormEvents
| summarize EventCount = count() by State
| sort by EventCount desc
| where State != ""
| take 10
| render columnchart

Azure Data Explorer data visualisation

Other supported properties are optional for you to build your chart as well. If we look at the query below we can elaborate on the render line:

StormEvents
| summarize sum(DamageProperty)by State
| lookup PopulationData on State
| project-away State
| render scatterchart with (xtitle="State population", title="Property damage by state", legend=hidden)

The render line of the query carries out the following:

Creates a scatter chart to visualise the data.
X-axis (xtitle) represents the state population.
Y-axis implicitly represents property damage (from DamageProperty).
The chart title is set to "Property damage by state."
The legend is hidden for a cleaner visualisation.

KQL data visualisation

(adsbygoogle = window.adsbygoogle || []).push({});

Data visualisation in PowerBI

While you can build Azure Monitor Workbooks or Azure Dashboards using the KQL queries and visualisations there are times when you might want to visualise the data in PowerBI.

You can pull data from your KQL databases or Azure Resource Graph from your Azure environment into a PowerBI report.

Check out the video tutorial showing you how to pull in Azure Resource Graph data into PowerBI.

Conclusion

KQL’s data visualisation capabilities open up a world of possibilities for transforming raw data into meaningful insights. Whether you’re using Azure Monitor Workbooks, Dashboards, or PowerBI, these tools make it easier to understand and communicate your data’s story.

Ready to dive deeper into KQL? Check out my other blogs for more tips and examples, and don’t forget to subscribe to stay updated with the latest content. Let’s unlock the full potential of your data together!

Advanced Windows Server Management Enabled by Azure Arc

Sarah Lean — Fri, 07 Mar 2025 15:26:03 +0000

At Microsoft Ignite 2024 Microsoft announced the general availability of Windows Server management enabled by Azure Arc. This allows Windows Server customers with Software Assurance access to certain Azure management services at no extra cost and add some additional management features that are only available through this offering.

Also as part of this announcement, you can now buy Windows Servers licenses for your Arc Arc enabled servers on a Pay As You Go basis through the Azure Portal.

Let’s break down what these announcements mean and how you can actually make them work for you within your environment.

Windows Server Pay-as-you-go licensing

Licensing can be complicated and also expensive. And depending on your procurement processes purchasing a new Windows Server license may take too long for your project timeline.

This is where the new Azure Arc Pay-as-you-go licensing option for Windows Server 2025 can be quite useful.

You can deploy a Windows Server device on-premises, Arc enable the device and then license it, and you only pay for as much as you use. So if that new Windows Server 2025 device is live for 30 days and then deleted, you only pay for the license for those days.

The charges will be billed via your Azure subscription.

While I am no expert in licensing and you should also check the documentation or consult your licensing provider there are some things you should be aware of with the Pay-as-you-go license:

There are no client access licenses (CALs) required for standard functionality. However, Remote Desktop Services (RDS) CALs are still required.
It doesn’t provide additional rights for virtual machines (VMs) running on the same server.
Pay-as–you-go licensing is only available for Windows Server 2025 Standard or Datacenter edition.

Set up Windows Server Pay-as-you-go

When you install Windows Server 2025 the setup will ask you the licensing method you wish to use, ensure you select Pay-as-you-go, this will allow you to continue the install without providing a product key.

Once the operating system is installed on your device, you need to install the Azure Arc agent onto the server.

The next step is to enable the license via the Azure Portal.

Head to https://portal.azure.com
Locate the Azure Arc management blade
Click on Azure Arc resources > Machines
Select the machine you wish to license
Expand Licenses > Windows Server

Windows Server Pay-as-you-go licensing via Azure Arc

Tick the Pay-as-you-go with Azure box
Click Confirm

Windows Server Pay-as-you-go licensing via Azure Arc

The server is now licensed and you will be billed via your Azure subscription.

Key features and benefits for Windows Server Management enabled by Azure Arc

If you are using Windows Server Pay-as-you-go licensing or have Windows Server licenses with Software Assurance (SA) Microsoft are offering a lot of management services within Azure, many of which are included at no additional cost. Additionally, some new management features are available:

Azure Update Manager: This feature allows you to assess the update status of your servers and deploy updates ensuring you are always up-to-date with the latest security patches and improvements. _Available to Windows Server 2012 and above. _
Azure Change Tracking and Inventory: This tool within Azure allows you to monitor changes made to your server such as software, services, files and registry helping you to quickly identify any changes that have been made. ** ** With this there are additional costs of storing data within Log Analytics. _Available to Windows Server 2012 and above. _
Azure Machine Configuration: This feature allows you to configure machine properties using Azure Policy, ensuring a consistent configuration across all servers. ** ** _Available to Windows Server 2012 and above. _
Windows Admin Centre in Azure for Arc: This tool allows you to be able to manage your server from anywhere, without the need for VPNs or public IP addresses. It includes capabilities like RDP, Hyper-V management and event viewer. _Available to Windows Server 2016 and above. _
Remote Support: This feature offers professional support with just-in-time access, revocation rights and more. ** ** _Available to Windows Server 2016 and above. _
Network HUD: A host networking diagnostics and operational tool that runs spot checks, health checks, and cluster-wide checks to ensure optimal network setup. Available to Windows Server 2025 only.
Best Practices Assessment: This collects and analyses server data to help provide guidance on how to optimise performance, security, and adhere to best practices. ** ** With this there are additional costs of storing data within Log Analytics. _Available to Windows Server 2016 and above. _
Azure Site Recovery Configuration: Helps to configure Azure Site Recovery to ensure business continuity and provides replications and data resilience for critical workloads. With this there are additional costs with the VM replication. _Available to Windows Server 2016 and above. _

Set up Windows Server Management enabled by Azure Arc

From your browser head to https://portal.azure.com
Navigate to the Azure Arc management blade.
Under Licenses select Windows Server Azure benefits and licenses

Set up Windows Server Management enabled by Azure Arc

Select the Azure Arc-enabled servers that are eligible for enrolment (those that have Windows Server Software Assurance licenses or using the Pay-as-you-go licensing)
Now select Activate Azure benefits

Activate Windows Server Management benefits

Review the terms and select the checkbox
Now select Activate

Activate Azure benefits

It may take up to 10 mins for the activation to happen.

Conclusion

The introduction of Pay-as-you-go licensing for Windows Server 2025, alongside the expanded benefits for Windows Server Software Assurance customers, provides greater flexibility and cost efficiency for organisations. With enhanced management capabilities through Azure Arc, businesses can streamline operations, improve security, and simplify licensing.

If you haven’t yet Arc-enabled your on-premises servers, now is the perfect time to explore these new capabilities and make the most of what Azure Arc has to offer.

Documenting your KQL queries

Sarah Lean — Fri, 28 Feb 2025 20:01:47 +0000

Documentation is important. It helps your colleagues to understand why you did something. It helps you later on remember why you did something.

Documenting your Kusto Query Language (KQL) queries is just important.

In this blog, we’ll explore why documenting your queries matters, how to write effective comments in KQL, and practical tips for maintaining clarity and structure.

Why documenting queries matters

There are several benefits to documenting your queries.

When something breaks, clear comments and documentation make troubleshooting faster.
Team members can quickly understand your query logic, even if they didn’t write it.
Documentation reduces the learning curve for new team members.
Clear notes help you (or someone else) understand the query’s purpose months or years later.

Imagine encountering this query months after writing it:

SecurityEvent 
| where EventID == 4625 
| summarize count() by AccountName

Without comments, you might not remember the query’s purpose. Proper documentation solves this problem.

How to add comments in KQL

Within KQL you can denote a comment using two forward slashes: //

You can use this either on a single line or multiple lines.

An example query would be:

// Filter for failed login attempts
SecurityEvent
| where EventID == 4625

Alternatively, you could write a more in-depth description in your query like this:// Show Microsoft Defender for Cloud pricing per subscription

// Returns Microsoft Defender plans’ pricing per subscription.
// 
// The query uses 'project' to show the listed properties in the results. You can add or remove properties.
// 
securityresources
| where type == 'microsoft.security/pricings'
| project Subscription= subscriptionId, Azure_Defender_plan= name, Status= properties.pricingTier

Every line that you want to to write a comment on, or if you are leaving blank lines need to start with the two forward slashes. If not they might be mistaken as part of the query, which could cause problems when you run the query.

You can also add comments per line such as this:

SecurityEvent // The dataset
| where TimeGenerated > ago(1h) // Activity in the last hour
| where EventID == 4624 // Successful logon
| where AccountType =~ "user" // case insensitive

Over the years I’ve learnt that well-placed documentation or comments in queries can be really helpful. Some of the things I include in comments on my queries:

The purpose of the query and what it is trying to achieve.
Explaining key steps, especially on multi step or complex queries.
Assumptions or limitations. For example if a time or date is part of the query, I explain if it’s using American date format (MM/DD/YYYY) or if it’s using European/International date format (DD/MM/YYYY).
Who created the query and when.

Conclusion

Documenting your KQL queries isn’t just best practice - it’s necessary to help with collaboration, debugging and future-proofing.

Add purposeful comments to your queries and they’ll become a valuable library over time.

Start documenting your queries today, and share your favourite tips in the comments!

Azure Local licensing explained

Sarah Lean — Thu, 20 Feb 2025 08:30:50 +0000

When planning your hybrid cloud strategy, it's crucial to consider not just the technical capabilities but also the costs involved. Azure Local (formerly Azure Stack HCI) is an excellent solution for organisations looking to run virtualised, containerised, and virtual desktop workloads while maintaining a hybrid setup.

By bridging on-premises systems with Azure, it provides flexibility for workloads that can't—or shouldn't—be fully moved to the cloud.

However, understanding the hardware and licensing costs is vital to properly budgeting for your Azure Local deployment. In this post, we’ll break down the various licensing options available and how they can impact your overall costs.

Azure Local hardware costs

There is of course the cost of the hardware. Which you would buy direct from the hardware vendor, whether that be Dell, HP, Lenovo, or another vendor.

Microsoft provides an up-to-date catalog of certified Azure Local solutions, making it easy to find options that suit your budget and computing needs.

There are lots of options available to suit your budget, location and computing needs.

Azure Local catalog

Azure Local licensing models

Beyond the hardware costs you need to think about the software or licensing costs.

It costs to run Azure Local. But there are a number of ways you can pay for that.

Per-core licensing

With per-core licensing, purchased directly from Microsoft, costs are calculated based on the physical processor cores in your hardware.

This option is priced at $10 USD per month per physical processor core.

_This cost doesn’t include the guest operating system (OS) licensing for any virtual machines (VM) running within the Azure Local configuration. _

OEM licensing

The OEM licensing option is something that exclusively comes from your OEM partner. It is a pre-installed license that is activated in Azure.

The license is valid for the lifetime of the hardware that the Azure Local is installed on.

Azure Hybrid Benefits

Azure Hybrid Benefit was first introduced to help reduce the costs of running your workloads in the cloud. Enabling those customers who had purchased Windows Server with Software Assurance to use that license in Azure and avoid having to pay licensing costs on any virtual machines there.

Since Azure Local is considered an Azure service, you can access Azure Hybrid Benefits on Azure Local.

But it goes one step further, as it waives the Azure Local host costs as well.

So let’s look at this in terms of a real-world example. You are refreshing your on-premises virtualisation solution. For non-Microsoft solutions you will need to consider both the hardware and hypervisor licensing costs. And hypervisor licenses can be expensive and you still need to purchase any Windows Server licenses you need for your Windows workloads. This means your total cost includes hardware, hypervisor licensing, and Windows Server licensing.

With Azure Local, you can use your Windows Server Datacenter licenses with Software Assurance to cover the hypervisor license and the Windows server workload costs as well. So you only have the HARDWARE costs to consider.

How to buy Azure Local licenses

Depending on the license type that you wish to use there are different people you need to talk to.

For the per-core licensing, you can buy that direct through the Azure portal.

For the OEM licensing your hardware vendor should be able to facilitate that cost and conversation with you.

And for Windows Server licenses with Software Assurance you should chat to your Licensing Solution Provider (LSP). They’ll be able to advise you of what licenses you currently have and quote for any additional licenses you need.

💡

Disclaimer

Licensing can be complex and nuanced.

There are lots of caveats and gotchas in each licensing model for Azure Local, so be sure to speak to the relevant people. Read the terms and conditions, the small print. And understand it fully for your scenario.

This blog post is intended to be an explainer to the licensing options you have, so you can cost up your Azure Local project properly and be able to compare it to other options out there fairly. It's not intended to be a deep dive into all the options and small print.

(adsbygoogle = window.adsbygoogle || []).push({});

Conclusion

Azure Local provides a powerful and flexible solution for hybrid cloud scenarios, allowing you to modernise your infrastructure while leveraging existing investments like Windows Server licenses with Software Assurance.

But remember to make a truly information decision you need to understand the licensing models and ensure the option you choose aligns with your organisation’s needs.

To ensure success, consult with hardware vendors, Licensing Solution Providers, and Microsoft to evaluate your licensing needs and calculate costs effectively. When approached thoughtfully, Azure Local can be a cost-effective and future-ready solution for your hybrid cloud journey.