Repositories aus GitLab Enterprise Edition in einem privaten Netzwerk erstellen

Mit Cloud Build können Sie Trigger erstellen, um Builds aus Repositories zu erstellen, die auf GitLab Enterprise Edition gehostet werden. Dadurch 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 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 den Build mit privaten Pools erstellen. Das Projekt, das Ihr VPC-Netzwerk enthält, kann sich in einem anderen Projekt befinden als das Projekt, das Ihren Service Directory-Dienst enthält. Gehen Sie vor dem Erstellen von Triggern so vor, dass die Instanz erreichbar ist:

  1. Aktivieren Sie die Service Directory API.

  2. Achten Sie darauf, dass 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. Richten Sie mit den folgenden Schritten einen Service Directory-Dienst ein:

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

      Die Region, die Sie in Ihrem Namespace angeben, muss mit der Region übereinstimmen, die Sie in der Cloud Build-Hostverbindung angeben.

    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 lässt sich auch in Dienste wie Load-Balancer und Google Kubernetes Engine (GKE) einbinden. Weitere Informationen finden Sie unter Service Directory und Load-Balancing – Übersicht oder Service Directory for GKE – Übersicht.

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

    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. Gewähren Sie Ihrem Cloud Build-Dienstkonto service-${PROJECT_NUMBER}@gcp-sa-cloudbuild.iam.gserviceaccount.com die Rolle Service Directory Viewer.

  6. Weisen Sie Ihrem Cloud Build-Dienstkonto die Rolle Autorisierter Private Service Connect-Dienst zu, um Zugriff auf Ihre VPC-Netzwerkressource service-${PROJECT_NUMBER}@gcp-sa-cloudbuild.iam.gserviceaccount.com zu gewähren. Sie müssen die Rolle in dem Projekt zuweisen, 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

Mit den Daten, die von Cloud Build an GitLab Enterprise Edition gesendet werden, können Sie Trigger anhand des Namens identifizieren und Build-Ergebnisse in Ihren GitLab Enterprise Edition-Repositories ansehen.

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

  • Google Cloud-Projekt-ID
  • Triggername

Nächste Schritte