Workload-Identität, keine Schlüssel
BYOC auf Google Cloud
Läufer in Ihrem GCP-Projekt mit Workload Identity, lokaler SSD und Artifact Registry-Caching.
Workload-Identität
Verbundauthentifizierung ohne Dienstkontoschlüssel, die rotieren oder offengelegt werden müssen.
Lokale SSD
Hängen Sie lokales NVMe für das Festplattenprofil an, das die gehosteten Läufer verwenden.
Artefaktregister
Beim Pull-Through-Caching bleiben Bild-Pulls in Ihrem Projekt.
GCP-Bereitstellungen verwenden eine verwaltete Instanzgruppe pro Runner-Shape. Für lokale SSDs ist eine Opt-in-Option pro Form erforderlich, da dadurch die für Sie verfügbaren Maschinenfamilien geändert werden.
Häufige Fragen
- Benötige ich Dienstkontoschlüssel?
- Nein. Stattdessen wird die Workload-Identitätsföderation verwendet, sodass keine langlebigen JSON-Anmeldeinformationen rotiert oder verloren gehen müssen. Beschränken Sie die Vertrauensbedingung mindestens auf den Repository-Eigentümer.
- Spielt lokale SSD eine Rolle?
- Erheblich. Dateiintensive CI-Schritte sind festplattengebunden und lokales NVMe gibt BYOC-Läufern das gleiche Profil wie das gehostete Produkt. Außerdem wird dadurch eingeschränkt, welche Maschinenfamilien Sie verwenden können. Wählen Sie daher zuerst die Festplatte aus.
- Werden Windows-Runner auf GCP unterstützt?
- Der Support ist eingeschränkter als bei AWS und Azure. Auf der Seite „Azure-Einschränkungen“ finden Sie die aktuelle Funktionsmatrix aller Anbieter.
Ihr nächster Build könnte doppelt so schnell sein — zum halben Preis
Kostenlos starten. Der Wechsel zurück ist dieselbe eine Zeile — auch dieses Diff veröffentlichen wir.