Hardcopy

When running services locally in Docker that need to authenticate with Azure Service Bus, you can leverage the Azure CLI (az login) to provide credentials. This avoids manually setting up connection strings or managed identities for local development.

Step 1: Authenticate Using Azure CLI

Run the following command to authenticate and persist credentials inside a volume:

docker run -it --rm -v "$PWD/azure-auth:/root/.azure" mcr.microsoft.com/azure-cli az login

This will:

• Prompt you to log in to Azure.
• Store authentication tokens in a directory called azure-auth inside your project.
• Remove the container after login (--rm ensures it doesn’t persist).

Step 2: Mount the Credentials in Your Service Container

Modify your docker-compose.yml to mount this volume in the service that needs Azure authentication:

services:
  my-service:
    image: my-service-image
    volumes:
      - "./azure-auth:/root/.azure"

This ensures that when your service runs, it has access to the Azure credentials stored in azure-auth.

Step 3: Verify Authentication

Inside the running container, you can verify that authentication works by running:

az account show

If configured correctly, this should display your logged-in Azure account details.

This setup allows your Docker container to seamlessly authenticate with Azure Service Bus while keeping credentials isolated and manageable.

Step 4: Use in C# to Connect to Azure Service Bus

Once authentication is set up, you can use the Azure SDK for .NET to connect to Azure Service Bus in your C# application. Ensure your application runs inside the container with the mounted credentials.

Install the required NuGet package if you haven't already:

Then, in your C# application, use DefaultAzureCredential to authenticate and connect to Service Bus:

This setup allows your C# application to authenticate with Azure Service Bus using the credentials stored in the mounted azure-auth directory. 🚀

When working with Azure Blob Storage, you might encounter issues due to case sensitivity in blob names. If your application expects all blob names to be lowercase but some are stored in mixed or uppercase, renaming them manually can be tedious. This Bash script automates the process, ensuring all blob names are converted to lowercase using azcopy.

How It Works

1. Lists All Blobs: The script retrieves all blobs from a specified container using azcopy list.
2. Converts Names to Lowercase: It iterates through the blobs and converts each name to lowercase.
3. Copies & Renames: If the name has changed, it copies the blob to a new lowercase-named blob.
4. Deletes the Original Blob: After successfully copying, it deletes the original blob.

Prerequisites

• Install and configure azcopy.
• Set your storage account name, container name, and SAS token in the script.

The Script

#!/bin/bash

STORAGE_ACCOUNT_NAME=
CONTAINER_NAME=
SAS_TOKEN=

# Set the base URL for the storage account
STORAGE_BASE_URL="https://${STORAGE_ACCOUNT_NAME}.blob.core.windows.net/${CONTAINER_NAME}"

# List all blobs in the specified container
BLOBS=$(azcopy list "${STORAGE_BASE_URL}?${SAS_TOKEN}" --output-type text | grep -oP '.*(?=\s{2})')

# Iterate through each blob in the list
for BLOB_NAME in $BLOBS; do
  # Convert the blob name to lowercase
  LOWERCASE_BLOB_NAME=$(echo "$BLOB_NAME" | tr '[:upper:]' '[:lower:]')

  # Check if the blob name has changed after converting to lowercase
  if [ "$BLOB_NAME" != "$LOWERCASE_BLOB_NAME" ]; then
    # Copy the original blob to a new blob with the lowercase name
    azcopy copy "${STORAGE_BASE_URL}/${BLOB_NAME}?${SAS_TOKEN}" "${STORAGE_BASE_URL}/${LOWERCASE_BLOB_NAME}?${SAS_TOKEN}"

    # Delete the original blob after the copy operation has completed
    azcopy rm "${STORAGE_BASE_URL}/${BLOB_NAME}?${SAS_TOKEN}"
  fi
done

Use Case

This script is particularly useful when migrating data or normalizing blob names to avoid case-sensitivity issues in applications.

🚀 Run the script and ensure your blob names stay consistent!

You can't use a 102 status code because Azure will always wait for a follow up code. In my code I changed it to a 202 Accepted instead.

If you try and use a 102 in Azure, you will eventually get a 502 response, which states that the server received an invalid response while acting as a proxy or gateway. Which translates to, I received a 102 but not a final status code from you code.

A 102 should only ever be used to say that the call is still in progress ans must always be followed up with a final status code, be that a 200 or 202 like I changed mine to.