Solucionar problemas comuns nas Instâncias de Contêiner do Azure

Artigo
09/04/2024

Este artigo mostra como solucionar problemas ao gerenciar ou implantar contêineres para Instâncias de Contêiner do Azure. Confira também Perguntas frequentes.

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

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

Convenções de nomenclatura

Ao definir a especificação de contêiner, alguns parâmetros exigem aderência às restrições de nomenclatura. A tabela a seguir apresenta os requisitos específicos para o contêiner de propriedades do grupo. Para obter mais informações, confira as Convenções de nomenclatura no Centro de Arquitetura do Azure e as regras de nomenclatura e as restrições para recursos do Azure.

Escopo	Comprimento	Capitalização	Caracteres 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 último caractere	`<name>-<role>-container<number>`	`web-batch-container1`
Portas de contêiner	Entre 1 e 65535	Integer	Um número inteiro entre 1 e 65535	`<port-number>`	`443`
Rótulo do nome DNS	5 a 63	Não diferencia maiúsculas de minúsculas	Alfanumérico e hífen em qualquer lugar, exceto o primeiro ou último caractere	`<name>`	`frontend-site1`
Variável de ambiente	1-63	Não diferencia maiúsculas de minúsculas	Alfanumérico e sublinhado (_) em qualquer lugar, exceto o primeiro ou último caractere	`<name>`	`MY_VARIABLE`
Nome do volume	5 a 63	Minúsculas	Alfanumérico e hifens em qualquer lugar, exceto o primeiro ou o último caractere. Não pode conter dois hífenes consecutivos.	`<name>`	`batch-output-volume`

¹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.

Não há suporte para a versão do SO da imagem

Se você especificar uma imagem sem suporte das Instâncias de Contêiner do Azure, um erro OsVersionNotSupported 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 geralmente ocorre ao implantar imagens do Windows que se baseiam na versão 1709 ou 1803 do Canal Semestral, que não têm suporte. Para imagens do Windows com suporte em Instâncias de Contêiner do Azure, confira as Perguntas frequentes.

Não é possível efetuar pull da imagem

Se as Instâncias de Contêiner do Azure não puderem efetuar pull da imagem inicialmente, elas tentarão novamente durante um tempo. Se a operação de pull de imagem continuar a falhar, o ACI eventualmente falhará na implantação e um erro Failed to pull image será exibido.

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

Se não for possível efetuar pull da imagem, eventos como a seguir serã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 a diversas cargas de recursos regionais no Azure, você poderá receber o seguinte erro durante a tentativa de 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 o 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 suas configurações de implantação do contêiner caem dentro dos parâmetros definidos na Disponibilidade de região para Instâncias de Contêiner do Azure
Especificar configurações de CPU e memória inferiores para o contêiner
Implantar em uma região diferente do Azure
Implantar em um momento posterior

Problemas durante o runtime 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 o motivo pelo qual um grupo de contêineres pode ser reiniciado sem entrada explícita do usuário. Primeiro, os contêineres podem ter reinicializações causadas por uma falha no processo de aplicativo. O serviço ACI recomenda aplicar soluções de observabilidade, como SDK do Application Insights, métricas do grupo de contêineres e logs de grupo de contêineres para determinar por que houve problemas no aplicativo. Em segundo lugar, o sistema dos clientes podem passar por reinicializações iniciadas pela infraestrutura da ACI devido a eventos de manutenção. Para aumentar a disponibilidade do 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.

Contêiner sai e reinicia continuamente (sem processo de longa execução)

A política de reinicialização padrão dos grupos de contêineres é Sempre; portanto, o grupo de contêineres sempre reiniciará após ser executado até a conclusão. Talvez seja necessário alterar isso para OnFailure ou Nunca se você pretende executar contêineres baseados em tarefa. Se você especificar Em caso de Falha e ainda continuar sendo reiniciado, pode haver um problema com o aplicativo ou script executado em seu contêiner.

Ao executar grupos de contêineres sem processos de longa execução, talvez você veja saídas e reinicializações repetidos com imagens como Ubuntu ou Alpine. Conectar-se por meio de EXEC não funcionará, porque o contêiner não tem nenhum processo que o mantenha ativo. Para resolver esse problema, inclua um comando de início, como no exemplo a seguir, à sua 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 propriedade restartCount. Para verificar o número de reinícios de um contêiner, é possível usar o comando az container show na CLI do Azure. No exemplo de saída a seguir, que foi truncado apenas para facilitar a visualização, você 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
...
}

Observação

A maioria das imagens de contêiner para as distribuições de Linux definem um shell (assim como um bash) como o comando padrão. Já que um shell por si só não é um serviço de execução longa, esses contêineres saem imediatamente e entram em um loop de reinicialização quando configurados com a política de reinício padrão Sempre.

Contêiner leva muito tempo para 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
Local da imagem
Imagens armazenadas em cache

Imagens do Windows têm considerações adicionais.

Tamanho da imagem

Se o contêiner leva muito tempo para iniciar mas eventualmente tem êxito, comece observando o tamanho da sua imagem de contêiner. Como as Instâncias de Contêiner do Azure efetuam pull da imagem de contêiner sob demanda, o tempo de inicialização efetivo está diretamente relacionado ao tamanho delas.

Você pode exibir o tamanho da sua imagem de contêiner usando o comando docker images 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 sua imagem final não contenha nada que não seja necessário no runtime. Uma forma de fazer isso é com builds de vários estágios. Builds de vários estágios tornam fácil assegurar que a imagem final contenha somente os artefatos necessários para seu aplicativo, sem nenhum conteúdo extra que foi necessário no momento do build.

Local da imagem

Outra maneira de reduzir o impacto do pull da 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 em que você pretende implantar as 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 de contêiner para imagens criadas sobre imagens de base comuns do Windows, incluindo nanoserver:1809, servercore:ltsc2019 e servercore:1809. Imagens do Linux usadas com frequência, tais como ubuntu:1604 e alpine:3.6, também foram armazenadas em cache. Tanto para imagens do Windows quanto do Linux, evite usar a marca latest. Examine as Melhores práticas de marcação de imagem do Registro de Contêiner para obter diretrizes. Para obter uma lista atualizada das imagens e das marcações armazenadas em cache, use a API Listar imagens em cache.

Observação

Use as imagens com base no Windows Server 2019 nas instâncias de contêiner do Azure nesta versão prévia.

Preparação de rede lenta de contêineres do Windows

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 atraso e tente novamente a lógica para permitir que 30 segundos estabeleçam conectividade com a Internet. Após a configuração inicial, a rede de contêineres deverá de retomada apropriadamente.

Não é possível conectar à API do Docker subjacente ou executar contêineres com privilégios

As Instâncias de Contêiner do Azure não expõem acesso direto para a infraestrutura subjacente que hospeda grupos de contêineres. Isso inclui o acesso ao runtime do contêiner, à tecnologia de orquestração e à execução de operações de contêiner com privilégios. Para ver quais operações são compatíveis com a ACI, verifique a documentação de referência REST. Se faltar alguma coisa, envie uma solicitação nos Fóruns de comentários do ACI.

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

As Instâncias de Contêiner do Azure ainda não dão suporte ao mapeamento de porta como com a configuração regular do Docker. Se você perceber que o endereço IP de um grupo de contêineres não está acessível quando deveria, verifique se você configurou sua imagem de contêiner para escutar nas mesmas portas expostas em seu grupo de contêineres, usando a propriedade ports.

Se você quiser confirmar que as Instâncias de Contêiner do Azure são capazes de escutar na porta configurada em sua imagem de contêiner, teste uma implantação da imagem aci-helloworld que expõe a porta. Execute também o aplicativo aci-helloworld para que ele escute na porta. aci-helloworld aceita uma variável de ambiente opcional PORT para substituir a porta padrão 80 escutada. 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 passar o número da porta como o valor da variável de ambiente. Este exemplo é formatado para o shell do Bash. Se você preferir outro shell, como o PowerShell ou o Prompt de Comando, será necessário ajustar a atribuição de variável adequadamente.
```
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 de comando de az container create. Procure pelo 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 no navegador, por exemplo: 192.0.2.0:9000.

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

Problemas durante implantações confidenciais do grupo de contêineres

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

As políticas de CCE personalizadas devem ser geradas na extensão de configuração da CLI do Azure. Antes de gerar a política, verifique se todas as propriedades especificadas no modelo do ARM são válidas e correspondem ao que você espera representar em uma política de computação confidencial. Algumas propriedades a serem validadas incluem a imagem de 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 seu computador local, que podem não corresponder às versões disponíveis remotamente. Isso pode causar incompatibilidade de camadas durante a validação da política. Remova imagens antigas e efetue o pull das imagens de contêiner mais recentes para seu ambiente local. Depois de confirmar que possui o SHA mais recente, você deve regenerar a política de CCE.

Processo/contêiner encerrado com o código de saída: 139

Esse 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óximas etapas

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

Compartilhar via