Sondas de integridade em Aplicativos de Contêiner do Azure

Artigo
04/10/2024

As sondas de integridade dos Aplicativos de Contêiner do Azure permitem que o tempo de execução dos Aplicativos de Contêiner inspecione regularmente o status de seus aplicativos de contêiner.

Você pode configurar testes usando TCP ou HTTP(S) exclusivamente.

O Container Apps suporta as seguintes sondas:

Teste	Description
Arranque	Verifica se o seu aplicativo foi iniciado com êxito. Essa verificação é separada da sonda de vivacidade e é executada durante a fase inicial de inicialização do seu aplicativo.
Vivacidade	Verifica se seu aplicativo ainda está em execução e responsivo.
Prontidão	Verifica se uma réplica está pronta para lidar com solicitações de entrada.

Para obter uma lista completa da especificação de teste suportada nos Aplicativos de Contêiner do Azure, consulte Especificações da API REST do Azure.

Sondas HTTP

Os testes HTTP permitem implementar lógica personalizada para verificar o status das dependências do aplicativo antes de relatar um status íntegro.

Configure seus pontos de extremidade de teste de integridade para responder com um código de status HTTP maior ou igual e 200 menor que 400 para indicar sucesso. Qualquer outro código de resposta fora desse intervalo indica uma falha.

O exemplo a seguir demonstra como implementar um ponto de extremidade liveness em 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
  }
})

Sondas TCP

As sondas TCP aguardam para estabelecer uma conexão com o servidor para indicar o sucesso. A sonda falhará se não conseguir estabelecer uma conexão com seu aplicativo.

Restrições

Você só pode adicionar um de cada tipo de teste por contêiner.
exec Não há suporte para testes.
Os valores das portas devem ser inteiros; portas nomeadas não são suportadas.
gRPC não é suportado.

Exemplos

A listagem de código a seguir mostra como você pode definir testes de integridade para seus contêineres.

Os ... espaços reservados denotam código omitido. Consulte Container Apps ARM template API specification para obter detalhes completos do modelo ARM.

Modelo 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
...

A configuração opcional failureThreshold define o número de tentativas que os Aplicativos de Contêiner tentam executar a sonda se a execução falhar. Tentativas que excedem a failureThreshold quantidade causam resultados diferentes para cada tipo de teste.

Configuração predefinida

Se a entrada estiver habilitada, os seguintes testes padrão serão adicionados automaticamente ao contêiner principal do aplicativo se nenhum for definido para cada tipo.

Tipo de sonda	Valores predefinidos
Arranque	Protocolo: TCP Porto: porta de destino de entrada Tempo limite: 3 segundos Período: 1 segundo Atraso inicial: 1 segundo Limiar de sucesso: 1 Limiar de falha: 240
Prontidão	Protocolo: TCP Porto: porta de destino de entrada Tempo limite: 5 segundos Período: 5 segundos Atraso inicial: 3 segundos Limiar de sucesso: 1 Limiar de falha: 48
Vivacidade	Protocolo: TCP Porto: porta de destino de entrada

Se seu aplicativo demorar muito tempo para iniciar (o que é comum em Java), muitas vezes você precisará personalizar os testes para que seu contêiner não falhe.

O exemplo a seguir demonstra como configurar os testes de vivacidade e prontidão para estender os tempos de inicialização.

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

Próximos passos

Registo de aplicações

Partilhar via