Queue Storage und Table Storage lokal mit Azurite nutzen

Architektur und Abgrenzung

Azurite läuft auf Windows, Linux und macOS und stellt Standardports bereit: 10.000 für Blob, 10.001 für Queue, 10.002 für Table. Die Tabellenunterstützung befindet sich im Preview-Status, einige API-Operationen fallen eingeschränkt aus. Leistungsversprechen gibt es nicht, Azurite zielt auf Entwicklung und Tests. Dafür ist die Lösung gut geeignet. Die Endpunkte unterscheiden sich natürlich zunächst von Azure. Lokal adressieren Clients IP-basierte URLs, der Kontoname steht im Pfad. Ein Blob liegt zum Beispiel unter http://127.0.0.1:10000/devstoreaccount1/container/blob.txt.

Produktionsähnliche URLs lassen sich über Hosteinträge und angepasste Verbindungszeichenfolgen simulieren. Für eigene Konten und Schlüssel akzeptiert Azurite die Umgebungsvariable AZURITE_ACCOUNTS, mehrere Einträge sind dabei möglich. Der Emulator ersetzt den alten Azure Storage Emulator und folgt den aktuellen API-Versionen. RA-GRS wird für Lesezugriffe auf eine Sekundäradresse simuliert, der Zugriff erfolgt mit Suffix -secondary am Kontonamen. Beim Wechsel auf produktionsähnliche URLs müssen Entwickler die Verbindungskonfiguration beachten. Der Storage Explorer verarbeitet den Default-Account mit Pfadsyntax nicht korrekt, was zu fehlerhaften Aufrufen führen kann.

Verbindungsmodelle und Konfiguration

Der einfache Weg führt über UseDevelopmentStorage=true. Viele SDKs und Tools erkennen diese Vorgabe und wählen automatisch die Devstore-Konten samt Schlüsseln. Alternativ wird eine vollständige Zeichenfolge genutzt, die Protokoll, AccountName, AccountKey und explizite Endpunkte enthält. In Containerumgebungen liegt der Host bei host.docker.internal, die Account-Auflösung erfolgt dann aus dem Pfad. Für produktionsähnliche Hostnamen ist der Startparameter --disableProductStyleUrl wichtig, wenn Account-Namen im Pfad stehen sollen.

Azure Functions und Worker-Prozesse arbeiten lokal gegen Azurite über local.settings.json. Die Zeile AzureWebJobsStorage mit UseDevelopmentStorage=true genügt, um Trigger für Queue oder Bindings für Table auf den Emulator zu lenken. Visual Studio ergänzt in vielen Projekten Service-Registrierungen für BlobServiceClient, QueueServiceClient oder TableClient und legt den Verbindungsstring in User Secrets ab. VS Code startet Azurite über die Erweiterung.

Queue Storage praxisnah

Die Warteschlangen bilden asynchrone Verarbeitungsketten nach. Nachrichten lassen sich lokal erzeugen, sichtbar halten, wieder veröffentlichen oder löschen. Ein typisches .NET-Beispiel:

using Azure.Storage.Queues;

using Azure.Storage.Queues.Models;

string cs = "UseDevelopmentStorage=true;";

var client = new QueueClient(cs, "jobs");

client.CreateIfNotExists();

client.SendMessage("build-42");

client.SendMessage("index-987");

QueueMessage[] msgs = client.ReceiveMessages(maxMessages: 2, visibilityTimeout: TimeSpan.FromSeconds(30));

foreach (var m in msgs)

{

    Console.WriteLine(m.MessageText);

    client.DeleteMessage(m.MessageId, m.PopReceipt);

}

Dieses Beispiel erstellt eine Warteschlange, sendet zwei Nachrichten, liest beide und löscht sie anschließend. Konkurrierende Konsumenten werden durch Sichtbarkeitsfristen abgebildet. Fehlerpfade lassen sich durch Nichtlöschung simulieren, der Re-Enqueue folgt nach Ablauf der Frist. Poison-Queue-Muster lassen sich lokal testen, indem bei Überschreitung eines Zählers die Nachricht in eine separate Warteschlange verschoben wird.

Table Storage praxisnah

Tabellen speichern schlüsselbasiert strukturierte Entitäten mit PartitionKey und RowKey. Die Segmentierung über Partitionen ist integraler Bestandteil, Abfragen begrenzen sich sinnvoll auf PartitionKey und Schlüsselbereiche. Das Beispiel legt eine Tabelle an und fügt zwei Entitäten ein:

using Azure;

using Azure.Data.Tables;

string cs = "UseDevelopmentStorage=true;";

var table = new TableClient(cs, "produkte");

table.CreateIfNotExists();

var p1 = new TableEntity("Bekleidung", Guid.NewGuid().ToString())

{

    ["Name"] = "T-Shirt",

    ["Preis"] = 19.99m,

    ["Bestand"] = 50

};

var p2 = new TableEntity("Bekleidung", Guid.NewGuid().ToString())

{

    ["Name"] = "Hose",

    ["Preis"] = 49.90m,

    ["Bestand"] = 20

};

table.AddEntity(p1);

table.AddEntity(p2);

// Abfrage nach Partition

Pageable<TableEntity> page = table.Query<TableEntity>(e => e.PartitionKey == "Bekleidung");

foreach (var e in page) { Console.WriteLine(e.GetString("Name")); }

Bei der Migration in die Cloud ändert sich lediglich der Verbindungsstring. API-Semantik und Fehlercodes sind weitgehend deckungsgleich. Abweichungen betreffen Einzelfälle wie Fehlermeldungstexte.

Storage Explorer als Kontrollzentrum

Der Desktop-Client entdeckt laufende Azurite-Instanzen automatisch, sofern die erwarteten Ports aktiv sind. In der Baumansicht erscheint der Emulator unter Lokal & angefügt im Bereich der Speicherkonten, gruppiert nach den drei Diensten. Die Portbindung entspricht 10.000 für Blob, 10.001 für Queue und 10.002 für Table.

Abweichende Ports oder Container erfordern eine manuelle Verbindung. Der Dialog Mit Azure Storage verbinden bietet einen Ressourcentyp für lokale Emulatoren. Der Explorer startet Azurite nicht eigenständig, die Instanz muss vorab laufen. Ein CLI-Start mit azurite --silent --location c:\azurite --debug c:\azurite\debug.log initialisiert Arbeitsverzeichnis und Protokollierung.

Das Tool unterstützt Anbindungen über Entra ID, Verbindungsschlüssel, SAS oder URI. Fehlende Datenrollen führen zu ausgegrauten Vorgängen, nötig sind je nach Datentyp Rollen wie Storage Blob Data Contributor oder Storage Queue Data Reader.

Für selektiven Zugriff wird eine SAS-URL hinterlegt. Die Ressource erscheint danach unter Lokal & angefügt im Zweig für angefügte Container und ist ohne Abonnement sichtbar. Die Bedienung gleicht dem Portal, läuft aber lokal. Blobs werden per Editor geöffnet, Eigenschaften und Metadaten lassen sich direkt ändern. Warteschlangennachrichten werden eingefügt, abgerufen und gelöscht, Inhalte erscheinen strukturiert. Tabellenzeilen entstehen über Partition Key, Row Key und frei definierte Spalten, Filter grenzen die Ansicht ein.

Für Docker-Setups zählt der Kontext. Der Explorer spricht im Standardkontext mit dem lokalen Docker-Daemon. Ein Wechsel gelingt über docker context use. Snap-Installationen benötigen die Kopplung an den Docker-Daemon. Eigen definierte Konten in Containern prüfen Administratoren über docker exec … printenv AZURITE_ACCOUNTS. Das erleichtert die Kontrolle von Account-Namen und Schlüsseln.

Diagnosepfade sind direkt verfügbar. Fehlende Rollen verhindern das Anzeigen von Daten, SAS-Defizite löst ein erneutes Anfügen. Zertifikatsfehler korrigiert ein Import von Zertifikaten, der Start mit --ignore-certificate-errors bleibt eine Notlösung. Proxys unterstützt der Explorer mit Standardauthentisierung, NTLM scheidet hier allerdings aus. Für Netzwerk-Tracing eignet sich Fiddler mit System-Proxy. Protokolle liegen im Anwendungsverzeichnis, AzCopy-Logs separat pro Benutzerprofil.

Entwicklungsabläufe und Tools

In Visual Studio erscheint Azurite nach Aktivierung unter Service Dependencies. Das Tooling ergänzt Registrierungen in Program.cs und injiziert fertige Clients in den DI-Container, der Verbindungs-String landet in User Secrets. Der Start des Emulators erfolgt im Hintergrund. VS Code startet und stoppt Azurite über die Erweiterung. Azure Functions fragen bei F5 nach einer Storage-Verbindung und schreiben UseDevelopmentStorage=true in die lokalen Einstellungen. Der Wechsel zur Cloud ist ein reines Umlenken des Verbindungs-Strings.

Der Storage Explorer ergänzt diese Abläufe. Der Upload in einen Blobcontainer bestätigt Datenpfade, ohne dass eine Anwendung kompiliert werden muss. Queue-Nachrichten lassen sich erstellen und parallel in der Konsole verarbeiten. Tabellenentitäten werden im Editor angelegt und per SDK gelesen oder gefiltert, was Schemafehler im Modell sofort sichtbar macht.

CI und Testautomatisierung

In Build-Pipelines läuft Azurite als Container. Ein typischer Job startet das Image, öffnet die Ports und führt Tests aus. Der Explorer ist für diese Szenarien nicht erforderlich, bleibt aber in Debug-Phasen nützlich. Wichtig ist die Kontrolle des Containerstatus und der Portfreigaben:

jobs:

  test:

    runs-on: ubuntu-latest

    steps:

      - uses: actions/checkout@v4

      - run: docker run -d --name azurite -p 10000:10000 -p 10001:10001 -p 10002:10002 mcr.microsoft.com/azure-storage/azurite

      - run: dotnet test

Persistenz, Aufräumen und Fehlverhalten

Beim ersten Start legt Azurite pro Dienst Arbeitsverzeichnisse und Metadatendateien an. Ein Reset erfolgt durch Löschen der Ordner und Neustart des Emulators. Fehlertexte können vom Cloud-Verhalten abweichen, Statuscodes bleiben deckungsgleich. Für Tabellenszenarien mit Durable Functions ist Table-Support erforderlich, die Preview-Einschränkungen sind einzuplanen.

Sobald Logik, Schema und Nebenbedingungen stabil laufen, wird der lokale Verbindungsstring durch einen Cloud-String ersetzt. Storage Explorer prüft dieselben Vorgänge nun gegen ein echtes Konto. SAS-Regeln und rollenbasierte Zugriffe (RBAC) sichern Datenebene und Verwaltung. Der Umstieg bleibt degenerationsfrei, da API-Semantik konsistent entworfen wurde.