Integritätstests in Azure Container Apps

Artikel
04/12/2024

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
Startup	Ü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-Tests

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 Livetest-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-Tests

TCP-Prüfpunkte warten, um 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 Integritätstests 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.

ARM-Vorlage
YAML

{
  ...
  "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 versuchen durchzuführen, wenn die Testausführung fehlerhaft ist. Über failureThreshold hinausgehende Versuche führen zu unterschiedlichen Ergebnissen für jeden Testtyp.

Standardkonfiguration

Wenn eingehender Datenverkehr aktiviert ist, werden die folgenden Standardtests automatisch dem Hauptcontainer der App hinzugefügt, wenn nicht für jeden Typ einer definiert ist.

Hinweis

Standardsonden werden derzeit nicht auf Workloadprofilumgebungen angewendet, wenn Sie den Verbrauchsplan verwenden. Dieses Verhalten kann sich in Zukunft ändern.

Testtyp	Standardwerte
Startup	Protokoll: TCP Port: Eingangszielport Timeout: 3 Sekunden Zeitraum: 1 Sekunde Anfängliche Verzögerung: 1 Sekunde Erfolgsschwellenwert: 1 Fehlerschwellenwert: 240
Bereitschaft	Protokoll: TCP Port: Eingangszielport Timeout: 5 Sekunden Zeitraum: 5 Sekunden Anfängliche Verzögerung: 3 Sekunden Erfolgsschwellenwert: 1 Fehlerschwellenwert: 48
Livezustand	Protokoll: TCP Port: Eingangszielport

Wenn Ihre App eine längere Zeit benötigt, um zu starten, was in Java häufig auftritt, müssen Sie den Test oft anpassen, damit Ihr Container nicht abstürzt.

Im folgenden Beispiel wird veranschaulicht, wie die Live- und Bereitschaftstests 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

Anwendungsprotokollierung

Freigeben über