Integritätstests in Azure Container Apps

Integritätsprüfungen von Azure Container Apps ermöglichen es der Container-Apps-Runtime, regelmäßig den Status Ihrer Container-Apps zu prüfen.

Sie können Probes ausschließlich über TCP oder HTTP(S) einrichten.

Azure-Container-Apps unterstützen die folgenden Prüfpunkte:

Eine vollständige Liste der in Azure Container Apps unterstützten Probespezifikationen finden Sie unter Azure REST API-Spezifikationen.

HTTP-Abfragen

MIT HTTP-Prüfern können Sie benutzerdefinierte Logik implementieren, um den Status von Anwendungsabhängigkeiten zu überprüfen, bevor ein fehlerfreier Status gemeldet wird.

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.

Das folgende Beispiel zeigt, 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 einzelnen Probetyp 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. Details zur vollständigen ARM-Vorlage finden Sie in der Container Apps ARM-Vorlagen-API-Spezifikation.

{
  ...
  "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
        }]
    }]
  ...
}

...
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 Sie Ingress aktivieren, fügt das Portal automatisch die folgenden Standardsonden zum Haupt-App-Container hinzu, sofern Sie nicht jeden Typ definieren. Ausgenommen sind GPU-Workloadprofile (sowohl dedizierte als auch Verbrauch). Das Portal fügt keine Standardsonden automatisch zu Sidecar-Containern hinzu.

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 umgestellt, 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 starten das fragliche 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 bedeuten, dass die Überarbeitung nicht ordnungsgemäß konfiguriert ist.

Wenn Ihre App eine lange Startzeit benötigt, passen Sie die Testeinstellungen an, um zu verhindern, dass der Container neu gestartet (oder als fehlerhaft gekennzeichnet) wird, bevor er bereit ist. Durch das Anpassen der Probekonfiguration wird sichergestellt, dass Ihre App genügend Zeit zum Starten hat, ohne unnötige Neustarts auszulösen.

Im folgenden Beispiel wird veranschaulicht, wie die Lebendigkeits- und Bereitschaftssonden konfiguriert werden, um die Startzeiten 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
       }]

Nächste Schritte