Freigeben über

Konfigurieren eines benutzerdefinierten Containers für Azure App Service

In diesem Artikel erfahren Sie, wie Sie einen benutzerdefinierten Container für die Ausführung unter Azure App Service konfigurieren.

Dieser Leitfaden enthält die wichtigsten Konzepte und Anweisungen für die Containerstellung von Windows-Apps in App Service. Neue Azure App Service-Benutzer sollten zuerst dem Schnellstart und dem Lernprogramm für benutzerdefinierte Container folgen.

Dieser Leitfaden enthält die wichtigsten Konzepte und Anweisungen für die Containerstellung von Linux-Apps in App Service. Wenn Sie mit Azure App Service noch nicht fertig sind, folgen Sie zuerst der benutzerdefinierten Containerschnellstartanleitung und dem Lernprogramm. Informationen zu Sidecar-Containern finden Sie im Tutorial: Konfigurieren eines Sidecar-Containers für benutzerdefinierte Container in Azure App Service.

Hinweis

Der Dienstprinzipal wird für die Pullauthentifizierung von Windows-Containerimages nicht mehr unterstützt. Es wird empfohlen, verwaltete Identität für Windows- und Linux-Container zu verwenden.

Unterstützte übergeordnete Images

Wählen Sie für Ihr benutzerdefiniertes Windows-Image das richtige übergeordnete Image (Basisimage) für das gewünschte Framework aus:

  • Verwenden Sie zum Bereitstellen von .NET Framework-Apps ein übergeordnetes Image, das auf dem LTSC-Release (Long-Term Servicing Channel, langfristiger Wartungskanal) von Windows Server 2019 Core basiert.
  • Verwenden Sie zum Bereitstellen von .NET Core-Apps ein übergeordnetes Image, das auf dem Release Annual Channel (AC) von Windows Server 2019 Nano basiert.

Es dauert einige Zeit, ein Basis-Image beim Start der App herunterzuladen. Sie können die Startzeit reduzieren, indem Sie eines der folgenden übergeordneten Bilder verwenden, die bereits in Azure App Service zwischengespeichert sind:

Ändern des Docker-Images eines benutzerdefinierten Containers

Wenn Sie einen vorhandenen benutzerdefinierten Container vom aktuellen Docker-Image auf ein neues Image umstellen möchten, verwenden Sie den folgenden Befehl:

az webapp config container set --name <app-name> --resource-group <group-name> --docker-custom-image-name <docker-hub-repo>/<image>

Verwenden eines Images aus einer privaten Registrierung

Führen Sie den folgenden Befehl aus, um ein Image aus einer privaten Registrierung wie Azure Container Registry zu verwenden:

az webapp config container set --name <app-name> --resource-group <group-name> --docker-custom-image-name <image-name> --docker-registry-server-url <private-repo-url> --docker-registry-server-user <username> --docker-registry-server-password <password>

Geben Sie für <Benutzername> und <Kennwort> die Anmeldeinformationen für das Konto Ihrer privaten Registrierung an.

Verwenden Sie eine verwaltete Identität zum Pullen eines Image aus Azure Container Registry.

Folgen Sie den folgenden Schritte, um Ihre Web-App zum Pullen aus Azure Container Registry (ACR) mithilfe einer verwalteten Identität zu konfigurieren. Die Schritte verwenden vom System zugewiesene verwaltete Identität. Sie können stattdessen die vom Benutzer zugewiesene verwaltete Identität verwenden.

  1. Aktivieren Sie die vom System zugewiesene verwaltete Identität für die Web-App mithilfe des Az webapp Identity Assign-Befehls :

    az webapp identity assign --resource-group <group-name> --name <app-name> --query principalId --output tsv

    Ersetzen Sie <den App-Namen> durch den Namen, den Sie im vorherigen Schritt verwendet haben. Die Ausgabe des Befehls (gefiltert nach den Argumenten --query und --output) ist die Dienstprinzipal-ID der zugewiesenen Identität.

  2. So erhalten Sie die Ressourcen-ID Ihrer Azure Container Registry:

    az acr show --resource-group <group-name> --name <registry-name> --query id --output tsv

    Ersetzen Sie <den Registrierungsnamen> durch den Namen Ihrer Registrierung. Die Ausgabe des Befehls, gefiltert durch die Argumente --query und --output, ist die Ressourcen-ID der Azure-Containerregistrierung.

  3. Erteilen Sie der verwalteten Identität die Berechtigung für den Zugriff auf die Containerregistrierung:

    az role assignment create --assignee <principal-id> --scope <registry-resource-id> --role "AcrPull"

    Ersetzen Sie die folgenden Werte:

    • <principal-id> mit der Dienstprinzipal-ID aus dem az webapp identity assign Befehl
    • <registry-resource-id> mit der ID Ihrer Containerregistrierung über den az acr show Befehl

    Weitere Informationen zu diesen Berechtigungen finden Sie unter Was ist die rollenbasierte Zugriffssteuerung von Azure?.

  4. Konfigurieren Sie Ihre App so, dass sie die verwaltete Identität zum Abrufen aus der Azure Container Registry verwendet.

    az webapp config set --resource-group <group-name> --name <app-name> --generic-configurations '{"acrUseManagedIdentityCreds": true}'

    Ersetzen Sie die folgenden Werte:

    • <App-Name> mit dem Namen Ihrer Web-App.

    Tipp

    Wenn Sie die Befehle mithilfe der PowerShell-Konsole ausführen, müssen Sie die Zeichenfolgen im --generic-configurations-Argument in diesem und im nächsten Schritt mit Escapezeichen versehen. Beispiel: --generic-configurations '{\"acrUseManagedIdentityCreds\": true'

  5. (Optional) Wenn Ihre App eine benutzerseitig zugewiesene verwaltete Identität verwendet, stellen Sie sicher, dass die Identität für die Web-App konfiguriert ist, und legen Sie dann die Eigenschaft acrUserManagedIdentityID fest, um ihre Client-ID anzugeben:

    az identity show --resource-group <group-name> --name <identity-name> --query clientId --output tsv

    Ersetzen Sie <identity-name> in Ihrer benutzerseitig zugewiesenen verwalteten Identität, und verwenden Sie die Ausgabe <client-id>, um die ID der benutzerseitig zugewiesenen verwalteten Identität zu konfigurieren.

    az  webapp config set --resource-group <group-name> --name <app-name> --generic-configurations '{"acrUserManagedIdentityID": "<client-id>"}'

Sie sind fertig! Die Web-App verwendet jetzt verwaltete Identität, um aus der Azure-Containerregistrierung abzurufen.

Verwenden eines Images aus einer netzwerkgeschützten Registrierung

Um eine Verbindung mit einer Registrierung in einem virtuellen Netzwerk oder lokal herzustellen und von dieser abzurufen, muss Ihre App in ein virtuelles Netzwerk integriert werden. Außerdem benötigen Sie eine Integration des virtuellen Netzwerks für die Azure-Containerregistrierung mit privatem Endpunkt. Nachdem Sie Ihr Netzwerk und die DNS-Auflösung konfiguriert haben, aktivieren Sie das Routing des Image-Pull durch das virtuelle Netzwerk, indem Sie die vnetImagePullEnabled Standorteinstellung konfigurieren:

az resource update --resource-group <group-name> --name <app-name> --resource-type "Microsoft.Web/sites" --set properties.vnetImagePullEnabled [true|false]

Ich kann den aktualisierten Container nicht sehen

Wenn Sie Ihre Docker-Container-Einstellungen so ändern, dass sie auf einen neuen Container verweisen, kann es ein paar Minuten dauern, bis die App HTTP-Anfragen aus dem neuen Container bedient. Während der neue Container abgerufen und gestartet wird, bedient App Service weiterhin Anforderungen aus dem alten Container. Nur wenn der neue Container gestartet wird und zum Empfangen von Anforderungen bereit ist, beginnt App Service mit dem Senden von Anforderungen an ihn.

So werden Containerimages gespeichert

Wenn Sie ein benutzerdefiniertes Docker-Image zum ersten Mal in App Service ausführen, führt App Service ein docker pull aus und ruft alle Imageebenen ab. Diese Ebenen werden auf dem Datenträger gespeichert, so als ob Sie Docker lokal verwendeten. Jedes Mal, wenn die App neu gestartet wird, führt App Service docker pull aus. Dabei werden nur geänderte Ebenen gepullt. Wenn keine Änderungen vorliegen, verwendet App Service vorhandene Ebenen auf dem lokalen Datenträger.

Wenn die App Compute-Instanzen aus irgendeinem Grund ändert (z. B. durch Hoch- oder Herunterskalieren der Tarife), muss App Service alle Ebenen erneut abrufen. Das gleiche gilt, wenn Sie eine Skalierung ausführen, um weitere Instanzen hinzuzufügen. Es gibt auch seltene Fälle, in denen sich die App-Instanzen ohne Skalierungsvorgang ändern können.

Konfigurieren der Portnummer

Standardmäßig geht App Service davon aus, dass Ihr benutzerdefinierter Container auf Port 80 lauscht. Wenn Ihr Container an einem anderen Port lauscht, legen Sie die App-Einstellung WEBSITES_PORT in Ihrer App Service-App fest. Sie können es mithilfe der Cloud Shell festlegen. In Bash:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITES_PORT=8000

In PowerShell:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITES_PORT"="8000"}

App Service ermöglicht es Ihrem Container zurzeit, nur einen Port für HTTP-Anforderungen verfügbar zu machen.

Konfigurieren von Umgebungsvariablen

Ihr benutzerdefinierter Container verwendet möglicherweise Umgebungsvariablen, die extern bereitgestellt werden müssen. Sie können sie mithilfe der Cloud Shell übergeben. In Bash:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings DB_HOST="myownserver.mysql.database.azure.com"

In PowerShell:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"DB_HOST"="myownserver.mysql.database.azure.com"}

Wenn Ihre App ausgeführt wird, werden die Einstellungen der App Service-App automatisch als Umgebungsvariablen in den Prozess eingefügt. Sie können Containerumgebungsvariablen mit der URL https://<app-name>.scm.azurewebsites.net/Env überprüfen.

Wenn Ihre App Bilder aus einer privaten Registrierung oder von Docker Hub verwendet, werden Anmeldeinformationen für den Zugriff auf das Repository in Umgebungsvariablen gespeichert: DOCKER_REGISTRY_SERVER_URL, DOCKER_REGISTRY_SERVER_USERNAMEund DOCKER_REGISTRY_SERVER_PASSWORD. Aufgrund von Sicherheitsrisiken wird keiner dieser reservierten Variablennamen in der Anwendung verfügbar gemacht.

Für Container, die auf IIS oder dem .NET Framework (4.0 oder höher) basieren, werden die Anmeldeinformationen automatisch von dem App Service in System.ConfigurationManager als .NET-App-Konfigurationseinstellungen und Verbindungszeichenfolgen eingefügt. Für alle anderen Sprachen oder Frameworks werden sie als Umgebungsvariablen für den Prozess mit einem der folgenden Präfixe bereitgestellt:

  • APPSETTING_
  • SQLCONTR_
  • MYSQLCONTR_
  • SQLAZURECOSTR_
  • POSTGRESQLCONTR_
  • CUSTOMCONNSTR_

Diese Methode funktioniert sowohl für Apps mit einem einzelnen Container als auch für Apps mit mehreren Containern, wobei die Umgebungsvariablen in der Datei docker-compose.yml angegeben sind.

Verwenden von beständig freigegebenem Speicher

Sie können das Verzeichnis C:\home im Dateisystem Ihres benutzerdefinierten Containers verwenden, damit Dateien auch nach einem Neustart erhalten bleiben und instanzübergreifend freigegeben werden können. Das Verzeichnis "C:\home " wird bereitgestellt, damit Ihr benutzerdefinierter Container auf beständigen Speicher zugreifen kann.

Wenn der permanente Speicher deaktiviert ist, werden Schreibvorgänge im Verzeichnis "C:\home " nicht über App-Neustarts oder mehrere Instanzen hinweg beibehalten. Wenn der permanente Speicher aktiviert ist, bleiben alle Schreibvorgänge im Verzeichnis "C:\home " erhalten. Alle Instanzen einer skalierten App haben Zugriff darauf. Alle vorhandenen Dateien, die bereits im beständigen Speicher vorhanden sind, wenn der Container beginnt, überschreiben alle Inhalte im Verzeichnis "C:\home " des Containers.

Die einzige Ausnahme ist das Verzeichnis "C:\home\LogFiles ". In diesem Verzeichnis werden container- und Anwendungsprotokolle gespeichert. Dieser Ordner wird beim Neustart der App immer beibehalten, wenn die Anwendungsprotokollierung mit der Option "Dateisystem " aktiviert ist, unabhängig davon, ob der persistente Speicher aktiviert ist. Anders ausgedrückt: Das Aktivieren oder Deaktivieren des beständigen Speichers wirkt sich nicht auf das Verhalten der Anwendungsprotokollierung aus.

Standardmäßig ist der persistente Speicher bei benutzerdefinierten Windows-Containern aktiviert. Um ihn zu deaktivieren, legen Sie den Wert der WEBSITES_ENABLE_APP_SERVICE_STORAGE App-Einstellung mithilfe der false fest. In Bash:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITES_ENABLE_APP_SERVICE_STORAGE=false

In PowerShell:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITES_ENABLE_APP_SERVICE_STORAGE"=false}

Sie können das Verzeichnis /home im Dateisystem Ihres benutzerdefinierten Containers verwenden, damit Dateien auch nach einem Neustart erhalten bleiben und instanzübergreifend freigegeben werden können. Das Verzeichnis "/home " wird bereitgestellt, damit Ihr benutzerdefinierter Container auf beständigen Speicher zugreifen kann. Das Speichern von Daten innerhalb von /home trägt zum Speicherplatzkontingent bei, das in Ihrem App Service Plan enthalten ist.

Wenn der permanente Speicher deaktiviert ist, werden Schreibvorgänge in das Verzeichnis "/home " nicht über App-Neustarts oder mehrere Instanzen hinweg beibehalten. Wenn der permanente Speicher aktiviert ist, bleiben alle Schreibvorgänge im Verzeichnis "/home " erhalten. Alle Instanzen einer skalierten App haben Zugriff darauf. Alle vorhandenen Dateien, die bereits im beständigen Speicher vorhanden sind, wenn der Container beginnt, überschreiben alle Inhalte im /home-Verzeichnis des Containers.

Die einzige Ausnahme ist das Verzeichnis "/home/LogFiles ". In diesem Verzeichnis werden container- und Anwendungsprotokolle gespeichert. Dieser Ordner wird beim Neustart der App immer beibehalten, wenn die Anwendungsprotokollierung mit der Option "Dateisystem " aktiviert ist, unabhängig davon, ob der persistente Speicher aktiviert ist. Anders ausgedrückt: Das Aktivieren oder Deaktivieren des beständigen Speichers wirkt sich nicht auf das Verhalten der Anwendungsprotokollierung aus.

Es wird empfohlen, Daten in /home oder einen bereitgestellten Azure-Speicherpfad zu schreiben. Daten, die außerhalb dieser Pfade geschrieben wurden, sind während neustarts nicht persistent. Die Daten werden auf einem plattformverwalteten Hostspeicherplatz getrennt vom Dateispeicherkontingent für App Service-Pläne gespeichert.

Standardmäßig ist der persistente Speicher bei benutzerdefinierten Linux-Containern deaktiviert. Legen Sie zum Aktivieren den Wert der WEBSITES_ENABLE_APP_SERVICE_STORAGE App-Einstellung mithilfe der true auf fest. In Bash:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITES_ENABLE_APP_SERVICE_STORAGE=true

In PowerShell:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITES_ENABLE_APP_SERVICE_STORAGE"=true}

Hinweis

Sie können auch Ihren eigenen beständigen Speicher konfigurieren.

Erkennen einer HTTPS-Sitzung

App Service beendet TLS auf den Front-Ends. Das bedeutet, dass TLS-Anforderungen nie zu Ihrer App gelangen. Sie müssen keine Unterstützung für TLS in Ihre App implementieren und sollten sie nicht implementieren.

Die Front-Ends befinden sich in Azure-Rechenzentren. Wenn Sie TLS mit Ihrer App verwenden, wird Ihr Datenverkehr über das Internet immer sicher verschlüsselt.

Anpassen der Einfügung von ASP.NET-Computerschlüsseln

Während des Containerstarts werden automatisch generierte Schlüssel als Computerschlüssel für ASP.NET-Kryptografieroutinen in den Container eingefügt. Sie können diese Schlüssel in Ihrem Container finden, indem Sie nach den folgenden Umgebungsvariablen suchen: MACHINEKEY_Decryption, MACHINEKEY_DecryptionKey, MACHINEKEY_ValidationKey, MACHINEKEY_Validation.

Die neuen Schlüssel bei jedem Neustart könnten die ASP.NET-Formularauthentifizierung und den Anzeigestatus zurücksetzen, wenn Ihre Anwendung davon abhängt. Um die automatische Neugenerierung von Schlüsseln zu verhindern, legen Sie sie manuell als App Service-App-Einstellungen fest.

Herstellen einer Verbindung mit dem Container

Um sich direkt mit Ihrem Windows-Container für Diagnoseaufgaben zu verbinden, navigieren Sie zu https://<app-name>.scm.azurewebsites.net/ und wählen Sie die SSH-Option aus. Mit dieser Option wird eine direkte SSH-Sitzung eingerichtet, in der Sie Befehle in Ihrem Container ausführen können.

  • Sie funktioniert gesondert vom darüber angesiedelten grafischen Browser, in dem nur die Dateien in Ihrem freigegebenen Speicher angezeigt werden.
  • In einer skalierten Anwendung ist die SSH-Sitzung mit einer der Containerinstanzen verbunden. Sie können eine andere Instanz aus der Dropdownliste " Instanz " im oberen Kudu-Menü auswählen.
  • Jede Änderung, die Sie an dem Container innerhalb der SSH-Sitzung vornehmen, bleibt nicht erhalten, wenn Ihre App neu gestartet wird (mit Ausnahme von Änderungen im freigegebenen Speicher). Solche Änderungen sind nicht Teil des Docker-Images. Um Ihre Änderungen beizubehalten, wie z. B. Registrierungseinstellungen und Softwareinstallation, machen Sie sie zu einem Teil der Dockerfile-Datei.

Zugreifen auf Diagnoseprotokolle

App Service protokolliert Aktionen des Docker-Hosts und aus dem Container stammende Aktivitäten. Protokolle vom Docker-Host (Plattformprotokolle) sind standardmäßig aktiviert. Sie müssen Anwendungsprotokolle oder Webserverprotokolle manuell innerhalb des Containers aktivieren. Weitere Informationen finden Sie unter Aktivieren der Anwendungsprotokollierung und Aktivieren der Webserverprotokollierung.

Es gibt verschiedene Möglichkeiten, um auf Docker-Protokolle zuzugreifen:

Im Azure-Portal

Docker-Protokolle werden im Azure-Portal auf der Seite "Containereinstellungen" Ihrer App angezeigt. Die Protokolle werden abgeschnitten. Um alle Protokolle herunterzuladen, wählen Sie "Herunterladen" aus.

Von Kudu

Um die einzelnen Protokolldateien anzuzeigen, navigieren Sie zu https://<app-name>.scm.azurewebsites.net/DebugConsole dem LogFiles-Ordner , und wählen Sie den Ordner "LogFiles" aus. Um das gesamte LogFiles-Verzeichnis herunterzuladen, wählen Sie links neben dem Verzeichnisnamen das Symbol " Herunterladen " aus. Sie können auch über einen FTP-Client auf diesen Ordner zugreifen.

Im SSH-Terminal können Sie standardmäßig nicht auf den Ordner "C:\home\LogFiles " zugreifen, da der permanente freigegebene Speicher nicht aktiviert ist. Um dieses Verhalten im Konsolenterminal zu aktivieren, aktivieren Sie den persistenten freigegebenen Speicher.

Wenn Sie versuchen, das Docker-Protokoll, das gerade verwendet wird, mit einem FTP-Client herunterzuladen, erhalten Sie möglicherweise eine Fehlermeldung aufgrund einer Dateisperre.

Mit der Kudu-API

Navigieren Sie direkt zu https://<app-name>.scm.azurewebsites.net/api/logs/docker, um die Metadaten für die Docker-Protokolle anzuzeigen. Möglicherweise werden mehrere Protokolldateien aufgelistet. Mit href der Eigenschaft können Sie die Protokolldatei direkt herunterladen.

Um alle Protokolle zusammen in einer ZIP-Datei herunterzuladen, greifen Sie auf https://<app-name>.scm.azurewebsites.net/api/logs/docker/zip zu.

Container-Arbeitsspeicher anpassen

Standardmäßig sind alle in Azure App Service bereitgestellten Windows-Container mit einem Speicherlimit konfiguriert. In der folgenden Tabelle sind die Standardeinstellungen pro App Service-Plan-SKU aufgeführt.

App Service-Plan-SKU Standardspeicherlimit pro App in MB
P1v3 1024
P1Mv3 1024
P2v3 1536
P2Mv3 1536
P3v3 2048
P3Mv3 2048
P4Mv3 2560
P5Mv3 3072

Sie können diesen Wert ändern, indem Sie die WEBSITE_MEMORY_LIMIT_MB App-Einstellung mithilfe der Cloud Shell bereitstellen. In Bash:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITE_MEMORY_LIMIT_MB=2000

In PowerShell:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITE_MEMORY_LIMIT_MB"=2000}

Der Wert wird in MB definiert und muss kleiner oder gleich dem gesamten physischen Arbeitsspeicher des Hosts sein. In einem App Service-Plan mit 8 GB RAM darf die kumulierte Gesamtsumme WEBSITE_MEMORY_LIMIT_MB aller Apps beispielsweise 8 GB nicht überschreiten. Weitere Informationen dazu, wie viel Arbeitsspeicher verfügbar ist, finden Sie im Abschnitt "Premium v3-Serviceplan" der App Service-Preise.

Anpassen der Anzahl der Compute-Kerne

Standardmäßig wird ein Windows-Container mit allen verfügbaren Kernen für Ihren ausgewählten Tarif ausgeführt. Möglicherweise möchten Sie die Anzahl der Kerne verringern, die Ihr Staging-Slot verwendet. Um die Anzahl der von einem Container verwendeten Kerne zu verringern, legen Sie die App-Einstellung WEBSITE_CPU_CORES_LIMIT auf die bevorzugte Anzahl von Kernen fest. Sie können es mithilfe der Cloud Shell festlegen. In Bash:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --slot staging --settings WEBSITE_CPU_CORES_LIMIT=1

In PowerShell:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITE_CPU_CORES_LIMIT"=1}

Tipp

Durch das Aktualisieren der App-Einstellung wird ein automatischer Neustart ausgelöst, was zu minimalen Ausfallzeiten führt. Bei einer Produktions-App sollten Sie erwägen, sie in einen Stagingslot zu wechseln, die App-Einstellung im Stagingslot zu ändern, und die App dann wieder zurück in die Produktion zu wechseln.

Um Ihre angepasste Nummer zu überprüfen, öffnen Sie eine SSH-Sitzung aus dem Azure-Portal, oder verwenden Sie das Kudu-Portal (https://<app-name>.scm.azurewebsites.net/webssh/host). Geben Sie die folgenden Befehle mithilfe von PowerShell ein. Jeder Befehl gibt eine Zahl zurück.

Get-ComputerInfo | ft CsNumberOfLogicalProcessors # Total number of enabled logical processors. Disabled processors are excluded.
Get-ComputerInfo | ft CsNumberOfProcessors # Number of physical processors.

Die Prozessoren können Multicore- oder Hyperthreading-Prozessoren sein. Informationen dazu, wie viele Kerne verfügbar sind, finden Sie im Abschnitt "Premium v3-Serviceplan" des App Service-Preises.

Anpassen des Integritäts-Ping-Verhaltens

In App Service wird ein Container als erfolgreich gestartet betrachtet, wenn der Container gestartet wird und auf einen HTTP-Ping antwortet. Die Gesundheits-Ping-Anforderung enthält den Header User-Agent= "App Service Hyper-V Container Availability Check". Wenn der Container gestartet wird, aber nach einer bestimmten Zeitspanne nicht auf Pings reagiert, protokolliert App Service ein Ereignis im Docker-Protokoll.

Wenn Ihre Anwendung ressourcenintensiv ist, antwortet der Container möglicherweise nicht rechtzeitig auf den HTTP-Ping. Um die Aktionen zu kontrollieren, wenn HTTP-Pings fehlschlagen, legen Sie die App-Einstellung CONTAINER_AVAILABILITY_CHECK_MODE fest. Sie können es mithilfe der Cloud Shell festlegen. In Bash:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings CONTAINER_AVAILABILITY_CHECK_MODE="ReportOnly"

In PowerShell:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"CONTAINER_AVAILABILITY_CHECK_MODE"="ReportOnly"}

In der folgenden Tabelle sind die möglichen Werte aufgeführt:

Wert Beschreibungen
Reparatur Starten Sie den Container nach drei aufeinander folgenden Verfügbarkeitsprüfungen neu.
ReportOnly Der Standardwert. Den Container nicht neu starte, aber den Container nach drei aufeinanderfolgenden Verfügbarkeitsprüfungen in den Docker-Protokollen protokollieren.
Deaktiviert Keine Verfügbarkeitsprüfung durchführen.

Unterstützung für gruppenverwaltete Dienstkonten

Gruppenverwaltete Dienstkonten (Group Managed Service Accounts, gMSAs) werden zurzeit in Windows-Containern in App Service nicht unterstützt.

Aktivieren von SSH

Secure Shell (SSH) wird häufig verwendet, um administrative Befehle remote über ein Befehlszeilenterminal auszuführen. Führen Sie die folgenden Schritte aus, um das Ssh-Konsolenfeature des Azure-Portals mit benutzerdefinierten Containern zu aktivieren:

  1. Erstellen Sie eine Standarddatei vom Typ sshd_config mit den folgenden Beispielinhalten, und platzieren Sie sie im Stammverzeichnis des Anwendungsprojekts:

    Port 			2222
ListenAddress 		0.0.0.0
LoginGraceTime 		180
X11Forwarding 		yes
Ciphers aes128-cbc,3des-cbc,aes256-cbc,aes128-ctr,aes192-ctr,aes256-ctr
MACs hmac-sha1,hmac-sha1-96
StrictModes 		yes
SyslogFacility 		DAEMON
PasswordAuthentication 	yes
PermitEmptyPasswords 	no
PermitRootLogin 	yes
Subsystem sftp internal-sftp

    Hinweis

    Diese Datei konfiguriert OpenSSH und muss die folgenden Elemente enthalten, damit sie mit der SSH-Funktion des Azure-Portals kompatibel ist:

    • Port muss auf 2222 festgelegt werden.
    • Ciphers muss mindestens ein Element aus dieser Liste enthalten: aes128-cbc,3des-cbc,aes256-cbc.
    • MACs muss mindestens ein Element aus dieser Liste enthalten: hmac-sha1,hmac-sha1-96.

  2. Erstellen Sie ein Eintragspunktskript mit dem Namen entrypoint.sh oder ändern Sie eine vorhandene Eintragspunktdatei. Fügen Sie den Befehl hinzu, um den SSH-Dienst zusammen mit dem Anwendungsstartbefehl zu starten. Das folgende Beispiel veranschaulicht das Starten einer Python-Anwendung. Ersetzen Sie den letzten Befehl entsprechend der Projektsprache/des Projektstapels:

    #!/bin/sh
set -e
service ssh start
exec gunicorn -w 4 -b 0.0.0.0:8000 app:app

  3. Fügen Sie dem Dockerfile die folgenden Anweisungen gemäß der Basisimageverteilung hinzu. Mit diesen Anweisungen werden folgende Schritte ausgeführt: Kopieren der neuen Dateien, Installieren des OpenSSH-Servers, Festlegen der richtigen Berechtigungen und Konfigurieren des benutzerdefinierten Einstiegspunkts sowie Verfügbarmachen der Ports, die für die Anwendung bzw. den SSH-Server erforderlich sind:

    COPY entrypoint.sh ./

# Start and enable SSH
RUN apt-get update \
    && apt-get install -y --no-install-recommends dialog \
    && apt-get install -y --no-install-recommends openssh-server \
    && echo "root:Docker!" | chpasswd \
    && chmod u+x ./entrypoint.sh
COPY sshd_config /etc/ssh/

EXPOSE 8000 2222

ENTRYPOINT [ "./entrypoint.sh" ]

    Hinweis

    Das Stammkennwort muss genau Docker! sein, da es von App Service verwendet wird, damit Sie mit dem Container auf die SSH-Sitzung zugreifen können. Diese Konfiguration erlaubt keine externen Verbindungen zum Container. Port 2222 des Containers ist nur innerhalb des Brückennetzes eines privaten virtuellen Netzes zugänglich und für einen Angreifer aus dem Internet nicht erreichbar.

  4. Erstellen Sie das Docker-Image neu, und übertragen Sie es an die Registrierung, und testen Sie dann das Web App SSH-Feature im Azure-Portal.

Weitere Informationen zur Problembehandlung finden Sie im Azure App Service-Blog: Aktivieren von SSH unter Linux Web App für Container

Zugreifen auf Diagnoseprotokolle

Sie können auf die Konsolenprotokolle zugreifen, die aus dem Container generiert werden.

Führen Sie den folgenden Befehl aus, um die Containerprotokollierung zu aktivieren:

az webapp log config --name <app-name> --resource-group <resource-group-name> --docker-container-logging filesystem

Ersetzen von <app-name> und <resource-group-name> durch Namen, die für Ihre Web-App geeignet sind.

Nachdem Sie die Containerprotokollierung aktiviert haben, führen Sie den folgenden Befehl aus, um den Protokolldatenstrom anzuzeigen:

az webapp log tail --name <app-name> --resource-group <resource-group-name>

Wenn Konsolenprotokolle nicht sofort angezeigt werden, überprüfen Sie es in 30 Sekunden erneut.

Wenn Sie das Protokollstreaming jederzeit beenden möchten, wählen Sie STRG+C aus.

Konfigurieren von Apps mit mehreren Containern

Hinweis

Das Docker Compose-Feature wird am 31. März 2027 eingestellt. Sidecar-Container sind mit Mehrcontainer-Apps in App Service erfolgreich. Informationen zu neuen Diensten finden Sie unter Tutorial: Konfigurieren eines Sidecar-Containers für benutzerdefinierte Container in Azure App Service. Informationen zu vorhandenen Multicontainer-Apps in App Service finden Sie unter Migrieren Ihrer Docker Compose-Anwendungen zum Sidecar-Feature.

Verwenden von beständigem Speicher in Docker Compose

Apps mit mehreren Containern wie WordPress benötigen einen beständigen Speicher, um ordnungsgemäß zu funktionieren. Um dies zu ermöglichen, muss Ihre Docker Compose-Konfiguration auf einen Speicherort außerhalb Ihres Containers verweisen. Speicherorte in Ihrem Container bleiben nach dem Neustart der App nicht mehr unverändert.

Um beständigen Speicher zu aktivieren, legen Sie die WEBSITES_ENABLE_APP_SERVICE_STORAGE App-Einstellung fest. Verwenden Sie den Befehl "az webapp config appsettings set" in Cloud Shell.

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITES_ENABLE_APP_SERVICE_STORAGE=TRUE

Ordnen Sie in Ihrer Datei docker-compose.yml die volumes-Option zu ${WEBAPP_STORAGE_HOME} zu.

WEBAPP_STORAGE_HOME ist eine Umgebungsvariable in App Service, die dem beständigen Speicher für Ihre App zugeordnet wird. Beispiel:

wordpress:
  image: <image name:tag>
  volumes:
  - "${WEBAPP_STORAGE_HOME}/site/wwwroot:/var/www/html"
  - "${WEBAPP_STORAGE_HOME}/phpmyadmin:/var/www/phpmyadmin"
  - "${WEBAPP_STORAGE_HOME}/LogFiles:/var/log"

Einschränkungen der Vorschau

Apps mit mehreren Containern befinden sich derzeit in der Vorschauphase. Die folgenden Features der App Service-Plattform werden nicht unterstützt:

  • Authentifizierung/Autorisierung
  • Verwaltete Identitäten
  • CORS
  • Die Integration virtueller Netzwerke wird für Docker Compose-Szenarien nicht unterstützt.
  • Docker Compose unter Azure App Service verfügt derzeit über ein Limit von 4.000 Zeichen.

Optionen von Docker Compose

In den folgenden Listen werden unterstützte und nicht unterstützte Docker Compose-Konfigurationsoptionen angezeigt:

Unterstützte Optionen

Nicht unterstützte Optionen

  • build (unzulässig)
  • depends_on (ignoriert)
  • Netzwerke (ignoriert)
  • secrets (ignoriert)
  • andere Ports als 80 und 8080 (ignoriert)
  • Standardumgebungsvariablen wie $variable and ${variable}, anders als in Docker

Syntaxeinschränkungen

  • „version x.x“ muss immer die erste YAML-Anweisung in der Datei sein.
  • Der Abschnitt „Ports“ muss Zahlen in Anführungszeichen verwenden.
  • Der Abschnitt „image > volume“ muss in Anführungszeichen gesetzt werden und darf keine Berechtigungsdefinitionen enthalten.
  • Im Abschnitt „volumes“ darf nach dem Volumenamen keine leere geschweifte Klammer stehen

Hinweis

Alle weiteren Optionen, die nicht ausdrücklich aufgeführt sind, werden in der Public Preview ignoriert.

Ignorieren Sie die Bots933456-Nachricht in Protokollen

Möglicherweise wird die folgende Meldung in den Containerprotokollen angezeigt:

2019-04-08T14:07:56.641002476Z "-" - - [08/Apr/2019:14:07:56 +0000] "GET /robots933456.txt HTTP/1.1" 404 415 "-" "-"

Diese Meldung können Sie problemlos ignorieren. /robots933456.txt ist ein Dummy-URL-Pfad, den App Service verwendet, um zu überprüfen, ob der Container in der Lage ist, Anforderungen zu verarbeiten. Eine 404-Antwort gibt an, dass der Pfad nicht vorhanden ist, und signalisiert dem App-Dienst, dass der Container fehlerfrei ist und bereit ist, auf Anforderungen zu reagieren.

Verwandte Inhalte

Tutorial: Migrieren benutzerdefinierter Software zu Azure App Service mithilfe eines benutzerdefinierten Containers

Tutorial: Konfigurieren eines Sidecar-Containers für benutzerdefinierte Container in Azure App Service

Oder sehen Sie sich weitere Ressourcen an: