Пробы работоспособности в Контейнерах приложений Azure

Статья
10/26/2023

Пробы работоспособности приложений контейнеров Azure позволяют среде выполнения контейнерных приложений регулярно проверять состояние приложений контейнеров.

Пробы можно настроить, используя исключительно TCP или HTTP(S).

Контейнерные приложения поддерживают следующие пробы:

Проба	Description
Запуск	Проверяет, успешно ли запущено приложение. Этот проверка отличается от пробы активности и выполняется на начальном этапе запуска приложения.
Живость	Проверяет, работает ли ваше приложение и реагирует.
Готовность	Проверяет, готов ли реплика обрабатывать входящие запросы.

Полный список спецификаций проб, поддерживаемых в приложениях контейнеров Azure, см. в спецификациях REST API Azure.

Пробы HTTP

Пробы HTTP позволяют реализовать пользовательскую логику для проверки состояния зависимостей приложения перед отправкой отчетов о работоспособном состоянии.

Настройте конечные точки пробы работоспособности для ответа с кодом состояния HTTP, большим или равным 200 и меньшим 400, для указания успешного выполнения. Любой другой код ответа за пределами этого диапазона указывает на сбой.

В следующем примере показано, как реализовать конечную точку активности в 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

Проверки TCP ожидают установления соединения с сервером, чтобы указать успешность. Проверка завершается ошибкой, если не удается установить подключение к приложению.

Ограничения

Для каждого контейнера можно добавить только один из каждого типа пробы.
Пробы exec не поддерживаются.
Значения портов должны быть целыми числами; именованные порты не поддерживаются.
gRPC не поддерживается.

Примеры

В следующем листинге кода показано, как определять пробы работоспособности для контейнеров.

Заполнители ... обозначают пропущенный код. Полные сведения о шаблоне ARM см. в спецификации API шаблона ARM для Контейнеров приложений.

Шаблон 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
...

Необязательный failureThreshold параметр определяет количество попыток, когда приложения-контейнеры пытаются выполнить пробу, если выполнение завершается ошибкой. Попытки, превышающие failureThreshold объем, вызывают разные результаты для каждого типа пробы.

Конфигурация по умолчанию

Если входящий трафик включен, следующие пробы по умолчанию автоматически добавляются в основной контейнер приложений, если ни один из них не определен для каждого типа.

Примечание.

Пробы по умолчанию в настоящее время не применяются к средам профиля рабочей нагрузки при использовании плана потребления. Это поведение может измениться в будущем.

Тип пробы	Значения по умолчанию
Запуск	Протокол: TCP Порт: целевой порт входящего трафика Время ожидания: 3 секунды Период: 1 секунда Начальная задержка: 1 секунда Порог успеха: 1 Порог сбоя: 240
Готовность	Протокол: TCP Порт: целевой порт входящего трафика Время ожидания: 5 секунд Период: 5 секунд Начальная задержка: 3 секунды Порог успеха: 1 Порог сбоя: 48
Живость	Протокол: TCP Порт: целевой порт входящего трафика

Если ваше приложение занимает длительное время начала (обычно в Java), вам часто нужно настроить пробы, чтобы контейнер не сбой.

В следующем примере показано, как настроить пробы активности и готовности для увеличения времени запуска.

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

Следующие шаги

Ведение журнала приложений