Dela via

Hälsokontroller i Azure Container Apps

Med hälsoprovtagningar i Azure Container Apps kan Container Apps-miljön regelbundet kontrollera statusen för dina container-appar.

Du kan konfigurera avsökningar med enbart TCP eller HTTP(S).

Container Apps stöder följande sonderingar:

Avsökning beskrivning
Startupföretag Kontrollerar om programmet har startats. Den här kontrollen är separat från livenesskontrollen och körs under applikationens inledande startfas.
Livhet Kontrollerar om applikationen fortfarande körs och svarar.
Beredskap Kontrollerar om en replik är redo att hantera inkommande begäranden.

För en fullständig lista över probsspecifikationerna som stöds i Azure Container Apps, se Azure REST API-specifikationer.

HTTP-avsökningar

MED HTTP-avsökningar kan du implementera anpassad logik för att kontrollera statusen för programberoenden innan du rapporterar en felfri status.

Konfigurera slutpunkterna för hälsokontrollen så att de svarar med en HTTP-statuskod som är större än eller lika med 200 och mindre än 400 för att indikera framgång. All annan svarskod utanför det här intervallet indikerar ett fel.

I följande exempel visas hur du implementerar en liveness-slutpunkt i JavaScript.

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-avsökningar

TCP-sonder väntar på att anslutningen till servern ska upprättas för att indikera att anslutningen har lyckats. Avsökningen misslyckas om den inte kan upprätta en anslutning till ditt program.

Begränsningar

  • Du kan bara lägga till en av varje probtyp per behållare.
  • exec avsökningar stöds inte.
  • Portvärdena måste vara heltal. namngivna portar stöds inte.
  • gRPC stöds inte.

Exempel

Följande kodexempel visar hur du kan definiera hälsokontroller för dina containrar.

Platshållarna ... anger utelämnad kod. Se API-specifikationen för ARM-mallar för Container Apps för fullständig INFORMATION om ARM-mallar.

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

Den valfria failureThreshold inställningen definierar antalet försök som Container Apps försöker köra avsökningen om körningen misslyckas. Försök som överskrider failureThreshold mängden orsakar olika resultat för varje avsökningstyp.

Standardkonfiguration

Om ingress är aktiverat läggs följande standardavsökningar automatiskt till i huvudappcontainern om ingen har definierats för varje typ, förutom för GPU-arbetsbelastningsprofiler (både dedikerade och förbrukning).

Avsökningstyp Standardvärden
Startuppföretag Protokoll: TCP
Port: inkommande målport
Tidsgräns: 3 sekunder
Period: 1 sekund
Inledande fördröjning: 1 sekund
Tröskelvärde för lyckad åtgärd: 1
Tröskelvärde för fel: 240
Livskraft Protokoll: TCP
Port: inkommande målport
Beredskap Protokoll: TCP
Port: inkommande målport
Tidsgräns: 5 sekunder
Period: 5 sekunder
Inledande fördröjning: 3 sekunder
Tröskelvärde för lyckad åtgärd: 1
Tröskelvärde för fel: 48

Om du kör containerappen i flera revisionslägen väntar du tills dina beredskapsavsökningar visar att det har lyckats innan du flyttar trafik till den revisionen. I enkelt revisionsläge flyttas trafiken automatiskt när beredskapsavsökningen returnerar ett lyckat tillstånd.

Ett revisionstillstånd visas som ohälsosamt om någon av replikerna misslyckas med kontrollen av förbereddhetsprovet, även om alla andra repliker i revisionen är friska. Container Apps startar om repliken i fråga tills den är felfri igen eller om tröskelvärdet för fel överskrids. Om tröskelvärdet för fel överskrids kan du försöka starta om revisionen, men det kan innebära att revisionen inte är korrekt konfigurerad.

Om din app tar längre tid att starta (vilket är vanligt i Java) måste du ofta anpassa avsökningarna så att containern inte kraschar.

Det följande exemplet visar hur du konfigurerar livfullhets- och beredskapskontroller för att förlänga starttiderna.

"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ästa steg

Applikationsloggning