Investigações de integridade em Aplicativos de Contêiner do Azure
As investigações de integridade dos Aplicativos de Contêiner do Azure permitem que o runtime de Aplicativos de Contêiner inspecione regularmente o status dos aplicativos de contêiner.
Você pode configurar investigações usando TCP ou HTTP (S) exclusivamente.
Os Aplicativos de Contêiner dão suporte às seguintes investigações:
| Investigação | Descrição |
|---|---|
| Inicialização | Verificam se o aplicativo foi iniciado com êxito. Essa verificação é separada da investigação de atividade e é executada durante a fase de inicialização do aplicativo. |
| Atividade | Verifica se o aplicativo ainda está em execução e responde. |
| Preparação | Verificar se uma réplica está pronta para lidar com solicitações de entrada. |
Para obter uma lista das especificações de investigação com suporte nos Aplicativos de Contêiner do Azure, consulte as Especificações da API REST do Azure.
Investigações HTTP
As investigações HTTP permitem que você implemente uma lógica personalizada para verificar o status das dependências do aplicativo antes de relatar um status Íntegro.
Configure seus pontos de extremidade de investigação de integridade para responder com um código de status HTTP maior ou igual a 200 e menor que 400 para indicar êxito. Qualquer outro código de resposta fora desse intervalo indica uma falha.
O exemplo a seguir demonstra como implementar um ponto de extremidade de vida 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
}
})
Investigações de TCP
As investigações de TCP esperam que uma conexão seja estabelecida com o servidor para indicar êxito. A investigação falhará se não conseguir estabelecer uma conexão com seu aplicativo.
Restrições
- Você só pode adicionar um de cada tipo de investigação por contêiner.
- Não há suporte para a investigação
exec. - Os valores de porta devem ser inteiros; Não há suporte para portas nomeadas.
- Não há suporte para gRPC.
Exemplos
A listagem de código a seguir mostra como você pode definir investigações de integridade para seus contêineres.
Os espaços reservados ... denotam código omitido. Confira a Especificação da API do modelo do ARM dos Aplicativos de Contêiner para obter detalhes completos do modelo do ARM.
{
...
"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 feitas pelos Aplicativos de Contêiner para executar a investigação se a execução falhar. As tentativas que excedem a quantidade failureThreshold causam resultados diferentes para cada tipo de investigação.
Configuração padrão
Se a entrada estiver habilitada, as investigações padrão a seguir serão adicionadas automaticamente ao contêiner de aplicativo principal se não houver uma definição para cada tipo.
| Tipo de investigação | Valores padrão |
|---|---|
| Inicialização | Protocolo: TCP Porta: porta de destino de entrada Tempo limite: 3 segundos Período: 1 segundo Atraso inicial: 1 segundo Limite de êxito: 1 Limite de falhas: 240 |
| Atividade | Protocolo: TCP Porta: porta de destino de entrada |
| Preparação | Protocolo: TCP Porta: porta de destino de entrada Tempo limite: 5 segundos Período: 5 segundos Atraso inicial: 3 segundos Limite de êxito: 1 Limite de falhas: 48 |
Se você estiver executando seu aplicativo de contêiner no modo várias revisões, após implantar uma revisão aguarde até que as sondas do seu grau de prontidão indiquem sucesso antes de transferir o tráfego para a revisão em questão. No modo uma revisão, o tráfego é transferido automaticamente assim que a sonda do grau de prontidão retorna um estado bem-sucedido.
Um estado de revisão aparece como não íntegro se uma das respectivas réplicas apresentar falha na sonda do grau de prontidão, mesmo que todas as outras réplicas na revisão estejam íntegras. A plataforma Aplicativos de Contêiner reinicia a réplica em questão até que esteja íntegra novamente ou o limite de falhas seja excedido. Se o limite de falhas for excedido, tente reiniciar a revisão. Porém, isso pode significar que a revisão não está configurada corretamente.
Se o aplicativo demorar muito para começar (o que é comum em Java), geralmente é necessário personalizar as investigações para que o contêiner não falhe.
O exemplo a seguir demonstra como configurar as investigações de dinamismo e preparaçã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
}]