Sondy kondycji w usłudze Azure Container Apps

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

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

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

Aby uzyskać pełną listę specyfikacji sond obsługiwanych w usłudze Azure Container Apps, zobacz 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 żywotnoś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ć pełne szczegóły szablonu usługi ARM, zobacz Container Apps ARM template API specification (Specyfikacja interfejsu API szablonu usługi ARM usługi Container Apps).

{
  ...
  "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 włączysz ingres, portal automatycznie doda następujące domyślne sondy do głównego kontenera aplikacji, jeśli nie zdefiniujesz każdego typu, z wyjątkiem profili obciążeń GPU (dedykowanych i konsumpcyjnych). Portal nie dodaje automatycznie domyślnych sond do kontenerów przyczepki.

Jeśli uruchomisz aplikację kontenera w trybie wielu wersji, po wdrożeniu poprawki poczekaj, aż sondy gotowości wskażą powodzenie przed przeniesieniem ruchu do tej poprawki. W trybie pojedynczej rewizji ruch jest automatycznie przekierowywany, gdy sonda gotowości zwróci stan gotowości.

Stan poprawki jest wyświetlany jako w złej kondycji, jeśli którakolwiek z jego replik nie przejdzie testu gotowości, nawet jeśli wszystkie inne repliki w poprawce są w dobrej kondycji. Usługa Container Apps ponownie uruchamia daną replikę, aż odzyska ona pełną funkcjonalność lub zostanie przekroczony dopuszczalny próg awarii. Jeśli próg niepowodzenia zostanie przekroczony, spróbuj ponownie uruchomić poprawkę, ale może to oznaczać, że poprawka nie jest poprawnie skonfigurowana.

Jeśli aplikacja wymaga długiego czasu uruchamiania, dostosuj ustawienia sondy, aby zapobiec ponownemu uruchomieniu kontenera (lub oznaczonemu jako w złej kondycji), zanim będzie gotowy. Dostosowanie konfiguracji sondy pomaga upewnić się, że aplikacja ma wystarczająco dużo czasu, aby rozpocząć bez wyzwalania niepotrzebnych ponownych uruchomień.

W poniższym przykładzie pokazano, jak skonfigurować sondy aktywności i gotowości, aby wydłużyć czas 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