GitLab Artifact Central : un registre unique pour gouverner vos artefacts

Chaque build logiciel s'appuie sur des paquets open source, des images de base et des bibliothèques, auxquels s'ajoute votre code. Lorsqu'un de ces composants est manquant ou a dérivé, le build échoue. À la vitesse des agents, ces échecs se multiplient, et aucune équipe ne peut les résoudre manuellement.

La multiplication des registres projet par projet aggrave la situation, car les règles de conservation, les limites de stockage et les droits de publication sont tous gérés séparément au sein de chaque projet. Cette conception au niveau du projet fonctionne tant qu'une personne configure chaque registre manuellement, mais elle atteint ses limites dès que des agents s'exécutent en continu sur des centaines de projets.

Lors de GitLab Transcend, nous avons annoncé GitLab Artifact Central : un registre unique au niveau de l'organisation qui remplace des centaines de registres au niveau des projets. Ainsi, chaque opération de pull ou de publication, qu'elle soit effectuée par un humain ou un agent, passe par le même point de contrôle réglementé afin que les équipes de plateforme puissent assembler le bon logiciel du premier coup.

Découvrez pourquoi nous avons développé GitLab Artifact Central et comment il peut aider votre équipe.

Une politique unique, appliquée partout

Dans GitLab, les règles de conservation, les limites de stockage et les droits de publication sont tous gérés séparément au sein du registre de paquets et de conteneurs gratuit de chaque projet. GitLab Artifact Central fait passer cette gestion à un niveau supérieur. Les équipes définissent les règles de conservation, les paramètres de quota et les politiques d'accès une seule fois au niveau de l'organisation, au lieu de les recréer dans chaque projet.

Tous les dépôts sont fermés par défaut : l'appartenance à l'organisation constitue une condition d'accès, et non un droit en soi. L'appartenance à l'organisation seule ne déverrouille aucun dépôt tant qu'un rôle ne l'autorise pas explicitement. Nous avons créé quatre rôles spécifiques aux artefacts : Administrateur, Gestionnaire, Contributeur et Lecteur. Ces rôles sont distincts des rôles de projet existants de GitLab, de sorte que l'octroi d'un accès à un dépôt ne modifie en rien les privilèges de l'utilisateur ailleurs.

Une seule URL pour la publication, la mise en proxy ou les deux

Au lieu de parcourir une page wiki interne, les équipes de développement se réfèrent à une seule URL pour tout. GitLab Artifact Central y parvient grâce à trois types de dépôts :

• Hébergé : les paquets et images privés que vos équipes créent et publient.
• Distant : un proxy devant une source externe, comme Docker Hub ou Maven Central, dont la connexion est testée avant que quoi que ce soit n'en dépende.
• Virtuel : un point de terminaison unique qui regroupe les dépôts hébergés et distants. GitLab vérifie d'abord le dépôt hébergé, puis bascule vers la source distante. Le premier pull externe est mis en cache, de sorte que les pulls suivants proviennent directement de GitLab sans passer par Internet.

Les dépôts virtuels sont particulièrement utiles pour les équipes qui comparent GitLab à d'autres solutions de gestion d'artefacts. Ils offrent aux équipes de développement l'expérience familière d'un point de terminaison unique, sans qu'elles aient à se soucier de l'emplacement d'un artefact. Que l'artefact ait été créé en interne ou extrait d'un registre externe, les équipes le demandent de la même façon. Pendant la période bêta, GitLab Artifact Central prend en charge Maven, npm, Docker et OCI. D'autres formats seront ajoutés ultérieurement.

Tout retracer automatiquement

Voici ce qui est difficile à reproduire en dehors de GitLab. Chaque artefact publié via GitLab Artifact Central conserve automatiquement l'origine de son build : quel pipeline l'a créé, de quelle branche et de quel commit il provient, qui a déclenché le job. Comme il s'agit de la même plateforme qui a exécuté le build, le registre dispose déjà de ces informations.

L'authentification fonctionne de la même manière. La publication et le pull utilisent CI_JOB_TOKEN, l'identité dont disposent déjà vos pipelines, tant pour les utilisateurs que pour les agents. Un agent qui publie ou effectue un pull via des pipelines CI utilise exactement ce même token de job, et non un compte de service ajouté après coup avec des autorisations séparées à gérer. Avec un registre autonome, remonter la piste d'un artefact jusqu'à sa source implique de corréler séparément les identifiants entre votre système CI et votre registre, à l'aide d'un script dont une personne doit assurer la responsabilité et la maintenance. Avec GitLab Artifact Central, le pipeline, la branche, le commit et le job sont déjà associés à l'artefact lui-même.

Une visibilité instantanée sur tout ce que vous publiez

GitLab Artifact Central réside sur la même plateforme que votre code, vos merge requests et vos pipelines. Ainsi, les artefacts publiés depuis la CI conservent l'origine de leur build : le pipeline qui les a créés, le commit et la personne qui les a publiés.

Nous prévoyons ensuite de connecter ces informations à l'ensemble de votre organisation via GitLab Orbit, afin que la question « Lesquels de mes services en cours d'exécution sont concernés par cette vulnérabilité ? » obtienne une réponse unique, au lieu de nécessiter une recherche manuelle dans quatre ou cinq outils différents.

Associer GitLab Artifact Central à GitLab Dependency Firewall

GitLab Dependency Firewall, un produit GitLab distinct désormais disponible en accès anticipé pour les clients GitLab Premium et GitLab Ultimate, fonctionne dès son installation avec GitLab Artifact Central. Avec GitLab Dependency Firewall, vous pouvez bloquer les paquets à risque avant même qu'ils n'atteignent un build. Vous ajoutez sa vérification à chaque pipeline à l'aide de la CLI glab, de sorte que la couverture est assurée pipeline par pipeline, quel que soit le gestionnaire de paquets utilisé par vos équipes. Nous prévoyons ensuite de renforcer l'intégration entre ces deux produits, afin qu'une seule politique applicable à l'ensemble de votre organisation bloque les paquets à risque en fonction de leur vulnérabilité, de leur licence ou de leur ancienneté dès leur récupération.

Deux avantages d'un même registre

Voyons ce que cela donne du point de vue d'un développeur qui livre du code, puis de celui de l'équipe de plateforme qui veille à la cohérence de l'ensemble.

Un développeur qui publie depuis la CI : votre pipeline publie un artefact Maven à l'aide du token de job qu'il possède déjà, sans qu'il soit nécessaire de gérer de nouveaux secrets. Si ce même développeur a besoin d'un paquet interne en plus d'un élément provenant de Maven Central, il pointe vers une URL de dépôt virtuel unique et laisse GitLab Artifact Central déterminer où se trouve chaque élément.

Une équipe de plateforme qui définit une politique une seule fois : au lieu de configurer des règles sur des centaines de projets distincts, un administrateur définit une seule fois les quotas de stockage et les règles d'accès aux dépôts au niveau de l'organisation. Chaque dépôt sous-jacent hérite ensuite de ces paramètres. Lorsque vous devez savoir quel volume de données votre entreprise stocke, et où, la réponse se trouve dans un seul tableau de bord.

Migrer vos artefacts

La plupart des entreprises ne partent pas de zéro, et abandonner brutalement un registre existant n'est pas réaliste. Avec GitLab Artifact Central, vous pouvez ajouter vos dépôts existants en tant que sources distantes derrière un dépôt virtuel, de sorte que les équipes de développement accèdent à une seule URL et que les artefacts ne sont transférés que lorsqu'un build les demande réellement. Nul besoin de copie en masse, de fenêtre de migration le week-end ni de transfert de pétaoctets de données sur votre réseau.

Votre ancien registre reste le système de référence. Lorsque vous êtes prêt, vous convertissez cette source distante en dépôt hébergé sur GitLab Artifact Central. Votre migration gagne ainsi en sécurité et se déroule progressivement.

Essayez GitLab Artifact Central gratuitement en version bêta

GitLab Artifact Central est disponible dès aujourd'hui en version bêta sur GitLab.com, avec une disponibilité sur GitLab Self-Managed prévue dans le courant du mois. La version bêta est entièrement gratuite et ne nécessite aucun achat. Nous analysons l'utilisation pour définir la tarification avant la disponibilité générale, et nous vous communiquerons plus de détails à ce moment-là.

Aidez-nous à continuer à développer GitLab Artifact Central

Nous n'en serions pas là sans nos partenaires qui utilisent GitLab Artifact Central dans le cadre de workflows réels depuis plusieurs semaines. Leurs retours ont déjà influencé la version que nous lançons aujourd'hui, et vos commentaires façonneront les prochaines évolutions.

Aucune invitation n'est requise pour participer à la version bêta de GitLab Artifact Central : inscrivez-vous simplement sur notre site web, et un membre de notre équipe vous contactera pour l'activer sur votre compte. Si vous ne disposez pas encore d'un compte GitLab, vous pouvez également vous inscrire à la version bêta, et un membre de notre équipe vous contactera.

Nous avons hâte de découvrir ce que vous allez créer.

Regardez le replay de notre événement GitLab Transcend dès maintenant ! Découvrez les démonstrations des nouvelles fonctionnalités de la plateforme et comment tirer parti de la rapidité de l'IA agentique sur l'ensemble du cycle de vie logiciel.