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

Auf dieser Seite wird beschrieben, wie Sie die Triggerfunktion in einer GitLab Enterprise Edition-Instanz aktivieren können, wenn Ihre Instanz in einem privaten Netzwerk gehostet wird.

Hinweis

  • Aktivieren Sie die APIs 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 Rolle „Inhaber“ (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 private Pools für den Build verwenden. Das Projekt mit Ihrem VPC-Netzwerk kann sich in einem anderen Projekt befinden als das Projekt mit Ihrem Service Directory-Dienst. Gehen Sie so 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 dasGoogle Cloud -Projekt, in dem Sie den Service Directory-Dienst erstellen möchten. Informationen zum Zuweisen von IAM-Rollen finden Sie unter Zugriff auf Cloud Build-Ressourcen konfigurieren.

  3. So richten Sie einen Service Directory-Dienst ein:

    1. Namespace für Ihr Google Cloud -Projekt konfigurieren

      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. Endpunkt für Ihren registrierten Dienst konfigurieren

      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 bietet auch die Integration in Dienste wie Load-Balancer und Google Kubernetes Engine (GKE). Weitere Informationen finden Sie unter Service Directory und Load Balancing oder Service Directory für GKE.

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

    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. Dem Cloud Build-Dienst-Agent Zugriff auf VPC-Netzwerkressourcen gewähren:

    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, erstellen Sie einen neuen privaten Pool.

  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 beim Verbinden Ihres GitLab Enterprise Edition-Hosts mit Cloud Build ein selbstsigniertes oder privates Zertifikat einfügen, müssen Sie den Host-URI als alternativen Antragstellernamen (Subject Alternative Name, SAN) Ihres Zertifikats festlegen.

Ihr GitLab Enterprise Edition-Trigger löst jetzt automatisch Builds in Ihrer GitLab Enterprise Edition-Instanz basierend auf Ihrer Konfiguration aus.

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

Service Directory verwendet den IP-Adressbereich 35.199.192.0/19, um eine Verbindung zu Ihrem Host außerhalb von Google Cloudherzustellen. Sie müssen diesen Bereich der 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 für Ihre Verbindung ein Cloud Router verwendet wird, können Sie die Verbindung so konfigurieren, dass der Bereich an Ihr privates Netzwerk übertragen 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, den Service Directory-IP-Adressbereich 35.199.192.0/19 an Cloud VPN oder Cloud Interconnect weiterzuleiten, können Sie mit Cloud Load Balancing einen Load Balancer erstellen, der den Traffic an Ihren Host weiterleitet.

Wenn Sie den Service Directory-Endpunkt erstellen, verwenden Sie die IP-Adresse der Weiterleitungsregel des Load Balancers anstelle der IP-Adresse Ihres Hosts. Sie können einen internen HTTPS-Load-Balancer oder einen internen TCP-Load-Balancer (Transmission Control Protocol) verwenden, wenn Sie Ihren Endpunkt erstellen.

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

  • Für den Zugriff auf Ihren Host ist nur eine Netzwerk-Endpunktgruppe (NEG) mit Hybridkonnektivität erforderlich.
  • Für den TCP-Load-Balancer ist der unverschlüsselte private Schlüssel für Ihr SSL-Zertifikat nicht erforderlich.
  • Für Ihre Cloud VPN-Einrichtung muss Cloud Router mit globalem dynamischen Routing verwendet werden. Wenn Ihr Cloud VPN statisches Routing verwendet, können Sie stattdessen einen Proxy verwenden, der Cloud Service Mesh nutzt. Weitere Informationen finden Sie unter Edge-Netzwerkdienste 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.

Datenfreigabe

Die von Cloud Build an GitLab Enterprise Edition gesendeten Daten helfen Ihnen, Trigger anhand des Namens zu identifizieren und Build-Ergebnisse in Ihren GitLab Enterprise Edition-Repositories zu sehen.

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

  • Google Cloud Projekt-ID
  • Triggername

Nächste Schritte