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. So können Sie Builds als Reaktion auf Ereignisse wie Commit-Pushes oder Merge-Anfragen ausführen, die mit Ihrem GitLab Enterprise Edition-Repository verknüpft sind.

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

Hinweis

  • Aktivieren Sie die APIs für Cloud Build, Secret Manager, Compute Engine und Service Networking, falls sie noch nicht aktiviert sind.

    Rollen, die zum Aktivieren von APIs erforderlich sind

    Zum Aktivieren von APIs benötigen Sie die Berechtigung serviceusage.services.enable. Wenn Sie das Projekt erstellt haben, haben Sie diese Berechtigung wahrscheinlich bereits über die Inhaberrolle (roles/owner). Andernfalls können Sie diese Berechtigung über die Rolle „Service Usage-Administrator“ (roles/serviceusage.serviceUsageAdmin) erhalten. Informationen zum Zuweisen von Rollen

    APIs aktivieren

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 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 folgendermaßen vor, um sicherzustellen, dass Ihre Instanz erreichbar ist, bevor Sie Trigger erstellen:

  1. Aktivieren Sie die Service Directory API.

  2. Sie benötigen die Rolle Project IAM Admin für das ProjektGoogle Cloud , in dem Sie Ihren Service Directory-Dienst erstellen möchten. Informationen zum Zuweisen von IAM-Rollen finden Sie unter Zugriff auf Cloud Build-Ressourcen konfigurieren.

  3. Richten Sie einen Service Directory-Dienst ein, indem Sie die folgenden Schritte ausführen:

    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 Ihrer Cloud Build-Hostverbindung angeben.

    2. Konfigurieren Sie einen Dienst in Ihrem Namespace.

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

      Wenn Sie einen Endpunkt konfigurieren, 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 bietet auch die Einbindung in Dienste wie Load Balancer und Google Kubernetes Engine (GKE). Weitere Informationen finden Sie unter Service Directory und Load Balancing – Übersicht oder Service Directory für GKE – Übersicht.

  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 \
   --member="serviceAccount:$CLOUD_BUILD_SERVICE_AGENT" \
   --role="roles/servicedirectory.viewer"

    Ersetzen Sie Folgendes:

    • PROJECT_ID ist Ihre Cloud Build-Projekt-ID.
    • PROJECT_ID_CONTAINING_SERVICE_DIRECTORY ist die ID IhresGoogle Cloud -Projekts, das Ihr Service Directory enthält.

  5. Gewähren Sie dem Cloud Build-Dienst-Agent Zugriff auf die VPC-Netzwerkressource:

    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_NETWORK_RESOURCE \
   --member="serviceAccount:$CLOUD_BUILD_SERVICE_AGENT" \
   --role="roles/servicedirectory.pscAuthorizedService"

    Ersetzen Sie Folgendes:

    • PROJECT_ID ist Ihre Cloud Build-Projekt-ID.
    • PROJECT_ID_CONTAINING_NETWORK_RESOURCE ist die ID IhresGoogle Cloud -Projekts, das Ihre Netzwerkressource enthält.

  6. 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.

  7. 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 ein selbst signiertes oder privates Zertifikat verwenden, wenn Sie Ihren GitLab Enterprise Edition-Host mit Cloud Build verbinden, müssen Sie den Host-URI als Subject Alternative Name (SAN) Ihres Zertifikats festlegen.

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

Service Directory verwenden, um Hosts außerhalb von Google Cloudzu erreichen

Service Directory verwendet den IP-Adressbereich 35.199.192.0/19, um Ihren Host außerhalb von Google Cloudzu verbinden. Sie müssen diesen Bereich einer Zulassungsliste in Ihrer Firewall hinzufügen. Außerdem muss Ihr privates Netzwerk so konfiguriert sein, dass dieser Bereich über die Cloud VPN- oder Cloud Interconnect-Verbindung weitergeleitet wird.

Wenn Ihre Verbindung einen Cloud Router verwendet, können Sie Ihre Verbindung so konfigurieren, dass der Bereich an Ihr privates Netzwerk kommuniziert wird.

Weitere Informationen finden Sie unter Privaten Netzwerkzugriff konfigurieren.

Cloud Load Balancing verwenden, um Hosts außerhalb von Google Cloudzu erreichen

Wenn Ihre Netzwerkkonfiguration es nicht zulässt, dass der Service Directory-IP-Adressbereich 35.199.192.0/19 an Cloud VPN oder Cloud Interconnect weitergeleitet wird, können Sie mit Cloud Load Balancing einen Load Balancer erstellen, der Traffic an Ihren Host weiterleitet.

Verwenden Sie beim Erstellen des Service Directory-Endpunkts die IP-Adresse der Weiterleitungsregel des Load Balancers anstelle der IP-Adresse Ihres Hosts. Sie können beim Erstellen des Endpunkts einen internen HTTPS-Load-Balancer oder einen internen TCP-Load-Balancer (Transmission Control Protocol) verwenden.

Beachten Sie beim Erstellen des TCP-Load-Balancers Folgendes:

  • Zum Erreichen Ihres Hosts ist nur eine Netzwerk-Endpunktgruppe (NEG) für Hybridkonnektivität erforderlich.
  • Der TCP-Load-Balancer benötigt den unverschlüsselten privaten Schlüssel für Ihr SSL-Zertifikat nicht.
  • In Ihrer Cloud VPN-Einrichtung muss Cloud Router mit globalem dynamischem Routing verwendet werden. Wenn Ihr Cloud VPN statisches Routing verwendet, können Sie stattdessen einen Proxy verwenden, der Cloud Service Mesh verwendet. Weitere Informationen finden Sie unter Network Edge-Dienste für Hybridbereitstellungen einrichten.

Weitere Informationen zum Erstellen eines HTTPS-Load-Balancers finden Sie unter Internen Application Load Balancer mit Hybridkonnektivität einrichten. Weitere Informationen zum Erstellen eines TCP-Load-Balancers finden Sie unter Regionalen internen Proxy-Network Load Balancer mit Hybridkonnektivität einrichten.

Datenweitergabe

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

Die folgenden Daten werden zwischen Cloud Build und GitLab Enterprise Edition ausgetauscht:

  • Google Cloud -Projekt-ID
  • Triggername

Nächste Schritte