Forum aux questions (FAQ) sur Azure Container Apps

Cet article répertorie les questions fréquemment posées sur Azure Container Apps, ainsi que les réponses associées.

Régions

Où puis-je trouver les dernières informations sur les régions prises en charge dans Azure Container Apps ?

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

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

API

Azure Container Apps fournit-il un accès direct à l’API Kubernetes sous-jacente ?

Non, Azure Container Apps ne fournit pas d’accès direct à l’API Kubernetes.

Puis-je importer mon API Azure Container Apps à partir du contexte de Gestion des API ?

Oui, vous pouvez importer une API Azure Container Apps à partir du contexte de gestion des API.

Facturation

Comment Azure Container Apps est-il facturé ?

La facturation est basée sur la consommation des ressources, notamment le processeur, la mémoire et le nombre de demandes. Pour plus d’informations, consultez la page de facturation .

Paramétrage

Puis-je configurer GitHub Actions pour générer et déployer automatiquement mon code sur Azure Container Apps ?

Oui. Vous pouvez configurer GitHub Actions à l’aide d’Azure CLI ou du portail Azure :

• À 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.

Pourquoi l’URL que reçoit mon application est différente de l’URL spécifiée dans la requête ?

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.

Les environnements Consommation uniquement prennent-ils en charge les itinéraires personnalisés définis par l’utilisateur ?

Les environnements consommation uniquement ont une prise en charge limitée des itinéraires définis par l’utilisateur (UDR). ExpressRoute n’est pas pris en charge. La prise en charge limitée des UDR est disponible lorsqu’elle est configurée comme suit :

• Un itinéraire doit être défini à l’aide de l’étiquette Azure.<REGION_NAME> de service avec Next Hop = « Internet ».

• Les règles de groupe de sécurité réseau (NSG) doivent également être configurées comme décrit dans la documentation du groupe de sécurité réseau pour garantir que l’environnement fonctionne correctement.

Ces limitations ne s’appliquent pas aux profils de charge de travail, et pour la prise en charge complète des itinéraires UDR et Express Route, utilisez des environnements de profil de charge de travail.

Gestion des données

Où Azure Container Apps stocke-t-il les données client ?

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

Contingents

Comment demander une augmentation de quota ?

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

Tenez compte des détails suivants lors de l’envoi d’une demande 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.

API de microservices avec Dapr

Quelles fonctionnalités et API Dapr sont disponibles dans Azure Container Apps ?

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.

Les API et composants alpha Dapr de niveau 2 sont-ils pris en charge ou disponibles dans Azure Container Apps ?

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

Comment puis-je demander une amélioration des fonctionnalités Dapr pour Azure Container Apps ?

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é.

Pourquoi la version « -msft.<number> » est-elle affichée dans mon environnement d’application conteneur ?

Comme 1.13.6-msft.1 est déployé dans des régions de production, vous pouvez toujours voir les versions antérieures (comme 1.12.5 ou 1.12.5-msft.6). Le suffixe -msft.<number> indique les personnalisations spécifiques effectuées pour Azure Container Apps afin d’améliorer votre expérience.

À quelle fréquence les versions de Dapr sont-elles publiées pour Azure Container Apps ?

Les versions de Dapr sont mises à jour de manière optimale, avec une forte attention sur la stabilité, les tests approfondis et la réduction de l’impact du client. L’objectif est de s’assurer que les mises à jour sont intégrées en toute transparence sans introduire de changements cassants.

Étant donné que les mises à jour de version Dapr sont appliquées automatiquement, vous bénéficiez toujours de la version la plus sécurisée. Toutefois, Dapr dans Azure Container Apps ne suit pas une planification de mise en production fixe pour les nouvelles fonctionnalités. Au lieu de cela, la publication de nouvelles versions de Dapr pour les nouvelles fonctionnalités dépend de la hiérarchisation et de la stabilité des fichiers binaires Dapr.

Recherchez les mises à jour et les annonces de publication pour Dapr dans Azure Container Apps dans GitHub.

Puis-je utiliser une version de Dapr spécifique pour mon environnement ?

La sélection des versions personnalisées n’est pas prise en charge. Au lieu de cela, votre environnement est automatiquement mis à niveau, en conservant l’intégrité de l’offre complètement managée et serverless de Dapr dans Azure Container Apps. Vous pouvez contrôler les mises à niveau automatiques en configurant la fonctionnalité de maintenance planifiée sur votre environnement d’applications conteneur.

Déploiements sans Docker

Qu’est-ce qu’un déploiement sans Docker ?

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.

Pendant le déploiement de mon application sans Docker, les messages « ImagePullBackOff sur Légion », « Erreur Kubernetes » ou « Erreur de passerelle » s’affichent et mon application ne se déploie pas correctement.

Vous rencontrez un problème connu avec les déploiements sans Docker. Une nouvelle tentative peut résoudre ce problème pour vous. Si vous rencontrez ce problème, ouvrez un problème GitHub afin que notre équipe puisse enquêter.

Déployer des applications .NET

Que se passe-t-il si la mise à l’échelle mon application .NET échoue ?

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.

Déployer des applications Java

Quelles versions JDK sont prises en charge et comment configurer la version JDK ?

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.

Quels sont les outils de génération Java pris en charge ?

Azure Container Apps prend actuellement en charge Apache Maven comme outil de génération Java.

Comment personnaliser un build d’image Java à partir du code source ?

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

Comment vérifier que le build et l’image de mon build sans Docker sont disponibles dans la même région que mon application ?

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.

Marquage

Comment utiliser « latest » ou une balise statique pour mon image conteneur ?

Évitez d’utiliser des balises statiques comme latest pour les images conteneur. L’utilisation de balises statiques peut entraîner des problèmes de mise en cache et rendre votre application difficile à résoudre. Utilisez plutôt des balises uniques pour chaque déploiement, telles qu’un hachage Git ou une date et une heure pour vous assurer que les mises à jour sont correctement suivies et déployées.

OpenTelemetry

Quels protocoles de transport l’agent managé OpenTelemetry prend-il en charge ?

L’agent managé prend uniquement en charge gRPC.

Cet article répertorie les questions fréquemment posées sur Azure Container Apps, ainsi que les réponses associées.

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

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

Non, Azure Container Apps ne fournit pas d’accès direct à l’API Kubernetes.

Oui, vous pouvez importer une API Azure Container Apps à partir du contexte de gestion des API.

La facturation est basée sur la consommation des ressources, notamment le processeur, la mémoire et le nombre de demandes. Pour plus d’informations, consultez la page de facturation .

Oui. Vous pouvez configurer GitHub Actions à l’aide d’Azure CLI ou du portail Azure :

• À 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.

Les environnements consommation uniquement ont une prise en charge limitée des itinéraires définis par l’utilisateur (UDR). ExpressRoute n’est pas pris en charge. La prise en charge limitée des UDR est disponible lorsqu’elle est configurée comme suit :

• Un itinéraire doit être défini à l’aide de l’étiquette Azure.<REGION_NAME> de service avec Next Hop = « Internet ».

• Les règles de groupe de sécurité réseau (NSG) doivent également être configurées comme décrit dans la documentation du groupe de sécurité réseau pour garantir que l’environnement fonctionne correctement.

Ces limitations ne s’appliquent pas aux profils de charge de travail, et pour la prise en charge complète des itinéraires UDR et Express Route, utilisez 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.

Tenez compte des détails suivants lors de l’envoi d’une demande 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

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é.

Comme 1.13.6-msft.1 est déployé dans des régions de production, vous pouvez toujours voir les versions antérieures (comme 1.12.5 ou 1.12.5-msft.6). Le suffixe -msft.<number> indique les personnalisations spécifiques effectuées pour Azure Container Apps afin d’améliorer votre expérience.

Les versions de Dapr sont mises à jour de manière optimale, avec une forte attention sur la stabilité, les tests approfondis et la réduction de l’impact du client. L’objectif est de s’assurer que les mises à jour sont intégrées en toute transparence sans introduire de changements cassants.

Étant donné que les mises à jour de version Dapr sont appliquées automatiquement, vous bénéficiez toujours de la version la plus sécurisée. Toutefois, Dapr dans Azure Container Apps ne suit pas une planification de mise en production fixe pour les nouvelles fonctionnalités. Au lieu de cela, la publication de nouvelles versions de Dapr pour les nouvelles fonctionnalités dépend de la hiérarchisation et de la stabilité des fichiers binaires Dapr.

Recherchez les mises à jour et les annonces de publication pour Dapr dans Azure Container Apps dans GitHub.

La sélection des versions personnalisées n’est pas prise en charge. Au lieu de cela, votre environnement est automatiquement mis à niveau, en conservant l’intégrité de l’offre complètement managée et serverless de Dapr dans Azure Container Apps. Vous pouvez contrôler les mises à niveau automatiques en configurant la fonctionnalité de maintenance planifiée sur votre environnement d’applications conteneur.

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. Une nouvelle tentative peut résoudre ce problème pour vous. 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.

Azure Container Apps prend actuellement en charge Apache Maven comme outil de génération Java.

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.

Évitez d’utiliser des balises statiques comme latest pour les images conteneur. L’utilisation de balises statiques peut entraîner des problèmes de mise en cache et rendre votre application difficile à résoudre. Utilisez plutôt des balises uniques pour chaque déploiement, telles qu’un hachage Git ou une date et une heure pour vous assurer que les mises à jour sont correctement suivies et déployées.

L’agent managé prend uniquement en charge gRPC.