Statustests in Azure Container Apps

Artikel
04/10/2024

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:

Test	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-tests

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

Configureer uw statustesteindpunten om te reageren met een HTTP-statuscode die groter is dan of gelijk is aan 200 en kleiner is dan om aan te geven dat 400 de status is geslaagd. 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-tests wachten totdat er een verbinding met de server tot stand is gebracht om aan te geven dat het is gelukt. 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 tests 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.

ARM-sjabloon
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
...

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.

Notitie

Standaardtests worden momenteel niet toegepast op workloadprofielomgevingen bij gebruik van het verbruiksabonnement. Dit gedrag kan in de toekomst veranderen.

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
Gereedheid	Protocol: TCP Poort: doelpoort voor inkomend verkeer Time-out: 5 seconden Periode: 5 seconden Initiële vertraging: 3 seconden Slagingsdrempel: 1 Foutdrempel: 48
Leeflijkheid	Protocol: TCP Poort: doelpoort voor inkomend verkeer

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 gereedheidstests 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

Toepassingslogboekregistratie

Delen via