Sondy kondycji w usłudze Azure Container Apps

Artykuł
04/10/2024

Sondy kondycji usługi Azure Container Apps umożliwiają środowisku uruchomieniowemu usługi Container Apps regularne sprawdzanie stanu aplikacji kontenera.

Sondy można skonfigurować wyłącznie przy użyciu protokołu TCP lub HTTP(S).

Usługa Container Apps obsługuje następujące sondy:

Sonda	opis
Uruchamianie	Sprawdza, czy aplikacja została pomyślnie uruchomiona. Ta kontrola jest oddzielona od sondy aktualności i jest wykonywana w początkowej fazie uruchamiania aplikacji.
Liveness (Żywość)	Sprawdza, czy aplikacja jest nadal uruchomiona i odpowiada.
Gotowość	Sprawdza, czy replika jest gotowa do obsługi żądań przychodzących.

Pełną listę specyfikacji sondy obsługiwanych w usłudze Azure Container Apps można znaleźć w temacie Specyfikacje interfejsu API REST platformy Azure.

Sondy HTTP

Sondy HTTP umożliwiają zaimplementowanie logiki niestandardowej w celu sprawdzenia stanu zależności aplikacji przed raportowaniem stanu dobrej kondycji.

Skonfiguruj punkty końcowe sondy kondycji, aby odpowiadały przy użyciu kodu stanu HTTP większego lub równego 200 i mniejszego niż 400 , aby wskazać powodzenie. Każdy inny kod odpowiedzi poza tym zakresem wskazuje błąd.

W poniższym przykładzie pokazano, jak zaimplementować punkt końcowy aktualności w języku 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
  }
})

Sondy TCP

Sondy TCP czekają na nawiązanie połączenia z serwerem, aby wskazać powodzenie. Sonda kończy się niepowodzeniem, jeśli nie może nawiązać połączenia z aplikacją.

Ograniczenia

Można dodać tylko jeden z każdego typu sondy dla kontenera.
exec sondy nie są obsługiwane.
Wartości portów muszą być liczbami całkowitymi; nazwane porty nie są obsługiwane.
Usługa gRPC nie jest obsługiwana.

Przykłady

Poniższa lista kodu pokazuje, jak można zdefiniować sondy kondycji dla kontenerów.

Symbole ... zastępcze oznaczają pominięty kod. Aby uzyskać szczegółowe informacje na temat szablonu usługi ARM, zapoznaj się ze specyfikacją interfejsu API szablonu arm usługi Container Apps.

Szablon usługi 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
...

Opcjonalne failureThreshold ustawienie definiuje liczbę prób wykonania sondy przez usługę Container Apps, jeśli wykonanie zakończy się niepowodzeniem. Próby, które przekraczają failureThreshold ilość, powodują różne wyniki dla każdego typu sondy.

Konfiguracja domyślna

Jeśli ruch przychodzący jest włączony, następujące sondy domyślne są automatycznie dodawane do głównego kontenera aplikacji, jeśli żaden z nich nie jest zdefiniowany dla każdego typu.

Uwaga

Domyślne sondy nie są obecnie stosowane w środowiskach profilu obciążenia podczas korzystania z planu Zużycie. To zachowanie może ulec zmianie w przyszłości.

Typ sondy	Wartości domyślne
Uruchamianie	Protokół: TCP Port: port docelowy ruchu przychodzącego Limit czasu: 3 sekundy Okres: 1 sekunda Opóźnienie początkowe: 1 sekunda Próg powodzenia: 1 Próg niepowodzenia: 240
Gotowość	Protokół: TCP Port: port docelowy ruchu przychodzącego Limit czasu: 5 sekund Okres: 5 sekund Opóźnienie początkowe: 3 sekundy Próg powodzenia: 1 Próg niepowodzenia: 48
Liveness (Żywość)	Protokół: TCP Port: port docelowy ruchu przychodzącego

Jeśli uruchomienie aplikacji zajmuje dłuższy czas (co jest powszechne w języku Java), często trzeba dostosować sondy, aby kontener nie ulegał awarii.

W poniższym przykładzie pokazano, jak skonfigurować sondy aktualności i gotowości w celu wydłużenia czasu uruchamiania.

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

Następne kroki

Rejestrowanie aplikacji

Share via