Resolução de problemas comuns nas Instâncias de Contentor do Azure

Artigo
08/29/2024

Este artigo mostra como solucionar problemas comuns de gerenciamento ou implantação de contêineres em Instâncias de Contêiner do Azure. Consulte também Perguntas frequentes.

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

Problemas durante a implantação do grupo de contêineres

Convenções de nomenclatura

Quando você define sua especificação de contêiner, certos parâmetros exigem a adesão às restrições de nomenclatura. A tabela a seguir mostra os requisitos específicos para as propriedades do grupo de contêineres. Para obter mais informações, consulte Convenções de nomenclatura na Central de Arquitetura do Azure e Regras e restrições de nomenclatura para recursos do Azure.

Âmbito	Duração	Maiúsculas e Minúsculas	Carateres válidos	Padrão sugerido	Exemplo
Nome do contêiner¹	1-63	Minúsculas	Alfanumérico e hífen em qualquer lugar, exceto o primeiro ou o último caractere	`<name>-<role>-container<number>`	`web-batch-container1`
Portos de contentores	Entre 1 e 65535	Número inteiro	Inteiro entre 1 e 65535	`<port-number>`	`443`
Etiqueta de nome DNS	5-63	Não sensível às maiúsculas e minúsculas	Alfanumérico e hífen em qualquer lugar, exceto o primeiro ou o último caractere	`<name>`	`frontend-site1`
Variável de ambiente	1-63	Não sensível às maiúsculas e minúsculas	Alfanumérico e sublinhado (_) em qualquer lugar, exceto o primeiro ou o último caractere	`<name>`	`MY_VARIABLE`
Nome do volume	5-63	Minúsculas	Alfanumérico e hífenes em qualquer lugar, exceto no primeiro ou no último caractere. Não pode conter duas hífenes consecutivas.	`<name>`	`batch-output-volume`

1 Restrição também para nomes de grupos de contêineres quando não especificados independentemente de instâncias de contêiner, por exemplo, com az container create implantações de comando.

Versão do SO da imagem não suportada

Se você especificar uma imagem que as Instâncias de Contêiner do Azure não suportam, um OsVersionNotSupported erro será retornado. O erro é semelhante ao seguinte, onde {0} é o nome da imagem que você tentou implantar:

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

Esse erro é encontrado com mais freqüência ao implantar imagens do Windows baseadas na versão 1709 ou 1803 do Canal Semestral, que não são suportadas. Para obter imagens do Windows com suporte em Instâncias de Contêiner do Azure, consulte Perguntas frequentes.

Não é possível solicitar a imagem

Se as Instâncias de Contêiner do Azure não conseguirem extrair sua imagem inicialmente, ela tentará novamente por tempo. Se a operação de pull de imagem continuar a falhar, o ACI eventualmente falhará na implantação e você poderá ver um Failed to pull image erro.

Para resolver esse problema, exclua a instância do contêiner e tente novamente a implantação. Verifique se a imagem existe no registro e se você digitou o nome da imagem corretamente.

Se a imagem não puder ser extraída, eventos como os seguintes são mostrados na saída do 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 de recursos regionais no Azure, você pode receber o seguinte erro ao tentar implantar uma instância de contêiner:

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.

Esse erro indica que, devido à carga pesada na região em que você tenta implantar, os recursos especificados para seu contêiner não podem ser alocados naquele momento. Use uma ou mais das seguintes etapas de mitigação para ajudar a resolver o problema.

Verifique se as configurações de implantação de contêiner estão dentro dos parâmetros definidos em Disponibilidade de região para instâncias de contêiner do Azure
Especificar configurações mais baixas de CPU e memória para o contêiner
Implantar em uma região diferente do Azure
Implantar posteriormente

Problemas durante o tempo de execução do grupo de contêineres

O contêiner teve uma reinicialização isolada sem entrada explícita do usuário

Há duas categorias amplas para explicar por que um grupo de contêineres pode reiniciar sem entrada explícita do usuário. Primeiro, os contêineres podem sofrer reinicializações causadas por uma falha no processo do aplicativo. O serviço ACI recomenda a aplicação de soluções de observabilidade, como SDK do Application Insights, métricas de grupo de contêineres e logs de grupos de contêineres para determinar por que o aplicativo enfrentou problemas. Em segundo lugar, os clientes podem experimentar reinicializações iniciadas pela infraestrutura ACI devido a eventos de manutenção. Para aumentar a disponibilidade do seu aplicativo, execute vários grupos de contêineres atrás de um componente de entrada, como um Gateway de Aplicativo ou Gerenciador de Tráfego.

O contentor é desligado e reiniciado continuamente (sem processo de longa duração)

Os grupos de contêineres usam como padrão uma política de reinicialização de Sempre, portanto, os contêineres no grupo de contêineres sempre são reiniciados após serem executados até a conclusão. Talvez seja necessário alterar isso para OnFailure ou Never se você pretende executar contêineres baseados em tarefas. Se você especificar OnFailure e ainda vir reinicializações contínuas, pode haver um problema com o aplicativo ou script executado em seu contêiner.

Quando você executa grupos de contêineres sem processos de longa execução, você pode ver saídas repetidas e reinicializações com imagens como Ubuntu ou Alpine. A conexão via EXEC não funcionará, pois o contêiner não tem nenhum processo para mantê-lo vivo. Para resolver esse problema, inclua um comando start como o exemplo a seguir com a implantação do grupo de contêineres para manter o contêiner em execução.

## 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 de Instâncias de Contêiner e o portal do Azure incluem uma restartCount propriedade. Para verificar o número de reinicializações de um contêiner, você pode usar o comando az container show na CLI do Azure. No exemplo de saída a seguir, que truncamos para brevidade, você vê a restartCount propriedade 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
...
}

Nota

A maioria das imagens de contêiner para distribuições Linux define um shell, como bash, como o comando padrão. Como um shell por si só não é um serviço de longa execução, esses contêineres saem imediatamente e caem em um loop de reinicialização quando configurados com a política padrão Always restart.

O contentor demora muito tempo a iniciar

Os três principais fatores que contribuem para o tempo de inicialização do contêiner nas Instâncias de Contêiner do Azure são:

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

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

Tamanho da imagem

Se o contêiner demorar muito tempo para começar, mas eventualmente for bem-sucedido, comece observando o tamanho da imagem do contêiner. Como as Instâncias de Contêiner do Azure extraem sua imagem de contêiner sob demanda, o tempo de inicialização exibido está diretamente relacionado ao seu tamanho.

Você pode exibir o tamanho da imagem do contêiner usando o comando na CLI docker images 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 sua imagem final não contenha nada que não seja necessário em tempo de execução. Uma maneira de fazer isso é com compilações de vários estágios. As compilações de vários estágios facilitam a garantia de que a imagem final contenha apenas os artefatos necessários para seu aplicativo, e não qualquer conteúdo extra que era necessário no momento da compilação.

Localização da imagem

Outra maneira de reduzir o impacto da extração de imagem no tempo de inicialização do contêiner é hospedar a imagem de contêiner no Registro de Contêiner do Azure na mesma região onde você pretende implantar instâncias de contêiner. Isso reduz o caminho de rede que a imagem de contêiner precisa percorrer, reduzindo significativamente o tempo de download.

Imagens armazenadas em cache

As Instâncias de Contêiner do Azure usam um mecanismo de cache para ajudar a acelerar o tempo de inicialização do contêiner para imagens criadas em imagens base comuns do Windows, incluindo nanoserver:1809, servercore:ltsc2019e servercore:1809. Imagens Linux comumente usadas, como ubuntu:1604 e alpine:3.6 também são armazenadas em cache. Para imagens Windows e Linux, evite usar a latest tag . Analise as práticas recomendadas da marca Image do Container Registry para obter orientação. Para obter uma lista atualizada de imagens e tags armazenadas em cache, use a API Listar imagens em cache.

Nota

O uso de imagens baseadas no Windows Server 2019 em Instâncias de Contêiner do Azure está em visualização.

Os contêineres do Windows diminuem a prontidão da rede

Na criação inicial, os contêineres do Windows podem não ter conectividade de entrada ou saída por até 30 segundos (ou mais, em casos raros). Se o aplicativo contêiner precisar de uma conexão com a Internet, adicione a lógica de atraso e repetição para permitir 30 segundos para estabelecer conectividade com a Internet. Após a configuração inicial, a rede de contêineres deve ser retomada adequadamente.

Não é possível conectar-se à API subjacente do Docker ou executar contêineres privilegiados

As Instâncias de Contêiner do Azure não expõem o acesso direto à infraestrutura subjacente que hospeda grupos de contêineres. Isso inclui acesso ao tempo de execução do contêiner, tecnologia de orquestração e execução de operações de contêiner privilegiadas. Para ver quais operações o ACI suporta, consulte a documentação de referência REST. Se faltar alguma coisa, envie uma solicitação nos fóruns de feedback do ACI.

O endereço IP do grupo de contentores pode não estar acessível devido a portas incompatíveis

As Instâncias de Contêiner do Azure ainda não oferecem suporte ao mapeamento de portas, como na configuração regular do docker. Se você achar que o endereço IP de um grupo de contêineres não está acessível quando você acredita que deveria estar, certifique-se de configurar sua imagem de contêiner para ouvir as mesmas portas que você expõe em seu grupo de contêineres com a ports propriedade.

Se você quiser confirmar se as Instâncias de Contêiner do Azure podem escutar na porta que você configurou na imagem do contêiner, teste uma implantação da aci-helloworld imagem que expõe a porta. Execute também o aci-helloworld aplicativo para que ele ouça na porta. aci-helloworld aceita uma variável PORT de ambiente opcional para substituir a porta padrão 80 em que escuta. Por exemplo, para testar a porta 9000, defina a variável de ambiente ao criar o grupo de contêineres:

Configure o grupo de contêineres para expor a porta 9000 e passe o número da porta como o valor da variável de ambiente. O exemplo é formatado para o shell Bash. Se preferir outro shell, como PowerShell ou Prompt de Comando, será necessário ajustar a atribuição de variáveis de acordo.
```
az container create --resource-group myResourceGroup \
--name mycontainer --image mcr.microsoft.com/azuredocs/aci-helloworld \
--ip-address Public --ports 9000 \
--environment-variables 'PORT'='9000'
```
Localize o endereço IP do grupo de contêineres na saída do az container createcomando . Procure o valor de ip.
Depois que o contêiner for provisionado com êxito, navegue até o endereço IP e a porta do aplicativo de contêiner em seu navegador, por exemplo: 192.0.2.0:9000.

Você verá a mensagem "Bem-vindo às instâncias de contêiner do Azure!" exibida pelo aplicativo Web.
Quando terminar de usar o contêiner, remova-o usando o az container delete comando:
```
az container delete --resource-group myResourceGroup --name mycontainer
```

Problemas durante implantações de grupos de contêineres confidenciais

Erros de política ao usar a política CCE personalizada

As políticas de CCE personalizadas devem ser geradas na extensão confcom da CLI do Azure. Antes de gerar a política, verifique se todas as propriedades especificadas no seu modelo ARM são válidas e correspondem ao que você espera que seja representado em uma política de computação confidencial. Algumas propriedades a serem validadas incluem a imagem do contêiner, variáveis de ambiente, montagens de volume e comandos de contêiner.

Hash ausente da política

A extensão confcom da CLI do Azure usa imagens armazenadas em cache em sua máquina local que podem não corresponder àquelas que estão disponíveis remotamente, o que pode resultar em incompatibilidade de camada quando a política é validada. Certifique-se de remover todas as imagens antigas e extrair as imagens de contêiner mais recentes para seu ambiente local. Depois de ter certeza de que tem o SHA mais recente, você deve regenerar a política de 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 esse problema.

Próximos passos

Saiba como recuperar logs e eventos de contêiner para ajudar a depurar seus contêineres.

Partilhar via