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 à API do 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 para o 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 Azure.<REGION_NAME> marca de serviço 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 suporte completo de UDR e Rota Expressa, 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:

• Escalar 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 de uso mais intensivo. Recomendado se suas cargas de trabalho puderem ser implantadas nos mesmos limites de rede e segurança.
  • Aumentar ambientes: recomendado se suas cargas de trabalho precisarem de limites de rede ou 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. Quando você solicitar uma alteração na cota do seu ambiente regional, também deve solicitar uma alteração correspondente na cota do ambiente global.

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

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

• Raciocínio de negócios para escala: se os limites da plataforma estão bloqueando suas demandas de carga de trabalho, é possível que você seja qualificado para uma solicitação de aumento de cota. 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 dapr são atualizadas com base no melhor esforço, com um foco forte na estabilidade, no teste completo e na minimização do impacto do cliente. O objetivo é garantir que as atualizações sejam integradas perfeitamente sem introduzir alterações significativas.

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 nos Aplicativos de Contêiner do Azure não segue um cronograma de lançamento fixo para novos recursos. Em vez disso, a versão de novas versões daPr para novas funcionalidades depende da priorização e estabilidade dos binários da 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 é aceita. Em vez disso, o ambiente é atualizado automaticamente, mantendo a integridade da oferta totalmente gerenciada e sem servidor do 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 só dá suporte a gRPC.