Laboratório de Troubleshooting: Provision a container by using Azure Container Instances
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Um time de operações implantou um container group no Azure Container Instances usando um arquivo YAML. O grupo contém dois contêineres: um aplicativo principal e um sidecar de coleta de logs. A implantação foi concluída com sucesso segundo o portal do Azure, e o status do container group aparece como Running.
No entanto, a equipe relata que o endpoint público do aplicativo não responde. Ao tentar acessar http://<ip-publico>:8080, a conexão é recusada.
O YAML utilizado na implantação contém o seguinte trecho relevante:
ipAddress:
type: Public
ports:
- protocol: TCP
port: 80
containers:
- name: app-principal
image: meuregistry.azurecr.io/webapp:latest
ports:
- port: 8080
resources:
requests:
cpu: 1
memoryInGb: 1
- name: sidecar-logs
image: meuregistry.azurecr.io/logcollector:v2
resources:
requests:
cpu: 0.5
memoryInGb: 0.5
A equipe confirma que a imagem webapp:latest expõe a aplicação na porta 8080 internamente e que as credenciais do registro foram fornecidas corretamente. O sidecar está funcional e enviando logs ao Azure Monitor.
Qual é a causa raiz da inacessibilidade do endpoint?
A) O tipo de IP Public não é compatível com container groups que possuem mais de um contêiner; é necessário usar uma Virtual Network.
B) A porta exposta no ipAddress é 80, mas o contêiner da aplicação escuta na porta 8080; o tráfego externo chega na 80 e não tem mapeamento para a porta real da aplicação.
C) O sidecar está consumindo parte da cota de CPU e memória, causando throttling no contêiner principal e impedindo que ele aceite conexões.
D) A imagem webapp:latest usa tag flutuante, o que causa recriação periódica do contêiner e interrompe conexões ativas durante o pull.
Cenário 2 — Decisão de Ação
A causa de uma falha foi identificada: um container group em produção está implantado sem integração com Azure Virtual Network, e uma nova política de segurança da empresa exige que todos os contêineres ACI em produção se comuniquem exclusivamente por rede privada, sem IP público exposto.
O container group atual processa pedidos em tempo real para um e-commerce, com pico de uso entre 18h e 22h. São 14h de uma sexta-feira. A equipe de rede confirmou que a sub-rede delegada para ACI já está provisionada e disponível. O time de desenvolvimento informou que nenhuma mudança de código é necessária, apenas reconfiguração de infraestrutura.
Recriar o container group com integração de VNet exige destruir e reimplantar o recurso, pois essa propriedade não pode ser alterada em um grupo existente.
Qual é a ação correta a tomar neste momento?
A) Recriar imediatamente o container group com a configuração de VNet, aproveitando que ainda faltam 4 horas para o pico de uso.
B) Remover o IP público do container group atual via portal do Azure para atender à política imediatamente, e planejar a migração para VNet no próximo ciclo de manutenção.
C) Planejar a recriação do container group com VNet para um horário de baixo tráfego fora do pico, documentar o risco temporário de não conformidade e comunicar às partes envolvidas.
D) Solicitar uma exceção permanente à política de segurança para esse container group, argumentando que a recriação em produção representa risco operacional.
Cenário 3 — Causa Raiz
Uma pipeline de CI/CD implanta automaticamente um contêiner no ACI após cada build bem-sucedido. A pipeline usa o seguinte comando para recriar o contêiner:
az container delete \
--resource-group rg-staging \
--name processador-staging \
--yes
az container create \
--resource-group rg-staging \
--name processador-staging \
--image meuregistry.azurecr.io/processador:latest \
--cpu 2 \
--memory 4 \
--restart-policy Never \
--environment-variables ENV=staging DB_HOST=db.internal.empresa.com \
--registry-login-server meuregistry.azurecr.io \
--registry-username $ACR_USER \
--registry-password $ACR_PASS
Após uma execução recente da pipeline, a equipe observa que o contêiner inicia normalmente, mas encerra em menos de 10 segundos sem produzir nenhuma saída nos logs. O status final registrado é Terminated com código de saída 0.
Name State ExitCode StartTime FinishTime
-------------------- ----------- ---------- --------------------------- ---------------------------
processador-staging Terminated 0 2024-11-15T14:03:22+00:00 2024-11-15T14:03:31+00:00
A equipe verificou que a variável DB_HOST está correta e que o banco de dados está acessível. O registro de contêiner está autenticado e a imagem foi baixada com sucesso.
Qual é a causa raiz do comportamento observado?
A) A política Never impede que o contêiner reinicie após a conclusão, mas o problema real é que a aplicação encerrou com falha silenciosa; o código de saída 0 foi retornado incorretamente pela camada do ACI.
B) A variável ENV=staging está sendo interpretada como um comando pelo entrypoint da imagem, causando encerramento antecipado.
C) O processo principal da imagem processador:latest concluiu sua execução normalmente; código de saída 0 com restart-policy Never é o comportamento esperado para uma tarefa de execução finita que terminou com sucesso.
D) O comando az container delete anterior não aguardou a exclusão completa do recurso, causando conflito de estado durante a recriação e execução prematura do contêiner.
Cenário 4 — Sequência de Diagnóstico
Um container group foi implantado no ACI e o status exibido no portal é Waiting. O contêiner nunca avança para o estado Running. A equipe precisa diagnosticar a causa.
Os seguintes passos de investigação estão disponíveis, fora de ordem:
- Passo P: Executar
az container logspara verificar se há saída do processo principal antes da falha. - Passo Q: Executar
az container showpara inspecionar o estado atual do container group e verificar os eventos recentes. - Passo R: Verificar se as credenciais do registro de contêiner fornecidas no comando de criação estão corretas e se a imagem referenciada existe no registro.
- Passo S: Verificar os eventos do container group em busca de mensagens como
Failed to pull imageouImagePullBackOff. - Passo T: Revisar os recursos solicitados (CPU e memória) e comparar com os limites disponíveis na região e no SKU utilizado.
Qual é a sequência correta de diagnóstico?
A) P, Q, R, S, T
B) Q, S, R, T, P
C) R, S, Q, T, P
D) S, Q, R, P, T
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista determinante está na própria configuração YAML: a seção ipAddress expõe apenas a porta 80 para o exterior, mas o contêiner da aplicação declara e escuta na porta 8080. No ACI, as portas declaradas em ipAddress.ports são as únicas abertas no IP público do container group. A porta 8080 do contêiner não está mapeada para o exterior, portanto qualquer requisição que chega ao IP público simplesmente não encontra destino.
A informação sobre o sidecar funcional e os logs no Azure Monitor é irrelevante para o diagnóstico e foi incluída propositalmente para desviar a atenção. O sidecar não compartilha portas com o exterior e seu funcionamento não influencia a exposição de portas do contêiner principal.
Os distratores exploram o equívoco de buscar a causa em lugares mais complexos: throttling de recursos, comportamento de tags flutuantes ou restrições arquiteturais de multi-contêiner. O distrator mais perigoso é A, pois poderia levar a uma refatoração desnecessária da topologia de rede quando o problema é simplesmente uma porta não declarada no bloco de IP.
Gabarito — Cenário 2
Resposta: C
O contexto de restrições é determinante aqui. São 14h de sexta-feira, o pico de tráfego ocorre entre 18h e 22h, e recriar o container group exige destruir o recurso existente, gerando indisponibilidade. Executar essa operação imediatamente (alternativa A) introduz risco de instabilidade 4 horas antes do pico, sem janela suficiente para validação.
A alternativa B é tecnicamente inválida: remover o IP público de um container group existente não satisfaz a política, que exige integração com VNet, e além disso pode não ser possível sem recriar o recurso dependendo da configuração atual.
A alternativa D representa capitulação operacional sem fundamento técnico, já que a sub-rede delegada está disponível e a equipe confirmou que a mudança é viável.
A ação correta é planejar a recriação para um horário de baixo tráfego, documentar formalmente o estado de não conformidade temporária e comunicar os riscos. Isso respeita simultaneamente a política de segurança, a continuidade do negócio e a governança do processo.
Gabarito — Cenário 3
Resposta: C
O código de saída 0 é a pista central e definitiva. No sistema operacional e no modelo de contêineres, código de saída 0 significa encerramento bem-sucedido sem erro. Combinado com restart-policy Never, o comportamento descrito é exatamente o esperado para uma tarefa de processamento finita: o contêiner executou sua carga, concluiu com sucesso e encerrou sem reiniciar.
A equipe provavelmente esperava um comportamento de serviço contínuo, mas a imagem foi construída para execução pontual. A informação sobre DB_HOST estar correto e a autenticação do registro ter funcionado são relevantes para confirmar que não houve falha de infraestrutura, mas não alteram o diagnóstico.
O distrator mais perigoso é A, pois introduz a hipótese de que o ACI teria mascarado um código de saída de erro, o que não corresponde ao comportamento da plataforma. Agir com base nessa hipótese levaria a investigação na direção errada, possivelmente reconstruindo a imagem ou alterando a aplicação sem necessidade.
Gabarito — Cenário 4
Resposta: B
A sequência correta é Q, S, R, T, P, e a lógica é de progressão do geral para o específico.
Q primeiro: inspecionar o estado geral do container group com az container show fornece uma visão imediata dos eventos registrados pela plataforma, sem hipóteses prévias.
S em seguida: os eventos do container group revelam diretamente se houve falha no pull da imagem, que é a causa mais comum do estado Waiting. Verificar isso antes de qualquer outra hipótese é eficiente.
R depois: se os eventos indicam falha de pull, verificar as credenciais e a existência da imagem no registro confirma ou descarta essa hipótese com precisão.
T na sequência: se a imagem foi baixada corretamente mas o contêiner ainda não iniciou, investigar limitações de recursos na região é o próximo passo lógico.
P por último: az container logs só é útil se o contêiner chegou a iniciar e produzir saída. No estado Waiting, esse comando provavelmente não retornará nada relevante e deve ser reservado para quando os passos anteriores não identificarem a causa.
A alternativa A comete o erro clássico de verificar logs antes de entender o estado do sistema. As alternativas C e D chegam a verificar credenciais antes de observar os eventos, o que é diagnóstico às cegas.
Árvore de Troubleshooting: Provision a container by using Azure Container Instances
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro (navy) | Sintoma inicial, ponto de entrada |
| Azul (blue) | Pergunta diagnóstica ou ponto de decisão |
| Laranja | Verificação intermediária ou validação de estado |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
Diante de um problema real com Azure Container Instances, comece pelo nó raiz e responda à primeira pergunta observável: o contêiner está em Waiting, em Running sem responder, ou encerrando imediatamente? Cada resposta leva a um ramo específico de perguntas progressivamente mais precisas. Siga apenas o caminho que corresponde ao que você observa, sem pular etapas. Os nós laranja indicam verificações intermediárias que confirmam ou descartam uma hipótese antes de declarar a causa. Chegando a um nó vermelho, a causa está identificada; o nó verde imediatamente abaixo indica a ação correta a executar.