Teilen ü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.

Hier erhalten Sie Informationen zu wichtigen Konzepten und Anleitungen für die Containerisierung von Windows-Apps im App-Dienst. Neue Benutzer sollten zuerst dem Schnellstart des benutzerdefinierten Containers und dem Lernprogramm folgen.

Hier erhalten Sie Informationen zu wichtigen Konzepten und Anleitungen für die Containerisierung von Linux-Apps in App Service. Neue Benutzer sollten zuerst dem Schnellstart und dem Lernprogramm des benutzerdefinierten Containers folgen. Informationen zu Sidecar-Containern finden Sie im Tutorial: Konfigurieren eines Sidecar-Containers für benutzerdefinierte Container in Azure App Service.

Hinweis

Die Verwendung eines Serviceprincipals für die Pullauthentifizierung für Windows-Containerimages wird nicht mehr unterstützt. Es wird empfohlen, verwaltete Identitäten sowohl für Windows- als auch für Linux-Container zu verwenden.

Unterstützte übergeordnete Images

Wählen Sie das richtige übergeordnete Image (Basisimage) für das framework aus, das Sie für Ihr benutzerdefiniertes Windows-Image verwenden möchten:

  • Verwenden Sie zum Bereitstellen von .NET Framework-Apps ein übergeordnetes Image, das auf der Windows Server 2019 Core Long-Term Servicing Channel-Version basiert.
  • Verwenden Sie zum Bereitstellen von .NET Core-Apps ein Basisimage, das auf der Windows Server 2019 Nano Annual Channel-Version 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

Verwenden Sie den folgenden Befehl, um das aktuelle Docker-Image in ein neues Image in einem vorhandenen benutzerdefinierten Container zu ändern:

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 die Anmeldeinformationen für Ihr privates Registrierungskonto in den \<username> Feldern und \<password> Feldern an.

Verwenden der verwalteten Identität zum Abrufen eines Images aus der Azure-Containerregistrierung

Führen Sie die folgenden Schritte aus, um Ihre Web-App so zu konfigurieren, dass sie mithilfe der verwalteten Identität aus der Azure-Containerregistrierung abgerufen wird. Bei den Schritten wird die vom System zugewiesene verwaltete Identität verwendet, Sie können jedoch auch 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. Rufen Sie die Ressourcen-ID Ihrer Containerregistrierung ab:

    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 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 in 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>"}'

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

Verwenden eines Bilds 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 einem privaten Endpunkt. Nachdem Sie Ihr Netzwerk und die DNS-Auflösung konfiguriert haben, aktivieren Sie das Routing des Image-Pull über das virtuelle Netzwerk. Konfigurieren Sie die vnetImagePullEnabled Website-Einstellung.

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

Problembehandlung, was zu tun ist, wenn der aktualisierte Container nicht angezeigt wird

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 vom alten Container. Der App-Dienst sendet nur Anforderungen an den neuen Container, nachdem er gestartet wurde, und ist bereit, Anforderungen zu empfangen.

Erfahren Sie, wie Containerimages gespeichert werden

Wenn Sie zum ersten Mal ein benutzerdefiniertes Docker-Image in App Service ausführen, führt App Service den docker pull Befehl aus und ruft alle Imageebenen ab. Die Ebenen werden auf dem Datenträger gespeichert, identisch mit der Verwendung von Docker lokal. Jedes Mal, wenn die App neu gestartet wird, führt Der App-Dienst den docker pull Befehl 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 aus irgendeinem Grund Recheneinheiten ändert (z. B. wenn sich Preisstufen ändern), muss der App-Dienst alle Schichten erneut abrufen. Das gleiche gilt, wenn Sie eine Skalierung ausführen, um weitere Instanzen hinzuzufügen. In seltenen Fällen können sich die App-Instanzen auch ohne Skalierungsvorgang ändern.

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 sie mithilfe von Azure Cloud Shell festlegen. Verwenden Sie in Bash den folgenden Befehl:

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

Verwenden Sie in PowerShell den folgenden Befehl:

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 Sie extern bereitstellen müssen. Sie können sie mithilfe von Cloud Shell übergeben. Verwenden Sie in Bash den folgenden Befehl:

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

Verwenden Sie in PowerShell den folgenden Befehl:

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

Wenn Ihre App ausgeführt wird, werden die App Service-App-Einstellungen 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 Sie per SSH auf einen Container für benutzerdefinierte Docker-Images zugreifen, könnten Ihnen nur wenige Umgebungsvariablen angezeigt werden, wenn Sie versuchen, Befehle wie env oder printenv zu verwenden. Wenn Sie alle Umgebungsvariablen im Container anzeigen möchten, z. B. solche, die Sie zur Laufzeitverwendung an Ihre Anwendung übergeben, fügen Sie diese Zeile zu Ihrem Einstiegspunktskript hinzu:

eval $(printenv | sed -n "s/^\([^=]\+\)=\(.*\)$/export \1=\2/p" | sed 's/"/\\\"/g' | sed '/=/s//="/' | sed 's/$/"/' >> /etc/profile)

Sehen Sie sich ein vollständiges Beispiel an.

Wenn Ihre App Bilder aus einer privaten Registrierung oder von Docker Hub verwendet, werden die 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 Internetinformationsdienste (IIS) oder .NET Framework-Container (4.0 oder höher) werden die Anmeldeinformationen von App Service automatisch als .NET-App-Einstellungen und Verbindungszeichenfolgen in System.ConfigurationManager 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_

Sie können diese Methode sowohl für Einzelcontainer- als auch für Multicontainer-Apps verwenden, bei denen die Umgebungsvariablen in der docker-compose.yml Datei angegeben sind.

Verwenden von beständig freigegebenem Speicher

Sie können das C:\home Verzeichnis in Ihrem benutzerdefinierten Containerdateisystem verwenden, um Dateien über Neustarts hinweg beizubehalten und sie über Instanzen hinweg freizugeben. Wenn Sie das C:\home Verzeichnis verwenden, kann Ihr benutzerdefinierter Container auf beständigen Speicher zugreifen.

Wenn der permanente Speicher deaktiviert ist, werden Schreibvorgänge in das C:\home Verzeichnis nicht über App-Neustarts oder mehrere Instanzen hinweg beibehalten. Wenn der permanente Speicher aktiviert ist, werden alle Schreibvorgänge in das C:\home Verzeichnis beibehalten. Alle Instanzen einer skalierten App haben Zugriff darauf. Wenn der Container gestartet wird, werden alle Inhalte im C:\home Verzeichnis des Containers überschrieben, wenn dateien im beständigen Speicher vorhanden sind.

Die einzige Ausnahme ist das C:\home\LogFiles Verzeichnis. In diesem Verzeichnis werden container- und Anwendungsprotokolle gespeichert. Der 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: Wenn Sie beständigen Speicher aktivieren oder deaktivieren, wirkt sich dies nicht auf das Verhalten der Anwendungsprotokollierung aus.

Standardmäßig ist der persistente Speicher bei benutzerdefinierten Windows-Containern aktiviert. Legen Sie hierzu den Wert der App-Einstellung WEBSITES_ENABLE_APP_SERVICE_STORAGE über die Cloud Shell auf false fest. Verwenden Sie in Bash den folgenden Befehl:

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

Verwenden Sie in PowerShell den folgenden Befehl:

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

Sie können das /home Verzeichnis in Ihrem benutzerdefinierten Containerdateisystem verwenden, um Dateien über Neustarts hinweg beizubehalten und sie über Instanzen hinweg freizugeben. Wenn Sie das C:\home Verzeichnis verwenden, kann Ihr benutzerdefinierter Container auf beständigen Speicher zugreifen. Beachten Sie, dass Daten, die Sie innerhalb von /home speichern, zu dem Speicherplatzkontingent beitragen, das in Ihrem App Service-Plan enthalten ist.

Wenn der permanente Speicher deaktiviert ist, werden Schreibvorgänge in das C:\home Verzeichnis nicht über App-Neustarts oder mehrere Instanzen hinweg beibehalten. Wenn der permanente Speicher aktiviert ist, werden alle Schreibvorgänge in das C:\home Verzeichnis beibehalten. Alle Instanzen einer skalierten App haben Zugriff darauf. Wenn der Container gestartet wird, werden alle Inhalte im C:\home Verzeichnis des Containers überschrieben, wenn dateien im beständigen Speicher vorhanden sind.

Die einzige Ausnahme ist das C:\home\LogFiles Verzeichnis. In diesem Verzeichnis werden container- und Anwendungsprotokolle gespeichert. Der 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: Wenn Sie beständigen Speicher aktivieren oder deaktivieren, wirkt sich dies nicht auf das Verhalten der Anwendungsprotokollierung aus.

Es wird empfohlen, Daten in /home oder auf einem bereitgestellten Azure-Speicherpfad zu schreiben. Daten, die Sie außerhalb dieser Pfade schreiben, sind während neustarts nicht persistent. Die Daten werden auf plattformverwaltetem 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 auf true fest, indem Sie Cloud Shell verwenden. Verwenden Sie in Bash den folgenden Befehl:

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

Verwenden Sie in PowerShell den folgenden Befehl:

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 Schlüssel automatisch generiert und als Computerschlüssel für ASP.NET kryptografische Routinen in den Container eingefügt. Sie finden diese Schlüssel in Ihrem Container , indem Sie nach den folgenden Umgebungsvariablen suchen: MACHINEKEY_Decryption, , MACHINEKEY_DecryptionKey, MACHINEKEY_ValidationKeyund 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 eine direkte Verbindung zu Ihrem Windows-Container für Diagnoseaufgaben herzustellen, gehen Sie zu https://<app-name>.scm.azurewebsites.net/ und wählen Sie die Option "SSH" 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 App stellt die SSH-Sitzung eine Verbindung mit einer der Containerinstanzen bereit. Sie können eine andere Instanz aus der Dropdownliste " Instanz " im oberen Kudu-Menü auswählen.
  • Änderungen, die Sie am Container innerhalb der SSH-Sitzung vornehmen, werden nicht beibehalten, wenn Ihre App neu startet, mit Ausnahme von Änderungen am freigegebenen Speicher. Diese Änderungen sind nicht Teil des Docker-Images. Um Änderungen wie Registereinstellungen und Softwareinstallationen beizubehalten, machen Sie sie zu einem Teil der Dockerfile.

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.

Sie können auf verschiedene Arten auf Docker-Protokolle zugreifen:

Azure-Portal

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

Kudu

Um die einzelnen Protokolldateien anzuzeigen, wechseln Sie zu https://<app-name>.scm.azurewebsites.net/DebugConsole dem Ordner, und wählen Sie den LogFiles Ordner 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.

Standardmäßig können Sie nicht auf den C:\home\LogFiles Ordner im SSH-Terminal zugreifen, da beständiger freigegebener Speicher nicht aktiviert ist. Um dieses Verhalten im Konsolenterminal zu aktivieren, aktivieren Sie den persistenten freigegebenen Speicher.

Wenn Sie versuchen, das Docker-Protokoll herunterzuladen, das derzeit mit einem FTP-Client verwendet wird, wird aufgrund einer Dateisperre möglicherweise ein Fehler angezeigt.

Kudu-API

Gehen Sie direkt zu https://<app-name>.scm.azurewebsites.net/api/logs/docker, um die Metadaten der Docker-Logs zu sehen. Möglicherweise werden mehrere Protokolldateien aufgelistet. Sie können die href Eigenschaft verwenden, um die Protokolldatei direkt herunterzuladen.

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 SKU des App Service-Plans aufgeführt.

SKU des App-Dienstplans Standardspeichergrenzwert 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 in Cloud Shell angeben. Verwenden Sie in Bash den folgenden Befehl:

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

Verwenden Sie in PowerShell den folgenden Befehl:

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

Der Wert wird in Megabyte (MB) definiert und muss kleiner und gleich dem gesamten physischen Speicher des Hosts sein. Beispielsweise kann in einem App Service-Plan mit 8 GB RAM die kumulierte Gesamtsumme WEBSITE_MEMORY_LIMIT_MB aller Apps 8 GB nicht überschreiten. Weitere Informationen dazu, wie viel Arbeitsspeicher verfügbar ist, finden Sie im Premium v3-Serviceplan in den App Service-Preisen.

Anpassen der Anzahl der Compute-Kerne

Standardmäßig wird ein Windows-Container mit allen verfügbaren Kernen für Ihr Preisniveau 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 WEBSITE_CPU_CORES_LIMIT App-Einstellung auf die bevorzugte Anzahl von Kernen fest. Sie können es mithilfe von Cloud Shell festlegen. Verwenden Sie in Bash den folgenden Befehl:

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

Verwenden Sie in PowerShell den folgenden Befehl:

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. Ziehen Sie für eine Produktions-App in Betracht, sie in einen Staging-Slot zu tauschen. Ändern Sie die App-Einstellung im Staging-Slot, und wechseln Sie sie dann zurück in die Produktion.

Um Ihre angepasste Nummer zu überprüfen, öffnen Sie eine SSH-Sitzung über das Azure-Portal oder 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 Hyperthreadingprozessoren sein. Informationen dazu, wie viele Kerne verfügbar sind, finden Sie im Premium v3-Serviceplan in den App Service-Preisen.

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, reagiert der Container möglicherweise nicht rechtzeitig auf das HTTP-Ping. Um zu steuern, was passiert, wenn HTTP-Pings fehlschlagen, legen Sie die CONTAINER_AVAILABILITY_CHECK_MODE App-Einstellung fest. Sie können es mithilfe von Cloud Shell festlegen. Verwenden Sie in Bash den folgenden Befehl:

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

Verwenden Sie in PowerShell den folgenden Befehl:

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 Description
Repair Starten Sie den Container nach drei aufeinander folgenden Verfügbarkeitsprüfungen neu.
ReportOnly Der Standardwert. Melden Sie den Container in den Docker-Protokollen nach drei aufeinander folgenden Verfügbarkeitsprüfungen, starten Sie ihn jedoch nicht neu.
Off Keine Verfügbarkeitsprüfung durchführen.

Unterstützung für gruppenverwaltete Dienstkonten

Gruppenverwaltete Dienstkonten werden in Windows-Containern in App Service nicht unterstützt.

Aktivieren von SSH

Sie können Secure Shell (SSH) verwenden, 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, um das Ssh-Feature des Azure-Portals einzuhalten:

    • Der Port Wert muss auf 2222.
    • Die Ciphers Werte müssen mindestens ein Element in dieser Liste enthalten: aes128-cbc, , 3des-cbc, oder aes256-cbc.
    • Die MACs Werte müssen mindestens ein Element in dieser Liste enthalten: hmac-sha1 oder 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 gemäß der Projektsprache oder dem Projektstapel:

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

  3. Fügen Sie der Dockerfile-Datei gemäß der Basisimageverteilung die folgenden Anweisungen hinzu. Diese Anweisungen kopieren die neuen Dateien, installieren den OpenSSH-Server, legen die richtigen Berechtigungen fest und konfigurieren den benutzerdefinierten Einstiegspunkt und machen die ports verfügbar, die von der Anwendung bzw. dem SSH-Server benötigt werden:

    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 der App-Dienst es verwendet, um Ihnen Zugriff auf die SSH-Sitzung mit dem Container zu gewähren. Diese Konfiguration erlaubt keine externen Verbindungen zum Container. Auf den Port 2222 des Containers kann nur innerhalb des Brückennetzwerks eines privaten virtuellen Netzwerks zugegriffen werden. Ein Angreifer im Internet kann nicht darauf zugreifen.

  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 auf einer 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 Sie den <app-name>-Wert und den <resource-group-name>-Wert 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, verwenden Sie die Tastenkombination STRG+C.

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 im Tutorial: Konfigurieren eines Sidecar-Containers für einen benutzerdefinierten 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 beständigen Speicher zu aktivieren, 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 az webapp config appsettings set Befehl 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 docker-compose.yml Datei die volumes Option zu ${WEBAPP_STORAGE_HOME}.

WEBAPP_STORAGE_HOME ist eine Umgebungsvariable im App-Dienst, die dem beständigen Speicher für Ihre App zugeordnet ist. 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 oder Autorisierung.
  • Verwaltete Identitäten.
  • Ursprungsübergreifende Ressourcenfreigabe (CORS).
  • Integration des virtuellen Netzwerks in Docker Compose-Szenarien.

Docker Compose für Azure App Service hat derzeit einen Grenzwert von 4.000 Zeichen.

Optionen von Docker Compose

In den folgenden Abschnitten werden unterstützte und nicht unterstützte Docker Compose-Konfigurationsoptionen angezeigt.

Unterstützte Optionen

Nicht unterstützte Optionen

  • build (nicht zulässig)
  • depends_on (ignoriert)
  • networks (ignoriert)
  • secrets (ignoriert)
  • Andere Ports als 80 und 8080 (ignoriert)
  • Standardumgebungsvariablen wie $variable und ${variable} (im Gegensatz zu Docker)

Syntaxbeschränkungen

  • Die erste YAML-Anweisung in der Datei muss immer sein version x.x.
  • Der Abschnitt "Ports" muss zitierte Zahlen verwenden.
  • Der image > volume Abschnitt muss zitiert werden und darf keine Definitionen von Berechtigungen enthalten.
  • Der Abschnitt "Volumen" darf nach dem Volumennamen keine leere geschweifte Klammer enthalten.

Hinweis

Alle anderen nicht explizit erwähnten Optionen werden in der Vorschau 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. Der App-Dienst verwendet ihn, um zu überprüfen, ob der Container Anforderungen verarbeiten kann. Eine "404"-Fehlerantwort 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

  • Last updated on