Appliquer la rigueur de l’ingénierie logicielle à l’IA grâce aux conteneurs

À mesure que les charges de travail d'IA passent des prototypes expérimentaux aux environnements de production, les entreprises font face à un défi familier : comment protéger, gérer et encadrer ces nouveaux composants avec la même rigueur que celle appliquée aux applications logicielles traditionnelles ? Une partie essentielle de la solution réside dans un élément que votre organisation utilise probablement déjà de manière intensive : les conteneurs, et plus précisément les conteneurs OCI (Open Container Initiative).

Qu'est-ce que l'Open Container Initiative ?

L'Open Container Initiative définit des spécifications ouvertes pour les formats d'image, les environnements d'exécution des conteneurs et la distribution, ce qui permet aux organisations d'éviter la dépendance vis-à-vis d'un fournisseur.  Les conteneurs OCI constituent un format standard du secteur pour la mise en paquet des applications logicielles. Ils peuvent ainsi s'exécuter de manière cohérente dans différents environnements, moteurs de conteneurs (comme Docker ou Podman) et plateformes cloud.

Un artéfact OCI ressemble à un conteneur, mais au lieu d'images exécutables, les artéfacts stockent d'autres contenus tels que des fichiers et des répertoires.  Les référentiels d'artéfacts compatibles OCI (notamment Quay, Artifactory, Docker Hub et les registres des principaux fournisseurs de cloud) peuvent stocker et gérer les versions des conteneurs et des artéfacts OCI.

L'OCI fournit un moyen standardisé et portable d'empaqueter et de distribuer des logiciels. En mettant en paquet vos modèles d'IA, vos serveurs Model Context Protocol (MCP) et vos agents d'IA à l'aide de conteneurs OCI, vous pouvez utiliser vos processus de sécurité de la chaîne d'approvisionnement logicielle, vos pipelines de CI/CD et votre infrastructure d'orchestration de conteneurs. Cette approche apporte à votre pile d'IA la même gouvernance et la même auditabilité que celles déjà appliquées à vos charges de travail applicatives.

Conteneurisation des modèles d'IA avec ModelCar

Les grands modèles de langage (LLM) et les autres modèles d'IA présentent des défis uniques en matière de mise en paquet. Ces modèles se composent de fichiers binaires volumineux, de métadonnées de configuration et d'exigences spécifiques concernant la structure des fichiers. Par le passé, les organisations s'appuyaient sur le stockage objet compatible S3 pour distribuer les modèles, mais cette approche crée des frictions avec les flux de travail basés sur les conteneurs et les processus de sécurité existants. Nous recommandons la création de vos modèles d'IA dans des conteneurs OCI en utilisant une structure de fichiers spécifique nommée ModelCar.

Qu'est-ce qu'un conteneur ModelCar ?

Un ModelCar container est simple : les fichiers de modèles d'IA sont placés dans un dossier /models à l'intérieur du conteneur. Aucun paquetage ou composant d'exécution supplémentaire n'est requis : le conteneur contient simplement les artéfacts de modèle dans un format compatible OCI.

Cette approche offre des avantages significatifs. Dès que votre modèle est mis en paquet sous forme de conteneur, vous pouvez le gérer à l'aide des processus de sécurité de la chaîne d'approvisionnement logicielle que vous utilisez déjà pour vos conteneurs d'applications. Vous pouvez générer une nomenclature logicielle (SBOM) et une nomenclature d'IA (AI-BOM) pour le conteneur en tant que tâche dans votre pipeline de CI/CD. Vous pouvez également signer et valider le conteneur, générer des attestations de provenance prouvant que le conteneur a été créé par votre système de construction de confiance, stocker le conteneur dans votre référentiel d'artéfacts OCI interne et configurer vos politiques de déploiement pour extraire uniquement les conteneurs provenant de référentiels approuvés.

Red Hat Trusted Artifact Signer permet de signer des modèles et de valider l'authenticité ainsi que la transparence d'un modèle à l'aide de Sigstore and Rekor. 

Red Hat OpenShift AI 2.14 et les versions ultérieures prennent en charge la mise à disposition de modèles directement depuis les conteneurs ModelCar à l'aide de KServe, ce qui élimine totalement la dépendance au stockage compatible S3. Cette méthode simplifie le déploiement, améliore les temps de démarrage des serveurs d'inférence (en particulier lorsque le conteneur est mis en cache sur un nœud) et fournit une approche unifiée de la gestion des artéfacts au sein de votre organisation.

Un catalogue d'exemples de conteneurs ModelCar est disponible dans the GitHub repository, fournissant des modèles et des meilleures pratiques pour la mise en paquet de différents types de modèles.

Considérations relatives à la taille des modèles

Bien que la spécification OCI n'impose pas de limites strictes sur la taille des images, des contraintes pratiques existent. Les registres de conteneurs prennent généralement en charge des images allant de plusieurs Go à des dizaines de Go, la plupart des registres d'entreprise gérant sans problème des images allant jusqu'à 15 ou 20 Go. Pour les modèles très volumineux qui dépassent ces limites pratiques, il peut être nécessaire d'envisager des techniques de quantification de modèle pour réduire la taille des fichiers, ou d'autres mécanismes de distribution. Toutefois, pour la majorité des modèles de production, en particulier les variantes quantifiées telles que le Floating Point 8 bits (FP8) ou l'entier 4 bits (INT4), la conteneurisation avec ModelCar s'avère à la fois pratique et recommandée.

Artefacts OCI pour les modèles

ModelCar utilise des conteneurs OCI pour garantir une compatibilité maximale avec les anciens systèmes qui ne prennent pas entièrement en charge les artefacts OCI, mais les artefacts OCI constituent sans doute un choix plus efficace pour le stockage des modèles. 

Les équipes d'ingénierie de création peuvent alors mettre en paquets leurs modèles dans des artefacts OCI au lieu de conteneurs, puis les stocker dans leur référentiel d'artefacts OCI. Au moment du déploiement, vous pouvez monter l’artefact OCI directement sur votre pod de diffusion de modèles en tant que stockage, à l’aide d’un Kubernetes image volume. Le montage des artefacts OCI est implémenté dans les versions récentes de podman et de l'environnement d'exécution de conteneur CRI-O aujourd'hui, et des travaux sont en cours pour d'autres environnements d'exécution dont Containerd.

Conteneurisation de serveurs MCP pour le déploiement en entreprise

Le MCP est devenu la norme pour connecter les assistants et agents d'IA à des outils, sources de données et API externes. Les serveurs MCP servent de passerelles entre les systèmes d'IA et les ressources de votre entreprise, ce qui rend leur sécurité et leur gouvernance essentielles.

Pour les serveurs MCP qui seront partagés entre des équipes ou déployés dans des environnements de production, nous vous recommandons de les intégrer dans des conteneurs à l'aide des outils et processus de création que vous utilisez pour vos autres applications. Cette approche permet de gérer, déployer et protéger ces composants de manière cohérente. Ce processus est bien connu des personnes qui disposent d'applications conteneurisées : créer un fichier Containerfile, créer l'image, la publier dans votre registre, puis la déployer à l'aide de Red Hat OpenShift, Kubernetes, Podman ou Docker.  Vous pouvez utiliser vos outils de création habituels pour signer et vérifier des serveurs MCP, pour générer une nomenclature logicielle (SBOM), les stocker dans des référentiels d'artefacts OCI, etc.

Comme pour tous les logiciels, des codes malveillants peuvent accéder à un serveur MCP. Analysez et validez en continu vos serveurs MCP à l'aide de Red Hat Trusted Profile Analyzer pour identifier les vulnérabilités, les dépendances malveillantes et les violations de politiques.

Avantages des serveurs MCP conteneurisés

Les serveurs MCP conteneurisés peuvent être mis à l'échelle horizontalement pour faire face à l'augmentation de la charge. Ils sont surveillés à l'aide d'outils d'observabilité standard et régis par les politiques de sécurité existantes.

Le OpenShift Kubernetes MCP server illustre ce modèle. Il peut s'exécuter en local à des fins de développement ou être déployé dans le cluster à l'aide du transport HTTP Streamable pour l'accès des équipes. Le serveur prend en charge les modes d’accès configurables (lecture seule, non destructrice ou accès complet) et s’intègre au contrôle d’accès basé sur les rôles (RBAC) Kubernetes pour les autorisations.

Un écosystème se développe déjà autour des serveurs MCP conteneurisés. Par exemple, l'mcp lifecycle operator facilite le déploiement de serveurs MCP conteneurisés et leur connexion à vos agents via une configuration native pour Kubernetes. La passerelle MCP Gateway Kuadrant fournit des fonctions de sécurité d'entreprise avancées. D'autres outils courants, tels que Docker, fonctionnent également avec les serveurs MCP dans des conteneurs.

Quand ne pas conteneuriser vos serveurs MCP

Tous les serveurs MCP ne bénéficient pas de la mise en conteneur. La spécification du MCP prend en charge deux mécanismes de transport principaux : stdio (entrée/sortie standard) et les transports HTTP (y compris le protocole HTTP Streamable et le transport Server-Sent Events (SSE) existant). Cette distinction a de l'importance pour les décisions en matière de déploiement.

Les serveurs MCP basés sur Stdio communiquent via des flux de processus, le client d'IA générant le serveur en tant que processus enfant. Ce modèle convient aux scénarios à utilisateur unique, comme l'assistant de codage d'un développeur, un outil de productivité local ou un script d'automatisation personnel. Dans ces cas, le serveur MCP s'exécute sur l'ordinateur portable de l'utilisateur, accède aux fichiers et aux ressources locaux, puis s'arrête lorsqu'il devient inutile. La conteneurisation des serveurs MCP stdio accroît la complexité sans apporter d'avantage majeur pour ces cas d'utilisation locaux à utilisateur unique.

Les serveurs MCP basés sur HTTP, en revanche, s'exécutent en tant que processus indépendants capables de gérer plusieurs connexions client simultanées. Ils exposent des points de terminaison réseau et fonctionnent davantage comme des services web traditionnels. Ces serveurs constituent des candidats naturels pour la conteneurisation et bénéficient d'un déploiement, d'une mise à l'échelle et d'une gestion centralisés.

Le cadre de décision est le suivant : 

• Pour les environnements partagés ou de production : Si votre équipe doit partager le serveur MCP, si celui-ci est accessible via un réseau ou déployé dans un environnement de serveur, conteneurisez-le.
• Pour les agents conteneurisés : Si votre agent s'exécute dans un conteneur, un serveur MCP basé sur stdio doit s'exécuter dans le même conteneur que l'agent, tandis qu'un serveur MCP basé sur HTTP doit s'exécuter dans un conteneur distinct.
• Pour une utilisation locale à utilisateur unique : Si un serveur MCP s'exécute localement sur la machine d'un seul développeur à l'aide du transport stdio, la conteneurisation reste facultative et peut engendrer une surcharge inutile. 

Conteneurisation des compétences des agents

Les compétences d'agent (Agent Skills) apparaissent comme une alternative et un complément aux serveurs MCP. Elles constituent des « dossiers d'instructions, de scripts et de ressources que les agents peuvent découvrir et utiliser pour accomplir des tâches avec plus de précision et d'efficacité ». La spécification des compétences prévoit leur conditionnement sous forme de fichiers zip. 

Le développement de votre système de création permet de mettre en paquet vos compétences dans des conteneurs OCI ou des artefacts, tout comme les modèles et les serveurs MCP. Ensuite, vous pouvez signer et vérifier les compétences, générer un SBOM (nomenclature logicielle), les stocker dans des référentiels d'artefacts OCI, les télécharger et les associer à des Pods comme pour les modèles. Puisque les compétences peuvent contenir des scripts spécifiques à une plateforme, OCI propose également des fonctions pour fournir un ensemble de fichiers différent pour chaque plateforme. Si vos applications prenant en charge les compétences ne peuvent pas encore utiliser de conteneurs ou d'artefacts OCI, l'utilitaire de ligne de commande ORAS permet d'extraire une compétence dans le répertoire approprié. 

Alternativement, les compétences pourraient être gérées à l'avenir par des gestionnaires de paquets, à l’image de la gestion d'autres bibliothèques partagées pour divers langages de programmation. Dans ce cas, les compétences seraient importées et utilisées dans les conteneurs, sans être nécessairement distribuées sous forme de conteneurs. 

Cette technologie est émergente, surveillez donc les futurs développements ! 

Conteneurisation des agents d'IA

Les agents d'IA, des systèmes autonomes capables de planifier et d'exécuter des tâches en plusieurs étapes à l'aide de modèles d'IA et d'autres outils, représentent la prochaine évolution des applications d'IA. À mesure que les agents passent du prototype à la production, les entreprises nécessitent une approche structurée pour leur création, leur déploiement et leur gestion.

Le projet Kagenti fournit un framework natif Kubernetes précisément à cette fin. Kagenti fonctionne avec n'importe quel framework d'agent ou SDK et fournit des composants modulaires pour le déploiement en production. Kagenti traite principalement les agents comme des charges de travail conteneurisées définissables de manière déclarative à l'aide de ressources personnalisées Kubernetes.

Kagenti utilise Shipwright et Buildah pour intégrer des agents dans des conteneurs. Si votre entreprise utilise Tekton ou Jenkins pour le CI/CD (intégration continue et distribution continue), vous pouvez ajouter une tâche Buildah similaire à vos pipelines existants. Comme pour les modèles de Red Hat AI et les serveurs MCP, vous pouvez utiliser vos outils de construction habituels pour signer et vérifier des conteneurs d'agent, générer un SBOM (nomenclature logicielle), les stocker dans des dépôts d'artéfacts OCI, etc.

À l'instar des serveurs MCP, les agents conteneurisés peuvent faire l'objet d'une mise à l'échelle horizontale pour gérer une augmentation de la charge, être surveillés à l'aide d'outils d'observabilité standard et être régis par vos politiques de sécurité existantes.  Vous pouvez également analyser et valider en continu vos agents à l'aide de Red Hat Trusted Profile Analyzer afin d'identifier les vulnérabilités, les dépendances malveillantes et les violations de politiques.

Agents et sous-agents à utilisateur unique

Comme pour les serveurs MCP, tous les agents ne nécessitent pas une mise en conteneur. Les agents qui s'exécutent localement sur l'ordinateur portable d'un seul individu (tels que les sous-agents créés par un assistant de codage ou des agents d'automatisation personnels) peuvent ne pas nécessiter les ressources liées à la mise en paquet des conteneurs et au déploiement Kubernetes. Ces agents légers s'exécutent souvent en tant que processus enfants d'une application parente et partagent le contexte de sécurité de cette application.

Dans ces scénarios à utilisateur unique, l'objectif consiste à vérifier que l'application parente (l'IDE, l'assistant de codage ou l'outil d'automatisation) bénéficie d'une protection appropriée, plutôt que de conteneuriser chaque sous-composant. La gestion d'entreprise de ces agents locaux constitue un domaine en constante évolution. Les équipes doivent suivre les développements concernant les frameworks et les outils d'agent.

Conteneurs pour le sandboxing

Puisque les agents, les serveurs MCP et les modèles qui rédigent et exécutent du code introduisent de nouvelles vulnérabilités, une pratique exemplaire consiste à restreindre leur accès aux systèmes et à limiter les dommages potentiels. Ce concept est parfois appelé « agent sandbox » ou « code sandbox ». 

Les logiciels conteneurisés peuvent faire l'objet d'un déploiement avec des politiques réseau qui limitent les communications avec les services externes, de l'ouverture et du blocage de ports à l'inscription sur liste d'autorisation de sites web et de services spécifiques. Les fonctionnalités de contrôle d'accès basé sur les rôles (RBAC) de Kubernetes et de service mesh permettent un contrôle précis des accès. Les conteneurs OpenShift s'exécutent généralement sans privilèges root, ce qui limite leur accès aux données et aux ressources de calcul.  

Les conteneurs possèdent également des limites concernant l'utilisation du processeur et de la mémoire. Sur les postes de travail de développement, Podman exécute ses conteneurs sans privilèges root par défaut et restreint également l'accès du conteneur à votre réseau et à votre système de fichiers. OpenShift propose depuis longtemps l'isolement des conteneurs, et la Red Hat build of Podman Desktop permet également d'isoler les conteneurs sur les postes de travail des développeurs.

Le traitement incontrôlé par les agents constitue une autre préoccupation, car il peut mener à une attaque par déni de service. Avec OpenShift, les administrateurs de cluster peuvent définir des resource quotas pour chaque namespace, limitant ainsi les ressources de GPU, de processeur, de mémoire et de stockage qu'un seul projet peut consommer. Avec des quotas de ressources raisonnables, un agent incontrôlé ne peut pas priver d'autres charges de travail des ressources du cluster.

Bien qu'ils puissent s'exécuter sur un ordinateur portable personnel, nous avons constaté que l'exécution d'assistants de codage et d'agents personnels dans un conteneur est souvent bénéfique. Lorsqu'un agent s'exécute dans un conteneur en sandbox, il ne peut pas endommager les documents importants de votre ordinateur portable ni accéder à des données que vous ne souhaitez pas qu'il utilise. Cela signifie que vous pouvez approuver au préalable des actions courantes telles que la lecture ou l'écriture de fichiers, laisser l'agent s'exécuter avec moins de surveillance et simplement examiner le résultat final de la tâche attribuée.

Vous pouvez également démarrer plusieurs agents simultanément et les laisser travailler en parallèle, sans interférence mutuelle. Vous pouvez déployer des agents à exécution longue dans votre espace de noms personnel dans OpenShift, fermer votre ordinateur portable et rentrer chez vous pendant que les agents continuent de travailler pour vous. Vous pouvez même enregistrer le conteneur de l'agent pour préserver son état et reprendre son exécution plus tard. Deux projets émergents dans ce domaine sont paude pour les agents de codage et openclaw-installer pour OpenClaw.

Avantages de la conteneurisation des charges de travail d'IA

La conteneurisation des composants d'IA, modèles, serveurs MCP et agents, apporte des avantages considérables qui s'étendent à l'ensemble de l'organisation.

Sécurité de la chaîne d'approvisionnement logicielle

Les conteneurs peuvent être signés, attestés et vérifiés avant leur déploiement. Vous pouvez exiger que tous les composants d'IA soient créés par vos systèmes de CI/CD de confiance, analysés pour détecter les vulnérabilités et stockés dans des registres approuvés. Les attestations de provenance fournissent une piste d'audit qui montre précisément comment chaque artéfact a été produit.

Contrôle de version et restauration

Les images de conteneur sont immuables et balisées. Le personnel peut déployer des versions spécifiques, revenir aux versions précédentes en cas de problème et conserver un historique clair des déploiements.

Cohérence du déploiement

Une même image de conteneur s'exécute de manière identique dans les environnements de développement, de pré-production et de production, ce qui limite le risque d'erreurs liées à la copie des fichiers d'un environnement à un autre.

Observabilité

Les charges de travail conteneurisées s'intègrent aux infrastructures existantes de surveillance et de journalisation. Par exemple, Kagenti prend en charge le traçage OpenTelemetry (OTEL) prêt à l'emploi, ce qui permet de surveiller les opérations des agents à l'aide de votre pile d'observabilité standard.

Isolation et contrôle des accès

Enfin, les conteneurs offrent de grandes capacités de sandboxing (isolement de processus), ce qui aide à limiter le périmètre d'impact des problèmes éventuels.

Perspectives : Identité des charges de travail et architecture Zero Trust

La conteneurisation constitue également la base de modèles de sécurité plus avancés. Le projet Kagenti étudie l'intégration à SPIFFE/SPIRE pour l'identité des charges de travail et l'architecture Zero Trust pour les agents et les serveurs MCP. Bien que ces fonctionnalités émergent à peine, la conteneurisation et l'exécution des composants d'IA sur Kubernetes facilitent considérablement l'adoption de ces fonctions de sécurité à mesure qu'elles gagnent en maturité.

L'identité des charges de travail garantit que chaque agent ou serveur MCP possède une identité vérifiable par chiffrement, ce qui permet une communication sécurisée entre les services sans partage de secrets. Les principes du modèle Zero Trust, ne jamais faire confiance, toujours vérifier, deviennent applicables lorsque les composants d'IA sont conteneurisés et peuvent s'intégrer à l'infrastructure existante de gestion des identités et des accès.

Conclusion

Les conteneurs OCI fournissent une approche éprouvée et standardisée de la mise en paquet et de la distribution des logiciels qui s'étend naturellement aux charges de travail d'IA. En conteneurisant vos modèles d'IA, vos serveurs MCP et vos agents, vous apportez à votre pile d'IA la gouvernance, la sécurité et la maturité opérationnelle déjà appliquées à vos applications.

L'enjeu majeur consiste à reconnaître quand la conteneurisation apporte de la valeur. Les conteneurs s'avèrent essentiels pour les déploiements en production partagés et en réseau. Pour une utilisation locale par une personne seule, les conteneurs restent facultatifs, mais ils offrent des capacités de sandboxing et de portabilité sur tous les appareils, vous permettant de créer et déployer des applications où vous voulez Cette approche pragmatique permet d'appliquer le bon niveau de gouvernance à chaque composant tout en évitant une complexité inutile.

Les solutions Red Hat OpenShift AI, Red Hat Trusted Artifact Signer, Red Hat Trusted Profile Analyzer et Red Hat build of Podman constituent une base solide pour la gestion des charges de travail d'IA, du prototype à la production. Red Hat ajoute un support d'entreprise aux outils open source dotés de communautés actives afin d'aider les équipes à suivre le rythme des derniers développements en matière d'IA.