Bei der Einbindung von Secure Source Manager in andere CI/CD-Lösungen hängt der empfohlene Ansatz oft von Ihrer Netzwerkumgebung ab. Durch die Einbindung in ein privates Netzwerk wird sichergestellt, dass Ihre gesamte CI/CD-Lösung – vom Code-Repository über den Build und die Artefaktspeicherung bis hin zu den Bereitstellungstools – in einem sicheren privaten Netzwerk verbleibt.
Eine private Netzwerkarchitektur verwendet diese Schlüsselfunktionen:
- Secure Source Manager
- Private Service Connect
- Private Cloud Build-Pools
Empfohlener Workflow: Developer Connect
Für die meisten Nutzer, die eine Einbindung in ein privates Netzwerk zwischen Secure Source Manager und Cloud Build einrichten, ist Developer Connect aufgrund seiner Einfachheit die empfohlene Wahl.
Während Developer Connect Git-Proxys IAM für die Zugriffssteuerung verwenden, befindet sich der Proxy-Endpunkt im öffentlichen Internet. Für einen umfassenden Ansatz, bei dem alle Endpunkte in einem privaten Netzwerk verbleiben, können Sie mit VPC Service Controls den Zugriff auf den Proxy-Endpunkt einschränken.
Eine detaillierte Anleitung zum Einrichten dieser Einbindung finden Sie unter Secure Source Manager mit Cloud Build über Developer Connect einbinden.
Alternativer Workflow: Private Cloud Build-Pools
Wenn bestimmte Anforderungen verhindern, dass Sie einen Git-Proxy verfügbar machen, auch wenn er durch IAM und VPC Service Controls geschützt ist, verwenden Sie eine alternative Einrichtung, um Secure Source Manager über einen Private Service Connect-Endpunkt und private Cloud Build-Pools mit Cloud Build zu verbinden.
Eine detaillierte Anleitung zum Einrichten dieser Einbindung finden Sie unter Cloud Build mit einer Private Service Connect-Instanz verbinden.