Considérations relatives à l’utilisation de Container Apps dans une solution multilocataire
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 multilocataires. Il fournit également des liens pour obtenir des conseils si vous avez besoin d’aide pendant votre phase de planification.
Modèles d’isolation
Lorsque vous travaillez dans un système multilocataire qui utilise Container Apps, vous devez déterminer le niveau d’isolation requis. Container Apps prend en charge différents modèles de multilocation :
- Vous pouvez implémenter une multilocation approuvée en déployant un environnement partagé. Par exemple, ce modèle peut être approprié si vos locataires résident tous au sein 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é si le code exécuté par vos locataires n’est pas fiable.
Le tableau suivant récapitule les différences entre les principaux modèles d’isolation des locataires 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 conteneurisées partagées |
|---|---|---|---|
| Isolation des données | Élevé | Faible | Faible |
| Isolation des performances | Élevé | Moyenne. Pas d’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 approuvées | Implémentation d’une solution multilocataire au niveau de la logique métier |
Applications conteneurisées partagées
Vous envisagez peut-être de déployer des applications conteneurisées partagées dans un environnement Container Apps unique qui est utilisé pour l’ensemble de vos locataires.
Cette approche est généralement économique ; elle réduit la surcharge opérationnelle, 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 des locataires. Ce modèle n’est pas approprié pour les charges de travail multilocataires hostiles qui exécutent du code non fiable.
Par ailleurs, ce modèle est potentiellement sujet à des problèmes de voisins bruyants : la charge de travail d’un locataire peut impacter 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 conteneurisées partagées peut ne pas être approprié.
Notes
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 du niveau tarifaire qui leur est appliqué. Cette stratégie de déploiement vous permet de dépasser les 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 conteneurisées propres au locataire
Une autre approche à envisager est d’isoler vos locataires en déployant des applications conteneurisées propres au locataire dans un environnement partagé.
Ce modèle d’isolation assure une isolation logique entre chaque locataire. Il offre les avantages suivants :
- Rentabilité. En partageant un environnement Container Apps, un réseau virtuel et d’autres ressources attachées comme un espace de travail Log Analytics, vous pouvez généralement réduire le coût global et simplifier la gestion par locataire.
- Séparation des mises à niveau et des déploiements. Les binaires d’application de chaque locataire peuvent être déployés et mis à niveau indépendamment de ceux des autres applications conteneurisées dans le même environnement. Cette approche peut être utile si vous devez mettre à niveau plusieurs locataires vers des versions spécifiques de votre code à différents moments.
- Isolation des ressources. Chaque application conteneurisée dans un environnement se voit allouer ses propres ressources processeur et mémoire. Si un locataire nécessite plus de ressources, vous pouvez allouer davantage de ressources processeur et mémoire à l’application conteneurisée spécifique de ce locataire. N’oubliez pas que des limites d’allocations totales de ressources processeur et mémoire s’appliquent aux applications conteneurisées.
L’inconvénient est que cette approche n’assure aucune isolation matérielle ou réseau entre les locataires. Toutes les applications conteneurisées dans un environnement unique partagent le même réseau virtuel. Vous devez être sûr que les charges de travail déployées dans les applications sont fiables, notamment qu’elles n’utiliseront pas de manière inappropriée les ressources partagées.
Container Apps intègre la prise en charge de Dapr, qui utilise une conception modulaire pour fournir des fonctionnalités sous forme de composants. Dans Container Apps, les composants Dapr sont des ressources disponibles au niveau de l’environnement. Lorsque vous partagez un environnement entre plusieurs locataires, assurez-vous de limiter correctement l’étendue des composants Dapr à l’application conteneurisée appropriée propre au locataire. Cette précaution permet de garantir l’isolation et d’empêcher la fuite de données.
Notes
N’utilisez pas les révisions pour créer des versions différentes de votre application destinées à différents locataires. Les révisions n’assurent pas l’isolation des ressources. Elles sont conçues pour les scénarios de déploiement où vous avez besoin d’exécuter plusieurs versions de votre application dans le cadre d’un processus de déploiement de mises à jour, comme dans les déploiements bleus/verts et les tests A/B.
Un environnement par locataire
Vous pouvez envisager de déployer un environnement Container Apps pour chacun des locataires. Un environnement Container Apps constitue la limite d’isolation autour d’un groupe d’applications conteneurisées. Un environnement assure l’isolation des ressources réseau et de calcul sur le plan de données. Chaque environnement est déployé dans son propre réseau virtuel, lequel est partagé par toutes les applications dans l’environnement. Chaque environnement a sa propre configuration Dapr et de supervision.
Cette approche assure le plus haut niveau 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. Avec cette approche, vous pouvez contrôler plus précisément les allocations de ressources aux applications conteneurisées dans l’environnement. Vous pouvez déterminer les allocations en fonction des besoins des locataires. Par exemple, certains locataires peuvent nécessiter plus de ressources processeur et mémoire que d’autres. Vous pouvez alors allouer davantage de ressources aux applications de ces locataires tout en profitant de l’isolation fournie par les environnements propres aux locataires.
Toutefois, il existe des limites basses quant au nombre d’environnements déployables dans un abonnement par région. Dans certains cas, vous pouvez augmenter ces quotas en créant un ticket de support Azure.
Avant d’implémenter ce modèle d’isolation, veillez à prendre en compte la croissance attendue du nombre de locataires. Gardez à l’esprit que cette approche induit souvent un coût total de possession plus élevé et qu’elle complexifie le déploiement et le fonctionnement, car vous devrez déployer et gérer des ressources supplémentaires.
Fonctionnalités de Container Apps prenant en charge la multilocation
Noms de domaine personnalisés
Avec Container Apps, vous pouvez utiliser des DNS génériques et ajouter vos propres certificats TLS génériques. Lorsque vous utilisez des sous-domaines propres au locataire, les DNS et certificats TLS génériques vous permettent d’adapter facilement votre solution à 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. L’entrée doit également être activée pour l’application conteneurisée avant de pouvoir la lier à un domaine personnalisé.
Authentification et autorisation des requêtes
Container Apps peut valider des jetons d’authentification pour le compte de votre application. Si une requête ne contient pas de jeton, si le jeton n’est pas valide ou si la requête n’est pas autorisée, vous pouvez configurer Container Apps pour qu’il bloque la requête, ou qu’il la redirige 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. Ainsi, quel que soit le locataire Microsoft Entra de l’utilisateur, les jetons utilisateur sont validés et acceptés.
Vous pouvez également intégrer Container Apps à Azure Active Directory B2C pour l’authentification des utilisateurs via des fournisseurs d’identité partenaires.
Pour plus d’informations, consultez ces ressources :
- Autorisation dans 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 disponibles dans Azure App Service. Il y a cependant quelques 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 les identités managées de Microsoft Entra ID pour permettre à votre application conteneurisée d’accéder à d’autres ressources authentifiées par Microsoft Entra ID. Quand vous utilisez des identités managées, votre application conteneurisée 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 conteneurisée pour implémenter le contrôle d’accès en fonction du rôle.
Lorsque vous utilisez des identités managées, tenez compte du modèle d’isolation que vous avez choisi. Par exemple, supposez que vous partagez vos applications conteneurisées entre tous les locataires et que vous déployez des bases de données spécifiques pour chaque locataire. Vous devez vous assurer que l’application d’un locataire ne pourra pas accéder à la base de données d’un autre locataire.
Pour plus d'informations, voir Identités managé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 for 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 service senior, FastTrack for Azure
- Aarthi Murugan | Responsable programme senior, CS Tech Strategy App Innovation
- Kendall Roden | Responsable programme senior, Azure Container Apps
- Paul Salvatori | Ingénieur client principal, FastTrack for Azure
- Arsen Vladimirskiy | Ingénieur client principal, FastTrack for Azure
Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.