Freigeben über


Konfigurieren von Sidecars in Azure App Service

Dieser Artikel enthält praktische Schritte zum Aktivieren und Konfigurieren von Sidecars in Ihrer App Service-App.

Erstellen eines Sidecars im Azure-Portal

  1. Wechseln Sie im Azure-Portal zu Ihrer App Service-Ressource.
  2. Wählen Sie das Bereitstellungszentrum aus und wechseln Sie zur Registerkarte Container.
  3. Klicken Sie auf "Container hinzufügen ", um ein Sidecar hinzuzufügen.
  4. Geben Sie den Bildnamen, die Registrierungsauthentifizierung (falls erforderlich) und Umgebungsvariablen ein.
  5. Speichern Sie Ihre Änderungen. Das Sidecar wird zusammen mit Ihrem Haupt-App-Container bereitgestellt.

Aktivieren der Sidecar-Unterstützung für benutzerdefinierte Linux-Container

Für einen benutzerdefinierten Container müssen Sie die Sidecar-Unterstützung explizit aktivieren. Im Portal können Sie die Auswahl im Assistenten zum Erstellen des App-Diensts treffen. Sie können sie auch für eine vorhandene App auf der Seite "Deployment Center>Containers " einer vorhandenen Anwendung aktivieren, wie im folgenden Screenshot gezeigt:

Screenshot der Containereinstellungen einer benutzerdefinierten Container-App mit hervorgehobener Schaltfläche

Stellen Sie mit der Azure CLI LinuxFxVersion auf sitecontainers ein. Beispiel:

az webapp config set --name <app-name> --resource-group <resource-group> --linux-fx-version sitecontainers

Weitere Informationen finden Sie unter Was sind die Unterschiede bei benutzerdefinierten Containern mit Sidecar-Unterstützung?

Was sind die Unterschiede bei benutzerdefinierten Containern mit Sidecar-Unterstützung?

Sidecar-fähige Apps sind anders konfiguriert als Apps, die nicht sidecar-fähig sind.

  • Sidecar-fähige Apps werden durch LinuxFxVersion=sitecontainers gekennzeichnet und mit sitecontainers Ressourcen konfiguriert.
  • Apps, für die kein Sidecar aktiviert ist, konfigurieren den Containernamen und -typ direkt mit LinuxFxVersion=DOCKER|<image-details>.

Weitere Informationen finden Sie unter az webapp config set --linux-fx-version.

Apps, die nicht mit Sidecars aktiviert sind, konfigurieren den Hauptcontainer mit App-Einstellungen, z. B.:

  • DOCKER_REGISTRY_SERVER_URL
  • DOCKER_REGISTRY_SERVER_USERNAME
  • DOCKER_REGISTRY_SERVER_PASSWORD
  • WEBSITES_PORT

Diese Einstellungen gelten nicht für Sidecar-fähige Apps.

Definieren eines Sidecars mit einer ARM-Vorlage

Fügen Sie den Microsoft.Web/sites/sitecontainers Ressourcentyp zu einer App hinzu. Um ein Sidecar-Image von ACR mithilfe einer vom Benutzer zugewiesenen verwalteten Identität abzurufen, geben Sie authType als UserAssigned an und stellen Sie userManagedIdentityClientId bereit:

{
  "type": "Microsoft.Web/sites/sitecontainers",
  "apiVersion": "2024-04-01",
  "name": "<app-name>/<sidecar-name>",
  "properties": {
    "image": "<acr-name>.azurecr.io/<image-name>:<version>",
    "isMain": false,
    "authType": "UserAssigned",
    "userManagedIdentityClientId": "<client-id>",
    "environmentVariables": [
      { "name": "MY_ENV_VAR", "value": "my-value" }
    ]
  }
}

Von Bedeutung

Nur der Hauptcontainer ("isMain": true) empfängt externen Datenverkehr. In einer benutzerdefinierten Linux-Container-App mit aktivierter Sidecar-Unterstützung hat Ihr Hauptcontainer isMain auf truefestgelegt. Alle Sidecar-Container sollten "isMain": false haben.

Weitere Informationen finden Sie unter Microsoft.Web sites/sitecontainers.

Sidecars erstellen mit Azure CLI

Erstellen Sie eine sidecar-fähige App mit az webapp create. Beispiel:

az webapp create --name <app-name> --resource-group <group-name> --sitecontainers-app

Erstellen Sie einen Sidecar-Container mit az webapp sitecontainers create. Beispiel:

az webapp sitecontainers create --name <app-name> --resource-group <group-name> --container-name <container> --image <image> --target-port <port>

Erstellen eines Sidecar-Containers mit einer JSON-Datei:

az webapp sitecontainers create --name <app-name> --resource-group <group-name> --sitecontainers-spec-file <file-path>

Alle Sidecar-Befehle finden Sie unter az webapp sitecontainers.

Festlegen von Umgebungsvariablen

In einer Linux-App teilen alle Container (Haupt- und Sidecars) Umgebungsvariablen. Um eine bestimmte Variable für ein Sidecar außer Kraft zu setzen, fügen Sie sie in der Konfiguration des Sidecars hinzu.

  • Verwenden Sie in ARM-Vorlagen das environmentVariables Array in den Eigenschaften des Sidecars.
  • Fügen Sie im Portal Umgebungsvariablen in der Containerkonfigurations-UI hinzu.
  • Umgebungsvariablen können nach Namen auf App-Einstellungen verweisen; der Wert wird zur Laufzeit aufgelöst.

Fügen Sie die Redis-Sidecar-Erweiterung hinzu

Im Azure-Portal können Sie Ihrer App zum Zwischenspeichern eine Redis-Sidecar-Erweiterung hinzufügen. Das Redis-Sidecar ist nur für einfaches Zwischenspeichern vorgesehen, nicht ein Ersatz für Azure Cache für Redis.

So verwenden Sie das Redis Sidecar:

  • Legen Sie in Ihrem Anwendungscode die Redis-Verbindungszeichenfolge auf localhost:6379.
  • Konfigurieren Sie Redis im Startcode Ihrer App.
  • Verwenden Sie Zwischenspeicherungsmuster zum Speichern und Abrufen von Daten.
  • Testen Sie, indem Sie auf Ihre App zugreifen und Protokolle überprüfen, um die Cachenutzung zu bestätigen.

Fügen Sie die Datadog-Sidecar-Erweiterung hinzu

Über das Azure-Portal können Sie eine Datadog-Sidecar-Erweiterung hinzufügen, um Protokolle, Metriken und Ablaufverfolgungen zu sammeln, ohne den App-Code zu ändern. Wenn Sie die Erweiterung hinzufügen, geben Sie Ihre Datadog-Kontoinformationen an, damit die Sidecar-Erweiterung Telemetrie direkt an Datadog senden kann.

Für codebasierte Apps:

  1. Erstellen Sie ein startup.sh Skript zum Herunterladen und Initialisieren des Datadog-Tracers. Das folgende Skript ist ein Beispiel für eine .NET-App:

    #!/bin/bash
    
    # Create log directory. This should correspond to the "Datadog Trace Log Directory" extension setting
    mkdir -p /home/LogFiles/dotnet
    
    # Download the Datadog tracer tarball
    wget -O /datadog/tracer/datadog-dotnet-apm-2.49.0.tar.gz https://github.com/DataDog/dd-trace-dotnet/releases/download/v2.49.0/datadog-dotnet-apm-2.49.0.tar.gz
    
    # Navigate to the tracer directory, extract the tarball, and return to the original directory
    mkdir -p /datadog/tracer
    pushd /datadog/tracer
    tar -zxf datadog-dotnet-apm-2.49.0.tar.gz
    popd
    
    dotnet /home/site/wwwroot/<yourapp>.dll
    
  2. Legen Sie den Startbefehl in App Service fest, um dieses Skript auszuführen.

  3. Führen Sie die Anwendung aus, und bestätigen Sie, dass die Telemetrie ausgeliefert wird, indem Sie sich bei Ihrem Datadog-Dashboard anmelden.

Für containerbasierte Apps:

Bevor Sie die Datadog-Sidecar-Erweiterung hinzufügen, fügen Sie das Datadog Tracer-Setup in Ihrer Dockerfile hinzu, ähnlich dem Skriptbeispiel für codebasierte Apps.

Fügen Sie die Phi-3/Phi-4-Sidecar-Erweiterung hinzu

Im Azure-Portal können Sie Ihrer App eine Phi-3- oder Phi-4-Sidecar-Erweiterung hinzufügen, um ein lokales Rückschlussmodell für KI-Workloads bereitzustellen. Ihre App muss sich in einem Preisniveau befinden, das die Ableitungsanforderungen unterstützt. Bei nicht unterstützten Ebenen werden die Optionen für die Phi-3/Phi-4-Sidecar-Erweiterungen nicht angezeigt.

  • Der Phi-3/Phi-4-Sidecar macht eine Chat-Abschluss-API unter http://localhost:11434/v1/chat/completions.
  • Nach dem Hinzufügen des Sidecars kann der erste Start wegen des Ladevorgangs des Modells langsam sein.
  • Um die API aufzurufen, senden Sie POST-Anforderungen an diesen Endpunkt im gleichen Stil der OpenAPI-Chatabschluss-API.

Vollständige Schritt-für-Schritt-Anleitungen finden Sie unter:

Zugreifen auf ein Sidecar vom Hauptcontainer oder von einem anderen Sidecar

Sidecar-Container verwenden denselben Netzwerkhost wie der Hauptcontainer. Der Hauptcontainer und andere Sidecars können jeden Port auf einem Sidecar erreichen. localhost:<port> Wenn beispielsweise ein Sidecar auf Port 4318 lauscht, kann die Haupt-App darauf unter localhost:4318 zugreifen.

Das Feld "Port " im Portal ist nur Metadaten und wird nicht vom App-Dienst für das Routing verwendet.

Hinzufügen von Volume-Mounts

Standardmäßig wird das Standardvolume /home für alle Container bereitgestellt, es sei denn, es ist deaktiviert. Sie können zusätzliche Volume-Mounts für Ihre Sidecars konfigurieren.

Volume-Einbindungen ermöglichen das Teilen von nicht-persistenten Dateien und Verzeichnissen zwischen Containern innerhalb Ihrer Web-Anwendung.

  • Volume-Unterpfad: Ein logischer Verzeichnispfad, der vom App Service erstellt wurde. Container mit demselben Unterpfad teilen Dateien.
  • Container-Einbindepfad: Verzeichnispfad innerhalb des Containers, der dem Unterpfad des Volumes zugeordnet ist.

Beispielkonfiguration:

Sidecarname Volumeunterpfad Containereinbindungspfad Schreibgeschützt
Behälter1 /directory1/directory2 /container1Vol Falsch
Container2 /directory1/directory2 /container2Vol Richtig
Container3 /directory1/directory2/directory3 /container3Vol Falsch
Container4 /directory4 /container1Vol Falsch
  • Wenn Container1 /container1Vol/myfile.txt erstellt, kann Container2 es über /container2Vol/myfile.txt lesen.
  • Wenn Container1 /container1Vol/directory3/myfile.txt erstellt, kann Container2 es über /container2Vol/directory3/myfile.txt lesen, und Container3 kann über /container3Vol/myfile.txt Lese-/Schreibzugriff haben.
  • Container4 gibt kein Volume für die anderen frei.

Hinweis

Für codebasierte Linux-Apps kann der integrierte Linux-Container keine Volume-Mounts verwenden.

Weitere Ressourcen