Resolver problemas comuns no Azure Container Instances

Este artigo mostra como resolver problemas comuns de gestão ou implementação de contentores em Azure Container Instances. Veja também Perguntas mais frequentes.

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

Problemas durante a implementação do grupo de contentores

Convenções de nomenclatura

Ao definir a especificação do contentor, determinados parâmetros requerem a adesão às restrições de nomenclatura. Segue-se uma tabela com requisitos específicos para as propriedades do grupo de contentores. Para obter mais informações, veja Convenções de nomenclatura no Centro de Arquitetura do Azure e Regras de nomenclatura e restrições para recursos do Azure.

Âmbito Comprimento Maiúsculas e Minúsculas Carateres válidos Padrão sugerido Exemplo
Nome do contentor1 1-63 Minúsculas Alfanumérico e hífen em qualquer lugar, exceto o primeiro ou último caráter <name>-<role>-container<number> web-batch-container1
Portas de contentor Entre 1 e 65535 Número inteiro Número inteiro entre 1 e 65535 <port-number> 443
Etiqueta de nome DNS 5-63 Não sensível a maiúsculas e minúsculas Alfanumérico e hífen em qualquer lugar, exceto o primeiro ou último caráter <name> frontend-site1
Variável de ambiente 1-63 Não sensível a maiúsculas e minúsculas Alfanumérico e caráter de sublinhado (_) em qualquer lugar, exceto o primeiro ou último caráter <name> MY_VARIABLE
Nome do volume 5-63 Minúsculas Alfanumérico e hífenes em qualquer lugar, exceto o primeiro ou último caráter. Não é possível conter dois hífenes consecutivos. <name> batch-output-volume

1 Restrição também para nomes de grupos de contentores quando não especificados independentemente das instâncias de contentor, por exemplo, com az container create implementações de comandos.

Versão do SO da imagem não suportada

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

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

Este erro é encontrado com mais frequência ao implementar imagens do Windows baseadas no Semi-Annual versão 1709 ou 1803 do Canal, que não são suportadas. Para obter imagens suportadas do Windows no Azure Container Instances, consulte Perguntas mais frequentes.

Não é possível extrair a imagem

Se Azure Container Instances inicialmente não conseguir extrair a sua imagem, tentará novamente durante o tempo. Se a operação de solicitação de imagens continuar a falhar, o ACI irá eventualmente falhar na implementação e poderá ver um Failed to pull image erro.

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

Se a imagem não puder ser extraída, os 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 à carga de recursos regional variável no Azure, poderá 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 à carga pesada na região em que está a tentar implementar, os recursos especificados para o contentor não podem ser alocados nessa altura. Utilize um ou mais dos seguintes passos de mitigação para ajudar a resolver o problema.

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

Problemas durante o runtime do grupo de contentores

O contentor teve um reinício isolado sem introdução explícita do utilizador

Existem duas categorias abrangentes para o motivo pelo qual um grupo de contentores pode ser reiniciado sem introdução explícita do utilizador. Primeiro, os contentores podem sofrer reinícios causados por uma falha no processo de aplicação. O serviço ACI recomenda a aplicação de soluções de observabilidade, como o SDK do Application Insights, as métricas do grupo de contentores e os registos de grupos de contentores para determinar por que motivo a aplicação teve problemas. Em segundo lugar, os clientes podem experimentar reinícios iniciados pela infraestrutura do ACI devido a eventos de manutenção. Para aumentar a disponibilidade da sua aplicação, execute vários grupos de contentores por trás de um componente de entrada, como um Gateway de Aplicação ou o Gestor de Tráfego.

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

Os grupos de contentores são predefinidos para uma política de reinício do Always, pelo que os contentores no grupo de contentores reiniciam sempre depois de serem executados até à conclusão. Poderá ter de alterar esta opção para OnFailure ou Nunca se pretender executar contentores baseados em tarefas. Se especificar OnFailure e continuar a ver reinícios contínuos, poderá existir um problema com a aplicação ou o script executado no contentor.

Ao executar grupos de contentores sem processos de execução prolongada, poderá ver saídas repetidas e reinícios com imagens como o Ubuntu ou o Alpine. A ligação através do EXEC não funcionará, uma vez que o contentor não tem qualquer processo para mantê-lo vivo. Para resolver este problema, inclua um comando de início como o seguinte com a implementação do grupo de contentores para manter o contentor 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 Container Instances e portal do 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 seguinte exemplo de saída (que foi truncado por brevidade), pode ver a restartCount propriedade no final do resultado.

...
 "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 contentor para distribuições do Linux define uma shell, como o bash, como o comando predefinido. Uma vez que uma shell por si só não é um serviço de execução prolongada, estes contentores saem imediatamente e entram num ciclo de reinício quando configurados com a política de reinício sempre predefinida.

O contentor demora muito tempo a iniciar

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

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

Tamanho da imagem

Se o contentor demorar muito tempo a começar, mas eventualmente for bem-sucedido, comece por observar o tamanho da sua imagem de contentor. Uma vez que Azure Container Instances solicita a sua imagem de contentor a pedido, o tempo de arranque que vê está diretamente relacionado com o respetivo tamanho.

Pode ver o tamanho da sua imagem de contentor com 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 sua imagem final não contém nada que não seja necessário no runtime. Uma forma de o fazer é com compilações em várias fases. As compilações em várias fases facilitam a garantia de que a imagem final contém apenas os artefactos de que precisa para a sua aplicação e não nenhum dos conteúdos adicionais necessários no momento da compilação.

Localização da imagem

Outra forma de reduzir o impacto da solicitação da imagem no tempo de arranque do contentor é alojar a imagem de contentor no Azure Container Registry na mesma região onde pretende implementar instâncias de contentor. Esta ação abrevia o caminho de rede que a imagem de contentor precisa de percorrer, encurtando significativamente o tempo de transferência.

Imagens em cache

Azure Container Instances utiliza um mecanismo de colocação em cache para ajudar a acelerar o tempo de arranque do contentor para imagens criadas em imagens de base comuns do Windows, incluindo nanoserver:1809, servercore:ltsc2019e servercore:1809. As imagens do Linux utilizadas frequentemente, como ubuntu:1604 e alpine:3.6 também são colocadas em cache. Para imagens do Windows e do Linux, evite utilizar a latest etiqueta. Veja as melhores práticas de etiqueta de imagem do Container Registry para obter orientações. Para obter uma lista atualizada de imagens e etiquetas em cache, utilize a API De Imagens em Cache de Lista .

Nota

A utilização de imagens baseadas no Windows Server 2019 no Azure Container Instances está em pré-visualização.

Preparação lenta da rede dos contentores do Windows

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

Não é possível ligar à API do Docker subjacente ou executar contentores com privilégios

Azure Container Instances não expõe o acesso direto à infraestrutura subjacente que aloja grupos de contentores. Isto inclui o acesso ao runtime de contentor, tecnologia de orquestração e execução de operações de contentores com privilégios. Para ver que operações são suportadas pelo ACI, consulte a documentação de referência REST. Se houver algo em falta, submeta um pedido nos fóruns de comentários do ACI.

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

Azure Container Instances ainda não suporta o mapeamento de portas, como com a configuração normal do docker. Se achar que o endereço IP de um grupo de contentores não está acessível quando acredita que o deve ser, certifique-se de que configurou a sua imagem de contentor para ouvir as mesmas portas que expõe no grupo de contentores com a ports propriedade .

Se quiser confirmar que Azure Container Instances pode escutar na porta que configurou na sua imagem de contentor, teste uma implementação da aci-helloworld imagem que expõe a porta. Execute também a aplicação aci-helloworld para que esta oiça na porta. aci-helloworld aceita uma variável PORT de ambiente opcional para substituir a porta predefinida 80 que escuta. Por exemplo, para testar a porta 9000, defina a variável de ambiente quando criar o grupo de contentores:

  1. Configure o grupo de contentores para expor a porta 9000 e transmita o número da porta como o valor da variável de ambiente. O exemplo está formatado para a shell do 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. Localize o endereço IP do grupo de contentores na saída do comando de az container create. Procure o valor de IP.

  3. Depois de o contentor ser aprovisionado com êxito, navegue para o endereço IP e a porta da aplicação de contentor no browser, por exemplo: 192.0.2.0:9000.

    Deverá ver a mensagem "Bem-vindo ao Azure Container Instances!" apresentada pela aplicação Web.

  4. Quando terminar o contentor, remova-o com o az container delete comando:

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

Problemas durante implementações confidenciais de grupos de contentores

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

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

Hash em falta na política

A extensão confcom da CLI do Azure utilizará imagens em cache no seu computador local que podem não corresponder às que estão disponíveis remotamente, o que pode resultar num erro de correspondência de camadas quando a política é validada. Certifique-se de que remove quaisquer imagens antigas e solicita as imagens de contentor mais recentes para o seu ambiente local. Assim que tiver a certeza de que tem a SHA mais recente, deve regenerar a política 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 da Versão 22.04 do Ubuntu. A recomendação é utilizar uma imagem de base diferente para resolver este problema.

Passos seguintes

Saiba como obter registos de contentores e eventos para ajudar a depurar os contentores.