Considérations relatives à l’utilisation de Container Apps dans une solution mutualisée
Vous pouvez utiliser Azure Container Apps pour exécuter des microservices et des applications conteneurisées sur une plateforme serverless. Cet article décrit certaines des fonctionnalités de Container Apps qui sont utiles pour les solutions mutualisées. Il fournit également des liens vers des conseils qui peuvent vous aider pendant votre phase de planification.
Modèles d’isolation
Lorsque vous travaillez avec un système multilocataire qui utilise Container Apps, vous devez déterminer le niveau d’isolation requis. Le service Container Apps prend en charge différents modèles de multitenance :
- Vous pouvez implémenter une multilocation approuvée en déployant un environnement partagé. Par exemple, ce modèle peut être approprié lorsque vos locataires sont tous issus de votre organisation.
- Vous pouvez implémenter une multilocation hostile en déployant des environnements séparés pour chacun des locataires. Par exemple, ce modèle peut être approprié lorsque vous n’approuvez pas le code que vos locataires exécutent.
Le tableau suivant résume les différences entre les principaux modèles d’isolation de location pour Container Apps. Les modèles sont décrits plus loin dans cet article.
| Considération | Un environnement par locataire | Applications conteneurisées propres au locataire | applications conteneur partagées |
|---|---|---|---|
| Isolation des données | Élevé | Faible | Faible |
| Isolation des performances | Élevé | Moyenne. Aucune isolation réseau. | Faible |
| complexité du déploiement | Moyenne | Faible à moyen | Faible |
| complexité opérationnelle | Moyenne | Faible | Faible |
| coût des ressources | Élevé | Faible | Faible |
| exemple de scénario | Exécution de charges de travail multilocataires hostiles dans des environnements isolés pour la sécurité et la conformité | Optimisation des coûts, des ressources réseau et des opérations pour les applications multilocataires fiables | Implémentation d’une solution mutualisée au niveau de la logique métier |
Applications conteneur partagées
Vous pouvez envisager de déployer des applications conteneur partagées dans un seul environnement Container Apps utilisé pour tous vos locataires.
Cette approche est généralement rentable et nécessite la surcharge opérationnelle la moins importante, car il y a moins de ressources à gérer.
Toutefois, si vous souhaitez utiliser ce modèle d’isolation, votre code d’application doit être compatible avec la multilocation. Ce modèle d’isolation ne garantit pas l’isolation au niveau du réseau, du calcul, de la supervision ou des données. Votre code d’application doit gérer l’isolation du locataire. Ce modèle n’est pas approprié pour les charges de travail multilocataires hostiles qui exécutent du code non fiable.
De plus, ce modèle est potentiellement soumis à problèmes de voisin bruyant: la charge de travail d’un locataire peut affecter les performances de la charge de travail d’un autre locataire. Si vous devez fournir un débit dédié pour atténuer ce problème, le modèle d’applications conteneur partagées peut ne pas être approprié.
Remarque
Le modèle Empreintes de déploiement est utile lorsque les locataires ont des modèles de coûts différents. Par exemple, les locataires peuvent être affectés à des environnements Container Apps partagés ou dédiés en fonction de leur niveau tarifaire. Cette stratégie de déploiement vous permet d’aller au-delà des limites de Container Apps pour un seul abonnement par région et d’effectuer une mise à l’échelle linéaire à mesure que le nombre de locataires augmente.
Applications spécifiques au locataire de conteneurs
Une autre approche que vous pouvez envisager consiste à isoler vos locataires en déployant des applications conteneur spécifiques au locataire dans un environnement partagé.
Ce modèle d’isolation fournit une isolation logique entre chaque locataire. Il offre ces avantages :
- Efficacité des coûts. En partageant un environnement Container Apps, un réseau virtuel et d’autres ressources jointes comme un espace de travail Log Analytics, vous pouvez généralement réduire votre coût global et la complexité de la gestion par locataire.
- Séparation des mises à niveau et des déploiements. Les fichiers binaires d’application de chaque locataire peuvent être déployés et mis à niveau indépendamment de ceux d’autres applications conteneur dans le même environnement. Cette approche peut être utile si vous devez mettre à niveau différents locataires vers des versions spécifiques de votre code à différents moments.
- Isolation des ressources. Chaque application conteneur au sein de votre environnement est allouée à ses propres ressources processeur et mémoire. Si un locataire spécifique nécessite davantage de ressources, vous pouvez allouer davantage d’UC et de mémoire à l’application conteneur spécifique de ce locataire. N’oubliez pas qu’il existe des limites sur le nombre total d’allocations de processeur et de mémoire sur les applications conteneur.
Toutefois, cette approche ne fournit aucune isolation matérielle ou réseau entre les locataires. Toutes les applications conteneur d’un seul environnement partagent le même réseau virtuel. Vous devez être en mesure de faire confiance au fait que les charges de travail déployées sur les applications n’utilisent pas les ressources partagées.
Container Apps offre une prise en charge intégrée de Dapr, qui utilise une conception modulaire pour proposer des fonctionnalités sous forme de composants . Dans Container Apps, les composants Dapr sont des ressources au niveau de l’environnement. Lorsque vous partagez un seul environnement entre plusieurs locataires, assurez-vous d’étendre correctement les composants Dapr à l’application conteneur spécifique au locataire appropriée pour garantir l’isolation et éviter les risques de fuite de données.
Remarque
N’utilisez pas les révisions pour créer des versions distinctes de votre application pour différents clients. Les révisions ne fournissent pas d’isolation des ressources. Ils sont conçus pour les scénarios de déploiement dans lesquels vous devez avoir plusieurs versions de votre application s’exécutant dans le cadre d’un processus de déploiement de mise à jour, comme dans les déploiements bleu/vert et les tests A/B.
Un environnement par locataire
Vous pouvez envisager de déployer un environnement Container Apps pour chacun de vos locataires. Un environnement d’applications conteneur est la limite d’isolation autour d’un groupe d’applications conteneur. Un environnement fournit l'isolation des ressources de calcul et du réseau au niveau du plan de données. Chaque environnement est déployé dans son propre réseau virtuel, qui est partagé par toutes les applications au sein de l’environnement. Chaque environnement a sa propre configuration dapr et de supervision.
Cette approche offre le niveau le plus élevé d’isolation des données et des performances, car les données et le trafic de chaque locataire sont isolés dans un environnement spécifique. De plus, quand vous utilisez ce modèle, vos applications n’ont pas besoin de prendre en charge la multilocation. Lorsque vous utilisez cette approche, vous avez un contrôle plus précis sur la façon dont vous allouez des ressources à des applications conteneur dans l’environnement. Vous pouvez déterminer les allocations en fonction des exigences de votre locataire. Par exemple, certains locataires peuvent nécessiter plus de ressources processeur et de mémoire que d’autres, de sorte que vous pouvez fournir davantage de ressources aux applications de ces locataires tout en bénéficiant de l’isolation fournie par les environnements spécifiques au locataire.
Toutefois, les limites sur le nombre d'environnements que vous pouvez déployer dans un abonnement par régionsont faibles. Dans certains cas, vous pouvez augmenter ces quotas en créant un ticket de support Azure .
Veillez à connaître la croissance attendue du nombre de locataires avant d’implémenter ce modèle d’isolation. N’oubliez pas que cette approche entraîne souvent un coût total de possession plus élevé et des niveaux plus élevés de complexité opérationnelle et de déploiement, en raison des ressources supplémentaires dont vous avez besoin pour déployer et gérer.
Fonctionnalités de Container Apps prenant en charge la multilocation
Noms de domaine personnalisés
Container Apps vous permet d’utiliser DNS générique et d’ajouter vos propres certificats TLS génériques. Lorsque vous utilisez des sous-domaines spécifiques au locataire, les certificats DNS et TLS génériques vous permettent de mettre facilement à l’échelle votre solution vers un grand nombre de locataires sans avoir à reconfigurer manuellement chaque nouveau locataire.
Dans Container Apps, vous gérez les certificats au niveau de l’environnement. Ingress doit également être activé pour l’application conteneur avant de pouvoir associer un domaine personnalisé.
Demander l’authentification et l’autorisation
Container Apps peut valider des jetons d’authentification pour le compte de votre application. Si une demande ne contient pas de jeton, le jeton n’est pas valide ou si la demande n’est pas autorisée, vous pouvez configurer Container Apps pour bloquer la demande ou la rediriger vers votre fournisseur d’identité afin que l’utilisateur puisse se connecter.
Si vos locataires utilisent Microsoft Entra ID comme fournisseur d’identité, vous pouvez configurer Container Apps pour qu’il valide les jetons utilisateur en utilisant le point de terminaison /common. Cela garantit que, quel que soit le client Microsoft Entra de l’utilisateur, ses jetons sont validés et acceptés.
Vous pouvez également intégrer Container Apps à Azure Active Directory B2C pour l’authentification utilisateur via des fournisseurs d’identité partenaires.
Pour plus d’informations, consultez les ressources suivantes :
- Autorisation des Azure Container Apps
- Activer l’authentification et l’autorisation dans Azure Container Apps avec Microsoft Entra ID
Remarque
Les fonctionnalités d’authentification et d’autorisation dans Container Apps sont similaires à celles d’Azure App Service. Toutefois, il existe des différences. Pour plus d’informations, consultez Considérations relatives à l’utilisation de l’authentification intégrée.
Identités managées
Vous pouvez utiliser des identités managées à partir de Microsoft Entra ID pour permettre à votre application conteneur d’accéder à d’autres ressources authentifiées par l’ID Microsoft Entra. Lorsque vous utilisez des identités managées, votre application conteneur n’a pas besoin de gérer les informations d’identification pour la communication de service à service. Vous pouvez accorder des autorisations spécifiques à l’identité de votre application conteneur pour le contrôle d’accès en fonction du rôle.
Lorsque vous utilisez des identités managées, gardez à l’esprit votre choix de modèle d’isolation. Par exemple, supposons que vous partagez vos applications conteneur entre tous vos locataires et déployez des bases de données spécifiques au locataire. Vous devez vous assurer que l’application d’un locataire ne peut pas accéder à la base de données d’un autre locataire.
Pour plus d’informations, consultez identités gérées dans Azure Container Apps.
Contributeurs
Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.
Auteurs principaux :
- Daniel Larsen | Ingénieur client principal, FastTrack pour Azure
- Will Velida | Ingénieur client 2, FastTrack pour Azure
Autres contributeurs :
- John Downs | Ingénieur logiciel principal
- Chad Kittel | Ingénieur logiciel principal, Microsoft
- Xuhong Liu | Ingénieur de service senior, FastTrack pour Azure
- Aarthi Murugan | Responsable du programme senior, Innovation des applications de stratégie technique CS
- Kendall Roden | Senior Program Manager, Azure Container Apps
- Paolo Salvatori | Ingénieur client principal, FastTrack pour Azure
- Arsenal Vladimirskiy | Ingénieur client principal, FastTrack pour Azure
Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.
Étapes suivantes
- Vue d’ensemble du produit Container Apps
- Documentation Container Apps