Perguntas frequentes sobre os Aplicativos de Contêiner do Azure

Uma lista pode ser gerada executando o seguinte comando da CLI do Azure:

  az provider show \
  --namespace Microsoft.App \
  --query "resourceTypes[?resourceType=='managedEnvironments'].locations"

Não, os Aplicativos de Contêiner do Azure não fornecem acesso direto às APIs Kubernetes.

Sim, você pode importar uma API de Aplicativos de Contêiner do Azure do contexto do Gerenciamento de API.

A cobrança é baseada no consumo de recursos, incluindo CPU, memória e contagem de solicitações. Para obter mais informações, consulte a página de cobrança .

Sim. Você pode configurar o GitHub Actions usando a CLI do Azure ou o portal do Azure:

• Usando a CLI do Azure, execute az containerapp github-action -h para ver as opções.

• Usando o portal do Azure, vá para a janela "Implantação contínua" em seu aplicativo de contêiner.

Os Aplicativos de Contêiner do Azure decodificam a URL para proteger seu aplicativo contra ataques de confusão de URL. Uma URL de solicitação que contém partes codificadas, como http://mysite.com/archive/http%3A%2F%2Fmysite.com%2Farchive%2F123, é enviada ao seu aplicativo como http://mysite.com/archive/http%3A/mysite.com/archive/123.

Ambientes somente consumo têm suporte limitado para UDRs (rotas definidas pelo usuário). Não há suporte para o ExpressRoute. O suporte limitado à UDR está disponível quando configurado da seguinte maneira:

• Uma rota deve ser definida usando a marca de serviço Azure.<REGION_NAME> com o Próximo Salto = "Internet".

• As regras do NSG (grupo de segurança de rede) também devem ser configuradas conforme descrito na documentação do NSG para garantir que o ambiente funcione corretamente.

Essas limitações não se aplicam a perfis de carga de trabalho e, para obter suporte completo a UDR e Express Route, use ambientes de perfil de carga de trabalho.

Os Aplicativos de Contêiner do Azure não movem nem armazenam dados do cliente para fora da região implantada.

Solicite um aumento de cota no portal do Azure com os Aplicativos de Contêiner do Azure selecionados como o provedor.

Considere os seguintes detalhes ao enviar uma solicitação de aumento de cota:

• Dimensionamento de aplicativos versus ambientes: há várias cotas diferentes disponíveis para aumentar. Use estas descrições para ajudar a identificar suas necessidades:

  • Aumentar aplicativos e núcleos por ambiente: permite executar mais aplicativos em um ambiente e/ou aplicativos que exigem mais recursos do sistema. Recomendado se suas cargas de trabalho puderem ser implantadas nos mesmos limites de rede e segurança.
  • Aumentando os ambientes: recomendado se suas cargas de trabalho precisarem de limites de rede ou de segurança. Observação: pode ser necessário fornecer contexto de negócios adicional caso sua solicitação envolva o aumento de cotas em nível de ambiente. Ao solicitar uma alteração na sua quota de ambiente regional, você deve solicitar uma alteração correspondente na sua quota de ambiente global.

• Regiões: as aprovações de solicitações de aumento de capacidade variam de acordo com a capacidade de computação disponível nas regiões do Azure.

• Requisitos específicos de computação: a plataforma suporta 4 GB por aplicativo contêiner. As substituições de limites de memória são avaliadas caso a caso.

• Raciocínio empresarial para escalonamento: você pode ser elegível para uma solicitação de aumento de cota se os limites da plataforma estiverem bloqueando suas demandas de carga de trabalho. As substituições de limites de escala são avaliadas caso a caso.

Cada funcionalidade da Dapr passa por uma avaliação completa para garantir que ela impacte positivamente os clientes que executam microsserviços no ambiente de Aplicativos de Contêiner do Azure, proporcionando a melhor experiência possível.

A disponibilidade das APIs alfa da Dapr não é garantida ou com suporte da Microsoft.

Embora os componentes da Camada 1 sejam totalmente suportados, os componentes da Camada 2 são suportados com o melhor esforço. Saiba mais.

Você pode enviar uma solicitação de recurso por meio do repositório GitHub dos Aplicativos de Contêiner do Azure. Inclua "Dapr" no título da solicitação de recurso.

Enquanto 1.13.6-msft.1 é distribuído entre as regiões de produção, ainda é possível observar versões anteriores (como 1.12.5 ou 1.12.5-msft.6). O sufixo -msft.<number> indica as personalizações específicas feitas para os Aplicativos de Contêiner do Azure com o objetivo de melhorar sua experiência.

As versões do Dapr são atualizadas da melhor forma possível, com forte foco em estabilidade, testes rigorosos e minimização do impacto para o cliente. O objetivo é garantir que as atualizações sejam integradas perfeitamente, sem introduzir alterações que quebrem a compatibilidade.

Como as atualizações de versão do Dapr são aplicadas automaticamente, você sempre se beneficia da versão mais segura. No entanto, o Dapr no Azure Container Apps não segue um cronograma de lançamento fixo para novos recursos. Em vez disso, o lançamento de novas versões do Dapr para novas funcionalidades depende da priorização e da estabilidade dos binários do Dapr.

Encontre atualizações e comunicados de versão para Dapr nos Aplicativos de Contêiner do Azure no GitHub.

A seleção de versões personalizadas não é suportada. Em vez disso, seu ambiente é atualizado automaticamente, mantendo a integridade da oferta totalmente gerenciada e sem servidor da Dapr nos Aplicativos de Contêiner do Azure. Você pode controlar as atualizações automáticas configurando o recurso de manutenção planejada em seu ambiente de aplicativos conteinerizados.

Uma implantação sem Docker permite implantar seu aplicativo sem definir um Dockerfile em seu código. Em vez disso, a funcionalidade de build de nuvem dos Aplicativos de Contêiner usa Buildpacks para transformar o código-fonte em seu computador local em uma imagem de contêiner. Esta opção usa o registro padrão dos Aplicativos de Contêiner do Azure.

Você está enfrentando um problema conhecido com implantações sem Docker. Tentar novamente pode resolver esse problema para você. Se você encontrar esse problema, abra um problema do GitHub para que nossa equipe possa investigar.

Você precisa habilitar a proteção de dados para todos os aplicativos .NET nos Aplicativos de Contêiner do Azure. Consulte Implantação e dimensionamento de um aplicativo ASP.NET Core nos Aplicativos de Contêiner do Azure para obter detalhes.

Os Aplicativos de Contêiner dão suporte a quatro versões do JDK do LTS: JDK 8, JDK 11, JDK 17 e JDK 21. Para o build de código-fonte, a versão padrão é o JDK 17. Para um build de arquivo JAR, a versão do JDK é lida do local do arquivo META-INF\MANIFEST. MF no JAR, mas usa o JDK padrão versão 17 se a versão especificada não estiver disponível.

Você pode configurar a versão do JDK para substituir a versão padrão por meio de variáveis de ambiente de build.

Atualmente, os Aplicativos de Contêiner do Azure dão suporte ao Apache Maven como a ferramenta de build do Java.

Você pode personalizar um build de imagem Java por meio de variáveis de ambiente de build.

Ao usar containerapp up em combinação com uma base de código sem Docker, use o parâmetro --location para que o aplicativo seja executado em um local diferente do Leste dos EUA.

Evite usar marcas estáticas, como latest para imagens de contêiner. O uso de marcas estáticas pode levar a problemas de cache e pode dificultar a solução de problemas do aplicativo. Em vez disso, use marcas exclusivas para cada implantação, como um hash do Git ou data e hora para garantir que as atualizações sejam controladas e implantadas corretamente.

O agente gerenciado suporta apenas gRPC.