Delen via

Statustests in Azure Container Apps

Met azure Container Apps-statustests kan de Container Apps-runtime regelmatig de status van uw container-apps inspecteren.

U kunt tests instellen met TCP of HTTP(S) uitsluitend.

Container Apps ondersteunt de volgende tests:

Onderzoek Beschrijving
Opstarten Controleert of uw toepassing is gestart. Deze controle staat los van de livenesstest en wordt uitgevoerd tijdens de eerste opstartfase van uw toepassing.
Leeflijkheid Controleert of uw toepassing nog steeds wordt uitgevoerd en reageert.
Gereedheid Controleert of een replica gereed is voor het afhandelen van binnenkomende aanvragen.

Raadpleeg azure REST API-specificaties voor een volledige lijst met de testspecificaties die worden ondersteund in Azure Container Apps.

HTTP-probes

Met HTTP-probes kunt u aangepaste logica implementeren om de status van afhankelijke toepassingen te controleren voordat een gezonde status wordt gerapporteerd.

Configureer uw statustesteindpunten om te reageren met een HTTP-statuscode die groter dan of gelijk aan 200 en kleiner dan 400 is, om succes aan te geven. Elke andere antwoordcode buiten dit bereik geeft een fout aan.

In het volgende voorbeeld ziet u hoe u een liveness-eindpunt implementeert in 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-tests

TCP-probes wachten tot een verbinding met de server tot stand is gebracht om succes aan te geven. De test mislukt als er geen verbinding met uw toepassing tot stand kan worden gebracht.

Beperkingen

  • U kunt slechts één van elk testtype per container toevoegen.
  • exec probes worden niet ondersteund.
  • Poortwaarden moeten gehele getallen zijn; benoemde poorten worden niet ondersteund.
  • gRPC wordt niet ondersteund.

Voorbeelden

In de volgende codevermelding ziet u hoe u statustests voor uw containers kunt definiëren.

De ... tijdelijke aanduidingen geven weggelaten code aan. Raadpleeg de ARM-sjabloon-API-specificatie van Container Apps voor volledige ARM-sjabloondetails.

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

De optionele failureThreshold instelling definieert het aantal pogingen dat Container Apps probeert de test uit te voeren als de uitvoering mislukt. Pogingen die de failureThreshold hoeveelheid overschrijden, veroorzaken verschillende resultaten voor elk testtype.

Standaardconfiguratie

Als inkomend verkeer is ingeschakeld, worden de volgende standaardtests automatisch toegevoegd aan de hoofd-app-container als er geen is gedefinieerd voor elk type, met uitzondering van GPU-workloadprofielen (zowel toegewezen als verbruik).

Testtype Standaardwaarden
Opstarten Protocol: TCP
Poort: doelpoort voor inkomend verkeer
Time-out: 3 seconden
Periode: 1 seconde
Initiële vertraging: 1 seconde
Slagingsdrempel: 1
Foutdrempel: 240
Leeflijkheid Protocol: TCP
Poort: doelpoort voor inkomend verkeer
Gereedheid Protocol: TCP
Poort: doelpoort voor inkomend verkeer
Time-out: 5 seconden
Periode: 5 seconden
Initiële vertraging: 3 seconden
Slagingsdrempel: 1
Foutdrempel: 48

Als u uw container-app uitvoert in de modus meerdere revisies, wacht totdat uw gereedheidstests na het implementeren van een revisie zijn geslaagd voordat u verkeer naar die revisie verplaatst. In de modus voor één revisie wordt verkeer automatisch verplaatst zodra de gereedheidstest een geslaagde status retourneert.

Een revisiestatus lijkt als beschadigd als een van de replica's mislukt, zelfs als alle andere replica's in de revisie in orde zijn. Container Apps start de betreffende replica opnieuw op totdat deze weer in orde is of de drempelwaarde voor fouten wordt overschreden. Als de drempelwaarde voor fouten wordt overschreden, start u de revisie opnieuw, maar dit kan betekenen dat de revisie niet juist is geconfigureerd.

Als het lang duurt voordat uw app wordt gestart (wat gebruikelijk is in Java), moet u de tests vaak aanpassen, zodat uw container niet vastloopt.

In het volgende voorbeeld ziet u hoe u de liveness- en readiness-probes configureert om de tijden voor opstarten te verlengen.

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

Volgende stappen

Toepassingslogboekregistratie