Partager via

Héberger des serveurs MCP sur Azure Container Apps

Le protocole MCP (Model Context Protocol) est une norme ouverte qui connecte des applications IA à des sources et outils de données externes. En utilisant MCP, les clients IA tels que GitHub Copilot peuvent découvrir et appeler des fonctionnalités que vous exposez, transformer vos API, bases de données et logique métier en outils qu’un agent IA peut utiliser via le langage naturel.

Azure Container Apps prend en charge deux modèles d’hébergement pour les serveurs MCP :

Modèle d’hébergement Descriptif
Application conteneur autonome Déployez n’importe quel serveur MCP que vous générez en tant que conteneur avec entrée HTTP.
Sessions dynamiques Utilisez des pools de sessions gérées par la plateforme avec des outils MCP intégrés pour l’exécution du code en bac à sable.

Qu’est-ce que le protocole MCP (Model Context Protocol) ?

Un serveur MCP expose trois types de fonctionnalités aux clients :

Capacité Descriptif Example
Outils Fonctions que le modèle IA peut appeler (avec approbation de l’utilisateur) createTask, listTasks, deleteTask
Ressources Données en lecture seule que le client peut extraire Fichiers de configuration, schémas de base de données
Prompts Modèles préécrits pour les tâches courantes « Résumer toutes les tâches ouvertes »

Les clients communiquent avec les serveurs MCP via HTTP à l’aide du transport HTTP streamable. Le client envoie des demandes de JSON-RPC 2.0. Le serveur répond avec les résultats de l’outil, le contenu des ressources ou les modèles d’invite.

Le flux de requête suit ce modèle :

  1. Le client MCP (GitHub Copilot, Claude ou un client personnalisé) envoie une requête HTTPS contenant un message JSON-RPC 2.0 au serveur.

  2. Le serveur MCP (votre application conteneur) traite la requête et appelle tous les services back-end dont il a besoin, comme une base de données ou une API.

  3. Le serveur retourne une réponse JSON-RPC 2.0 avec les résultats de l’outil, le contenu des ressources ou les modèles d’invite.

Application conteneur autonome

Vous générez un serveur MCP à l’aide d’un KIT de développement logiciel (SDK) MCP officiel (disponible pour .NET, Python, TypeScript, Java, Go, Kotlin, etc.), puis conteneurisez et déployez-le sur Azure Container Apps.

Dans ce modèle, Container Apps n’a pas de sensibilisation spécifique à MCP. La plateforme fournit les éléments suivants :

  • Entrée HTTPS avec arrêt TLS automatique
  • Mise à l’échelle automatique, y compris la mise à l’échelle à zéro (il est recommandé d'avoir au moins une réplique pour l’utilisation interactive de MCP)
  • Stratégie CORS pour autoriser les requêtes interdomaines à partir de VS Code et de clients basés sur un navigateur
  • Authentification intégrée avec l’ID Microsoft Entra (facultatif)
  • Domaines personnalisés, fractionnement du trafic, Dapr, mise en réseau de service à service, identité managée et toutes les autres fonctionnalités de Container Apps standard

Flux de requête

Lorsque vous déployez un serveur MCP en tant qu’application conteneur autonome, les requêtes clientes transitent par l’entrée de Container Apps vers votre conteneur, où votre point de terminaison MCP traite le message JSON-RPC et retourne les résultats.

  1. Un client MCP envoie une requête HTTPS au nom de domaine complet de l’application conteneur.
  2. L’entrée container Apps met fin à TLS et transfère la requête à votre conteneur sur le port cible configuré (par exemple, 8080).
  3. Votre infrastructure web (ASP.NET, FastAPI, Express, Spring Boot) achemine la requête vers le point de terminaison MCP (généralement /mcp).
  4. Votre serveur MCP traite la requête, appelle tous les services principaux et retourne une réponse JSON-RPC 2.0.

Quand utiliser

Utilisez une application conteneur autonome si vous souhaitez créer des outils MCP personnalisés dans n’importe quel langage, intégrer aux services principaux et utiliser des fonctionnalités Container Apps standard.

  • Vous souhaitez un contrôle total sur les définitions d’outils, les intergiciels et la logique métier.
  • Votre serveur MCP est écrit dans n’importe quel langage avec un SDK MCP.
  • Vous devez vous connecter aux bases de données back-end, aux API ou aux services Azure.
  • Vous souhaitez utiliser des fonctionnalités Container Apps telles que Dapr, la mise en réseau de service à service ou l’identité managée.

Sessions dynamiques (MCP géré par la plateforme)

Les sessions dynamiques Azure Container Apps fournissent des environnements bac à sable (sandbox) pour exécuter du code en isolation. Lorsque vous activez MCP sur un pool de sessions, la plateforme expose un point de terminaison JSON-RPC que les clients peuvent utiliser pour lancer des environnements Shell ou Python et exécuter des commandes à distance.

Dans ce modèle, la plateforme gère le serveur MCP. Vous n’écrivez pas ou ne déployez pas de code de serveur MCP. La plateforme fournit les outils prédéfinis suivants :

Outil Descriptif
launchShell Crée un nouvel environnement et retourne un environmentId
runShellCommandInRemoteEnvironment Exécute une commande shell dans un environnement existant
runPythonCodeInRemoteEnvironment Exécute du code Python dans un environnement existant

Note

Le serveur MCP géré par la plateforme expose les trois outils, quel que soit le pool de containerTypesessions. Utilisez launchShell pour créer un environnement pour les pools shell et Python.

Flux de requête

Lorsque vous déployez un serveur MCP à l’aide de sessions dynamiques, la plateforme gère le serveur et fournit un point de terminaison JSON-RPC que les clients utilisent pour exécuter du code Shell ou Python dans des environnements bac à sable (sandbox).

  1. Un client MCP envoie une requête HTTPS au point de terminaison du pool /mcp sessions avec un en-tête x-ms-apikey pour l’authentification.
  2. Le proxy inverse de la plateforme valide la clé API et route la requête vers la session Hyper-V en bac à sable appropriée.
  3. La session exécute la commande shell demandée ou le code Python à l’intérieur du bac à sable.
  4. La plateforme retourne une réponse JSON-RPC 2.0 contenant les résultats d’exécution.

Quand utiliser

  • Vous avez besoin d'exécuter du code en bac à sable pour du code non approuvé ou généré par LLM.
  • Votre cas d’usage est Python ou le script d’interpréteur de commandes et aucun outil personnalisé n’est nécessaire.
  • Vous souhaitez Hyper-V isolation entre les sessions pour la sécurité.
  • Vous ne souhaitez pas générer ou gérer une application serveur MCP.

Authentication

Les sessions dynamiques MCP utilisent l’authentification par clé API via l’en-tête x-ms-apikey . Ce mécanisme est distinct de l’authentification par porteur de jeton employée dans les API de pool de sessions standard.

Récupérez la clé API à l’aide d’Azure CLI :

az rest --method POST \
    --uri "https://management.azure.com/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP_NAME>/providers/Microsoft.App/sessionPools/<POOL_NAME>/fetchMCPServerCredentials" \
    --uri-parameters api-version=2025-02-02-preview \
    --query "apiKey" -o tsv

Détails du protocole

Le serveur MCP géré par la plateforme pour les sessions dynamiques implémente les spécifications de protocole suivantes :

Propriété Valeur
Version du protocole MCP 2025-03-26
Nom du serveur Microsoft Container Apps MCP Server
Transport JSON-RPC 2.0 sur HTTP
Version de l'API 2025-02-02-preview
Méthodes prises en charge initialize, tools/list, tools/call

Important

La fonctionnalité MCP gérée par la plateforme pour les sessions dynamiques est en préversion. La version 2025-02-02-preview de l’API et mcpServerSettings les propriétés Azure Resource Manager (ARM) sont susceptibles de changer.

Entrée et mise en réseau

Le champ d’entrée transport Container Apps prend en charge auto, http, http2 et tcp. Le transport HTTP diffusant MCP s'exécute à l'intérieur de votre conteneur via le protocole HTTP standard, donc définissez transport sur auto ou http (valeur par défaut). Il n’existe aucune valeur de transport MCP spéciale.

Vous devez configurer une stratégie CORS si VS Code ou les clients basés sur un navigateur accèdent à votre serveur MCP. Au minimum, autorisez les origines, méthodes et en-têtes requis par votre client MCP.

Comparer les options d’hébergement

Le tableau suivant compare les deux modèles d’hébergement.

Considération Application conteneur autonome Sessions dynamiques (MCP managé)
Outils personnalisés Oui, définissez les outils souhaités Non, les outils définis par la plateforme uniquement
Langues Langue compatible avec un kit de développement logiciel (SDK) MCP Exécution de Python et d’interpréteur de commandes uniquement
Transport MCP HTTP diffusible (à l’intérieur du conteneur) JSON-RPC sur HTTP (géré par la plateforme)
Authentication Authentification intégrée (Microsoft Entra ID) Clé API (x-ms-apikey)
Isolement Niveau conteneur Hyper-V par session
Croissance Mise à l’échelle automatique basée sur la révision Par session, géré par pool
Cas d’utilisation Serveurs MCP à usage général Exécution de code dans un environnement sécurisé

Pour une comparaison plus large qui inclut App Service et Azure Functions, consultez Choisir un service Azure pour votre serveur MCP.

Étape suivante

Déployer un serveur MCP sur Container Apps

  • Last updated on