Perguntas frequentes sobre as Instâncias de Contêiner do Azure

O tamanho máximo de uma imagem de contêiner implantável em Instâncias de Contêiner do Azure é de 15 GB. Talvez seja possível implantar imagens maiores, dependendo da disponibilidade exata no momento da implantação, mas o tamanho maior da imagem não é garantido.

O tamanho da imagem de contentor afeta o tempo necessário para a implementação, pelo que, em geral, convém manter as imagens de contentor tão pequenas quanto possível.

Como um dos principais determinantes dos tempos de implantação é o tamanho da imagem, procure maneiras de reduzir o tamanho. Remova as camadas de que não precisa ou reduza o tamanho das camadas na imagem (escolhendo uma imagem base do SO mais leve). Por exemplo, se você estiver executando contêineres Linux, considere usar o Alpine como sua imagem base em vez de um Ubuntu Server completo. Da mesma forma, para contêineres do Windows, use uma imagem base do Nano Server, se possível.

Também deve verificar a lista de imagens pré-colocadas em cache no Azure Container Images, disponível através da API Listar Imagens em Cache. Talvez seja possível substituir uma camada de imagem por uma das imagens pré-carregadas na cache.

Veja orientações mais detalhadas sobre como reduzir o tempo de inicialização do contêiner.

• Nano Server: sac2016, 10.0.14393.3568 ou mais recente
• Windows Server Core: ltsc2016, 10.0.14393.3568 ou mais recente

• Nano Server: 1809, 10.0.17763.1040 ou mais recente
• Windows Server Core: ltsc2019, 180910.0.17763.1040 ou mais recente
• Windows: 1809, 10.0.17763.1040 ou mais recente

Não. O Azure Container Instances atualmente suporta apenas imagens de contentores x64 (AMD64). Imagens de contentores ARM64 (arm64) não são suportadas para implementação em Azure Container Instances. Esta limitação também se aplica quando o Azure Container Instances é usado como fornecedor para o AKS Virtual Node (Virtual Kubelet). Se tentar implementar uma imagem apenas ARM64, o contentor pode falhar ao iniciar porque a plataforma subjacente não suporta cargas de trabalho ARM64. O suporte para ARM64 no Azure Container Instances está a ser avaliado para futuras versões, mas atualmente não há um prazo anunciado nem uma data de entrega comprometida.

Utilize a imagem mais pequena que satisfaça os seus requisitos. Para Linux, pode usar uma imagem runtime-alpine do .NET Core, que é suportada desde o lançamento do .NET Core 2.1. Para Windows, se você estiver usando o .NET Framework completo, precisará usar uma imagem do Windows Server Core (imagem somente em tempo de execução, como 4.7.2-windowsservercore-ltsc2016). As imagens apenas de execução são mais pequenas, mas não suportam cargas de trabalho que exigem o SDK do .NET.

O ACI suporta a obtenção de imagens do ACR e de outros registos de contentores não pertencentes à Microsoft, como o DockerHub, desde que o endpoint do registo esteja acessível publicamente através da Internet.

Para registos restritos à rede ou privados (registos sem IP público), apenas o Azure Container Registry (ACR) é suportado. A ACI pode extrair imagens de um endpoint ACR privado usando uma identidade gerida e uma configuração de endpoint privado. A extração de imagens de registos privados não ACR (por exemplo, um registo Docker auto-hospedado acessível apenas através de uma rede virtual) não é suportado, mesmo que a conectividade da rede virtual esteja configurada entre a ACI e o registo.

Para mais informações, consulte Implementar em rede virtual - Acesso ao registo de imagens.

1. Identifique qual imagem base do Windows você está usando no momento.

   Se você estiver extraindo diretamente do Microsoft Container Registry (MCR), esse nome de imagem será sua imagem base.

   Se estiver a trabalhar com um repositório privado, terá de consultar o seu Dockerfile para identificar a imagem de base, que estará indicada após a linha 'FROM'.

2. Selecione a nova imagem base que deseja usar no Windows Server 2019. Os exemplos a seguir mostram imagens do Windows Server 2016 comumente usadas em Instâncias de Contêiner do Azure e nossas recomendações para imagens de substituição do Windows Server 2019.

   Imagem do Windows Server 2016	Imagens recomendadas do Windows Server 2019
   mcr.microsoft.com/windows/servercore/iis	mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
   mcr.microsoft.com/windows/servercore:ltsc2016	mcr.microsoft.com/windows/servercore:ltsc2019

   Para saber mais, leia sobre descoberta de imagens.

   Nota

   Se você quiser assistência para selecionar sua nova imagem base, crie um tíquete de suporte do Azure.

3. Siga o guia prático Atualizar contentores no Azure Container Instances para atualizar o seu grupo de contentores ACI para utilizar a sua nova imagem de base.

   Se você estiver usando MCR para seu registro de contêiner, poderá passar o nome da imagem MCR diretamente para o parâmetro de imagem do grupo de contêineres.

   Se você estiver usando um registro de contêiner privado, siga as etapas em Atualizar contêineres para uma nova versão do sistema operacional Windows. Verifique se os parâmetros de registro de imagem do grupo de contêineres estão atualizados se você os alterou.

Se vir o erro "O grupo de contentores '<nome>' ainda está em processo de transição; tente novamente mais tarde", isso deve-se a uma de duas limitações de conceção da plataforma:

1. A operação de arranque foi emitida demasiado depressa depois de um contentor sair ou de uma operação de paragem ser emitida. Os sidecars do sistema precisam de alguns segundos para propagar o estado terminado. Espere pelo menos alguns segundos antes de iniciar a operação após a saída do contentor ou depois de emitir a operação de paragem.
2. Operação de início emitida após a saída de um contentor quando a política de reinício está definida para Never. Quando a política de reinício é Never, o estado parado não é propagado e uma operação de arranque subsequente falha. Para resolver este problema, emita uma operação de paragem antes da operação de início, ou use uma operação de reinício em vez disso. Uma operação de reinício reinicia o processo do contentor em vez de iniciar uma implementação totalmente nova.

Isso realmente depende da sua carga de trabalho. Comece pequeno e teste o desempenho para ver como seus contêineres funcionam. Monitore o uso de recursos de CPU e memória e, em seguida, adicione núcleos ou memória com base no tipo de processos que você implanta no contêiner.

Certifique-se também de verificar a disponibilidade de recursos para a região em que você está implantando para os limites superiores em núcleos de CPU e memória disponível por grupo de contêineres.

As Instâncias de Contêiner do Azure visam ser um serviço de contêineres sob demanda sem servidor, por isso queremos que você se concentre no desenvolvimento de seus contêineres e não se preocupe com a infraestrutura! Para aqueles que estão curiosos ou querendo fazer comparações de desempenho, o ACI é executado em conjuntos de VMs do Azure de várias SKUs, principalmente das séries F e D. Esperamos que isso mude no futuro, à medida que continuamos a desenvolver e otimizar o serviço.

Sim (às vezes). Consulte o artigo Quotas e limites para as quotas atuais e quais os limites que podem ser aumentados mediante pedido.

Consulte o artigo sobre grandes contêineres para cargas de trabalho de computação e memória intensivas. Grandes contêineres tem suporte para contagens de vCPU maiores que 4 e capacidades de memória de 16 GB, com um máximo de 32 vCPU e 256 GB por grupo de contêineres padrão e 32 vCPU e 192 GB por grupo de contêineres confidenciais.

A disponibilidade atual da região é publicada aqui. Se você tiver um requisito para uma região específica, entre em contato com o Suporte do Azure.

Atualmente, o dimensionamento não está disponível para contêineres ou grupos de contêineres. Se você precisar executar mais instâncias, use nossa API para automatizar e criar mais solicitações para a criação de grupos de contêineres para o serviço.

Você pode implantar grupos de contêineres em uma rede virtual do Azure de sua escolha e delegar IPs privados aos grupos de contêineres para rotear o tráfego dentro da rede virtual em seus recursos do Azure. Para cenários de rede e limitações com Instâncias de Contêiner do Azure, consulte Cenários e recursos de rede virtual.

Sim, o serviço ACI reserva as seguintes portas para a funcionalidade do serviço: 22, 1025-1027, 3389-3399, 9999, 19000, 19080, 19390, 19100, 20000-30000, 49152-65534. Evite usar essas portas na definição do grupo de contêineres.

Os endereços IP do grupo de contêineres estão sujeitos a alterações após serem criados ou excluídos. Recomendamos que o código do aplicativo não dependa do endereço IP do grupo de contêineres. Também sugerimos usar o NAT Gateway ou o Application Gateway se você quiser manter um endereço IP estático.

A duração do grupo de contentores é calculada a partir do momento em que começamos a extrair a imagem do seu primeiro contentor (para uma nova implementação) ou em que o seu grupo de contentor é reiniciado (se já estiver implementado) até ao momento em que paramos o grupo de contentores. Consulte os detalhes em Preços das Instâncias de Contentor.

Os medidores param de funcionar quando todo o grupo de contêineres é interrompido. Enquanto um contêiner em seu grupo de contêineres estiver em execução, manteremos os recursos caso você queira iniciá-los novamente.

Computação confidencial é um termo da indústria definido pelo Confidential Computing Consortium (CCC) - uma fundação dedicada a definir e acelerar a adoção de computação confidencial. O CCC define computação confidencial como: A proteção de dados em uso através da realização de cálculos em um ambiente de execução confiável (TEE) baseado em hardware. Os Contêineres Confidenciais ACI introduzem proteção baseada em hardware, integridade de código e verificação do Ambiente de Execução Confiável (TEE). Os contêineres confidenciais aplicam o que há de mais recente em hardware de computação confidencial, permitindo que os clientes implantem seus aplicativos existentes sem modificações, aproveitando a proteção de dados baseada em hardware. A integridade do código e a verificação do TEE são alcançadas por meio do atestado de uma política de aplicação de computação confidencial, que é anexada ao grupo de contêineres no momento da implantação. Se alguma das propriedades do grupo de contentores diferir das da política de imposição da computação confidencial, o ambiente não consegue iniciar, garantindo assim que o TEE não é comprometido.

Os contêineres confidenciais podem ser usados para uma ampla variedade de cargas de trabalho elásticas, mas são especialmente adequados para cargas de trabalho que exigem fortes garantias de proteção de dados. Alguns exemplos dessas cargas de trabalho incluem cargas de trabalho de aprendizado de máquina que utilizam conjuntos de dados que incluem dados pessoais ou com algoritmos que são considerados propriedade intelectual. Os clientes do setor de saúde podem usá-lo para analisar dados de pacientes e pesquisar. Os clientes de serviços financeiros podem usá-lo para análise de crédito, cálculo de risco e balanceamento de carteira.

As políticas de imposição da computação confidencial podem ser geradas utilizando a extensão confcom com a CLI do Azure. Para obter mais informações, consulte a extensão confcom.

As implementações de contentores ACI baseadas em GPU e os contentores Windows não são suportadas com contentores confidenciais.

A disponibilidade atual da região para contêineres confidenciais é publicada aqui.

Os contêineres confidenciais nas Instâncias de Contêiner do Azure têm um custo adicional em comparação com os grupos de contêineres de SKU padrão. Para obter mais informações, consulte a página de preços.

Os contêineres ACI Spot são um novo recurso que permite que os clientes executem cargas de trabalho interruptíveis e conteinerizadas em capacidade do Azure não utilizada a preços com até 70% de desconto em comparação com contêineres ACI de prioridade regular.

Os contentores Spot do ACI podem ser interrompidos quando o Azure não tem capacidade excedentária disponível suficiente, e os clientes são cobrados pela utilização de memória e de núcleos por segundo. Com os ACI Spot Containers, agora você pode executar suas cargas de trabalho conteinerizadas, como processamento em lote, simulações de Monte Carlo, cargas de trabalho de desenvolvimento/teste e cargas de trabalho offline paralelizáveis que podem tolerar interrupções no Azure a uma fração do custo dos preços tradicionais da ACI. Esta oferta destina-se a clientes que desejam executar cargas de trabalho interruptíveis sem requisitos estritos de disponibilidade.

As implantações de contentores ACI baseadas em GPU, as zonas de disponibilidade, o suporte para implantações de ACI com IP público e as implantações de ACI numa rede virtual personalizada com IP privado não são suportados com contentores Spot.

Todos os clientes recebem uma cota padrão de 10 núcleos vCPU e 10 grupos de contêineres.

Os clientes podem enviar uma solicitação de suporte para aumentar a capacidade dos contêineres Spot selecionando o tipo de problema como "Serviços e limites de assinatura (cotas)" e o novo tipo de cota como "StandardSpotCores" adicionado para a oferta de contêineres ACI Spot quando você for solicitado a preencher os detalhes solicitados.

Os contentores Spot das Instâncias de Contentor do Azure (ACI) só estão disponíveis em regiões selecionadas durante a Pré-visualização Pública. Consulte Disponibilidade de recursos e regiões para obter mais informações.

Os contentores ACI Spot são oferecidos a um preço com desconto e oferecem até 70% de desconto para além dos contentores ACI prioritários regulares. Os descontos variariam por mês em cada região. Para obter mais informações, consulte a página de preços.

Próximos passos

• Saiba mais sobre as Instâncias de Contêiner do Azure.
• Solucione problemas comuns em Instâncias de Contêiner do Azure.