Delen via


Statustests in Azure Container Apps

Met Azure Container Apps-gezondheidsonderzoeken kan de Container Apps-runtime regelmatig de gezondheid van uw container-apps controleren.

U kunt tests instellen door uitsluitend TCP of HTTP(S) te gebruiken.

Azure 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.

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

HTTP-probes

Met HTTP-tests kunt u aangepaste logica implementeren om de status van toepassingsafhankelijkheden te controleren voordat u een goede status rapporteert.

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. Zie de SPECIFICATIE van de ARM-sjabloon-API voor Container Apps voor volledige ARM-sjablonen.

{
  ...
  "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 u inkomend verkeer inschakelt, voegt het portaal automatisch de volgende standaardprobes toe aan de hoofdcontainer van de app als u niet elk type afzonderlijk definieert, met uitzondering van GPU-workloadprofielen (zowel toegewezen als verbruik). De portal voegt niet automatisch standaardtests toe aan sidecar-containers.

Testtype Standaardwaarden
Opstarten Protocol: TCP
Poort: doelpoort voor inkomend verkeer
Time-out: 3 seconden
Periode: 1 seconde
Initiële vertraging: 1 seconde
Drempelwaarde voor geslaagd: één
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
Drempelwaarde voor succes: één
Foutdrempel: 48

Als u uw container-app uitvoert in meerdere revisiemodus, wacht u nadat u een revisie hebt geïmplementeerd, totdat de gereedheidstests zijn geslaagd voordat u verkeer naar die revisie verplaatst. In de enkelvoudige revisiemodus wordt verkeer automatisch omgeleid zodra de gereedheidsprobe een succesvolle 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 herstart de replica totdat deze weer gezond is of de falingsdrempel 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 uw app een lange opstarttijd vereist, past u de testinstellingen aan om te voorkomen dat de container opnieuw wordt opgestart (of gemarkeerd als beschadigd) voordat deze gereed is. Door de probeconfiguratie aan te passen, zorgt u ervoor dat uw app voldoende tijd heeft om te starten zonder onnodige herstarts te veroorzaken.

In het volgende voorbeeld ziet u hoe u de liveness- en readiness-probes configureert om de opstarttijden 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