DEV Community: evdbogaard

Running MLflow in Azure Container Apps: Lessons from our setup

evdbogaard — Tue, 30 Sep 2025 07:18:39 +0000

We have been doing more and more work with prompting, and we wanted a way to keep track of which prompts were used, how many tokens they consumed, and what the resulting output was. Just as important, the data needed to be available to everyone on the team so we could all learn from the results. To support this, we decided to set up an MLflow server.

MLflow is an open-source platform for managing the machine learning lifecycle. While it is often used for tracking experiments and storing models, we mainly used it for tracking our prompt runs and related metadata. At first, one team member ran MLflow locally in a Docker container, which worked fine as long as only one person needed it. But as the project grew this was no longer sustainable. We wanted a setup that was reliable, shareable, and preserved our experiment history. Our main goals were to put MLflow online and connect it to a SQL database for persistent storage. Our first thought was simple: take the same Docker image and run it inside an Azure Container App. Easy, right? Unfortunately, we hit some difficulties along the way.

In this blog, we'll walk through the initial docker run command we used locally, all the way to the final version that worked in Azure. Along the way, we explained the hurdles we encountered and how we solved them.

Running locally

The command to run MLflow locally was:

docker run -it -p 5000:5000 ghcr.io/mlflow/mlflow mlflow server --host 0.0.0.0

The most important part of the command was the --host 0.0.0.0. By default, the MLflow server only accepted connections from the local machine. It needed the --host argument to accept connections from other machines as well. The -p 5000:5000 mapped port 5000 from the container to localhost.

The command mlflow server was required as a startup command for the image to actually start the server. Without it, nothing would start.

Running MLflow like this meant all data was stored locally in the container's filesystem. This was a problem, because as soon as the container was deleted, all stored data was lost.

Artifact and backend store

As stated before, all data was stored in a simple folder structure. With only one or two people using MLflow, this could work as changes were appended to existing files. However, there were no concepts like file locks to prevent multiple people from writing simultaneously. The more people used MLflow, the higher the chance of corrupting these files.

To solve this MLflow has the option to configure external stores where it can send its information so it's safely stored outside the container.

MLflow had two types of stores to preserve information about runs:

Backend store: stores metadata about runs (IDs, start and end times, parameters, metrics, tags, logs, etc.)
Artifact store: stores artifacts for each run (model weights, images, logs, etc.)

Setting up database store

MLflow supports a wide range of databases for the backend store. As we were already using Azure SQL Database, we decided to use that for MLflow as well.

To tell MLflow to use a database we added the following argument to the Docker run command:

--backend-store-uri "mssql+pyodbc://{dbUser}:{dbPassword}@{dbServer}.database.windows.net/{dbName}?driver=ODBC+Driver+18+for+SQL+Server&Encrypt=yes&TrustServerCertificate=no&Connection+Timeout=30"

When we added this argument, MLflow failed to start because the base image did not have all the required dependencies for MSSQL. To solve this, we created our own Dockerfile and installed the missing dependencies.

FROM ghcr.io/mlflow/mlflow:latest

USER root

RUN apt-get update && apt-get install -y \
    curl gnupg2

RUN curl https://packages.microsoft.com/keys/microsoft.asc | apt-key add - && \
    curl https://packages.microsoft.com/config/debian/11/prod.list > /etc/apt/sources.list.d/mssql-release.list && \
    apt-get update && ACCEPT_EULA=Y apt-get install -y msodbcsql18

RUN pip install --no-cache-dir pyodbc

USER 1000

This ensured both msodbcsql18 and pyodbc were installed. With these, MLflow started successfully, but as explained earlier, we still needed an artifact store or else information about individual runs would be missing.

Setting up the artifacts store

MLflow supports multiple artifact storage types, such as Amazon S3, Azure Blob Storage, and Google Cloud Storage. Since we were most familiar with Azure, we used Azure Blob Storage.

To point MLflow to Azure Blob Storage, we used the following argument:

--artifacts-destination wasbs://{blobContainerName}@{storageAccountName}.blob.core.windows.net/

For authentication, there were two options:

Connection string: By passing in an environment variable to the container MLflow would automatically use it to connect to the correct Storage Account (-e AZURE_STORAGE_CONNECTION_STRING="DefaultEndpointsProtocol=https;AccountName={storageAccountName};AccountKey={storageAccountKey};EndpointSuffix=core.windows.net")
Role-Based Access Control (RBAC): our preferred option, since we have been moving away from using keys and connection strings as much as possible in Azure

To use RBAC, we removed the connection string and added two Python packages in our Dockerfile:

azure-storage-blob: required for both RBAC and connection strings
azure-identity: required for RBAC

RUN pip install --no-cache-dir pyodbc azure-storage-blob azure-identity

Bringing it to Azure Container Apps

Up to this point, everything we did was still running with a local Docker command. The full command looked like this (evdbmlflow was our locally built image):

docker run -p 5000:5000 evdbmlflow:latest mlflow server --host 0.0.0.0 --backend-store-uri "mssql+pyodbc://{dbUser}:{dbPassword}@{dbServer}.database.windows.net/{dbName}?driver=ODBC+Driver+18+for+SQL+Server&Encrypt=yes&TrustServerCertificate=no&Connection+Timeout=30" --artifacts-destination wasbs://{blobContainerName}@{storageAccountName}.blob.core.windows.net/

To get everything running in Azure Container Apps we did the following steps:

1. Build and push the image:
We created our Dockerfile and pushed the image to an Azure Container Registry (ACR)
2. Provisioned supporting resources:
We deployed the required Azure services: Azure SQL Database, Azure Blob Storage, Log Analytics, Container App Environment, Container App, Role Assignments(RBAC). These made sure we had the backend to write our metadata and artifacts to and permissions were set so the container had access to everything it needs.
3. Deploy the Container App: Finally we've configured the Container App to use our custom image and added the startup command and arguments we also used for our local container so it could connect to Blob Storage and SQL.

Instead of clicking through the portal, we've provisioned everything using Bicep with a few CLI commands. The full setup is available in this GitHub repository: https://github.com/evdbogaard/blog-mlflow-azure.

It contains:

acr.bicep: Used to create the container registry
Dockerfile: The full Dockerfile used
dockercommands.sh: cli commands used to login to the registry, build the image, and push the image
infra.bicep: Provisioning of all the supporting resources and the container app itself.

You now have an MLflow server up and running inside an Azure Container App. In the Bicep templates we kept the resource configurations simple, but in production you would want to tighten security and optimize costs.

MLflow tracking server behavior in Azure Container Apps

While we had MLflow running in the cloud, we noticed that in some cases artifacts still were not logged. After investigation, we discovered that the bug came from our client-side Python code.

import os
import mlflow

from dotenv import load_dotenv
from langchain_openai import AzureChatOpenAI

load_dotenv()

mlflow.set_experiment(f"My Test Experiment")
mlflow.langchain.autolog()

llm = AzureChatOpenAI(
    api_key=os.getenv("AZURE_OPENAI_API_KEY"),
    azure_endpoint=os.getenv("AZURE_OPENAI_ENDPOINT"),
    deployment_name=os.getenv("AZURE_OPENAI_DEPLOYMENT_NAME"),
    api_version="2024-12-01-preview",
)

response = llm.invoke("What is MLflow?")
print(response)

When we ran the code locally, both traces and artifacts appeared in MLflow. Running it in a local container also worked. But once we moved the container to Azure Container Apps, artifacts stopped working.

It turned out that Azure Container Apps injected a number of environment variables. One of them was OTEL_EXPORTER_OTLP_ENDPOINT. When this was set, MLflow switched from its default behavior and attempted to send traces to an OpenTelemetry Collector. We could not find a way to prevent this variable from being injected.

Our workaround was to unset it explicitly before importing MLflow:

os.environ.pop("OTEL_EXPORTER_OTLP_ENDPOINT", None)

With this change, behavior was consistent between local and cloud runs. When we opnened the MLflow UI, we could see the traces showing up correctly, including detailed breakdowns of the prompts sent to the LLM, the responses, token usage, and more.

Resources

If you found the content of this blog useful, here are some resources for further reading:

Getting structured JSON from LLMs in C#

evdbogaard — Fri, 25 Jul 2025 11:26:08 +0000

Lately we've been trying to get more hands on with AI and started working on a project that uses a large language model (LLM) to extract specific information from documents. In order to use the output of the prompt in our code we needed the model to return JSON and deserialize that into a structured type.

While this worked well in many cases, we ran into issues where the generated JSON didn't match our expected structure and failed to deserialize. In this blog we'll look at our initial implementation and some possible solutions we found to prevent the deserialization issues.

We began by having the LLM extract information and return it to use as a JSON string. That string was then deserialized into a C# object for further use. For most documents, this approach worked just fine. However, we noticed that in some cases, the model would hallucinate and generate either properties that didn't exist or types we weren't expecting. This lead to deserialization issues causing us to have no data for that specific document. Unfortunately, tweaking the temperature parameter didn't prevent this from happening.

JSON mode

Our first approach was to use JSON mode. This setting tells the LLM to return a valid JSON object, but it doesn’t enforce the structure beyond that. Here’s a basic code snippet showing how we implemented it. To keep the focus on how JSON mode is used we’ve stripped out the prompt and other details from the code snippet that felt unrelated to the problem.

var azureOpenAIClient = new AzureOpenAIClient(new Uri(endpoint), new AzureCliCredential());
var chatClient = azureOpenAIClient.GetChatClient(deploymentName);

ChatCompletionOptions options = new()
{
    // Omitted out other options...
    ResponseFormat = ChatResponseFormat.CreateJsonObjectFormat()
};

List<ChatMessage> messages = [
    new SystemChatMessage(prompt), // The prompt telling what information to retrieve from the document
    new AssistantChatMessage(example), // JSON example of how the output should look
    new UserChatMessage(documentContent) // Content of the document to process
];

var completion = await chatClient.CompleteChatAsync(messages, options);
var result = JsonSerializer.Deserialize<OutputModel>(completion.Value.Content.First().Text);

To increase the chances of having a valid JSON response we did two things. First, we used ChatResponseFormat.CreateJsonObjectFormat() to tell the model we expect JSON as the output. Together with this setting you have to specify in your prompt that JSON should be generated. Second, we included an AssistantChatMessage containing a valid JSON example of the expected output. It's filled with dummy data and serialized to a string before passed to the model.

The code to do that looks like this:

static string CreateExample()
{
    var responseModel = new OutputModel
    {
        PersonNames = [
            "John Doe",
            "Doe, J.",
            "Doe, John",
        ],
        Addresses = [
            new() { Street = "123 Maple Street", City = "Springfield", PostalCode = "62704", Country = "USA" },
            new() { Street = "456 Queen St", City = "Toronto" },
            new() { Street = "789 Rue de Rivoli", City = "Paris", Country = "France" },
            new() { Street = "10 Downing Street", City = "London", PostalCode = "SW1A 2AA", Country = "UK" },
            new() { City = "Cupertino", PostalCode = "95014", Country = "USA" },
        ],
    };

    return JsonSerializer.Serialize(responseModel, options: new() { PropertyNameCaseInsensitive = true });
}

public record OutputModel
{
    public string[] PersonNames { get; set; } = [];
    public AddressModel[] Addresses { get; set; } = [];
}

public record AddressModel
{
    public string Street { get; set; } = "";
    public string City { get; set; } = "";
    public string PostalCode { get; set; } = "";
    public string Country { get; set; } = "";
}

Most of the time the LLM generated an output that was correct for us. For example:
{"PersonNames":["Henk"],"Addresses":[{"City":"Amsterdam","Country":"Netherlands"}]}
Unfortunately on some occasions it generated an output that was a bit different and would look like this:
{"PersonNames": ["Henk"], "Addresses": ["Amsterdam"]}

In that case, the Addresses property was a string array instead of an array of AddressModel, which led to deserialization errors.

Structured outputs

Newer models introduced structured outputs, which is an improvement upon the JSON mode and solves this exact problem. While JSON mode guarantees valid JSON, but structured outputs go further by enforcing a specific schema.

To use this, we swapped CreateJsonObjectFormat() for CreateJsonSchemaFormat() and provided a JSON schema based on our expected model. Since .NET doesn't generate JSON schemas by default, we used the NJsonSchema NuGet package for the example code here:

// dotnet add package NJsonSchema
var schema = JsonSchema.FromType<OutputModel>();
ChatCompletionOptions options = new()
{
    // Omitted out other options...
    ResponseFormat = ChatResponseFormat.CreateJsonSchemaFormat(
        jsonSchemaFormatName: nameof(OutputModel),
        jsonSchema: BinaryData.FromString(schema.ToJson())
    )
};

By using structured outputs we can now trust the LLM to always return a JSON string we can safely deserialize back in our code.

Using semantic kernel

A different way to call LLMs in C# is by using Semantic Kernel. It provides extra abstractions that make using LLMs easier in code. Structured outputs also has better support as it no longer requires manual JSON schema generation.

Here's what that code looks like when rewritten for Semantic Kernel:

var kernel = Kernel.CreateBuilder()
    .AddAzureOpenAIChatCompletion(
        deploymentName: deploymentName,
        endpoint: endpoint,
        credentials: new AzureCliCredential()
    )
    .Build();

var chatClient = kernel.GetRequiredService<IChatCompletionService>();

var messages = new ChatHistory();
messages.AddSystemMessage(prompt);
messages.AddAssistantMessage(example);
messages.AddUserMessage(documentContent);

OpenAIPromptExecutionSettings settings = new()
{
    ResponseFormat = typeof(OutputModel)
};

var completion = await chatClient.GetChatMessageContentAsync(messages, settings);

By passing typeof(OutputModel) into the OpenAIPromptExecutionSettings, Semantic Kernel automatically handled schema generation for us.

Validating outputs

Structured outputs worked great, but not all models we used supported them. In those cases, we had to fall back on a more manual approach. We built a custom JsonConverter to validate and deserialize each property individually. If one value failed, we skipped it and kept the rest. This meant we would still lose some data, but we could display most of the generated output instead of nothing.

internal class OutputModelConverter : JsonConverter<OutputModelConverter>
{
    public override OutputModelModel? Read(ref Utf8JsonReader reader, Type typeToConvert, JsonSerializerOptions options)
    {
        var model = new OutputModelModel();

        using var doc = JsonDocument.ParseValue(ref reader);

        var root = doc.RootElement;
        model.PersonNames = TryGetStringArray(root, "PersonNames") ?? [];
        model.Addresses = TryGetObjectArray<AddressModel>(root, "Addresses", options) ?? [];

        return model;
    }

    public override void Write(Utf8JsonWriter writer, NerResponseModel value, JsonSerializerOptions options)
    {
        JsonSerializer.Serialize(writer, value, options);
    }

    private static string[]? TryGetStringArray(JsonElement root, string propertyName)
    {
        try
        {
            if (root.TryGetProperty(propertyName, out var property) && property.ValueKind == JsonValueKind.Array)
                return property
                    .EnumerateArray()
                    .Where(e => e.ValueKind == JsonValueKind.String)
                    .Select(e => e.GetString()!)
                    .ToArray();
        }
        catch
        {
            // ...logging which property failed
        }
        return null;
    }

    private static T[]? TryGetObjectArray<T>(JsonElement root, string propertyName, JsonSerializerOptions options)
    {
        if (root.TryGetProperty(propertyName, out var property) && property.ValueKind == JsonValueKind.Array)
        {
            var list = new List<T>();
            foreach (var item in property.EnumerateArray())
            {
                try
                {
                    var obj = item.Deserialize<T>(options);
                    if (obj != null)
                        list.Add(obj);
                }
                catch
                {
                    // ...logging which property failed
                }
            }
            return list.Count > 0 ? [.. list] : null;
        }
        return null;
    }
}

References

If you want to dive deeper into the topics discussed in this post, here are a few helpful links:

Handling Nullable References with deserialization in .NET 9

evdbogaard — Tue, 31 Dec 2024 07:26:34 +0000

.NET 9 introduced many features, including long-awaited improvements for JSON deserialization. These updates enhance handling nullable types, which helps avoid common issues like NullReferenceException.

Over the years, C# has provided tools to manage nullability, such as enabling nullable annotations and using the required modifier. However, deserialization often bypassed these safeguards. Let’s explore how .NET 9 addresses this problem.

Nullable reference types

Before C# 8.0, NullReferenceException errors were common, especially with uninitialized strings. A string without a value defaults to null, creating potential runtime issues. Developers often assigned default values to avoid exceptions, but these solutions lacked visibility.

With C# 8.0, nullable reference types were introduced to improve safety by detecting null references. Enabling this feature requires adding <Nullable>enable</Nullable> to your project file.

Once enabled, the compiler issues warnings about potentially uninitialized properties. For example, the class below triggers warnings for FirstName and LastName, as there is no constructor to initialize them:

class Person
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
}

To resolve these warnings, you can provide a default value or mark the property as optional:

class Person
{
    public string FirstName { get; set; } = ""; // Default value ensures it's never null
    public string? LastName { get; set; } // Optional, can still be null
}

The `required` modifier

Setting default values isn't always ideal. In C# 11, the required modifier was introduced to enforce property initialization during object creation. A required property must be set, or the code won’t compile.

Setting a default value isn't always what we want. In C# 11 the required modifier was introduced which allows us to say "you cannot create a new object of this class, without at least specifying these fields/properties".
It allows us to get rid of the default value and now prevents code compilation if a required property isn't being set.

class Person
{
    public required string FirstName { get; set; }
    public required string LastName { get; set; }
}

// --- Example

var person = new Person
{
    FirstName = "John"
}; // Compilation error: 'LastName' is required

This modifier ensures objects are properly initialized.

The problem with deserialization

By default, System.Text.Json ignores nullability when deserializing objects. Consider the example below:

class Person
{
    public required string FirstName { get; set; }
    public required string LastName { get; set; }
}

// ---

var json = "{\"firstName\":\"John\", \"lastName\":null}";
var person = JsonSerializer.Deserialize<Person>(json, options: JsonSerializerOptions.Web);
Console.WriteLine($"Person: {person.FirstName} {person.LastName}"); // Output: "Person: John "
person.LastName.ToUpper(); // Throws NullReferenceException

The deserializer creates a Person object with LastName set to null, even though this would not be possible with direct initialization. This behavior undermines the protections provided by nullable reference types and required modifiers.

Respecting Nullable Annotations in .NET 9

.NET 9 addresses this issue with the RespectNullableAnnotationsDefault feature. This opt-in feature enforces nullability rules during deserialization, ensuring invalid objects aren’t created. Since it introduces breaking changes, it’s disabled by default but recommended for new projects.

Here's the updated behavior:

class Person
{
    public required string FirstName { get; set; }
    public required string LastName { get; set; }
}

// ---

var json = "{\"firstName\":\"John\", \"lastName\":null}";
var person = JsonSerializer.Deserialize<Person>(json, options: JsonSerializerOptions.Web);
// Throws JsonException: "The property or field 'lastName' on type 'Person' doesn't allow setting null values"

Enabling `RespectNullableAnnotationsDefault`

To enable this feature globally, add the following to your project file:

<ItemGroup>
  <RuntimeHostConfigurationOption Include="System.Text.Json.Serialization.RespectNullableAnnotationsDefault" Value="true" />
</ItemGroup>

Alternatively, enable it for specific calls:

JsonSerializerOptions options = new() { RespectNullableAnnotations = true };
JsonSerializer.Deserialize<Person>(json, options: options);

Conclusion

With .NET 9's RespectNullableAnnotationsDefault option, developers can better enforce property validity during deserialization. These improvements complement existing nullability tools.

References

If you want to read more about changes to system.text.json in .NET 9 or nullable references in general, please check out the following links:

Using versioning with Bicep Registry

evdbogaard — Wed, 15 Feb 2023 07:44:27 +0000

One of the great things about Bicep is that it allows you to split it up in smaller modules that can be easily referenced from another Bicep file. This increases readability of your files and also allows for easier reuse of these modules. When you want to reference the same module in different repositories there are a couple of ways to do this. One of them is by using a Bicep Registry. For this you can use Azure Container Registry which next to container images also accepts Bicep files. To later on reference them in a Bicep file you can use the following url br:evdbregistry.azurecr.io/bicep/modules/mymodule:v1.
The first part is url of the specific registry and the module path. You end with a tag which points to a specific version of that module inside the registry.

At the company I work we started using a Bicep Registry as well and wanted to have versioning for all files that are put inside the registry. To do this we setup a new repository and pipeline to handle this. However, there were two main problems we needed to tackle.

These issues were:

Which tags to use when pushing to the registry?
How to push only the files that changed into the registry, instead of everything all the time?

Which tag to pick?

When you push a bicep module towards a registry you need to supply a tag. An easy way for tags is to keep track of which version it is (i.e. v1, v2, etc.). The information on which version a specific file is can be stored inside the bicep module itself with the help of the metadata keyword.

When a bicep file is build into an ARM Json file some extra data is added in the metadata section. This contains version of bicep used and a hash. You can add to this section by using the metadata keyword as follows: metadata version = 'v1'.
When you build your bicep file you can see the metadata is added in the json file.

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "metadata": {
    "_generator": {
      "name": "bicep",
      "version": "0.14.6.61914",
      "templateHash": "7937327168356229929"
    },
    "version": "v1"
  },
  "resources": []
}

Finding changed files

We the version info we could in theory write every file all the time to the container registry, but it is a big waste to do this for files that didn't even change.
To determine which files have changed I use the following git command: git diff --name-only --diff-filter=d HEAD^ HEAD

This gives the differences between the current commit (HEAD) and it's parent (HEAD^). Because of --name-only the information we get back is stripped down to only file names that have changed. The diff-filter is added to exclude deleted files as we don't want to write those to a registry as they no longer exist.

note: Azure DevOps Pipelines by default use a shallow fetch as a way of optimization. For this command to work you need a depth of 2. To edit this go to your pipeline -> edit -> trigger -> YAML -> Get sources -> Shallow fetch

Putting everything in YAML

The pipeline consists out of two stages. The first stage will find all changed files, build them, and put them into an artifact. The second stage will get the artifact and push the files one by one to the registry.
Each stage has its own PowerShell script to do this.

Build stage

$changedFiles = git diff --name-only --diff-filter=d HEAD^ HEAD
$artifactsDirectory = "$(Build.ArtifactStagingDirectory)"
foreach($fileName in $changedFiles)
{
  Write-Host "Found $fileName"
  if (!$fileName.EndsWith(".bicep"))
  {
    continue
  }

  $file = Get-ChildItem $fileName
  az bicep build -f $fileName --outfile "${artifactsDirectory}/$($file.BaseName).json"
}

First we get all files that have been changed since the last commit. From this list we need to filter out anything that isn't a bicep file. There are other files in the repository (like the yml file itself) that don't need to be pushed to the registry. Finally we use az bicep build to generate a json file. This is a good check to see if the bicep file itself is valid, and in the next stage we need to read the json file to get the version information out of it.
It doesn't matter that we converted the bicep files to json already in this stage. The az bicep publish accepts both json and bicep files.
All build files are put in together in the artifact staging directory and are published as an artifact in the final step of this stage.

Publish stage

$files = Get-ChildItem $(Pipeline.Workspace) -Filter "*.json" -R

foreach ($file in $files)
  {
    $fileBaseName = $file.BaseName
    $jsonFile = Get-Content $file.FullName | Out-String | ConvertFrom-Json
    $version = $jsonFile.metadata.version

    Write-Host "Pushing to registry ${fileBaseName}:${version}"
    az bicep publish --file $file.FullName --target "br:evdbregistry.azurecr.io/bicep/modules/${fileBaseName}:${version}"
}

In this stage the artifact is downloaded and we load in all the files one by one. As they are json files we can easily convert them to json and pick the version information from the metadata block. Finally we use az bicep publish and give the necessary parameters to push the script inside the registry.

Full yaml file:

trigger:
  branches:
    include:
      - main

pool:
  vmImage: 'ubuntu-latest'

stages:
  - stage: build
    jobs:
      - job: generate_artifact
        displayName: "Generate artifacts"
        steps:
        - task: PowerShell@2
          displayName: Copy changed files
          inputs:
            targetType: 'inline'
            script: |
              $changedFiles = git diff --name-only --diff-filter=d HEAD^ HEAD
              $artifactsDirectory = "$(Build.ArtifactStagingDirectory)"
              foreach($fileName in $changedFiles)
              {
                Write-Host "Found $fileName"
                if (!$fileName.EndsWith(".bicep"))
                {
                  continue
                }

                $file = Get-ChildItem $fileName
                az bicep build -f $fileName --outfile "${artifactsDirectory}/$($file.BaseName).json"
              }

        - publish: $(Build.ArtifactStagingDirectory)
          artifact: $(Build.BuildNumber)

  - stage: publish
    displayName: "Publish to container registry"
    dependsOn: build
    condition: succeeded()
    jobs:
      - deployment: publish_to_registry
        displayName: Publish to registry
        environment: 'BicepEnv'
        strategy:
          runOnce:
            deploy:
              steps:
              - task: AzureCLI@2
                displayName: 'Publish to registry'
                inputs:
                  azureSubscription: 'Bicep ARM'
                  scriptType: 'pscore'
                  scriptLocation: 'inlineScript'
                  inlineScript: |
                    $files = Get-ChildItem $(Pipeline.Workspace) -Filter "*.json" -R

                    foreach ($file in $files)
                    {
                      $fileBaseName = $file.BaseName
                      $jsonFile = Get-Content $file.FullName | Out-String | ConvertFrom-Json
                      $version = $jsonFile.metadata.version

                      Write-Host "Pushing to registry ${fileBaseName}:${version}"
                      az bicep publish --file $file.FullName --target "br:evdbregistry.azurecr.io/bicep/modules/${fileBaseName}:${version}"
                    }

Automatic version number

What I don't like about above solution is that it still requires manual update of version numbers. If you're not careful and update a file, without updating the version number it will just overwrite the version that is stored inside the registry.

If you want an automatic version number you can use the pipeline variable $(Build.BuildNumber). This will generate a string that looks like 20230101.1. This guarantees that the tag is always unique as each build has a new number.

The downside of this approach is that there is no clear way to know which tags exists without looking into the registry itself. So it's up to yourself to see what you like best, fully automatic tags or more predictable version numbers that need to be updated manually.

.NET 7 Rate Limiting

evdbogaard — Tue, 01 Nov 2022 08:03:53 +0000

What is rate limiting?

With rate limiting we determine how much a specific resource can be accessed. If you for example know a resource can handle x amount of requests per minute you can block any request that goes over that so your resource isn't overwhelmed by the requests and starts throwing errors.

Rate limiting algorithms

With .NET 7 a few different algorithms are included for us to use. If these do not do what you want it's always possible to create your own. Inside the System.Threading.RateLimiting namespace there are the abstract classes ReplenishingRateLimiter and RateLimiter which can be used to create a custom implementation.

In the basis all RateLimiters have a PermitLimit, QueueLimit, and QueueProcessingOrder. Besides that depending on the specific RateLimiter there are other options you can set.

The PermitLimit holds the number of permits a given rate limiter can give. When there are no permits left new requests are either put in a queue or rejected.

The QueueLimit holds the number of requests that can be queued when there are no permits left. When a new permit becomes available it is first given to a request that is already waiting in the queue. Based on the QueueProcessingOrder it is either given to the oldest request in the queue or the newest request. If there are no permits and the queue is already full a request gets rejected immediately.

ConcurrencyLimiter

The number of permits given to this limiter tell it how many requests it can handle at the same time. When a request is made a permit is given out and when the request is done this permit is returned to the limiter.

FixedWindowRateLimiter

For this limiter a time window needs to be specified. Within that window it can handle the specified amount of requests. Unlike the ConcurrencyLimiter the permits are not given back when a request is done. Only after the time window is expired the full amount of permits is reset and new requests can be handled.

SlidingWindowRateLimiter

Similar to the FixedWindowRateLimiter, but the time window is separated in segment. Each segment keeps track of how many permits are given out in that segment and they replenish separately instead of only after the entire time window has passed.
For example a time window 1 hour which is split into 3 segments of 20 minutes. In the first segments 10 permits are used. The seconds segment 5 permits are used and in the third segment 15 permits are used. In total this means 30 permits are used. After 20 minutes the first segment is dropped and those 10 permits are free to use again.

TokenBucketRateLimiter

Different to the other limiters this one uses tokens instead of permits. Similar to the FixedWindowRateLimiter is that once a token is used it is not given back. The way it replenishes new tokens is by setting a replenishment period. Every time that period expires a predetermined amount of tokens is added back, never exceeding the maximum amount of tokens that is specified.

How to use

There are two packages we need to use rate limiting. The first one is System.Threading.RateLimiting. This package holds most of the rate limiting knowledge and the four algorithms described above.
The second package is Microsoft.AspNetCore.RateLimiting which has everything we need to add rate limiting to the middleware.

Each rate limiter has an AcquireAsync and AttemtAcquire method which can be used for asynchronous or synchronous retrieval of a permit. When there are no permits available, but there is still room in the queue these methods also keep waiting till a permit becomes available.
You get a RateLimitLease back which holds information if the system was successful in getting a permit. It is still your own responsibility to check this and take action if no permits were available. The lease implements IDisposable so it's important to call Dispose() before you are done (or use using statement to take care of it for you), as some rate limiters need it to know a permit is given back and can be reused again.

Below you can find some sample code of how this would look:

private static readonly ConcurrencyLimiter _limiter = new(new ConcurrencyLimiterOptions()
    {
        PermitLimit = 2,
        QueueProcessingOrder = QueueProcessingOrder.OldestFirst,
        QueueLimit = 0
    });

public async Task Get()
    {
        using var lease = await _limiter.AcquireAsync(HttpContext);

        if (!lease.IsAcquired)
            throw new Exception("No permits available");

        // Continue with your code
        ...
    }

Middleware

Having to type AcquireAsync and check the response for every method is a bit cumbersome, so lucky for us it's possible to add rate limiters through middleware.

In Program.cs you can call app.UseRateLimiter() which takes a RateLimiterOptions as parameter. There are three thing you can set here:

RejectionStatusCode: The HTTP status code that is used when a request is rejected by the rate limiter. By default this is 503.
OnRejected: A Func delegate that is called when a call is rejected. It has both the HttpContext and the RateLimitLease of the current request.
GlobalLimitter: A specific limiter that is executed for every request that passed through the middleware. If a specific request has multiple limiters that are set up for it the GlobalLimitter is always called first.

Besides these options there are also some helper methods to easily create policies. For each rate limiting algorithm described above there is a specific Add helper method, like AddConcurrencyLimiter. Each helper method takes a string as first argument, which is the name used for the policy. And a second argument which are the options for that specific rate limiter.

There is also an AddPolicy method which can be used for custom created policies.

To use a policy you can use the EnableRateLimitingAttribute. It has similar behavior to for example role based authorization where you can put the attribute on a controller or method itself. The DisableRateLimiting attribute can be used if you want to exempt a method or controller from rate limiting.

[ApiController]
[Route("[controller]")]
[EnableRateLimiting("policyName")]
public class WeatherForecastController : ControllerBase
{ ... }

PartitionedRateLimiter

The rate limiters we've seen so far cannot tell the difference between requests and handle everything the same. However in practice we probably want to have different behavior if someone is logged in or not. Or limit requests per ip address. For this the PartitionedRateLimiter is created. It basically creates a rate limiter per partition. You can pass in anything you want, but if you look at the GlobalLimiter we've seen earlier you see that it uses HttpContext. From that context we can then determine which value we want to use for the partition. To create on we can use a static method, an example of this can be seen below:

PartitionedRateLimiter.Create<HttpContext, string>(httpContext => RateLimitPartition.GetFixedWindowLimiter(httpContext.User.Identity.Name, options => new()
    {
        AutoReplenishment = true,
        PermitLimit = 100,
        QueueLimit = 0,
        QueueProcessingOrder = QueueProcessingOrder.OldestFirst,
        Window = TimeSpan.FromHours(1)
    }))

In this example we create a rate limiter that allows for 100 request per hour. This is linked to the User.Identity.Name, so two different users can have each 100 requests before their requests get rejected.
Now let's say that besides the 100 requests per hour we want to limit the total to 1000 per day. This can be done with the CreateChained helper method. You can chain multiple partitioned rate limiters together like this, and they don't even need to use the same partition. So you can for example rate limit on a user id and ip address at the same time.

PartitionedRateLimiter.CreateChained(
    PartitionedRateLimiter.Create<HttpContext, string>(httpContext =>
 RateLimitPartition.GetFixedWindowLimiter(httpContext.User.Identity.Name!, options => new()
    {
        AutoReplenishment = true,
        PermitLimit = 100,
        Window = TimeSpan.FromHours(1)
    })),
    PartitionedRateLimiter.Create<HttpContext, string>(httpContext =>
                RateLimitPartition.GetFixedWindowLimiter(httpContext.User.Identity?.Name!, options => new()
    {
        AutoReplenishment = true,
        PermitLimit = 1000,
        Window = TimeSpan.FromDays(1)
    })));

Custom policies

In case you want to have a more advanced policy you can implement a custom one using the IRateLimiterPolicy<T> interface. There are two things you need to implement for this, OnRejected, which has similar behavior to the one used inside UseRateLimiter, and GetPartition which returns a specific RateLimitPartition. See below for a small example of where an authenticated user has no limiting, but otherwise there is a limit on ip address.

public class MyRateLimiterPolicy : IRateLimiterPolicy<string>
{
    public Func<OnRejectedContext, CancellationToken, ValueTask>? OnRejected { get; } = (context, cancellationToken) =>
    {
        context.HttpContext.Response.StatusCode = 429;
        return new();
    };

    public RateLimitPartition<string> GetPartition(HttpContext httpContext)
    {
        if (httpContext.User.Identity!.IsAuthenticated)
            return RateLimitPartition.GetNoLimiter(httpContext.User.Identity.Name!);

        return RateLimitPartition.GetFixedWindowLimiter(httpContext.Connection.RemoteIpAddress!.ToString(), options => new()
        {
            PermitLimit = 100,
            Window = TimeSpan.FromHours(1)
        });
    }
}

Links

https://devblogs.microsoft.com/dotnet/announcing-rate-limiting-for-dotnet/

Health checks in ASP.Net Core web API

evdbogaard — Tue, 14 Sep 2021 06:00:08 +0000

When you have an API running in the cloud it is important to know how healthy it is and if it might experience issues by itself or other services it relies on.
To help you with that health checks were added tot ASP.Net Core to allow near-real-time monitoring of information about the state of your system. With only a few lines of code you can enable it in your own API.
In your ConfigureServices method add the following line services.AddHealthChecks and in the Configure method under the endpoints.MapControllers(); line add endpoints.MapHealthChecks("/hc");. Congratulations you now have created and endpoint that shows the status of your API. If you run your code and go to that url you can see it reports Healthy. As you haven't added any checks it doesn't really have any value yet, but the basis is set. Now let's look on how to add some checks to it.

Custom health checks

You can add multiple health checks that need to be checked. Fortunately for us there is already a nice Github repository available with all kinds of health checks in it. You can check it out here. There are nuget packages for different kinds of services like db, service bus, storage, keyvault, etc.
Although it's nice these packages are already available for us, there will be cases where you need to write your own custom health check. For this they created the IHealthCheck interface.
You have to create a new class that implements that interface and you have created your own custom health check. Add AddCheck<MyCustomHealthCheck>() after the AddHealthChecks call, it's fluent to your ConfigureServices method and the health checks are automatically executed when the end point is called.

Demo project

To make the above text a little more visual lets show it all through a small demo project. We're going to create a new dotnet web api project and add a check to CosmosDb and also create a custom check through which we can fake an unhealthy app.
So first lets create a new project. I prefer command line to do this, but there are of course other possible options.

In the command line type: dotnet new webapi -o Demo.HealthCheck.Api
Open the newly created project in your favorite editor
In Startup.cs find ConfigureServices and at the end of the method add services.AddHealthChecks();.
In the same file find the line endpoints.MapControllers(); and under it add endpoints.MapHealthChecks("/hc");
Run the code and verify that the endpoint /hc exists and returns Healthy

With this we have the basic setup working. It's now time to add some actual checks. For demo purposes I created a CosmosDb account in the Azure portal. As this is not a blog post on CosmosDb I assume you created these yourself or simply omit this checks from your own project. The idea behind it is valid for other services like Sql Server, MySql, Postgres, etc. You have to supply a connection string and it tries to connect to it. If it succeeds everything is good, else Unhealthy is returned.

There are nuget package available for different services. For CosmosDb we need to type the following in the command line: dotnet add package AspNetCore.HealthChecks.CosmosDb.
Now that we have the package installed we can alter our AddHealthChecks() line to include a check for CosmosDb. You can now add AddCosmosDb() as a check. It asks for a connection string and you can optionally also pass in a database name. The health check tries to connect to the database and reports if it experiences issues. Your code should look similar to the example below.

services.AddHealthChecks()
    .AddCosmosDb(cosmosDbConnString, "master");

You can try it and and pass in a non-existing database name or wrong connection string and go to the /hc endpoint. It shows Unhealthy in those cases.

Now lets create a custom check for us to implement. This can be anything you want. For demo purposes we're going to create a signleton class that holds a boolean called Healthy. If that boolean is true the check responds with healthy, else it will return unhealthy.

Create a new class called HealthService.cs
Inside that class add a bool property call Healthy, make it true by default.
In Startup.cs inject the class as a singleton: services.AddSingleton<HealthService>();
Create a new class called CustomCheck.cs
Have the class implement the interface IHealthCheck
Inject the HealthService we just created and have it return Healthy on true or Unhealthy.
In Startup.cs add to the other health checks the code AddCheck<CustomCheck>(nameof(CustomCheck));

The code how it should look is below:

public class CustomCheck : IHealthCheck
    {
        readonly HealthService _healthService;

        public CustomCheck(HealthService healthService) => _healthService = healthService;

        public Task<HealthCheckResult> CheckHealthAsync(HealthCheckContext context, CancellationToken cancellationToken = default)
            => _healthService.Healthy
                ? Task.FromResult(HealthCheckResult.Healthy())
                : Task.FromResult(HealthCheckResult.Unhealthy());
    }

Startup.cs
services
    .AddSingleton<HealthService>()
    .AddHealthChecks()
    .AddCosmosDb(cosmosDbConnString, "master")
    .AddCheck<CustomCheck>(nameof(CustomCheck));

Some things of interest. The HealthCheckResults we return in our custom check are functions. They can be given a description as parameter to make it clearer why a specific response has failed. Secondly when adding our custom check we have to supply a name. This name is used internally to know which check we are talking about. We didn't supply it with the CosmosDb check as the nuget package implementation made sure a default one was set.

Besides the name we can supply other parameters. We can set a timeout how long a check can take and add tags and use those to better identify checks or even ignore checks with certain tags.

If we run the code now it still shows Healthy, but when you toggle the bool to false it will show Unhealthy. Right now the only way to do this is by restarting the application, but if you add an endpoint that would update that value changes can be seen on refresh of the page.

UI

Besides a simple text answer there is also a lightweight graphical UI provided that makes it more visual. It comes with its own nuget package and similar to the normal health checks can be added with only a few lines of code.

In the command line type dotnet add package AspNetCore.HealthChecks.UI
In the command line type dotnet add package AspNetCore.HealthChecks.UI.InMemory.Storage (There are different storage options for the UI like Sql, Postgress, etc. They all have their own nuget package. For the demo we use the simple InMemory storage)
In the command line type 'dotnet add package AspNetCore.HealthChecks.UI.Client`
Add the following line to Startup.cs: services.AddHealthChecksUI().AddInMemoryStorage();
Update your UseEndpoints() code in Startup.cs to the code below: endpoints.MapControllers(); endpoints.MapHealthChecks("/hc", new HealthCheckOptions { ResponseWriter = UIResponseWriter.WriteHealthCheckUIResponse }); endpoints.MapHealthChecksUI(options => options.UIPath = "/hc-ui");

The ResponseWriter change is needed for the UI to fully understand how to display everything. Before the health endpoint only pushed out a single word. Now it will push out a json object which the UI will read and know how to display. You can see this when you go to the health endpoint yourself.

If you run the project and go to /hc-ui you see an empty status screen. We setup the code for the UI, but forgot to tell it which checks to look at. Let's do that now. Update your AddHealthChecksUI code to the following:

services .AddHealthChecksUI(options => { options.AddHealthCheckEndpoint("Healthcheck API", "/hc"); }) .AddInMemoryStorage();

We supply it with the health endpoint of this API and give it a name as well. If we look at our UI again we see the following:

Write some code to update the bool we used for the custom check and see how the UI is updated. Or rotate the key used for your CosmosDb connection and see that the checks update correctly. You can inspect the details of each check and see when it failed.

In appsettings.json you can provide configuration for the UI to look at multiple APIs and display them all on a single place. This way you can group results of different APIs in a single place.

To the cloud

It is good to have checks and being able to output the data, but we don't want to manually check the dashboard every time to see if there is a problem.
Luckily for us Azure has provided some features that automatically check the health endpoint of a web app and can take an unhealthy instance out of the load balancer until it's healthy again, or even restart or replace it.

In the Azure portal under App service we can setup a Health check.

There is only one option to set initially and this is Enable. Once you select that option two extra options become available. The first one is the path to your health endpoint, which is /hc in our case. The second is the time an app can be unhealthy before it is removed from the load balancer. Once you save your changes every minute a call to the health endpoint will be made.

Azure only looks at the HTTP response the page gives. If the response is in the 2XX range the instance is considered healthy, else it is shown as degraded or unhealthy. It also doesn't follow redirects. If your webapp settings allow http the check by Azure is done over http. If it is set to HTTPS only then Azure used https calls to check the endpoint. In case your health checks return HTTP 307 response make sure you set your webapp to only use https or remove the redirect from your code (it's in there by default).

There are two important configuration values you can set for your webapp.

WEBSITE_HEALTHCHECK_MAXPINGFAILURES: How many failed requests are needed for the service to be removed from the load balancer (is also set by the slider in the portal)
WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT: How many unhealthy instances will be excluded from the load balancer.

When an instance is removed from the load balancer Azure keeps checking the health endpoint to see if it returns to being healthy. If this takes to long it will try restarting the underlying VM and if the instance in unhealthy for over an hour it will be replaced. The instance still counts towards your total instances for scaling rules, it only is removed from the load balancer. When scaling happens Azure first checks the health endpoint to make sure the new instance is working correctly before adding it.

Besides the automatic removal of an instance from the load balancer you can also setup alerting rules to get notified when a certain percentage of your instances is in an unhealthy state.

References

This is just a small view on what can be done with health checks in ASP.Net Core. In case you are interested feel free to check out the resources below who go into the subject matter a bit deeper.

The demo project used can be found here.

Bicep vs ARM templates

evdbogaard — Sun, 30 May 2021 19:34:29 +0000

For a while now Bicep v0.3 is out. Prior to this version it was already a great tool to use, but since v0.3 it is fully capable to do the same as an ARM template. So, what is it and why would you want to use it?

Infrastructure as code solutions allow you to declare how your infrastructure should look in a file (e.g json). When setup the way you want it makes it easier to add new resources and make sure they have the same settings as others. Especially for resources you only add once a year it can be easy for a developer to forget the exact settings he used the last time. Instead of looking them up they are already documented in the file and only adding the name to an array makes sure it gets created correctly. This also lowers the changes of human error, which is always nice.

What is Bicep?

Bicep is a Domain Specific Language (DSL) that allows declarative deployment of Azure resources. Everything you can do with an ARM template you can also do with Bicep and as soon as a new resource is added to Azure it is immediately supported by Bicep.

Azure Resource Manager (ARM) templates

As Bicep is closely linked to ARM templates you can't really talk about one, without mentioning the other. They both allow you to do the exact same thing, however when you start working with ARM templates you quickly notice it has some drawbacks. Let's start by comparing some ARM and Bicep templates with each other.

{
    "$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "subscriptionId": {
            "type": "string",
            "defaultValue": "[subscription().id]"
        },
        "name": {
            "type": "string",
            "defaultValue": "demo-bicep-webapp"
        },
        "location": {
            "type": "string",
            "defaultValue": "[resourceGroup().location]"
        },
        "serverFarmResourceGroup": {
            "type": "string",
            "defaultValue": "[resourceGroup().name]"
        },
        "sku": {
            "type": "string",
            "defaultValue": "Free"
        },
        "skuCode": {
            "type": "string",
            "defaultValue": "F1"
        }
    },
    "resources": [
        {
            "apiVersion": "2018-11-01",
            "name": "[parameters('name')]",
            "type": "Microsoft.Web/sites",
            "location": "[parameters('location')]",
            "dependsOn": [
                "[concat('Microsoft.Web/serverfarms/', parameters('name'))]"
            ],
            "properties": {
                "name": "[parameters('name')]",
                "siteConfig": {
                    "metadata": [
                        {
                            "name": "CURRENT_STACK",
                            "value": "dotnetcore"
                        }
                    ]
                },
                "serverFarmId": "[concat('/subscriptions/', parameters('subscriptionId'),'/resourcegroups/', parameters('serverFarmResourceGroup'), '/providers/Microsoft.Web/serverfarms/', parameters('name'))]"
            }
        },
        {
            "apiVersion": "2018-11-01",
            "name": "[parameters('name')]",
            "type": "Microsoft.Web/serverfarms",
            "location": "[parameters('location')]",
            "properties": {
                "name": "[parameters('name')]"
            },
            "sku": {
                "Tier": "[parameters('sku')]",
                "Name": "[parameters('skuCode')]"
            }
        }
    ]
}

Above you see a small ARM template that creates an App Service Plan and a Web App. As you can see there is a lot of boilerplate code to get everything working. Each value for a parameter needs to be on a new line. You have to figure out yourself which resources depend on each other and add them to the correct dependsOn block. And you need a pretty elaborate concat to get the Web App with the serverFarmId of the App Service Plan you create in the same template.

Below you see the same template, but written in Bicep. First thing you could notice is that it's only half the size of the ARM one. Paramters are more compact as the type, name, and default value can all be written in a single line. Secondly Bicep is smart enough to figure out if resources depend on each other. We use appServicePlan inside the resource of webApp, this allows it to know it first needs to deploy appServicePlan and automatically adds the dependsOn part when it gets converted from Bicep to an ARM template.

param name string = 'demo-bicep-webapp'
param location string = resourceGroup().location
param sku string = 'Free'
param skuCode string = 'F1'

resource webApp 'Microsoft.Web/sites@2018-11-01' = {
  name: name
  location: location
  properties: {
    name: name
    siteConfig: {
      metadata: [
        {
          name: 'CURRENT_STACK'
          value: 'dotnetcore'
        }
      ]
    }
    serverFarmId: appServicePlan.id
  }
}

resource appServicePlan 'Microsoft.Web/serverfarms@2018-11-01' = {
  name: name
  location: location
  properties: {
    name: name
  }
  sku: {
    Tier: sku
    Name: skuCode
  }
}

Modules

With the small examples used above it is easy to see what is going on. However, when you're deploying your entire infrastructure this way a single file quickly becomes too big.
ARM has linked templates to deal with this problem. A separate file you can link towards which holds a part of your deployment. Unfortunately linked templates cannot be a local file. The file must be accessible through an url. This can be a link to a storage account or a public repository like GitHub.

To use it add a deployment to your resources array with the link to the template and a link to the parameters file if available. Below is a small example of how this looks, taken from Microsoft docs.

"resources": [
  {
    "type": "Microsoft.Resources/deployments",
    "apiVersion": "2020-10-01",
    "name": "linkedTemplate",
    "properties": {
      "mode": "Incremental",
      "templateLink": {
        "uri": "https://mystorageaccount.blob.core.windows.net/AzureTemplates/newStorageAccount.json",
        "contentVersion": "1.0.0.0"
      },
      "parametersLink": {
        "uri": "https://mystorageaccount.blob.core.windows.net/AzureTemplates/newStorageAccount.parameters.json",
        "contentVersion": "1.0.0.0"
      }
    }
  }
]

With Bicep they introduced modules. When converted to ARM template a module translated to a nested template. A nested template is similar to a linked template with the difference that instead of an external link, the template is written in the same file. This generates a big ARM template that isn't friendly to read, but as you work from Bicep you don't need to make changes to the ARM template directly.

Each file saved with a bicep extension can be used as a module. From another bicep file use the module keyword and supply the name and params it needs. The name is only for the deployment and must be unique in the deployment itself. The params are the same params the file you point to uses. Modules also support a scope which allows you to deploy the module in a different resource group.

module webapp './webapp.bicep' = {
  name: 'webappDeploy'
  params: {
    name: 'demo-bicep-webapp'
  }
}

CLI commands

With the introduction of Bicep v0.3 it has been integrated with the Azure CLI. Before you had to install Bicep yourself, but now if you have Azure CLI installed you can do all the same commands starting with az bicep.

The command you probably use the most is az bicep build. It takes a single --file as input argument and converts it to an ARM template with the json extension. By default it has the same name as the input file, but you can choose to give it a different name with the --output argument. Prior to v0.3 it was possible to build multiple files at once, but since the integration with Azure CLI it seems only one file can be build at a time. If someone knows of a way to have multiple files build at once I'd be happy to learn that.

Besides building a Bicep file there is also a command to deploy your file to a resource group or subscription. This command previously only accepted an ARM template, but now it can handle Bicep files directly. In the background it converts them first to an ARM template and continues the deployment with that template.
The commands to do this are in the az deployment group. You can choose either sub or group depending if you want to deploy to an subscription or resource group. create is used to start a new deployment. Furthermore there are arguments to point to the bicep file, which can be a local file or an URL to a file, and add a parameters file if necessary. The total command could look like this: az deployment group create -g demo-rg --template-file webapp.bicep --parameters webapp.parameters.dev.json

There is another argument you can pass along with the above command. It is called --confirm-with-what-if or simply -c. This argument checks what you current deployment would change in your resource group or subscription and shows a list of changes it will make. You then need to confirm that you want those changes before it applies them.

Decompile an ARM template

As Bicep is new compared to ARM templates there is the possibility that you already have multiple templates. To make the step towards Bicep easier they added a command to convert an ARM template to Bicep. The command for this is az bicep decompile. It takes a json file as input and tries it best to make it in Bicep. If we take the ARM template from the beginning it converts to this:

param subscriptionId string = subscription().id
param name string = 'demo-bicep-webapp'
param location string = resourceGroup().location
param serverFarmResourceGroup string = resourceGroup().name
param sku string = 'Free'
param skuCode string = 'F1'

resource name_resource 'Microsoft.Web/sites@2018-11-01' = {
  name: name
  location: location
  properties: {
    name: name
    siteConfig: {
      metadata: [
        {
          name: 'CURRENT_STACK'
          value: 'dotnetcore'
        }
      ]
    }
    serverFarmId: '/subscriptions/${subscriptionId}/resourcegroups/${serverFarmResourceGroup}/providers/Microsoft.Web/serverfarms/${name}'
  }
  dependsOn: [
    Microsoft_Web_serverfarms_name
  ]
}

resource Microsoft_Web_serverfarms_name 'Microsoft.Web/serverfarms@2018-11-01' = {
  name: name
  location: location
  properties: {
    name: name
  }
  sku: {
    Tier: sku
    Name: skuCode
  }
}

As you can see it's not perfect as the serverFarmId can be simplified and that would eliminate the need of the dependsOn, but it is a great start if you have multiple ARM templates and want to move to Bicep.

There is more Bicep can do. As stated earlier everything that is possible in an ARM template is also possible in Bicep, with the exception of some know limitations (https://github.com/Azure/bicep#known-limitations). They are actively working on Bicep so the list gets shorter over time. The modules, less boilerplate code, and cli integration are already enough for me to choose Bicep over ARM template, but be sure to check it out yourself to see what more it supports.

References

https://github.com/Azure/bicep

Branch policies in Azure Repos

evdbogaard — Tue, 27 Apr 2021 19:39:33 +0000

Hi, I've been wanting to start writing some blog posts for a while, but always find excuses why not to do it. Now I had a small thing for work I had to figure out and though why not give it a go. Hope you find it interesting :)

What are Azure Repos?

When you have an Azure DevOps account you get access to Azure Repos. It is a collection of version control tools that help with code management. There are two types of version control offered within Azure Repos: Git and Team Foundation Version Control (TFVC).

Personally I have only experience with Git repos so I'll be focusing on them in this post. With an Azure DevOps account you can create both private and public git repositories for free.

What are branch policies?

Branch policies help you protect important branches and enforce code quality. When a branch has a policy set to it, it is no longer possible to commit directly to it. All changes need to be done through a Pull Request (PR).
There are different kind of policies that can be set up:

Require a minimum number of reviewers
Check for linked work items
Check for comment resolution
Limit merge types
Build validation
Status checks
Automatically include code reviewers

I won't go into depth about what each policy does. Most names are self explanatory and in case you want to read up more on them I suggest reading this article.

Setting policies through Azure DevOps

The easiest way to set branch policies is through the DevOps website. There are two ways to set them. Create a branch policy for all repositories at once, or set one per repository.

All repositories branch policy

Go to Project Settings -> Repositories -> Policies
At the bottom of the page you see all project-wide branch policies currently active. By clicking on the Plus icon you can select which branch to protect and enable the policies you need.

When activating a specific policy the page shows all options you can set for that policy. Some have more options than others. Changes are immediately saved and don't require a confirmation.

Specific repository branch policy

Go to Project Settings -> Repositories -> Select the repository -> Policies -> Select the branch
You now see a page that shows the policies set for this specific branch/repo combination. Setting or changing a policy works the same as previously described. If there is a project-wide branch policy set you can also see it here, but not alter it. You will see a small information message after the policy itself.

Automate setting policies with Azure CLI

As with most things Azure there are multiple ways to do it. If you have multiple repositories or branches you want to set the same policies on, but cannot use the project-wide branch policies then automation is your friend.
I had a problem similar to this and want to show how I solved it.

What I tried to do was adding policies to the main branch for multiple repositories, however some repositories didn't needed these rules. I also wanted to make sure that running the script multiple times would not result in errors or duplicate policies.

Here is the code I came up with (PowerShell):

$orgUrl = "URL_OF_ORGANIZATION" # https://dev.azure.com/OrgName
$project = "NAME_OF_PROJECT"

$repositories = @("Repository", "Names", "To", "Set", "Policies", "For")
$branch = "NAME_OF_BRANCH"
$approversId = "ID_OF_GROUP_OR_USER"

foreach($repo in $repositories) {
    $repoId = (az repos show --org $orgUrl -p $project --repository $repo --query id -o tsv)
    echo "$repo has id: $repoId"

    $currentPolicies = (az repos policy list --org $orgUrl -p $project --repository-id $repoId --branch $branch --query [].type.displayName -o tsv)

    if ($currentPolicies -eq $null -Or !$currentPolicies.Contains("Minimum number of reviewers")) {
        echo "Creating minimum number of reviewers policy for $repo"
        az repos policy approver-count create --org $orgUrl -p $project --branch $branch --repository-id $repoId --allow-downvotes false --blocking true --creator-vote-counts true --enabled true --minimum-approver-count 1 --reset-on-source-push false -o none
    } else {
        echo "$repo already has minimum number of reviewers policy"
    }

    if ($currentPolicies -eq $null -Or !$currentPolicies.Contains("Comment requirements")) {
        echo "Creating comment requirements policy for $repo"
        az repos policy comment-required create --org $orgUrl -p $project --branch $branch --repository-id $repoId --blocking true --enabled true -o none
    } else {
        echo "$repo already has comment requirements policy"
    }

    if ($currentPolicies -eq $null -Or !$currentPolicies.Contains("Work item linking")) {
        echo "Creating work item linking policy for $repo"
        az repos policy work-item-linking create --org $orgUrl -p $project --branch $branch --repository-id $repoId --blocking true --enabled true -o none
    } else {
        echo "$repo already has work item linking policy"
    }

    if ($currentPolicies -eq $null -Or !$currentPolicies.Contains("Required reviewers")) {
        echo "Creating required reviewers policy for $repo"
        az repos policy required-reviewer create --org $orgUrl -p $project --branch $branch --repository-id $repoId --blocking true --enabled true --message "PR Approvers" --required-reviewer-ids $approversId -o none
    } else {
        echo "$repo already has required reviewers policy"
    }
}

Let's look at it step by step. First of all az repos commands need an organization url and a project name. These can be set as default with the az devops configure command, but if they are not set they need to be passed with each command.

The approverIds is the ID of a group I created in Azure DevOps. The ID I obtained with this command: `az devops team list --org $orgUrl -p $project --query '[].{name:name, id:id}'

After that I create an array with repo names and set the branch I want to operate on. We then loop through each repository and get the ID and already active policies for that repo/branch combination.

Each policy has an unique id or displayname. I grabbed the displaynames here to make it more understandable. For each policy we want to set we check if it's displayname is already in the active policies list and skip if so.

Further improvements

The current code is really basic, but does it's job. We can improve it further by limiting the number of calls it needs to make. Especially with lots of repositories it can take a while to run.
I'm also not a fan of the Contains check, if someone knows a more efficient way to check please share it.
Finally there is an issue that if a policy is already set we simply ignore it, even if it has a different setup. Besides the create command there is also update. We probably need to do some kind of checking here to make sure all policies are updated correctly.

DEV Community: evdbogaard

Running MLflow in Azure Container Apps: Lessons from our setup

Running locally

Artifact and backend store

Setting up database store

Setting up the artifacts store

Bringing it to Azure Container Apps

MLflow tracking server behavior in Azure Container Apps

Resources

Getting structured JSON from LLMs in C#

JSON mode

Structured outputs

Using semantic kernel

Validating outputs

References

Handling Nullable References with deserialization in .NET 9

Nullable reference types

The required modifier

The problem with deserialization

Respecting Nullable Annotations in .NET 9

Enabling RespectNullableAnnotationsDefault

Conclusion

References

Using versioning with Bicep Registry

Which tag to pick?

Finding changed files

Putting everything in YAML

Build stage

Publish stage

Automatic version number

.NET 7 Rate Limiting

What is rate limiting?

Rate limiting algorithms

ConcurrencyLimiter

FixedWindowRateLimiter

SlidingWindowRateLimiter

TokenBucketRateLimiter

How to use

Middleware

PartitionedRateLimiter

Custom policies

Links

Health checks in ASP.Net Core web API

Custom health checks

Demo project

UI

To the cloud

References

Bicep vs ARM templates

What is Bicep?

Azure Resource Manager (ARM) templates

Modules

CLI commands

Decompile an ARM template

References

Branch policies in Azure Repos

What are Azure Repos?

What are branch policies?

Setting policies through Azure DevOps

All repositories branch policy

Specific repository branch policy

Automate setting policies with Azure CLI

Further improvements

Further reading

The `required` modifier

Enabling `RespectNullableAnnotationsDefault`