Réduction des goulots d'étranglement CI/CD avec GitLab

Les ingénieurs plateforme et DevOps passent trop de temps à rassembler les informations dispersées entre différents outils fragmentés et à gérer une infrastructure qui devrait simplement fonctionner.

Deux nouvelles fonctionnalités GitLab, disponibles actuellement en version bêta, abordent ce problème sous différents angles mais partagent le même objectif : donner aux praticiens un contrôle direct sur l'infrastructure CI/CD dont ils dépendent, sans ajouter un nouvel outil tiers. L'une affiche les données de performance au niveau des jobs directement à l'endroit où vous surveillez les pipelines. L'autre simplifie la façon dont vous extrayez les images de conteneurs à partir de plusieurs registres avec une mise en cache intégrée.

Ces deux fonctionnalités sont désormais ouvertes aux retours. Vos commentaires nous aideront à façonner les prochaines versions.

Indicateurs de performance des jobs CI/CD

• Niveaux disponibles : GitLab Premium, GitLab Ultimate
• Statut : Version bêta à disponibilité limitée sur GitLab.com ; disponible sur GitLab Self-Managed et GitLab Dedicated lorsque ClickHouse est configuré

À l'heure actuelle, il n'existe aucun moyen simple de savoir quand la durée d'un job commence à augmenter ou quels jobs ralentissent l'exécution de votre pipeline. La plupart des équipes construisent des tableaux de bord personnalisés ou examinent manuellement les logs pour répondre à des questions basiques telles que :

• Quels jobs sont les plus lents ?
• Où les taux d'échec augmentent-ils ?
• Quelle étape constitue le véritable goulot d'étranglement ?

Les indicateurs de performance des jobs CI/CD changent cela en ajoutant un nouveau panneau axé sur les jobs à la page d'analyse CI/CD au niveau du projet.

Pour chaque job, vous pouvez voir :

• La durée typique (P50, médiane) et la durée dans le pire des cas (P95) du job, pour que vous puissiez rapidement comparer les exécutions normales et les exécutions les plus lentes
• Le taux d'échec, pour que vous puissiez identifier les jobs fragiles ou instables
• Le nom et l’étape du job, couvrant par défaut les 30 derniers jours

Le tableau est triable, consultable par nom de job et paginé, ce qui permet aux équipes de plateforme d'obtenir une vue unique pour répondre aux questions qui nécessitaient auparavant des outils distincts ou des rapports personnalisés.

Essayez cette fonctionnalité

• Accédez à votre projet et sélectionnez Analyse > Données d'analyse CI/CD.
• Recherchez le panneau des indicateurs de performance des jobs CI/CD et triez-les par durée ou par taux d'échec pour trouver vos jobs les plus lents ou les moins fiables.

Documentation

• Analyses CI/CD – Indicateurs de performance des jobs CI/CD

À venir

Nous travaillons actuellement sur le regroupement par étape pour que vous puissiez consulter les indicateurs agrégés dans vos étapes de build, de test et de déploiement, et comprendre rapidement où concentrer vos efforts d'optimisation.

Partagez vos retours :

• Epic des indicateurs de performance des jobs CI/CD

Registre virtuel de conteneurs

Niveau : GitLab Premium, GitLab Ultimate Statut : Version bêta, compatible API dans la version 18.9

La plupart des organisations qui intègrent des images de conteneurs dans les pipelines CI/CD s'appuient sur plusieurs registres : Docker Hub, Harbor, Quay et les registres internes, pour n'en citer que quelques-uns. Gérer l'authentification, la disponibilité et la mise en cache sur l'ensemble de ces registres représente une charge opérationnelle qui ralentit les pipelines et introduit une certaine fragilité.

Le registre virtuel de conteneurs vous permet de créer un point de terminaison GitLab unique qui extrait des données de plusieurs sources de conteneurs en amont avec une mise en cache intégrée.

Au lieu de configurer les identifiants et la disponibilité pour chaque registre dans votre configuration de pipeline, vous pouvez :

• Diriger vos pipelines vers un point de terminaison de registre virtuel GitLab
• Configurer plusieurs registres en amont (Docker Hub, Harbor, Quay et autres utilisant l'authentification par jeton à longue durée de vie)
• Laisser GitLab résoudre automatiquement les extractions d'images, avec une mise en cache pull-through pour réduire les coûts de bande passante et améliorer la fiabilité

Pour les équipes qui évaluent GitLab comme remplacement de registre de conteneurs, cela comble une lacune critique en matière de capacités. Pour les équipes qui gèrent déjà des worflows de conteneurs multi-registres, cela centralise la gestion des images dans GitLab et réduit les extractions répétées.

Ce que la version bêta prend en charge aujourd'hui

• Registres en amont qui utilisent l'authentification par jeton à longue durée de vie : Docker Hub, Harbor, Quay et autres registres compatibles
• Mise en cache pull-through pour que les images couramment utilisées soient fournies par GitLab après le premier pull
• Configuration API-first, avec gestion de l'interface utilisateur en cours++

Les registres de fournisseurs cloud qui nécessitent une authentification IAM (tels que Amazon Elastic Container Registry, Google Artifact Registry et Azure Container Registry) sont à l'étude pour de futures itérations.

Essayez cette fonctionnalité

• Le registre virtuel de conteneurs est compatible API dans la version 18.9.
• SaaS (GitLab.com) : demandez l'accès via votre CSM ou en commentant le ticket ci-dessous pour que le feature flag soit activé pour votre groupe.
• GitLab Self-managed : activez le feature flag et configurez le registre virtuel à l'aide de l'API.

Documentation

• API du registre virtuel de conteneurs
• Extraire des images de conteneurs à partir du registre virtuel

Regardez cette démonstration du registre virtuel de conteneurs disponible en version bêta :

Partagez vos retours :

• Ticket lié aux retours sur le registre virtuel de conteneurs

Aidez-nous à construire GitLab

Tous les membres de la communauté GitLab sont des contributeurs. Nous avons développé ces versions bêta en fonction des demandes de la communauté.

• Les indicateurs de performance des jobs CI/CD ont été proposés par des équipes qui n'avaient aucun moyen facile de voir quand les temps de build commençaient à évoluer dans la mauvaise direction, ou quels jobs nuisaient à la fiabilité du pipeline.
• Le registre virtuel de conteneurs a été proposé par des entreprises clientes qui géraient plusieurs registres et cherchaient à réduire la prolifération d'outils et les coûts de bande passante tout en évaluant GitLab comme registre central.

Vos retours façonnent ce que nous créons. Essayez ces versions bêta et partagez votre expérience dans les tickets mentionnés dans cet article.

Cet article le premier d'une série de versions bêta Core DevOps que nous prévoyons de mettre en avant. D'autres suivront tout au long de l'année, et nous espérons que vous nous aiderez à les rendre aussi utiles que possible.