Azure Storage ist das Microsoft-Äquivalent zu Amazons S3 (Simple Storage Service). Sein Blob-Speicher speichert beliebige Text- oder Binärdaten, wie Dokumente, Mediendateien oder Anwendungsinstallationspakete.

Microsoft stellt eine großartige Client-Bibliothek für Spring-Boot-Anwendungen bereit, um auf Azure Storage zuzugreifen.

Alles, was ihr tun müsst, ist die folgende Abhängigkeit hinzuzufügen:

<dependency>
   <groupId>com.azure.spring</groupId>
   <artifactId>azure-spring-boot-starter-storage</artifactId>
   <version>3.10.0</version>
</dependency>

Dann tragt euren Kontonamen, Kontoschlüssel und Blob-Endpunkt in eure application.yaml ein – all diese Werte erhaltet ihr aus dem Azure Portal:

azure:
  storage: 
    account-name: <storage-account-name>
    account-key: <storage-account-access-key>
    blob-endpoint: <storage-endpoint-URL>

Ihr könnt dann Beans wie den BlobServiceClientBuilder autowiren, die den Zugriff auf euren Speicher ermöglichen und das Hoch- und Herunterladen von Dateien erlauben, wie in der Client-Bibliothek ausführlich erklärt.

Obwohl dieses Setup einfach zu verwenden ist, hat es einen wesentlichen Nachteil: Es macht euch zur Entwicklungs- und Integrationstestzeit von Azure Storage abhängig, was bedeutet, dass ihr ohne Internetzugang nicht mehr entwickeln könnt. Wenn eure Integrationstests ebenfalls von Azure abhängen, könnt ihr euren Build nicht einmal ohne Online-Verbindung ausführen. Obwohl das besonders bei Cloud-nativen Anwendungen immer häufiger der Fall sein wird – insbesondere bei anspruchsvollen KI-Diensten –, bin ich der Meinung, dass ihr euch bei grundlegenden Diensten wie dem Speichern von Dateien in einem Blob Storage so weit wie möglich unabhängig machen solltet.

Glücklicherweise gibt es eine Lösung:

Azurite als lokaler Azure Storage

Genau wie es MinIO für AWS S3 gibt, gibt es Azurite für Azure Storage.

Azurite ist ein Open-Source-Server (Emulator), der mit der Azure Storage API kompatibel ist. Auf Basis von Node.js läuft Azurite plattformübergreifend und richtet sich an alle, die Azure Storage einfach in einer lokalen Umgebung ausprobieren möchten. Azurite simuliert die meisten von Azure Storage unterstützten Befehle mit minimalen Abhängigkeiten.

Obwohl Azurite weite Teile der Azure Storage API unterstützt (Blob Storage, Queue Storage, Table Storage), ist es immer noch nicht dasselbe wie das Original auf Azure – das erinnert mich an meinen früheren Blogbeitrag, in dem ich über MockMvc in Spring als Ersatz für einen vollwertigen Webserver geschrieben habe.

Wie auch immer: Für die meisten Anwendungsfälle ist Azurite mehr als gut genug – genau wie MinIO als ausgereifter lokaler Ersatz für Amazons S3.

Azurite lokal zu starten ist mit einem einzigen Docker-Befehl möglich:

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

Ändert nun eure application.yaml von oben auf folgende Werte:

azure:
  storage: 
    account-name: devstoreaccount1
    account-key: Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==
    blob-endpoint: http://localhost:10000/devstoreaccount1

Startet eure Anwendung neu, und ihr seid mit eurer lokalen Azurite-Instanz verbunden und könnt vollständig autonom arbeiten.

Playtika TestContainers für lokale Integrationstests verwenden

Eine der großartigen Eigenschaften von Docker sind TestContainers, die eine nahtlose Integration mit JUnit5-Tests ermöglichen.

Playtikas Bibliothek testcontainers-spring-boot ist ein Wrapper um Testcontainers, der sich gut in das Auto-Konfigurationskonzept von Spring Boot einfügt. Sie konfiguriert eure Beans vor und kümmert sich um dynamische Ports, um Konflikte mit anderen lokalen Containern zu vermeiden.

Sie bietet Module für viele Container wie MySQL, RabbitMQ oder ElasticSearch, aber es gab noch keine Unterstützung für Azurite – also habe ich das selbst implementiert und einen Pull Request erstellt, der sehr schnell gemergt und veröffentlicht wurde.

Die Unterstützung für das Testen von Azurite über Testcontainers und Spring Boot ist nun für alle verfügbar, und so funktioniert es:

Importiert zunächst diese Bibliothek:

<dependency>
    <groupId>com.playtika.testcontainers</groupId>
    <artifactId>embedded-azurite</artifactId>
    <scope>test</scope>
</dependency>

Fügt in eurer src/test/resources/application.yaml folgende Eigenschaften hinzu:

azure:
  storage:
    account-name: ${embedded.azurite.account-name}
    account-key: ${embedded.azurite.account-key}
    blob-endpoint: ${embedded.azurite.blob-endpoint}

Diese embedded.azurite.*-Eigenschaften werden von embedded-azurite erzeugt, wie in der Dokumentation ausführlich erklärt.

Erstellt abschließend einen @SpringBootTest, der @EnableAutoConfiguration hinzufügt. Ihr könnt dann Beans wie den BlobServiceClientBuilder autowiren, und Testcontainers kümmert sich darum, Azurite vor den Tests zu starten.

Die Testklasse von embedded-azurite zeigt euch ein Beispiel dafür:

@SpringBootTest(classes = EmbeddedAzuriteBoostrapConfigurationTest.AzuriteTestConfiguration.class)
class EmbeddedAzuriteBoostrapConfigurationTest {
    @Autowired
    BlobServiceClientBuilder blobServiceClientBuilder;
    @Test
    void accountName() {
        BlobServiceClient blobServiceClient = blobServiceClientBuilder
             .buildClient();
        assertThat(blobServiceClient.getAccountName())
            .isEqualTo(AzuriteContainer.ACCOUNT_NAME);
    }
    @EnableAutoConfiguration
    public static class AzuriteTestConfiguration {
    }
}

Nun könnt ihr nicht nur lokal entwickeln, sondern auch Integrationstests mit Testcontainers lokal ausführen, ohne von einem externen Dienst abhängig zu sein.

https://github.com/Playtika/testcontainers-spring-boot/tree/develop/embedded-azurite