Sondas de saúde em Aplicações de Contêiner do Azure

As sondas de saúde das Aplicações de Contentores do Azure permitem que o runtime das Aplicações de Contentores verifique regularmente o estado das suas aplicações de contentores.

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

Os Aplicativos de Contêiner do Azure dão suporte às seguintes sondas:

Para obter uma lista completa das especificações de teste suportadas 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 estado das dependências da aplicação antes de indicar um estado saudável.

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

O exemplo a seguir mostra 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ê pode adicionar apenas uma de cada tipo de sonda por recipiente.
• exec Não há suporte para sondas.
• 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 ... marcadores denotam código omitido. Para obter detalhes completos do modelo ARM, consulte Especificação da API do modelo ARM de aplicativos de contêiner.

{
  ...
  "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 você habilitar o ingresso, o portal adicionará automaticamente as seguintes sondas padrão ao contêiner principal do aplicativo, caso não defina cada tipo, exceto para perfis de carga de trabalho da GPU (dedicados e de consumo). O portal não adiciona automaticamente sondas padrão aos contêineres de sidecar.

Se você executar seu aplicativo contêiner no modo de revisão múltipla, depois de implantar uma revisão, aguarde até que os testes de preparação indiquem sucesso antes de transferir o tráfego para essa revisão. No modo de revisão única, o tráfego muda automaticamente quando a sonda de prontidão retorna um estado bem-sucedido.

Um estado de revisão aparece como não saudável se qualquer uma das suas réplicas falhar na prova de prontidão, mesmo que todas as outras réplicas sejam saudáveis. O Container Apps reinicia a réplica em questão até que ela esteja íntegra novamente ou o limite de falha seja excedido. Se o limite de falha for excedido, tente reiniciar a revisão, mas isso pode significar que a revisão não está configurada corretamente.

Se o seu aplicativo exigir um longo tempo de inicialização, ajuste as configurações da sonda para evitar que o contêiner seja reiniciado (ou marcado como não íntegro) antes de estar pronto. Personalizar a configuração da sonda ajuda a garantir que seu aplicativo tenha tempo suficiente para iniciar sem acionar reinicializações desnecessárias.

O exemplo a seguir demonstra como configurar as sondas de vida 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