doc-locale/fr-fr/ci/runners/hosted_runners/_index.md
{{< details >}}
{{< /details >}}
Utilisez les runners hébergés par GitLab pour exécuter vos jobs CI/CD sur GitLab.com et GitLab Dedicated. Ces runners peuvent créer, tester et déployer des applications dans différents environnements.
Pour créer et enregistrer vos propres runners, consultez les runners auto-gérés.
{{< details >}}
{{< /details >}}
Ces runners sont entièrement intégrés à GitLab.com et sont activés par défaut pour tous les projets, sans aucune configuration requise. Vos jobs peuvent s'exécuter sur :
Lorsque vous utilisez des runners hébergés :
sudo sans mot de passe.small.[!note] Les jobs traités par les runners hébergés sur GitLab.com expirent après 3 heures, quelle que soit la valeur de timeout configurée dans un projet.
La section suivante présente un aperçu des couches de protection supplémentaires intégrées qui renforcent la sécurité de l'environnement de build GitLab Runner.
Les runners hébergés pour GitLab.com sont configurés comme suit :
Le graphique suivant illustre le diagramme d'architecture des runners hébergés pour GitLab.com.
Pour plus d'informations sur la façon dont les runners s'authentifient et exécutent la charge utile du job, consultez Runner Execution Flow.
En plus d'isoler les runners sur le réseau, chaque VM de runner éphémère ne traite qu'un seul job et est supprimée immédiatement après l'exécution du job. Dans l'exemple suivant, trois jobs sont exécutés dans le pipeline d'un projet. Chacun de ces jobs s'exécute dans une VM éphémère dédiée.
Le job de build s'est exécuté sur runner-ns46nmmj-project-43717858, le job de test sur f131a6a2runner-new2m-od-project-43717858 et le job de deploy sur runner-tmand5m-project-43717858.
GitLab envoie la commande de suppression de la VM de runner éphémère à l'API Google Compute immédiatement après la fin du job CI. L'hyperviseur Google Compute Engine prend en charge la tâche de suppression sécurisée de la machine virtuelle et des données associées.
Pour plus d'informations sur la sécurité des runners hébergés pour GitLab.com, consultez :
Les runners hébergés partagent un cache distribué stocké dans un bucket Google Cloud Storage (GCS). Le contenu du cache non mis à jour au cours des 14 derniers jours est automatiquement supprimé, conformément à la politique de gestion du cycle de vie des objets. La taille maximale d'un artefact de cache téléchargé peut atteindre 5 Go une fois que le cache devient une archive compressée.
Pour plus d'informations sur le fonctionnement de la mise en cache, consultez Diagramme d'architecture des runners hébergés pour GitLab.com et Mise en cache dans GitLab CI/CD.
Les jobs qui s'exécutent sur des runners hébergés pour GitLab.com consomment des minutes de calcul allouées à votre espace de nommage. Le nombre de minutes que vous pouvez utiliser sur ces runners dépend des minutes de calcul incluses dans votre abonnement ou des minutes de calcul achetées en supplément.
Pour plus d'informations sur le facteur de coût appliqué au type de machine selon sa taille, consultez facteur de coût.
L'objectif SLO est de faire démarrer l'exécution de 90 % des jobs CI/CD en 120 secondes ou moins. Le taux d'erreur doit être inférieur à 0,5 %.
GitLab vise à mettre à jour vers la dernière version de GitLab Runner dans la semaine suivant sa release. Vous pouvez retrouver toutes les modifications majeures de GitLab Runner sous Dépréciations et suppressions.
{{< details >}}
{{< /details >}}
Si vous souhaitez contribuer à GitLab, les jobs sont pris en charge par la flotte de runners gitlab-shared-runners-manager-X.gitlab.com, dédiée aux projets GitLab et aux duplications communautaires associées.
Ces runners reposent sur le même type de machine que nos runners Linux x86-64 small. Contrairement aux runners hébergés pour GitLab.com, les runners hébergés pour les contributions de la communauté GitLab sont réutilisés jusqu'à 40 fois.
Comme tout le monde est encouragé à contribuer, ces runners sont gratuits.
{{< details >}}
{{< /details >}}
Les runners hébergés pour GitLab Dedicated sont créés à la demande et sont entièrement intégrés à votre instance GitLab Dedicated. Pour plus d'informations, consultez les runners hébergés pour GitLab Dedicated.
Les runners hébergés sur macOS et Windows ne peuvent exécuter des jobs que sur des images prises en charge. Vous ne pouvez pas utiliser votre propre image. Les images prises en charge ont le cycle de vie suivant :
Les nouvelles images sont publiées en version bêta. Cela nous permet de recueillir des retours et de résoudre les problèmes potentiels avant la disponibilité générale. Les jobs qui s'exécutent sur des images en version bêta ne sont pas couverts par l'accord de niveau de service. Si vous utilisez des images en version bêta, vous pouvez fournir des retours en créant un ticket.
Une image devient généralement disponible après avoir complété la phase version bêta et être considérée comme stable. Pour devenir généralement disponible, l'image doit satisfaire aux exigences suivantes :
Les jobs qui s'exécutent sur des images généralement disponibles sont couverts par l'accord de niveau de service défini.
Au maximum deux images généralement disponibles sont prises en charge simultanément. Après la publication d'une nouvelle image généralement disponible, l'image généralement disponible la plus ancienne devient dépréciée. Une image dépréciée n'est plus mise à jour et est supprimée après 3 mois.
Vous pouvez consulter une estimation de l'utilisation des minutes de calcul par les runners hébergés par GitLab sur GitLab Dedicated.