Probe di integrità nelle App contenitore di Azure

Articolo
08/08/2024

I probe di integrità delle app contenitore consentono al runtime di App contenitore di controllare regolarmente lo stato delle app contenitore.

È possibile configurare i probe usando esclusivamente TCP o HTTP(S).

App contenitore supporta i probe seguenti:

Probe	Descrizione
Startup	Controlla se l'applicazione è stata avviata correttamente. Questo controllo è separato dal probe di attività e viene eseguito durante la fase di avvio iniziale dell'applicazione.
Attività	Controlla se l'applicazione è ancora in esecuzione e reattiva.
Idoneità	Verifica se una replica è pronta per gestire le richieste in ingresso.

Per un elenco completo delle specifiche del probe supportate in App Azure Container, vedere Specifiche dell'API REST di Azure.

Probe HTTP

I probe HTTP consentono di implementare la logica personalizzata per controllare lo stato delle dipendenze dell'applicazione prima di segnalare uno stato integro.

Configurare gli endpoint del probe di integrità per rispondere con un codice di stato HTTP maggiore o uguale a 200 e minore di 400 per indicare l'esito positivo. Qualsiasi altro codice di risposta esterno a questo intervallo indica un errore.

L'esempio seguente illustra come implementare un endpoint di attività 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
  }
})

Probe TCP

I probe TCP attendono di stabilire una connessione con il server per indicare l'esito positivo. Il probe non riesce se non riesce a stabilire una connessione all'applicazione.

Restrizioni

È possibile aggiungere un solo tipo di probe per ogni contenitore.
exec i probe non sono supportati.
I valori di porta devono essere numeri interi; le porte denominate non sono supportate.
gRPC non è supportato.

Esempi

L'elenco di codice seguente illustra come definire i probe di integrità per i contenitori.

I ... segnaposto indicano il codice omesso. Per informazioni dettagliate sul modello di Resource Manager, vedere Specifica dell'API del modello di Resource Manager per app contenitore.

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

L'impostazione facoltativa failureThreshold definisce il numero di tentativi di esecuzione di App contenitore se l'esecuzione non riesce. I tentativi che superano la failureThreshold quantità causano risultati diversi per ogni tipo di probe.

Configurazione predefinita

Se l'ingresso è abilitato, i probe predefiniti seguenti vengono aggiunti automaticamente al contenitore principale dell'app se non è definito alcun tipo per ogni tipo.

Tipo di probe	Valori predefiniti
Startup	Protocollo: TCP Porta: porta di destinazione in ingresso Timeout: 3 secondi Periodo: 1 secondo Ritardo iniziale: 1 secondo Soglia di riuscita: 1 Soglia di errore: 240
Idoneità	Protocollo: TCP Porta: porta di destinazione in ingresso Timeout: 5 secondi Periodo: 5 secondi Ritardo iniziale: 3 secondi Soglia di riuscita: 1 Soglia di errore: 48
Attività	Protocollo: TCP Porta: porta di destinazione in ingresso

Se l'app richiede una quantità estesa di tempo per l'avvio (che è comune in Java), spesso è necessario personalizzare i probe in modo che il contenitore non si arresti in modo anomalo.

L'esempio seguente illustra come configurare i probe di attività e conformità per estendere i tempi di avvio.

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

Passaggi successivi

Registrazione di applicazioni

Condividi tramite