Teilen über

Konfigurieren eines benutzerdefinierten Containers für Azure App Service

  • Artikel

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 den Schnellstart zu benutzerdefinierten Containern und das Tutorial befolgen.

Dieser Leitfaden enthält die wichtigsten Konzepte und Anweisungen für die Containerstellung von Linux-Apps in App Service. Wenn Sie Azure App Service noch nie verwendet haben, befolgen Sie zunächst den Schnellstart zu benutzerdefinierten Containern und das Tutorial. Informationen zu Sidecar-Containern (Vorschau) finden Sie im Tutorial: Konfigurieren eines Sidecar-Containers für benutzerdefinierte Container in Azure App Service (Vorschau).

Hinweis

Der Dienstprinzipal wird für die Pullauthentifizierung von Windows-Containerimages nicht mehr unterstützt. Das empfohlene Verfahren besteht darin, eine verwaltete Identität für Windows- und Linux-Container zu verwenden.

Unterstützte übergeordnete Images

Für Ihr benutzerdefiniertes Windows-Image müssen Sie das passende übergeordnete Image (Basisimage) für das gewünschte Framework auswählen:

  • 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 Semi-Annual Servicing Channel (SAC) von Windows Server 2019 Nano basiert.

Während des App-Starts dauert das Herunterladen eines übergeordneten Images eine Weile. Sie können die Startzeit jedoch reduzieren, indem Sie eins der folgenden übergeordneten Images 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. In diesen Schritten wird eine systemseitig zugewiesene verwaltete Identität verwendet, aber Sie können auch eine benutzerseitig zugewiesene verwaltete Identität verwenden.

  1. Aktivieren Sie die systemseitig zugewiesene verwaltete Identität für die Web-App mithilfe des Befehls az webapp identity assign:

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

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

  2. Abrufen der Ressourcen-ID von Azure Container Registry:

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

    Ersetzen Sie <registry-name> durch den Namen Ihrer Registrierung. Die Ausgabe des Befehls (gefiltert nach den Argumenten --query und --output) ist die Ressourcen-ID von Azure Container Registry.

  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> durch die Dienstprinzipal-ID aus dem Befehl az webapp identity assign
    • <registry-resource-id> durch die ID Ihrer Containerregistrierung aus dem 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> durch den 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 escapen. 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> 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>"}'

Jetzt ist alles festgelegt, und die Web-App verwendet jetzt die verwaltete Identität, um aus Azure Container Registry zu pullen.

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 (VNET) integriert werden. VNET Integration ist auch für Azure Container Registry mit privatem Endpunkt erforderlich. Wenn Ihre Netzwerk- und DNS-Lösung konfiguriert sind, aktivieren Sie das Routing des Imagepulls über das virtuelle Netzwerk, indem Sie die Standorteinstellung vnetImagePullEnabled 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.

Speichern von Containerimages

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. Bei jedem Neustart der App führt App Service ein docker pull aus, ruft aber nur Schichten ab, die sich geändert haben. 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 zentrales 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

App Service geht standardmäßig davon aus, dass der benutzerdefinierte Container an 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 über die Cloud Shell festlegen. In Bash:

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

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 über die 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"

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 Images aus einer privaten Registrierung oder von Docker Hub verwendet, werden die Anmeldeinformationen für den Zugriff auf das Repository in den Umgebungsvariablen DOCKER_REGISTRY_SERVER_URL, DOCKER_REGISTRY_SERVER_USERNAME und DOCKER_REGISTRY_SERVER_PASSWORD gespeichert. Aufgrund von Sicherheitsrisiken wird keiner dieser reservierten Variablennamen in der Anwendung verfügbar gemacht.

Für Container, die auf IIS oder .NET Framework (4.0 oder höher) basieren, werden sie 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 bereitgestellt, wobei eines der folgenden entsprechenden Präfixe verwendet wird:

  • 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 den beständigen Speicher zugreifen kann.

Wenn der beständige Speicher deaktiviert ist, bleiben Schreibvorgänge in das Verzeichnis C:\home nicht über App-Neustarts oder mehrere Instanzen hinweg erhalten. Wenn der beständige Speicher aktiviert ist, bleiben alle Schreibvorgänge in das Verzeichnis C:\home erhalten und können von allen Instanzen einer horizontal skalierten App aufgerufen werden. Darüber hinaus werden alle Inhalte im Verzeichnis C:\home des Containers durch alle vorhandenen Dateien überschrieben, die beim Starten des Containers bereits im beständigen Speicher vorhanden sind.

Die einzige Ausnahme ist das Verzeichnis C:\home\LogFiles, das zum Speichern der Container- und Anwendungsprotokolle verwendet wird. Dieser Ordner bleibt bei Neustarts der App immer bestehen, wenn die Anwendungsprotokollierung mit der Option Dateisystem aktiviert ist, unabhängig davon, ob der beständige Speicher aktiviert oder deaktiviert 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. Legen Sie hierzu den Wert der App-Einstellung WEBSITES_ENABLE_APP_SERVICE_STORAGE über die Cloud Shell auf false fest. In Bash:

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

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 den 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 beständige Speicher deaktiviert ist, bleiben Schreibvorgänge in das Verzeichnis /home nicht über App-Neustarts oder mehrere Instanzen hinweg erhalten. Wenn der beständige Speicher aktiviert ist, bleiben alle Schreibvorgänge in das Verzeichnis /home erhalten und können von allen Instanzen einer horizontal skalierten App aufgerufen werden. Darüber hinaus werden alle Inhalte im Verzeichnis /home des Containers durch alle vorhandenen Dateien überschrieben, die beim Starten des Containers bereits im beständigen Speicher vorhanden sind.

Die einzige Ausnahme ist das Verzeichnis /home/LogFiles, das zum Speichern der Container- und Anwendungsprotokolle verwendet wird. Dieser Ordner bleibt bei Neustarts der App immer bestehen, wenn die Anwendungsprotokollierung mit der Option Dateisystem aktiviert ist, unabhängig davon, ob der beständige Speicher aktiviert oder deaktiviert 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 in einen eingebundenen Azure-Speicherpfad zu schreiben. Daten, die außerhalb dieser Pfade geschrieben werden, bleiben während Neustarts nicht erhalten und werden vom Dateispeicherkontingent des App Service-Plans getrennt auf plattformverwaltetem Host-Datenträgerspeicherplatz gespeichert.

Standardmäßig ist der persistente Speicher bei benutzerdefinierten Linux-Containern deaktiviert. Um ihn zu aktivieren, legen Sie den Wert der App-Einstellung WEBSITES_ENABLE_APP_SERVICE_STORAGE über die trueCloud Shell auf fest. In Bash:

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

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/SSL auf den Front-Ends. Dies bedeutet, dass TLS/SSL-Anforderungen nie bis zu Ihrer App gelangen. Sie müssen und sollten keine Unterstützung für TLS/SSL in Ihrer App implementieren.

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

Anpassen des Einfügens des ASP.NET-Computerschlüssels

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

Sie können sich für Diagnoseaufgaben direkt mit Ihrem Windows-Container verbinden, indem Sie zu https://<app-name>.scm.azurewebsites.net/ navigieren und die SSH-Option auswählen. Eine direkte SSH-Sitzung mit Ihrem Container wird 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 Dropdown-Liste Instanz im oberen Kudu-Menü auswählen.
  • Jede Änderung, die Sie an dem Container innerhalb der SSH vornehmen, bleibt nicht erhalten, wenn Ihre App neu gestartet wird (mit Ausnahme von Änderungen im freigegebenen Speicher), weil sie nicht Teil des Docker-Images ist. 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) werden standardmäßig ausgeliefert, aber Anwendungsprotokolle oder Webserverprotokolle aus dem Container müssen manuell aktiviert werden. Weitere Informationen finden Sie unter Aktivieren der Diagnoseprotokollierung und Aktivieren der Webserverprotokollierung.

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

Im Azure-Portal

Docker-Protokolle werden im Portal auf der Seite Containereinstellungen Ihrer App angezeigt. Die Protokolle werden abgeschnitten, aber Sie können alle Protokolle herunterladen, indem Sie Herunterladen wählen.

Von Kudu

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

Im SSH-Terminal können Sie nicht standardmäßig auf den Ordner C:\home\LogFiles zugreifen, da der persistente 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. Es kann sein, dass mehr als eine Protokolldatei aufgelistet wird und über die href-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.

Anpassen des Containerarbeitsspeichers

Standardmäßig ist für alle Windows-Container, die in Azure App Service bereitgestellt werden, ein Arbeitsspeicherlimit 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 App-Einstellung WEBSITE_MEMORY_LIMIT_MB über die Cloud Shell bereitstellen. In Bash:

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

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. Beispielsweise darf in einem App Service-Plan mit 8 GB RAM der kumulative Gesamtwert von WEBSITE_MEMORY_LIMIT_MB für alle Apps 8 GB nicht überschreiten. Informationen dazu, wie viel Arbeitsspeicher für jeden Tarif verfügbar ist, finden Sie in der App Service-Preisübersicht im Abschnitt Premium V3-Serviceplan.

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. Sie könnten zum Beispiel die Anzahl der Kerne, die Ihr Staging Slot verwendet, reduzieren wollen. 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 sie über die 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

PowerShell:

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

Hinweis

Durch 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.

Überprüfen Sie Ihre angepasste Nummer, indem Sie eine SSH-Sitzung über das Portal oder über das Kudu-Portal (https://<app-name>.scm.azurewebsites.net/webssh/host) öffnen und die folgenden Befehle mithilfe von PowerShell eingeben. Jeder Befehl gibt eine Zahl aus.

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 für jeden Tarif verfügbar ist, finden Sie in der App Service-Preisübersicht im Abschnitt Premium V3-Serviceplan.

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 Integritäts-Ping-Anforderung enthält den Header User-Agent= "App Service Hyper-V Container Availability Check". Wenn der Container gestartet wird, aber nach einem bestimmten Zeitraum nicht auf einen Ping antwortet, protokolliert App Service ein Ereignis im Docker-Protokoll, das besagt, dass der Container nicht gestartet wurde.

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 sie über die Cloud Shell festlegen. In Bash:

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

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
Repair Neustarten des Containers nach drei aufeinanderfolgenden Verfügbarkeitsprüfungen
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 für die Remoteausführung von Verwaltungsbefehlen über ein Befehlszeilenterminal verwendet. Um die Funktion für die SSH-Konsole im Azure-Portal mit benutzerdefinierten Containern zu aktivieren, sind die folgenden Schritte erforderlich:

  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 Einstiegspunktskript mit dem Namen entrypoint.sh (oder ändern Sie eine vorhandene Einstiegspunktdatei), und fügen Sie den Befehl zum Starten des SSH-Diensts zusammen mit dem Befehl zum Starten der Anwendung hinzu. 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 Root-Passwort muss exakt Docker! lauten, da es vom App Service verwendet wird, um Ihnen den Zugriff auf die SSH-Sitzung mit dem Container zu ermöglichen. 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, pushen Sie es an die Registrierung, und testen Sie dann die Web-App-SSH-Funktion im Azure-Portal.

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

Zugreifen auf Diagnoseprotokolle

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

Aktivieren Sie zuerst Containerprotokollierung, indem Sie den folgenden Befehl ausführen:

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

Ersetzen Sie <app-name> und <resource-group-name> durch die entsprechenden Namen für Ihre Web-App.

Führen Sie den folgenden Befehl aus, um den Protokolldatenstrom anzuzeigen, nachdem die Containerprotokollierung aktiviert wurde:

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

Falls Sie nicht sofort Konsolenprotokolle sehen, können Sie es nach 30 Sekunden noch einmal versuchen.

Zum Beenden des Protokollstreamings können Sie jederzeit STRG+C drücken.

Sie können die Protokolldateien auch in einem Browser unter https://<app-name>.scm.azurewebsites.net/api/logs/docker untersuchen.

Konfigurieren von Apps mit mehreren Containern

Hinweis

Sidecar-Container (Vorschau) sind mit Mehrcontainer-Apps in App Service erfolgreich. Informationen zu den ersten Schritten finden Sie unter Tutorial: Konfigurieren eines Sidecar-Containers für benutzerdefinierte Container in Azure App Service (Vorschau).

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.

Aktivieren Sie den beständigen Speicher, indem Sie die App-Einstellung WEBSITES_ENABLE_APP_SERVICE_STORAGE mit dem Befehl az webapp config appsettings set in der Cloud Shell festlegen.

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 des virtuellen Netzwerks 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)
  • networks (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.

„robots933456“ 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 zeigt lediglich an, dass der Pfad nicht vorhanden ist, informiert App Service aber darüber, dass der Container fehlerfrei und bereit ist, um auf Anforderungen zu antworten.

Nächste Schritte

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 (Preview)

Oder sehen Sie sich weitere Ressourcen an: