Repositories aus der GitLab Enterprise Edition in einem privaten Netzwerk erstellen

Mit Cloud Build können Sie Trigger für Builds aus Repositories erstellen, die in GitLab Enterprise Edition gehostet werden. So können Sie Builds als Reaktion auf Ereignisse wie Commit-Push-Vorgänge oder Zusammenführungsanfragen ausführen, die mit Ihrem GitLab Enterprise Edition-Repository verknüpft sind.

Auf dieser Seite wird erläutert, wie Sie die Triggerfunktion für eine GitLab Enterprise Edition-Instanz aktivieren, wenn Ihre Instanz in einem privaten Netzwerk gehostet wird.

Hinweise

  • Cloud Build, Secret Manager, Compute Engine, and Service Networking APIs aktivieren.

    Aktivieren Sie die APIs

Repositories aus der GitLab Enterprise Edition in einem privaten Netzwerk erstellen

Wenn Ihre GitLab Enterprise Edition-Instanz nur innerhalb eines VPC-Netzwerk zugänglich ist, müssen Sie einen Service Directory-Dienst einrichten und mit privaten Pools erstellen. Das Projekt, das Ihr VPC-Netzwerk enthält, kann sich in einem anderen Projekt befinden als dem, das Ihren Service Directory-Dienst enthält. Folgen Sie der nachstehenden Anleitung, um dafür zu sorgen, dass die Instanz erreichbar ist, bevor Sie Trigger erstellen:

  1. Aktivieren Sie die Service Directory API.

  2. Prüfen Sie, ob dem Google Cloud-Projekt, in dem Sie den Service Directory-Dienst erstellen möchten, die Rolle Projekt-IAM-Administrator zugewiesen wurde. Informationen zum Zuweisen von IAM-Rollen finden Sie unter Zugriff auf Cloud Build-Ressourcen konfigurieren.

  3. Führen Sie die folgenden Schritte aus, um einen Service Directory-Dienst einzurichten:

    1. Konfigurieren Sie einen Namespace für Ihr Google Cloud-Projekt.

      Die im Namespace angegebene Region muss mit der Region übereinstimmen, die Sie in der Cloud Build-Hostverbindung angegeben haben.

    2. Konfigurieren Sie einen Dienst in Ihrem Namespace.

    3. Konfigurieren Sie einen Endpunkt für Ihren registrierten Dienst.

      Beim Konfigurieren eines Endpunkts müssen Sie eine interne IP-Adresse verwenden und eine HTTPS-Portnummer angeben, damit Cloud Build Ihren Dienst erreichen kann.

    Weitere Informationen zur Konfiguration des privaten Netzwerkzugriffs finden Sie unter Privaten Netzwerkzugriff konfigurieren. Service Directory ermöglicht auch die Einbindung in Dienste wie Load-Balancer und die Google Kubernetes Engine (GKE). Weitere Informationen finden Sie unter Übersicht über Service Directory und Load-Balancing oder Übersicht über Service Directory für GKE.

  4. Gewähren Sie Service Directory Zugriff auf den Cloud Build-Dienst-Agent:

    export PROJECT_NUMBER=$(gcloud projects describe PROJECT_ID --format="value(projectNumber)")
export CLOUD_BUILD_SERVICE_AGENT="service-${PROJECT_NUMBER}@gcp-sa-cloudbuild.iam.gserviceaccount.com"
gcloud projects add-iam-policy-binding PROJECT_ID_CONTAINING_SERVICE_DIRECTORY_RESOURCE \
   --member="serviceAccount:${CLOUD_BUILD_SERVICE_AGENT}" \
   --role="roles/servicedirectory.viewer"

    Wobei:

    • PROJECT_ID ist Ihre Google Cloud-Projekt-ID.
    • PROJECT_ID_CONTAINING_SERVICE_DIRECTORY_RESOURCE ist die Projekt-ID, die Ihre Service Directory-Ressource enthält.

  5. Weisen Sie Ihrem Cloud Build-Dienstkonto service-${PROJECT_NUMBER}@gcp-sa-cloudbuild.iam.gserviceaccount.com die Rolle Service Directory Viewer zu.

  6. Weisen Sie Ihrem Cloud Build-Dienstkonto die Rolle Autorisierter Private Service Connect-Dienst zu, um den Zugriff auf Ihre VPC-Netzwerkressource service-${PROJECT_NUMBER}@gcp-sa-cloudbuild.iam.gserviceaccount.com zu ermöglichen. Sie müssen die Rolle in dem Projekt gewähren, das Ihr VPC-Netzwerk enthält.

  7. Verwenden Sie private Pools, um Ihre Builds auszuführen. Wenn Sie noch keinen privaten Pool erstellt haben, finden Sie weitere Informationen unter Neuen privaten Pool erstellen.

  8. Folgen Sie der Anleitung zum Erstellen eines GitLab Enterprise Edition-Triggers, um Repositories zu erstellen, die auf einer GitLab Enterprise Edition-Instanz gehostet werden.

    Wenn Sie beim Verbinden Ihres GitLab Enterprise Edition-Hosts mit Cloud Build ein selbst signiertes oder privates Zertifikat verwenden, müssen Sie den Host-URI als alternativen Antragstellernamen (Subject Alternative Name, SAN) Ihres Zertifikats festlegen.

Ihr GitLab Enterprise Edition-Trigger ruft jetzt automatisch Builds auf Ihrer GitLab Enterprise Edition-Instanz basierend auf Ihrer Konfiguration auf.

Datenfreigabe

Mithilfe der von Cloud Build an GitLab Enterprise Edition gesendeten Daten können Sie Trigger anhand des Namens identifizieren und Build-Ergebnisse in Ihren Repositories der GitLab Enterprise Edition anzeigen.

Die folgenden Daten werden von Cloud Build und GitLab Enterprise Edition gemeinsam genutzt:

  • Google Cloud-Projekt-ID
  • Triggername

Nächste Schritte