Verwenden Sie Azure Cosmos DB als Docker-Container in CI/CD-Pipelines

Es gibt viele Vorteile bei der Verwendung von Docker-Containern in CI/CD-Pipelines, insbesondere für zustandsbehaftete Systeme wie Datenbanken. Zum Beispiel kann jeder CI-Job beim Ausführen von Integrationstests die Datenbank in einem isolierten Container mit einem sauberen Zustand starten, wodurch Konflikte zwischen den Tests vermieden werden. Dies führt zu einer Testumgebung, die zuverlässig, konsistent und kosteneffektiv ist. Dieser Ansatz reduziert auch die Latenz und verbessert die Gesamtleistung der CI/CD-Pipeline, da die Datenbank lokal zugänglich ist.

Der Linux-basierte Azure Cosmos DB-Emulator ist als Docker-Container verfügbar und kann auf verschiedenen Plattformen ausgeführt werden, einschließlich ARM64-Architekturen wie Apple Silicon. Er ermöglicht die lokale Entwicklung und das Testen von Anwendungen, ohne dass ein Azure-Abonnement erforderlich ist oder Servicekosten anfallen. Sie können ihn einfach als Docker-Container ausführen und für die lokale Entwicklung und das Testen verwenden:

docker pull mcr.microsoft.com/cosmosdb/linux/azure-cosmos-emulator:vnext-preview

Azure Cosmos DB mit GitHub Actions

Lass uns ein Beispiel durchgehen, um besser zu verstehen, wie man den Azure Cosmos DB Emulator mit GitHub Actions verwendet, das eine kontinuierliche Integration und kontinuierliche Bereitstellung (CI/CD) Plattform ist, die es dir ermöglicht, deinen Build-, Test- und Bereitstellungsprozess mithilfe von Workflows zu automatisieren. Ein Workflow ist ein konfigurierbarer automatisierter Prozess, der einen oder mehrere Jobs ausführen kann. Er wird durch eine YAML-Datei definiert, die in dein Repository eingecheckt wird, und wird ausgelöst, wenn ein Ereignis in deinem Repository eintritt, oder er kann manuell oder zu einem festgelegten Zeitplan ausgelöst werden.

Beispiel: CI-Workflow für eine .NET-Anwendung

Dieser GitHub Actions Workflow konfiguriert den Azure Cosmos DB Emulator auf Linux-Basis als GitHub Actions-Dienstcontainer als Teil eines Jobs. GitHub kümmert sich um das Starten des Docker-Containers und entfernt ihn, wenn der Job abgeschlossen ist – keine manuelle Intervention ist erforderlich (wie z.B. das Ausführen des Docker run-Befehls).

name: .NET App CI

on:
  push:
    branches: [main]
    paths:
      - 'dotnet-app/**'
  pull_request:
    branches: [main]
    paths:
      - 'dotnet-app/**'

jobs:
  build-and-test:
    runs-on: ${{ matrix.os }}

    strategy:
      matrix:
        os: [ubuntu-latest, ubuntu-24.04-arm]

    services:
      cosmosdb:
        image: mcr.microsoft.com/cosmosdb/linux/azure-cosmos-emulator:vnext-preview
        ports:
          - 8081:8081
        env:
          PROTOCOL: https

    env:
      COSMOSDB_CONNECTION_STRING: ${{ secrets.COSMOSDB_CONNECTION_STRING }}
      COSMOSDB_DATABASE_NAME: ${{ vars.COSMOSDB_DATABASE_NAME }}
      COSMOSDB_CONTAINER_NAME: ${{ vars.COSMOSDB_CONTAINER_NAME }}

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Set up .NET
        uses: actions/setup-dotnet@v3
        with:
          dotnet-version: '8.0.x'

      - name: Export Cosmos DB Emulator Certificate
        run: |
          sudo apt update && sudo apt install -y openssl
          openssl s_client -connect localhost:8081 </dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > cosmos_emulator.cert

          sudo cp cosmos_emulator.cert /usr/local/share/ca-certificates/
          sudo update-ca-certificates

      - name: Install dependencies
        run: cd dotnet-app && dotnet restore

      - name: Build
        run: cd dotnet-app && dotnet build --no-restore

      - name: Run tests
        run: cd dotnet-app && dotnet test --no-build --verbosity normal

Dieser Job ist so konfiguriert, dass er auf einem Ubuntu-Runner ausgeführt wird und verwendet das mcr.microsoft.com/cosmosdb/linux/azure-cosmos-emulator:vnext-preview Docker-Image als Dienstcontainer. Der Verbindungsstring, der Datenbankname und der Containername sind als Umgebungsvariablen konfiguriert. Da der Job direkt auf einem GitHub Actions gehosteten Runner ausgeführt wird, kann der Schritt „Tests ausführen“ auf den Emulator unter localhost:8081 zugreifen.

Der Schritt zum Exportieren des Cosmos DB Emulator-Zertifikats ist spezifisch für .NET (sowie Java) Anwendungen, da zum Zeitpunkt des Schreibens die .NET- und Java-SDKs den HTTP Modus im Emulator nicht unterstützen. Die Umgebungsvariable PROTOCOL ist im Abschnitt services auf https gesetzt und dieser Schritt exportiert das Emulatorzertifikat und fügt es dem vertrauenswürdigen Zertifikatspeicher des Betriebssystems hinzu.

Probier es aus!

Dieses GitHub-Repository bietet Beispiele dafür, wie man den Linux-Emulator als Teil eines GitHub Actions CI-Workflows für .NET-, Python-, Java- und Go-Anwendungen sowohl auf x64 als auch auf ARM64 Architekturen konfiguriert (demonstriert für einen Linux-Runner unter Verwendung von Ubuntu).

Forken Sie das Repository

Navigieren Sie zum GitHub-Repository und klicken Sie auf die Schaltfläche Fork in der oberen rechten Ecke der Repository-Seite, um eine Kopie des Repositories unter Ihrem eigenen GitHub-Konto zu erstellen.

Öffnen Sie in Ihrem GitHub-Konto das Repository und stellen Sie sicher, dass Sie die Workflows in den Repository-Einstellungen aktivieren.

Fügen Sie den Verbindungsstring für den Cosmos DB-Emulator (COSMOSDB_CONNECTION_STRING) als Repository-Geheimnis zum Repository hinzu. Verwenden Sie den folgenden Wert:

AccountEndpoint=http://localhost:8081/;AccountKey=C2y6yDjf5/R+ob0N8A7Cgv30VRDJIWEHLM+4QDU5DE2nQ9nDuVTqobD4b8mGGyPMbIZnqyMsEcaGQy67XIw/Jw==

Fügen Sie den Datenbanknamen (COSMOSDB_DATABASE_NAME) und den Containernamen (COSMOSDB_CONTAINER_NAME) als Repository-Variablen hinzu:

Klonen Sie das geforkte Repository auf Ihre lokale Maschine (stellen Sie sicher, dass Sie Ihren GitHub-Benutzernamen verwenden):

git clone https://github.com/<your-username>/cosmosdb-linux-emulator-github-actions.git

cd cosmosdb-linux-emulator-github-actions

Workflow auslösen

Um den Workflow auszulösen, nehmen Sie eine kleine Änderung an einem oder mehreren Codeabschnitten vor (.NET, Java, Python oder Go) und fügen Sie Ihre Änderungen hinzu und committen Sie diese. Für ein einfacheres Verständnis werden separate Workflows für jede Sprache verwendet.

Übertragen Sie Ihre Änderungen an Ihr geforktes Repository auf GitHub:

git add . 
git commit -m "Your commit message" 
git push origin main

Nachdem die Änderungen gepusht wurden, wird GitHub Actions automatisch den Workflow ausführen. Gehen Sie zum Register „Actions“ in Ihrem Repository, um den Status und die Ergebnisse der Workflows zu sehen. Überprüfen Sie jegliche Logs oder Ausgaben, um sicherzustellen, dass die Workflows korrekt ausgeführt werden.

Überlegungen zum GitHub Actions Runner

Das Beispiel-Repository hat Ubuntu-basierte Runner vorgeführt (für x64 und ARM64 Architekturen). Dies sollte auch für Windows ARM-basierte Runner funktionieren. Wenn Sie Windows x64 Runner in Betracht ziehen, beachten Sie, dass zum Zeitpunkt des Schreibens die GitHub Actions Service-Container in nicht-Linux-Runnern nicht unterstützt werden. Sie können dies jedoch umgehen, indem Sie Schritte hinzufügen, um Docker zu installieren und seinen Lebenszyklus zu verwalten, einschließlich dem Starten und Stoppen des Containers.

Zusammenfassung

Wie bereits erwähnt, gibt es viele Vorteile bei der Verwendung von Docker-Containern in CI-Pipelines. In diesem Fall wurde GitHub Actions als CI/CD-Plattform verwendet, aber diese Konzepte gelten auch für andere Lösungen. Probieren Sie es aus und lassen Sie uns wissen, was Sie denken!