Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Integritätssonden von Azure Container Apps ermöglichen es der Container-Apps-Runtime, regelmäßig den Status Ihrer Container-Apps zu prüfen.
Sie können Tests ausschließlich über TCP oder HTTP(S) einrichten.
Container-Apps unterstützen die folgenden Prüfpunkte:
| Test | Beschreibung |
|---|---|
| Start | Überprüft, ob Ihre Anwendung erfolgreich gestartet wurde. Diese Überprüfung unterscheidet sich von dem Livetest und wird während der ersten Startphase Ihrer Anwendung ausgeführt. |
| Livezustand | Überprüft, ob Ihre Anwendung noch ausgeführt wird und reaktionsfähig ist. |
| Bereitschaft | Überprüft, ob ein Replikat für die Verarbeitung eingehender Anforderungen bereit ist. |
Eine vollständige Liste der in Azure Container Apps unterstützten Integritätstestspezifikationen finden Sie unter Azure-REST-API-Spezifikationen.
HTTP-Abfragen
Mit HTTP-Tests können Sie benutzerdefinierte Logik implementieren, um den Status von Anwendungsabhängigkeiten zu überprüfen, bevor Sie einen fehlerfreien Status melden.
Konfigurieren Sie Ihre Integritätstest-Endpunkte so, dass sie mit einem HTTP-Statuscode antworten, der größer oder gleich 200 und kleiner als 400 ist, um einen Erfolg zu signalisieren. Jeder andere Antwortcode außerhalb dieses Bereichs weist auf einen Fehler hin.
Im folgenden Beispiel wird veranschaulicht, wie ein Liveness-Endpunkt in JavaScript implementiert wird.
const express = require('express');
const app = express();
app.get('/liveness', (req, res) => {
let isSystemStable = false;
// check for database availability
// check filesystem structure
// etc.
// set isSystemStable to true if all checks pass
if (isSystemStable) {
res.status(200); // Success
} else {
res.status(503); // Service unavailable
}
})
TCP-Sondierungen
TCP-Sonden warten darauf, eine Verbindung mit dem Server herzustellen, um den Erfolg anzuzeigen. Der Prüfpunkt schlägt fehl, wenn keine Verbindung mit Ihrer Anwendung hergestellt werden kann.
Beschränkungen
- Sie können pro Container nur einen Testtyp hinzufügen.
exec-Tests werden nicht unterstützt.- Portwerte müssen ganze Zahlen sein, benannte Ports werden nicht unterstützt.
- gRPC wird nicht unterstützt.
Beispiele
Die folgende Codeauflistung zeigt, wie Sie Health-Probes für Ihre Container definieren können.
Die Platzhalter ... geben ausgelassenen Code an. Ausführliche Informationen zu ARM-Vorlagen finden Sie unter den API-Spezifikation der ARM-Vorlage für Container Apps.
{
...
"containers":[
{
"image":"nginx",
"name":"web",
"probes": [
{
"type": "Liveness",
"httpGet": {
"path": "/health",
"port": 8080,
"httpHeaders": [
{
"name": "Custom-Header",
"value": "liveness probe"
}]
},
"initialDelaySeconds": 7,
"periodSeconds": 3
},
{
"type": "Readiness",
"tcpSocket": {
"port": 8081
},
"initialDelaySeconds": 10,
"periodSeconds": 3
},
{
"type": "Startup",
"httpGet": {
"path": "/startup",
"port": 8080,
"httpHeaders": [
{
"name": "Custom-Header",
"value": "startup probe"
}]
},
"initialDelaySeconds": 3,
"periodSeconds": 3
}]
}]
...
}
Die optionale failureThreshold-Einstellung definiert die Anzahl der Versuche, die Container Apps unternehmen, um die Prüfung durchzuführen, falls die Ausführung fehlschlägt. Über failureThreshold hinausgehende Versuche führen zu unterschiedlichen Ergebnissen für jeden Testtyp.
Standardkonfiguration
Wenn Ingress aktiviert ist, werden die folgenden Standardsonden automatisch zum Haupt-App-Container hinzugefügt, falls für jeden Typ keine definiert sind, außer bei GPU-Workload-Profilen (sowohl dediziert als auch verbrauchsabhängig).
| Testtyp | Standardwerte |
|---|---|
| Start | Protokoll: TCP Port: Eingangszielport Timeout: 3 Sekunden Zeitraum: 1 Sekunde Anfängliche Verzögerung: 1 Sekunde Erfolgsschwellenwert: 1 Fehlerschwellenwert: 240 |
| Lebendigkeit | Protokoll: TCP Port: Eingangszielport |
| Bereitschaft | Protokoll: TCP Port: Eingangszielport Timeout: 5 Sekunden Zeitraum: 5 Sekunden Anfängliche Verzögerung: 3 Sekunden Erfolgsschwellenwert: 1 Fehlerschwellenwert: 48 |
Wenn Sie Ihre Container-App im Mehrfachrevisionsmodus ausführen, warten Sie nach der Bereitstellung einer Revision, bis Ihre Bereitschaftstests einen Erfolg anzeigen, bevor Sie den Datenverkehr auf diese Revision übertragen. Im Einzelrevisionsmodus wird der Datenverkehr automatisch übertragen, wenn der Bereitschaftstest einen erfolgreichen Zustand zurückgibt.
Der Status einer Revision ist fehlerhaft, wenn bei der Überprüfung beim Bereitschaftstest eines ihrer Replikate fehlerhaft ist, selbst wenn alle anderen Replikate der Revision fehlerfrei sind. Container Apps startet das betreffende Replikat neu, bis es wieder fehlerfrei ist oder der Fehlerschwellenwert überschritten wird. Wenn der Fehlerschwellenwert überschritten wird, versuchen Sie, die Revision neu zu starten. Dies kann jedoch darauf hindeuten, dass die Revision nicht ordnungsgemäß konfiguriert ist.
Wenn Ihre App eine längere Zeit benötigt, um zu starten, was bei Java-Anwendungen häufig vorkommt, müssen Sie oft die Überprüfungen anpassen, damit der Container nicht abstürzt.
Im folgenden Beispiel wird veranschaulicht, wie die Liveness- und Readiness-Probes konfiguriert werden, um die Startzeit zu verlängern.
"probes": [
{
"type": "Liveness",
"failureThreshold": 3,
"periodSeconds": 10,
"successThreshold": 1,
"tcpSocket": {
"port": 80
},
"timeoutSeconds": 1
},
{
"type": "Readiness",
"failureThreshold": 48,
"initialDelaySeconds": 3,
"periodSeconds": 5,
"successThreshold": 1,
"tcpSocket": {
"port": 80
},
"timeoutSeconds": 5
}]