Forum aux questions (FAQ) sur Azure Container Apps

Vous pouvez générer une liste en exécutant la commande Azure CLI suivante :

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

Non, il n’existe aucun accès à l’API Kubernetes.

Oui.

Pour plus d’informations, consultez la page de facturation.

Oui. À l’aide de l’interface de ligne de commande Azure, exécutez az containerapp github-action -h pour afficher les options. Depuis le Portail Azure, accédez à la fenêtre « Déploiement continu » sous votre application conteneur.

Azure Container Apps décode l’URL pour protéger votre application contre les attaques par confusion d’URL. Une URL de requête qui a des parties encodées, comme http://mysite.com/archive/http%3A%2F%2Fmysite.com%2Farchive%2F123, est envoyée à votre application en tant que http://mysite.com/archive/http%3A/mysite.com/archive/123.

Pour les environnements Consommation uniquement, les itinéraires express ne sont pas pris en charge, et les itinéraires définis par l’utilisateur (UDR) limités sont pris en charge lorsqu’ils sont configurés de la manière suivante. La configuration UDR doit avoir un itinéraire configuré pour la balise Azure.<REGION_NAME> de service avec Next Hop = « Internet ». En outre, les règles de la documentation groupe de sécurité réseau (NSG) doivent être configurées pour que seul l’environnement Consommation soit opérationnel. Ces limitations ne s’appliquent pas aux profils de charge de travail, et pour une prise en charge complète de l’UDR et d’Express Route, il convient d’utiliser des environnements de profil de charge de travail.

Azure Container Apps ne déplace pas ou ne stocke pas les données client hors de la région déployée.

Demander une augmentation du quota dans le portail Azure avec Azure Container Apps sélectionné en tant que fournisseur.

Gardez à l’esprit les points suivants concernant les demandes d’augmentation de quota :

• Mise à l’échelle des applications et des environnements : il existe de nombreux quotas différents pouvant être augmentés. Utilisez ces descriptions pour identifier vos besoins :

  • Augmenter les applications et les cœurs par environnement : vous permet d’exécuter davantage d’applications au sein d’un environnement et/ou des applications plus gourmandes en ressources. Recommandé si vos charges de travail peuvent être déployées dans les mêmes limites de réseau et de sécurité.
  • Augmentation des environnements : recommandé si vos charges de travail ont besoin de limites de sécurité ou de réseau. Remarque : un contexte métier détaillé peut être nécessaire si votre requête implique l’augmentation de quotas au niveau de l’environnement. Lorsque vous demandez une modification de votre quota d’environnement régional, vous devez demander une modification correspondante de votre quota d’environnement global.

• Régions : les approbations des demandes d’augmentation varient en fonction de la capacité de calcul disponible dans les régions Azure.

• Exigences de calcul spécifiques : la plateforme prend en charge 4 Go par application conteneur. Les remplacements des limites de mémoire sont évalués au cas par cas.

• Raisonnement métier pour la mise à l’échelle : vous pourriez être éligible à une requête d’augmentation de quota si les limites de la plateforme bloquent vos demandes de charge de travail. Les remplacements des limites d’échelle sont évalués au cas par cas.

Chaque fonctionnalité Dapr subit une évaluation approfondie pour s’assurer qu’elle a un impact positif sur les clients exécutant des microservices dans l’environnement Azure Container Apps, tout en offrant la meilleure expérience possible.

La disponibilité des API alpha de Dapr n’est pas garantie ou prise en charge par Microsoft.

Bien que les composants de niveau 1 soient entièrement pris en charge, les composants de niveau 2 sont pris en charge avec le meilleur effort. Plus d’informations

La chronologie de publication classique de Dapr est de jusqu’à six semaines après la publication de l’OSS Dapr. La dernière version de Dapr est disponible dans Azure Container Apps uniquement après des tests rigoureux. Le déploiement dans toutes les régions peut prendre jusqu’à deux semaines, ou plus.

Vous pouvez envoyer une requête de fonctionnalité via le référentiel GitHub Azure Container Apps. Veillez à inclure « Dapr » dans le titre de la requête de fonctionnalité.

Un déploiement sans Docker vous permet de déployer votre application sans définir de Dockerfile dans votre code. Au lieu de cela, la fonctionnalité de création cloud Container Apps utilise Buildpacks pour transformer le code source sur votre ordinateur local en image conteneur. Cette option utilise le registre Azure Container Apps par défaut.

Vous rencontrez un problème connu avec les déploiements sans Docker. Il est possible que ce problème soit résolu en essayant à nouveau. Si vous rencontrez ce problème, ouvrez un problème GitHub afin que notre équipe puisse enquêter.

Vous devez activer la protection des données pour toutes les applications .NET sur Azure Container Apps. Pour plus d’informations, consultez Déploiement et mise à l’échelle d’une application ASP.NET Core sur Azure Container Apps.

Container Apps prend en charge quatre versions JDK LTS : JDK 8, JDK 11, JDK 17 et JDK 21. Pour la génération de code source, la version par défaut est JDK 17. Pour une génération de fichier JAR, la version JDK est lue depuis l’emplacement du fichier META-INF\MANIFEST. MF dans le fichier JAR, mais utilise la version par défaut JDK 17 si la version spécifiée n’est pas disponible.

Vous pouvez configurer la version JDK pour remplacer la version par défaut à l’aide de variables d’environnement de build.

Maven

Vous pouvez personnaliser un build d’image Java à l’aide de variables d’environnement de build.

Lorsque vous utilisez containerapp up en combinaison avec une base de code sans Docker, utilisez le paramètre --location afin que l’application s’exécute dans un emplacement autre que la région USA Est.