Resolver problemas comuns no Azure Container Instances

Este artigo mostra como resolver problemas comuns na gestão ou implementação de containers para Azure Container Instances. Ver também Perguntas Frequentes.

Se precisar de mais apoio, consulte as opções de Ajuda + suporte disponíveis no portal do Azure.

Problemas durante a implementação do grupo de contentores

Convenções de nomenclatura

Quando define a especificação do seu contentor, certos parâmetros exigem a aderência a restrições de nomeação. A tabela seguinte mostra os requisitos específicos para propriedades de grupos de contentores. Para mais informações, consulte Convenções de nomenclatura no Centro de Arquitetura do Azure e Regras e restrições de nomes para recursos do Azure.

¹Restrição também aplicável aos nomes de grupos de contentores quando não são especificados independentemente das instâncias de contentor, por exemplo, em implementações com o comando az container create.

A versão do sistema operativo da imagem não é suportada

Se especificar uma imagem que o Azure Container Instances não suporta, um OsVersionNotSupported erro é devolvedo. O erro é semelhante ao seguinte, onde {0} é o nome da imagem que tentou implementar:

{
  "error": {
    "code": "OsVersionNotSupported",
    "message": "The OS version of image '{0}' is not supported."
  }
}

Este erro ocorre mais frequentemente ao implementar imagens do Windows baseadas na versão Semi-Annual Channel 1709 ou 1803, que não são suportadas. Para imagens Windows suportadas no Azure Container Instances, consulte Perguntas Frequentes.

Não foi possível obter a imagem

Se o Azure Container Instances não conseguir inicialmente transferir a sua imagem, tenta novamente durante algum tempo. Se a operação de extração de imagem continuar a falhar, o ACI acaba por falhar a implementação, e pode aparecer um Failed to pull image erro.

Para resolver este problema, elimina a instância do contentor e tenta novamente a tua implementação. Certifique-se de que a imagem existe no registo e que escreveu corretamente o nome da imagem.

Se não for possível transferir a imagem, eventos como os seguintes são apresentados na saída de az container show:

"events": [
  {
    "count": 3,
    "firstTimestamp": "2017-12-21T22:56:19+00:00",
    "lastTimestamp": "2017-12-21T22:57:00+00:00",
    "message": "pulling image \"mcr.microsoft.com/azuredocs/aci-hellowrld\"",
    "name": "Pulling",
    "type": "Normal"
  },
  {
    "count": 3,
    "firstTimestamp": "2017-12-21T22:56:19+00:00",
    "lastTimestamp": "2017-12-21T22:57:00+00:00",
    "message": "Failed to pull image \"mcr.microsoft.com/azuredocs/aci-hellowrld\": rpc error: code 2 desc Error: image t/aci-hellowrld:latest not found",
    "name": "Failed",
    "type": "Warning"
  },
  {
    "count": 3,
    "firstTimestamp": "2017-12-21T22:56:20+00:00",
    "lastTimestamp": "2017-12-21T22:57:16+00:00",
    "message": "Back-off pulling image \"mcr.microsoft.com/azuredocs/aci-hellowrld\"",
    "name": "BackOff",
    "type": "Normal"
  }
],

Erro de recurso não disponível

Devido à variação da carga regional de recursos no Azure, pode receber o seguinte erro ao tentar implementar uma instância de contentor:

The requested resource with 'x' CPU and 'y.z' GB memory is not available in the location 'example region' at this moment. Please retry with a different resource request or in another location.

Este erro indica que, devido à grande carga na região onde tenta implantar, os recursos especificados para o seu contentor não podem ser alocados nesse momento. Use um ou mais dos seguintes passos de mitigação para ajudar a resolver o seu problema.

• Verifique se as definições de implementação do seu contentor se enquadram nos parâmetros definidos na Disponibilidade de Região para Azure Container Instances
• Especifique definições mais baixas de CPU e memória para o contentor
• Implementar para uma região diferente do Azure
• Implementar mais tarde

Problemas durante a execução do grupo de contentores

O contentor tinha um reinício isolado sem intervenção explícita do utilizador

Existem duas grandes categorias para o motivo pelo qual um grupo de contentores pode reiniciar sem uma entrada explícita do utilizador. Primeiro, os contentores podem ser reiniciados devido a uma falha num processo da aplicação. O serviço ACI recomenda a aplicação de soluções de observabilidade como Application Insights SDK, métricas de grupos de contentores e registos de grupos de contentores para determinar por que razão a aplicação teve problemas. Em segundo lugar, os clientes podem sofrer reinicializações iniciadas pela infraestrutura ACI devido a eventos de manutenção. Para aumentar a disponibilidade da sua aplicação, execute múltiplos grupos de contentores atrás de um componente de entrada, como um Gateway de Aplicações ou um Gestor de Tráfego.

O contentor sai e reinicia continuamente (sem um processo prolongado)

Os grupos de contentores têm, por predefinição, uma política de reinício definida como Sempre, pelo que os contentores do grupo reiniciam sempre após concluírem a execução. Pode ser necessário alterar para OnFailure ou Never se pretende executar containers baseados em tarefas. Se especificar OnFailure e continuar a ver reinicios contínuos, pode haver um problema com a aplicação ou script executado no seu contentor.

Quando executa grupos de contentores sem processos de longa duração, poderá ver terminações e reinícios repetidos em imagens como o Ubuntu ou o Alpine. Ligar via EXEC não funciona porque o contentor não tem nenhum processo que o mantenha vivo. Para resolver este problema, inclua um comando start como o seguinte exemplo com a implementação do grupo de contentores para manter o contentor a funcionar.

## Deploying a Linux container
az container create -g MyResourceGroup --name myapp --image ubuntu --command-line "tail -f /dev/null"

## Deploying a Windows container
az container create -g myResourceGroup --name mywindowsapp --os-type Windows --image mcr.microsoft.com/windows/servercore:ltsc2019
 --command-line "ping -t localhost"

A API Container Instances e o portal Azure incluem uma restartCount propriedade. Para verificar o número de reinícios de um contentor, pode utilizar o comando az container show na CLI do Azure. No exemplo de saída seguinte, que truncámos por brevidade, pode ver a propriedade restartCount no final da saída.

...
 "events": [
   {
     "count": 1,
     "firstTimestamp": "2017-11-13T21:20:06+00:00",
     "lastTimestamp": "2017-11-13T21:20:06+00:00",
     "message": "Pulling: pulling image \"myregistry.azurecr.io/aci-tutorial-app:v1\"",
     "type": "Normal"
   },
   {
     "count": 1,
     "firstTimestamp": "2017-11-13T21:20:14+00:00",
     "lastTimestamp": "2017-11-13T21:20:14+00:00",
     "message": "Pulled: Successfully pulled image \"myregistry.azurecr.io/aci-tutorial-app:v1\"",
     "type": "Normal"
   },
   {
     "count": 1,
     "firstTimestamp": "2017-11-13T21:20:14+00:00",
     "lastTimestamp": "2017-11-13T21:20:14+00:00",
     "message": "Created: Created container with id bf25a6ac73a925687cafcec792c9e3723b0776f683d8d1402b20cc9fb5f66a10",
     "type": "Normal"
   },
   {
     "count": 1,
     "firstTimestamp": "2017-11-13T21:20:14+00:00",
     "lastTimestamp": "2017-11-13T21:20:14+00:00",
     "message": "Started: Started container with id bf25a6ac73a925687cafcec792c9e3723b0776f683d8d1402b20cc9fb5f66a10",
     "type": "Normal"
   }
 ],
 "previousState": null,
 "restartCount": 0
...
}

O contentor demora muito tempo a arrancar

Os três principais fatores que contribuem para o tempo de arranque do contentor no Azure Container Instances são:

• Tamanho da imagem
• Localização da imagem
• Imagens em cache

As imagens do Windows têm ainda mais considerações.

Tamanho da imagem

Se o teu contentor demorar muito a arrancar, mas acabar por iniciar com sucesso, começa por verificar o tamanho da imagem do teu contentor. Como o Azure Container Instances puxa a imagem do teu contentor a pedido, o tempo de arranque que vês está diretamente relacionado com o seu tamanho.

Pode ver o tamanho da imagem do seu contentor usando o docker images comando na CLI do Docker:

docker images

REPOSITORY                                    TAG       IMAGE ID        CREATED          SIZE
mcr.microsoft.com/azuredocs/aci-helloworld    latest    7367f3256b41    15 months ago    67.6MB

A chave para manter os tamanhos de imagem pequenos é garantir que a imagem final não contém nada que não seja necessário em tempo de execução. Uma forma de o fazer é com compilações em várias fases. As compilações em múltiplas fases facilitam garantir que a imagem final contém apenas os artefactos necessários para a sua aplicação, e não qualquer conteúdo extra que era necessário na compilação.

Localização da imagem

Outra forma de reduzir o impacto do pull da imagem no tempo de arranque do seu contentor é alojar a imagem do container no Azure Container Registry na mesma região onde pretende implementar instâncias de container. Isto encurta o caminho de rede que a imagem do contentor precisa de percorrer, reduzindo significativamente o tempo de download.

Imagens em cache

O Azure Container Instances utiliza um mecanismo de cache para ajudar a acelerar o tempo de arranque do contentor para imagens construídas sobre imagens base comuns do Windows, incluindo nanoserver:1809, servercore:ltsc2019, e servercore:1809. Imagens Linux comuns como ubuntu:1604 e alpine:3.6 também são armazenadas em cache. Para imagens tanto do Windows como do Linux, evite usar a latest etiqueta. Consulte as melhores práticas de tags de imagem do Container Registry para obter orientações. Para obter uma lista atualizada das imagens e tags em cache, use a API List Cached Images.

Contentores do Windows demoram a prontidão da rede

Na criação inicial, os contentores do Windows podem não ter conectividade de entrada ou saída durante até 30 segundos (ou mais, em casos raros). Se a sua aplicação container precisar de ligação à Internet, adicione lógica de atraso e de tentativa para permitir 30 segundos para estabelecer a conectividade à Internet. Após a configuração inicial, a rede de contentores deve retomar adequadamente.

Não consigo ligar-me à API Docker subjacente nem executar containers privilegiados

O Azure Container Instances não expõe acesso direto à infraestrutura subjacente que aloja grupos de contentores. Isto inclui acesso ao tempo de execução do contentor, tecnologia de orquestração e execução de operações privilegiadas no contentor. Para ver que operações a ACI suporta, consulte a documentação de referência REST. Se houver algo em falta, submete um pedido nos fóruns de feedback da ACI.

O endereço IP do grupo de contentores pode não ser acessível devido a portas desajustadas

O Azure Container Instances ainda não suporta mapeamento de portas como acontece com a configuração normal do docker. Se verificar que o endereço IP de um grupo de contentores não está acessível quando considera que o deveria estar, certifique-se de que configurou a imagem do contentor para escutar nas mesmas portas que expõe no grupo de contentores com a propriedade ports.

Se quiser confirmar que o Azure Container Instances pode escutar na porta que configurou na imagem do seu contentor, teste uma implementação da imagem aci-helloworld que expõe essa porta. Também executa a aci-helloworld aplicação para que ela escute na porta. aci-helloworld aceita uma variável PORT de ambiente opcional para sobrepor a porta padrão 80 onde ouve. Por exemplo, para testar a porta 9000, defina a variável ambiente ao criar o grupo de contentores:

1. Configure o grupo de contentores para expor a porta 9000 e passe o número da porta como valor da variável de ambiente. O exemplo está formatado para o shell Bash. Se preferir outra shell, como o PowerShell ou a Linha de Comandos, terá de ajustar a atribuição de variáveis em conformidade.

   az container create --resource-group myResourceGroup \
   --name mycontainer --image mcr.microsoft.com/azuredocs/aci-helloworld \
   --ip-address Public --ports 9000 \
   --environment-variables 'PORT'='9000'
   

2. Encontre o endereço IP do grupo de contentores na saída de comando de az container create. Procura o valor de ip.

3. Depois de o contentor ser provisionado com sucesso, navegue até ao endereço IP e à porta da aplicação container no seu navegador, por exemplo: 192.0.2.0:9000.

   Deverias ver a mensagem "Bem-vindo ao Azure Container Instances!" exibida pela aplicação web.

4. Quando terminares com o recipiente, remove-o usando o az container delete comando:

   az container delete --resource-group myResourceGroup --name mycontainer
   

Problemas durante as implementações de grupos de contentores confidenciais

Erros de política ao utilizar uma política CCE personalizada

As políticas CCE personalizadas devem ser geradas pela extensão confcom do CLI do Azure. Antes de gerar a política, certifique-se de que todas as propriedades especificadas no seu modelo ARM são válidas e correspondem ao que espera que seja representado numa política de computação confidencial. Algumas propriedades a validar incluem a imagem do contentor, variáveis de ambiente, montagens de volume e comandos do contentor.

Hash em falta na diretiva

A extensão confcom do CLI do Azure usa imagens em cache na sua máquina local que podem não corresponder às disponíveis remotamente, o que pode resultar em desajustes de camada quando a política é validada. Certifique-se de remover quaisquer imagens antigas e de transportar as imagens mais recentes dos contentores para o seu ambiente local. Depois de ter a certeza de que tem a SHA mais recente, deve regenerar a apólice CCE.

Processo/contentor terminado com código de saída: 139

Este código de saída ocorre devido a limitações com a imagem base do Ubuntu Versão 22.04. A recomendação é usar uma imagem base diferente para resolver este problema.

Códigos de saída do contentor

Quando um contentor no Azure Container Instances termina, a plataforma reporta um código de saída que indica porque é que o processo parou. Pode ver os códigos de saída consultando os eventos do contentor com o comando az container show ou no portal do Azure em Containers>Eventos.

A tabela seguinte descreve os códigos de saída comuns que poderá encontrar:

Terminações iniciadas pela plataforma (códigos de saída 7147 e 7148)

Os códigos de saída 7147 e 7148 são códigos de saída das plataformas que provêm da infraestrutura subjacente. Pode nem sempre ver estes códigos diretamente nos detalhes do contentor, mas coincidem com mensagens de "Eliminar contentor (plataforma iniciada)" que aparecem em eventos de contentores. As causas comuns das cessações efetuadas pela plataforma incluem:

• Manutenção de infraestruturas: A plataforma realocou o seu contentor como parte da manutenção rotineira ou do balanceamento de carga.
• Restrições de recursos: O hospedeiro subjacente precisava de recuperar recursos.
• Atualizações da plataforma: A infraestrutura foi atualizada, exigindo reinício dos contentores.

Estes encerramentos são expectáveis num ambiente de nuvem. Para aumentar a disponibilidade da sua aplicação, execute múltiplos grupos de contentores atrás de um componente de entrada, como um Gateway de Aplicações ou um Gestor de Tráfego.

Para mais informações sobre terminações iniciadas pela plataforma, veja Diagnosticar erros comuns de pacotes de código usando o Service Fabric.

Passos seguintes

Aprenda a recuperar registos e eventos de contentores para ajudar a depurar os seus contentores.