Forum aux questions (FAQ) sur Azure Container Apps

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

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

Azure Container Apps offre aux développeurs la possibilité d’expérimenter les API et fonctionnalités alpha Dapr les plus récentes, sur un mode en libre-service. Bien que la disponibilité de ces API et composants alpha ne soit pas garantie, vous pouvez rester en avance et explorer les technologies de pointe dès qu’elles deviennent disponibles. Bien que ces API et composants alpha soient fournis « tel que » et « comme disponible », leur évolution continue vers un état stable garantit que les développeurs peuvent toujours être à la pointe de l’innovation.

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

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