Identité de la charge de travail, pas de clés
BYOC sur Google Cloud
Exécuteurs dans votre projet GCP avec Workload Identity, SSD local et mise en cache Artifact Registry.
Identité de la charge de travail
Authentification fédérée sans clés de compte de service susceptibles de tourner ou de fuir.
SSD local
Attachez un NVMe local pour le profil de disque utilisé par les exécuteurs hébergés.
Registre des artefacts
Pull-through caching keeps image pulls inside your project.
Les déploiements GCP utilisent un groupe d'instances géré par forme d'exécuteur. Le SSD local est facultatif par forme, car il modifie les familles de machines disponibles.
Questions fréquentes
- Ai-je besoin de clés de compte de service ?
- Non. La fédération d'identité de charge de travail est utilisée à la place, il n'y a donc pas d'informations d'identification JSON de longue durée à alterner ou à fuir. Étendez au minimum la condition de confiance au propriétaire du référentiel.
- Le SSD local est-il important ?
- Considérablement. Les étapes CI gourmandes en fichiers sont liées au disque, et le NVMe local est ce qui donne aux exécuteurs BYOC le même profil que le produit hébergé. Cela limite également les familles de machines que vous pouvez utiliser, alors choisissez d'abord le disque.
- Les exécuteurs Windows sont-ils pris en charge sur GCP ?
- Le support est plus limité que sur AWS et Azure. Consultez la page des limitations Azure pour connaître la matrice de capacités actuelle des différents fournisseurs.
Votre prochain build pourrait être deux fois plus rapide, pour moitié prix
Commencez gratuitement. Repartir tient à la même ligne, et nous publions ce diff aussi.