Looker PSC Southbound HTTPS Internet NEG Gitlab Self-Managed

Informacje o tym ćwiczeniu (w Codelabs)

41 minut

Ostatnia aktualizacja: 2 kwietnia 2025

Autorzy: Deepak Michael

1. Wprowadzenie

W tym laboratorium kodu utworzysz połączenie HTTPS z własnym środowiskiem GitLab za pomocą wewnętrznego systemu równoważenia obciążenia proxy TCP i internetowej grupy punktów końcowych sieci (NEG) wywoływanej z PSC Looker jako konsument usługi.

Private Service Connect to funkcja sieci Google Cloud, która umożliwia użytkownikom dostęp do usług zarządzanych z poziomu ich sieci VPC. Podobnie pozwala producentom usług zarządzanych hostować te usługi w swoich własnych oddzielnych sieciach VPC i oferować prywatne połączenie swoim klientom. Jeśli na przykład używasz Private Service Connect, aby uzyskać dostęp do Lookera, to Ty jesteś konsumentem usługi, a Google jest producentem usługi, jak pokazano na rysunku 1.

Rysunek 1.

Dostęp z południa, zwany też odwrotnym PSC, umożliwia konsumentowi utworzenie opublikowanej usługi jako producenta, aby umożliwić dostęp do punktów końcowych w sieci lokalnej, w sieci VPC, do usług zarządzanych i do Internetu. Połączenia wychodzące można wdrażać w dowolnym regionie, niezależnie od tego, gdzie wdrożono usługę Looker PSC, jak pokazano na rysunku 2.

Rysunek 2.

Czego się nauczysz

Wymagania związane z siecią
Tworzenie usługi producenta Private Service Connect
Tworzenie punktu końcowego Private Service Connect w Lookerze
Nawiązywanie połączenia z samodzielnie zarządzaną instancją GitLab

Czego potrzebujesz

Projekt Google Cloud z uprawnieniami właściciela
Konto i repozytorium GitLab
Istniejąca instancja PSC Lookera

2. Co utworzysz

Utworzysz sieć producenta looker-psc-demo, aby wdrożyć wewnętrzny równoważenie obciążenia proxy tcp i opublikować NEG w Internecie jako usługę za pomocą Private Service Connect (PSC). Po opublikowaniu wykonaj te czynności, aby potwierdzić dostęp do usługi Producer:

Tworzenie w Lookerze punktu końcowego PSC powiązanego z przyłączem usługi producenta
Użyj konsoli Looker, aby utworzyć nowy projekt i przetestować połączenie HTTPS ze środowiskiem GitLab Self-Managed.

3. Wymagania związane z siecią

Poniżej znajdziesz zestawienie wymagań sieciowych dla sieci producenta. Konsumentem w tym przypadku jest instancja PSC narzędzia Looker.

Komponenty	Opis
VPC (looker-psc-demo)	Sieć VPC w trybie niestandardowym
Podsieć NAT PSC	Pakiety z sieci VPC konsumenta są tłumaczone za pomocą źródłowego NAT (SNAT), tak aby ich oryginalne źródłowe adresy IP były konwertowane na źródłowe adresy IP z podsieci NAT w sieci VPC producenta.
Reguła przekierowania PSC w podsieci	Służy do przydzielenia adresu IP dla regionalnego wewnętrznego systemu równoważenia obciążenia TCP serwera proxy.
Podsieć grupy punktów końcowych sieci PSC	Służy do przydzielania adresu IP grupie punktów końcowych sieci.
Podsieć tylko-proxy	Każdemu proxy systemu równoważenia obciążenia przypisany jest wewnętrzny adres IP. Pakiety wysyłane z serwera proxy do maszyny wirtualnej lub punktu końcowego backendu mają źródłowy adres IP z podsieci tylko-proxy.
Internetowa grupa punktów końcowych sieci	Zasób używany do zdefiniowania zewnętrznego backendu dla systemu równoważenia obciążenia skonfigurowanego jako FQDN określający domeny FQDN Gitlab Self-Managed na potrzeby lokalnych zasobów. Internet FQDN wykonuje wyszukiwanie DNS w VPC w celu rozwiązania.
Usługa backendu	Usługa backendu pełni funkcję łącznika między systemem równoważenia obciążenia a zasobami backendu. W samouczku usługa backendu jest powiązana z NEG w internecie.

4. Topologia ćwiczenia z programowania

5. Konfiguracja i wymagania

Konfiguracja środowiska w samodzielnym tempie

Zaloguj się w konsoli Google Cloud i utwórz nowy projekt lub użyj istniejącego. Jeśli nie masz jeszcze konta Gmail ani Google Workspace, musisz je utworzyć.

Nazwa projektu to wyświetlana nazwa uczestników tego projektu. Jest to ciąg znaków, którego nie używają interfejsy API Google. Zawsze możesz ją zaktualizować.
Identyfikator projektu jest niepowtarzalny we wszystkich projektach Google Cloud i nie można go zmienić (po ustawieniu). Konsola Cloud automatycznie generuje unikalny ciąg znaków. Zwykle nie ma znaczenia, jaki to ciąg. W większości laboratoriów z kodem musisz podać identyfikator projektu (zwykle oznaczony jako PROJECT_ID). Jeśli nie podoba Ci się wygenerowany identyfikator, możesz wygenerować inny losowy. Możesz też spróbować użyć własnego adresu e-mail, aby sprawdzić, czy jest on dostępny. Po wykonaniu tego kroku nie można go zmienić. Pozostanie on na stałe w ramach projektu.
Informacyjnie: istnieje jeszcze 3 wartość, numer projektu, której używają niektóre interfejsy API. Więcej informacji o wszystkich 3 wartościach znajdziesz w dokumentacji.

Następnie musisz włączyć rozliczenia w konsoli Cloud, aby korzystać z zasobów i interfejsów API Cloud. Przejście przez ten samouczek nie będzie wiązać się z wysokimi kosztami, a być może nawet nie będzie trzeba nic płacić. Aby wyłączyć zasoby i uniknąć obciążenia opłatami po zakończeniu samouczka, możesz usunąć utworzone zasoby lub usunąć projekt. Nowi użytkownicy Google Cloud mogą skorzystać z bezpłatnego okresu próbnego, w którym mają do dyspozycji środki w wysokości 300 USD.

Uruchomienie Cloud Shell

Google Cloud można obsługiwać zdalnie z laptopa, ale w tym przypadku będziesz korzystać z Google Cloud Shell, czyli środowiska wiersza poleceń działającego w chmurze.

W konsoli Google Cloud kliknij ikonę Cloud Shell na pasku narzędzi w prawym górnym rogu:

Uzyskanie dostępu do środowiska i połączenie się z nim powinno zająć tylko kilka chwil. Po jego zakończeniu powinno wyświetlić się coś takiego:

Ta maszyna wirtualna zawiera wszystkie potrzebne narzędzia dla programistów. Zawiera stały katalog domowy o pojemności 5 GB i działa w Google Cloud, co znacznie poprawia wydajność sieci i uwierzytelnianie. Wszystkie zadania w tym CodeLab możesz wykonać w przeglądarce. Nie musisz niczego instalować.

6. Zanim zaczniesz

Włącz interfejsy API

W Cloud Shell sprawdź, czy identyfikator projektu jest skonfigurowany:

gcloud config list project
gcloud config set project [YOUR-PROJECT-ID]
project=[YOUR-PROJECT-ID]
region=[YOUR-REGION]
echo $project
echo $region

Włącz wszystkie niezbędne usługi:

gcloud services enable compute.googleapis.com

7. Tworzenie sieci VPC producenta

Sieć VPC

W Cloud Shell wykonaj te czynności:

gcloud compute networks create looker-psc-demo --subnet-mode custom

Tworzenie podsieci

Podsieci PSC zostaną powiązane z przyłączem usługi PSC na potrzeby tłumaczenia adresów sieciowych.

W Cloud Shell utwórz podsieć NAT PSC:

gcloud compute networks subnets create producer-psc-nat-subnet --network looker-psc-demo --range 172.16.10.0/28 --region $region --purpose=PRIVATE_SERVICE_CONNECT

W Cloud Shell utwórz podsieć reguły przekierowania producenta:

gcloud compute networks subnets create producer-psc-fr-subnet --network looker-psc-demo --range 172.16.20.0/28 --region $region --enable-private-ip-google-access

W Cloud Shell utwórz regionalną podrzędną sieć tylko-proxy dla producenta:

gcloud compute networks subnets create $region-proxy-only-subnet \
  --purpose=REGIONAL_MANAGED_PROXY \
  --role=ACTIVE \
  --region=$region \
  --network=looker-psc-demo \
  --range=10.10.10.0/24

Rezerwowanie adresu IP systemu równoważenia obciążenia

W Cloud Shell zarezerwuj wewnętrzny adres IP dla systemu równoważenia obciążenia:

gcloud compute addresses create internet-neg-lb-ip \
  --region=$region \
  --subnet=producer-psc-fr-subnet

W Cloud Shell wyświetl zarezerwowany adres IP.

gcloud compute addresses describe internet-neg-lb-ip \
  --region=$region | grep -i address:

Przykładowe dane wyjściowe:

user@cloudshell$ gcloud compute addresses describe internet-neg-lb-ip   --region=$region | grep -i address:
address: 172.16.20.2

Konfigurowanie internetowej grupy punktów końcowych sieci

Utwórz internetową grupę punktów końcowych sieci i ustaw parametr –network-endpoint-type na internet-fqdn-port (nazwa hosta i port, pod którym można uzyskać dostęp do zewnętrznego backendu).

W Cloud Shell utwórz NEG internetowy używany do uzyskiwania dostępu do instancji Gitlab Self-Managed, gitlabonprem.com.

gcloud compute network-endpoint-groups create gitlab-self-managed-internet-neg \
    --network-endpoint-type=INTERNET_FQDN_PORT \
    --network=looker-psc-demo \
    --region=$region

W Cloud Shell zaktualizuj internetową grupę punktów końcowych NEG gitlab-self-managed-internet-neg, podając FQDN gitlabonprem.com i port 443.

gcloud compute network-endpoint-groups update gitlab-self-managed-internet-neg \
    --add-endpoint="fqdn=gitlabonprem.com,port=443" \
    --region=$region

Tworzenie reguł zapory sieciowej

Aby umożliwić IAP połączenie z instancjami maszyn wirtualnych, utwórz regułę zapory sieciowej, która:

dotyczy wszystkich instancji maszyn wirtualnych, które mają być dostępne przez IAP;
Zezwala na ruch przychodzący z zakresu adresów IP 35.235.240.0/20. Ten zakres zawiera wszystkie adresy IP, których IAP używa do przekierowywania TCP.

W Cloud Shell utwórz regułę zapory sieciowej IAP.

gcloud compute firewall-rules create ssh-iap-looker-psc-demo \
    --network looker-psc-demo \
    --allow tcp:22 \
    --source-ranges=35.235.240.0/20

8. Tworzenie usługi producenta

Tworzenie komponentów systemu równoważenia obciążenia

W Cloud Shell wykonaj te czynności:

gcloud compute backend-services create producer-backend-svc  --protocol=tcp --region=$region --load-balancing-scheme=INTERNAL_MANAGED

gcloud compute backend-services add-backend producer-backend-svc --network-endpoint-group=gitlab-self-managed-internet-neg --network-endpoint-group-region=$region --region=$region

W Cloud Shell utwórz docelowy serwer proxy TCP, aby kierować żądania do usługi backendu:

gcloud compute target-tcp-proxies create producer-lb-tcp-proxy \
      --backend-service=producer-backend-svc  \
      --region=$region

Utwórz regułę przekierowania (wewnętrzny system równoważenia obciążenia serwera proxy TCP) za pomocą poniższej składni.

W Cloud Shell wykonaj te czynności:

gcloud compute forwarding-rules create producer-gitlab-self-managed-fr\
     --load-balancing-scheme=INTERNAL_MANAGED \
     --network-tier=PREMIUM \
     --network=looker-psc-demo \
     --subnet=producer-psc-fr-subnet \
     --address=internet-neg-lb-ip \
     --target-tcp-proxy=producer-lb-tcp-proxy \
     --target-tcp-proxy-region=$region \
     --region=$region \
     --ports=443

Tworzenie załącznika usługi

W Cloud Shell utwórz załącznik usługi gitlab-self-managed-svc-attachment-https z automatyczną akceptacją, która umożliwia połączenie usługi Looker Core z załącznikiem usługi. Jeśli chcesz kontrolować dostęp do załącznika usługi, możesz skorzystać z opcji wyraźnych akceptacji.

gcloud compute service-attachments create gitlab-self-managed-svc-attachment-https --region=$region --producer-forwarding-rule=producer-gitlab-self-managed-fr --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=producer-psc-nat-subnet

Następnie pobierz i zapisz przyłącze usługi wymienione w identyfikatorze URI samolinku rozpoczynającym się od projects, aby skonfigurować punkt końcowy PSC w Lookerze.

selfLink: projects/<your-project-id>/regions/<your-region>/serviceAttachments/gitlab-self-managed-svc-attachment-https

W Cloud Shell wykonaj te czynności:

gcloud compute service-attachments describe gitlab-self-managed-svc-attachment-https --region=$region

Przykład:

connectionPreference: ACCEPT_AUTOMATIC
creationTimestamp: '2025-03-04T18:55:42.254-08:00'
description: ''
enableProxyProtocol: false
fingerprint: MlY9GLLGsgE=
id: '9103522880241140673'
kind: compute#serviceAttachment
name: gitlab-self-managed-svc-attachment-https
natSubnets:
- https://www.googleapis.com/compute/v1/projects/$projectid/regions/us-central1/subnetworks/producer-psc-nat-subnet
pscServiceAttachmentId:
  high: '115404658846991336'
  low: '9103522880241140673'
reconcileConnections: false
region: https://www.googleapis.com/compute/v1/projects/$projectid/regions/us-central1
selfLink: https://www.googleapis.com/compute/v1/projects/$projectid/regions/us-central1/serviceAttachments/gitlab-self-managed-svc-attachment-https
targetService: https://www.googleapis.com/compute/v1/projects/$projectid/regions/us-central1/forwardingRules/producer-gitlab-self-managed-fr

W Cloud Console:

Usługi sieciowe → Private Service Connect → Opublikowane usługi

9. Nawiązywanie połączenia z punktem końcowym PSC w Looker

W następnej sekcji powiążesz załącznik usługi Producers z PSC Looker Core, używając flagi –psc-service-attachment w Cloud Shell dla jednej domeny.

W Cloud Shell utwórz powiązanie psc, aktualizując te parametry zgodnie ze swoim środowiskiem:

INSTANCE_NAME: nazwa instancji Lookera (podstawowej usługi Google Cloud).
DOMAIN_1: gitlabonprem.com
SERVICE_ATTACHMENT_1: identyfikator URI zarejestrowany podczas opisywania załącznika usługi, gitlab-self-managed-svc-attachment-https.
REGION: region, w którym hostowana jest instancja Lookera (podstawowej usługi Google Cloud).

W Cloud Shell wykonaj te czynności:

gcloud looker instances update INSTANCE_NAME \
--psc-service-attachment  domain=DOMAIN_1,attachment=SERVICE_ATTACHMENT_URI_1 \
--region=REGION

Przykład:

gcloud looker instances update looker-psc-instance \
--psc-service-attachment  domain=gitlabonprem.com,attachment=projects/$project/regions/$region/serviceAttachments/gitlab-self-managed-svc-attachment-https \
--region=$region

W Cloud Shell sprawdź, czy stan połączenia serviceAttachments to „ACCEPTED” (akceptowany). Zaktualizuj go, podając nazwę instancji PSC Looker: INSTANCE_NAME.

gcloud looker instances describe [INSTANCE_NAME] --region=$region --format=json

Przykład:

gcloud looker instances describe looker-psc-instance --region=$region --format=json

Przykład:

{
  "adminSettings": {},
  "createTime": "2024-08-23T00:00:45.339063195Z",
  "customDomain": {
    "domain": "cosmopup.looker.com",
    "state": "AVAILABLE"
  },
  "encryptionConfig": {},
  "lookerVersion": "24.12.28",
  "name": "projects/$project/locations/$region/instances/looker-psc-instance",
  "platformEdition": "LOOKER_CORE_ENTERPRISE_ANNUAL",
  "pscConfig": {
    "allowedVpcs": [

    "projects/$project/global/networks/looker-psc-demo"
    ],
    "lookerServiceAttachmentUri": "projects/t7ec792caf2a609d1-tp/regions/$region/serviceAttachments/looker-psc-f51982e2-ac0d-48b1-91bb-88656971c183",
    "serviceAttachments": [
      {
        "connectionStatus": "ACCEPTED",
        "localFqdn": "gitlabonprem.com",
        "targetServiceAttachmentUri": "projects/$project/regions/$region/serviceAttachments/gitlab-self-managed-svc-attachment-https"
      }
    ]
  },
  "pscEnabled": true,
  "state": "ACTIVE",
  "updateTime": "2024-08-30T17:47:33.440271635Z"
}

Weryfikowanie punktu końcowego PSC w Cloud Console

W Cloud Console możesz zweryfikować połączenie z PSC

W Cloud Console:

Looker → Instancja Lookera → Szczegóły

10. rozpoznawanie nazw DNS

W następnej sekcji utwórz instancję GCE i za pomocą polecenia PING sprawdź, czy domenę gitlabonprem.com, która jest zarządzana samodzielnie, można rozwiązać w DNS. Zgodnie z oczekiwaniami rozpoznawanie nazw nie powiedzie się, ponieważ wymaga strefy DNS prywatnej dla gitlabonprem.com.

11. Tworzenie instancji GCE

W Cloud Shell utwórz instancję GCE, która służy do sprawdzania poprawności rozwiązania DNS.

gcloud compute instances create gce-dns-lookup \
    --project=$projectid \
    --machine-type=e2-micro \
    --image-family debian-11 \
    --no-address \
    --image-project debian-cloud \
    --zone us-central1-a \
    --subnet=producer-psc-fr-subnet

Zaloguj się na maszynę consumer-vm za pomocą IAP w Cloud Shell, aby sprawdzić łączność z usługą producenta, wykonując polecenie curl. W przypadku przekroczenia limitu czasu spróbuj ponownie.

gcloud compute ssh gce-dns-lookup --project=$projectid --zone=us-central1-a --tunnel-through-iap

Z poziomu systemu operacyjnego przeprowadź test PING do gitlabonprem.com. Wystąpienie błędu jest oczekiwane.

ping gitlabonprem.com

Przykład:

user@gce-dns-lookup:~$ ping gitlabonprem.com
ping: gitlabonprem.com: Name or service not known

Wyjście z systemu operacyjnego i powrót do terminala Cloud Shell.

exit

12. Tworzenie prywatnej strefy DNS

W Cloud Shell utwórz prywatną strefę Cloud DNS.

gcloud dns --project=$projectid managed-zones create gitlab-self-managed --description="" --dns-name="gitlabonprem.com." --visibility="private" --networks="https://compute.googleapis.com/compute/v1/projects/$projectid/global/networks/looker-psc-demo"

W Cloud Shell utwórz rekord A z adresem IP instancji Gitlab zarządzanej samodzielnie, 192.168.10.4.

gcloud dns --project=$projectid record-sets create gitlabonprem.com. --zone="gitlab-self-managed" --type="A" --ttl="300" --rrdatas="192.168.10.4"

gcloud compute ssh gce-dns-lookup --project=$projectid --zone=us-central1-a --tunnel-through-iap

Z systemu operacyjnego przeprowadź test PING do gitlabonprem.com, który przekształca się w 192.168.10.4.

ping gitlabonprem.com

Przykład:

user@gce-dns-lookup:~$ ping gitlabonprem.com
PING gitlabonprem.com (192.168.10.4) 56(84) bytes of data

Wyjście z systemu operacyjnego i powrót do terminala Cloud Shell.

exit

13. Połączenia hybrydowe

Adres FQDN gitlabonprem.com może teraz zostać przekształcony w adres IP hostowany lokalnie. Następnie musisz skonfigurować sieć hybrydową (np. połączenie międzysieciowe lub sieć VPN o wysokiej dostępności) między siecią VPC looker-psc-demo a siecią lokalną, aby umożliwić połączenie.

Poniżej znajdziesz instrukcje konfigurowania połączenia hybrydowego NEG z siecią lokalną:

Wybór usługi dotyczącej łączności sieciowej | Google Cloud
W architekturze z centrum i promieniem z połączeniem równorzędnym sieci VPC usługa NEG hybrydowa jest wdrażana w tej samej sieci VPC co router Cloud Router (centrum).
Sprawdź, czy lokalne zapory sieciowe zostały zaktualizowane, aby uwzględnić zakres podsieci tylko-proxy, ponieważ ta podsieć służy jako adres IP źródłowy do komunikacji z zadaniami lokalnymi.
Rozgłaszaj podsieć tylko-proxy z routera Cloud Router jako niestandardowe rozgłaszanie trasy.

14. Testowanie połączenia

W następnych krokach użyjesz konsoli Looker do utworzenia projektu, który zweryfikuje połączenie HTTPS z witryną gitlabonprem.com. W tym celu wykonasz czynności opisane w artykule Konfigurowanie i testowanie połączenia Git.

15. Czyszczenie danych

Usuwanie komponentów laboratorium z jednego terminala Cloud Shell

gcloud compute service-attachments delete gitlab-self-managed-svc-attachment-https --region=$region -q

gcloud compute forwarding-rules delete producer-gitlab-self-managed-fr --region=$region -q

gcloud compute target-tcp-proxies delete producer-lb-tcp-proxy --region=$region -q

gcloud compute backend-services delete producer-backend-svc --region=$region -q

gcloud compute network-endpoint-groups delete gitlab-self-managed-internet-neg --region=$region -q

gcloud compute instances delete gce-dns-lookup --zone=us-central1-a -q

gcloud compute networks subnets delete producer-psc-fr-subnet producer-psc-nat-subnet $region-proxy-only-subnet --region=$region -q

gcloud dns --project=$projectid record-sets delete gitlabonprem.com. --zone="gitlab-sel
f-managed" --type="A"

gcloud dns --project=$projectid managed-zones delete gitlab-self-managed 

gcloud compute networks delete looker-psc-demo -q

16. Gratulacje

Gratulacje! Konfiguracja i weryfikacja łączności z instancją GitLab zarządzaną samodzielnie za pomocą konsoli Looker obsługiwanej przez Private Service Connect zostały zakończone pomyślnie.

Utworzono infrastrukturę producenta i poznano sposób tworzenia punktu końcowego NEG w internecie, usługi producenta i punktu końcowego PSC Lookera, które umożliwiają nawiązywanie połączenia z usługą producenta.

Looker PSC Southbound HTTPS Internet NEG Gitlab Self-Managed

1. Wprowadzenie

Czego się nauczysz

Czego potrzebujesz

2. Co utworzysz

3. Wymagania związane z siecią

4. Topologia ćwiczenia z programowania

5. Konfiguracja i wymagania

Konfiguracja środowiska w samodzielnym tempie

Uruchomienie Cloud Shell

6. Zanim zaczniesz

Włącz interfejsy API

7. Tworzenie sieci VPC producenta

Sieć VPC

Tworzenie podsieci

Rezerwowanie adresu IP systemu równoważenia obciążenia

Konfigurowanie internetowej grupy punktów końcowych sieci

Tworzenie reguł zapory sieciowej

8. Tworzenie usługi producenta

Tworzenie komponentów systemu równoważenia obciążenia

Tworzenie załącznika usługi

9. Nawiązywanie połączenia z punktem końcowym PSC w Looker

Weryfikowanie punktu końcowego PSC w Cloud Console

10. rozpoznawanie nazw DNS

11. Tworzenie instancji GCE

12. Tworzenie prywatnej strefy DNS

13. Połączenia hybrydowe

14. Testowanie połączenia

15. Czyszczenie danych

16. Gratulacje

Co dalej?

Więcej informacji i filmy

Dokumenty referencyjne