Looker PSC Southbound HTTPS Internet NEG Gitlab Self-Managed

1. Wprowadzenie

W tym ćwiczeniu wykonasz połączenie HTTPS w kierunku południowym ze środowiskiem GitLab Self-Managed za pomocą wewnętrznego systemu równoważenia obciążenia proxy TCP i grupy punktów końcowych sieci internetowej (NEG) wywoływanej z usługi Looker PSC jako konsument usługi.

Private Service Connect to funkcja sieci Google Cloud, która umożliwia konsumentom prywatny dostęp do usług zarządzanych z poziomu sieci VPC. Podobnie umożliwia producentom usług zarządzanych hostowanie tych usług we własnych, oddzielnych sieciach VPC i oferowanie prywatnego połączenia z klientami. Na przykład gdy używasz Private Service Connect do uzyskiwania dostępu do Lookera, jesteś konsumentem usługi, a Google jest producentem usług, co widać na ilustracji 1.

Rysunek 1.

Dostęp wychodzący, zwany też odwróconym PSC, umożliwia konsumentowi utworzenie opublikowanej usługi jako producenta, aby umożliwić Lookerowi dostęp do punktów końcowych lokalnie, w sieci VPC, do usług zarządzanych i internetu. Połączenia wychodzące można wdrażać w dowolnym regionie, niezależnie od tego, gdzie jest wdrożona usługa PSC Looker, 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 instancją GitLab Self-Managed

Czego potrzebujesz

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

2. Co utworzysz

Utworzysz sieć producenta, looker-psc-demo, aby wdrożyć wewnętrzny system równoważenia obciążenia proxy TCP i internetową grupę NEG opublikowaną jako usługa za pomocą usługi Private Service Connect (PSC). Po opublikowaniu wykonaj te czynności, aby sprawdzić dostęp do usługi Producer:

Utwórz w Looker punkt końcowy PSC powiązany z przyłączem usługi producenta.
Użyj Konsoli Lookera, aby utworzyć nowy projekt i przetestować łączność HTTPS ze środowiskiem GitLab Self-Managed.

3. Wymagania związane z siecią

Poniżej znajdziesz zestawienie wymagań sieciowych dla sieci producenta. Konsumentem w tym Codelabs jest instancja Looker PSC.

Komponenty	Opis
VPC (looker-psc-demo)	Sieć VPC w trybie niestandardowym
Podsieć NAT PSC	Pakiety z sieci VPC klienta są tłumaczone za pomocą źródłowego NAT (SNAT), dzięki czemu ich pierwotne źródłowe adresy IP są konwertowane na źródłowe adresy IP z podsieci NAT w sieci VPC producenta.
Podsieć reguły przekierowania PSC	Służy do przydzielania adresu IP regionalnemu wewnętrznemu systemowi 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żdy serwer proxy systemu równoważenia obciążenia ma przypisany 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 definiowania zewnętrznego backendu systemu równoważenia obciążenia skonfigurowanego jako pełna i jednoznaczna nazwa domeny (FQDN) oznaczająca pełną i jednoznaczną nazwę domeny Gitlab Self-Managed on-premise. Internetowy FQDN wykonuje wyszukiwanie DNS w sieci VPC w celu rozpoznania nazwy.
Usługa backendu	Usługa backendu pełni funkcję pomostu między systemem równoważenia obciążenia a zasobami backendu. W samouczku usługa backendu jest powiązana z internetową grupą punktów końcowych sieci.

4. Topologia ćwiczeń z programowania

5. Konfiguracja i wymagania

Samodzielne konfigurowanie środowiska

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óry nie jest używany przez interfejsy API Google. Zawsze możesz ją zaktualizować.
Identyfikator projektu jest unikalny we wszystkich projektach Google Cloud i nie można go zmienić po ustawieniu. Konsola Cloud automatycznie generuje unikalny ciąg znaków. Zwykle nie musisz się nim przejmować. W większości ćwiczeń z programowania musisz odwoływać się do identyfikatora projektu (zwykle oznaczanego jako PROJECT_ID). Jeśli wygenerowany identyfikator Ci się nie podoba, możesz wygenerować inny losowy identyfikator. Możesz też spróbować własnej nazwy i sprawdzić, czy jest dostępna. Po tym kroku nie można go zmienić i pozostaje on taki przez cały czas trwania projektu.
Warto wiedzieć, że istnieje też trzecia wartość, numer projektu, której używają niektóre interfejsy API. Więcej informacji o tych 3 wartościach znajdziesz w dokumentacji.

Następnie musisz włączyć płatności w konsoli Cloud, aby korzystać z zasobów i interfejsów API Google Cloud. Wykonanie tego laboratorium nie będzie kosztować dużo, a może nawet nic. Aby wyłączyć zasoby i uniknąć naliczania opłat po zakończeniu tego samouczka, możesz usunąć utworzone zasoby lub projekt. Nowi użytkownicy Google Cloud mogą skorzystać z programu bezpłatnego okresu próbnego o wartości 300 USD.

Uruchamianie Cloud Shell

Z Google Cloud można korzystać zdalnie na laptopie, ale w tym module praktycznym będziesz używać 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 zakończeniu powinno wyświetlić się coś takiego:

Ta maszyna wirtualna zawiera wszystkie potrzebne narzędzia dla programistów. Zawiera również stały katalog domowy o pojemności 5 GB i działa w Google Cloud, co znacznie zwiększa wydajność sieci i usprawnia proces uwierzytelniania. Wszystkie zadania w tym laboratorium 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

Podsieć PSC będzie powiązana z przyłączem usługi PSC na potrzeby translacji 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ą podsieć tylko-proxy 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ę NEG i ustaw wartość –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 internetową grupę NEG używaną 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 sieci gitlab-self-managed-internet-neg, podając pełną i jednoznaczną nazwę domeny 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

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

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

Utwórz załącznik usługi

W Cloud Shell utwórz połączenie z usługą gitlab-self-managed-svc-attachment-https z automatycznym zatwierdzaniem, które umożliwia połączenie Looker Core z tym połączeniem. Jeśli chcesz kontrolować dostęp do przyłączenia usługi, możesz użyć opcji wyraźnych zatwierdzeń.

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 uzyskaj i zanotuj załącznik usługi wymieniony w identyfikatorze URI selfLink zaczynają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 konsoli Cloud otwórz:

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

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

W następnej sekcji powiążesz przyłącze usługi producenta z usługą PSC Looker Core za pomocą flagi –psc-service-attachment w Cloud Shell dla pojedynczej domeny.

W Cloud Shell utwórz powiązanie PSC, aktualizując te parametry, aby pasowały do Twojego środowiska:

INSTANCE_NAME: nazwa instancji Lookera (podstawowej usługi Google Cloud).
DOMAIN_1: gitlabonprem.com
SERVICE_ATTACHMENT_1: identyfikator URI zarejestrowany podczas opisywania przyłącza usługi gitlab-self-managed-svc-attachment-https.
REGION: region, w którym jest hostowana 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”. Zaktualizuj go, podając nazwę instancji PSC Looker.

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"
}

Sprawdzanie poprawności punktu końcowego PSC w Cloud Console

W konsoli Cloud możesz sprawdzić połączenie PSC.

W konsoli Cloud otwórz:

Looker → Instancja Lookera → Szczegóły

10. rozpoznawanie nazw DNS

W sekcji poniżej utwórz instancję GCE i sprawdź rozpoznawanie nazw DNS w przypadku instancji Gitlab Self-Managed, gitlabonprem.com, wykonując polecenie PING. Zgodnie z oczekiwaniami rozpoznawanie się nie powiedzie i będzie wymagać prywatnej strefy DNS dla domeny gitlabonprem.com.

11. Tworzenie instancji GCE

W Cloud Shell utwórz instancję GCE, która będzie służyć do weryfikowania rozpoznawania 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ę wirtualną konsumenta za pomocą IAP w Cloud Shell, aby sprawdzić połączenie z usługą producenta, wykonując polecenie curl. Ponów próbę, jeśli nastąpi przekroczenie limitu czasu.

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

W systemie operacyjnym wykonaj polecenie PING dla domeny gitlabonprem.com. Oczekiwany jest błąd.

ping gitlabonprem.com

Przykład:

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

Wyjdź z systemu operacyjnego, aby wrócić 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 zawierający adres IP instancji Gitlab Self-Managed, czyli 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 poziomu systemu operacyjnego wykonaj polecenie PING do gitlabonprem.com, które rozwiązuje się na adres 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

Wyjdź z systemu operacyjnego, aby wrócić do terminala Cloud Shell.

exit

13. Połączenia hybrydowe

Pełna i jednoznaczna nazwa domeny gitlabonprem.com może być teraz rozpoznawana za pomocą prywatnego adresu IP hostowanego lokalnie. Następnie należy 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ć łączność.

Aby nawiązać połączenie hybrydowej grupy punktów końcowych sieci z lokalną infrastrukturą, wykonaj te czynności:

Wybór usługi połączenia sieciowe | Google Cloud
W architekturze centrum i promieni z połączeniem równorzędnym VPC hybrydowa grupa NEG jest wdrażana w tej samej sieci VPC co Cloud Router (centrum).
Sprawdź, czy lokalne zapory sieciowe są zaktualizowane, aby uwzględniać zakres podsieci tylko-proxy, ponieważ ta podsieć służy jako źródłowy adres IP do komunikacji z lokalnymi obciążeniami.
Rozgłaszanie podsieci tylko-proxy z routera Cloud Router jako niestandardowego rozgłaszania tras

14. Testowanie połączenia

W kolejnych krokach użyjesz konsoli Looker do utworzenia projektu, aby sprawdzić łączność HTTPS z witryną gitlabonprem.com. Wykonaj 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. Udało Ci się skonfigurować i zweryfikować połączenie z instancją GitLab Self-Managed za pomocą konsoli Looker opartej na Private Service Connect.

Utworzyliśmy infrastrukturę producenta, dowiedzieliśmy się, jak utworzyć internetową grupę NEG, usługę producenta i punkt końcowy PSC Lookera, które umożliwiają połączenie 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 ćwiczeń z programowania

5. Konfiguracja i wymagania

Samodzielne konfigurowanie środowiska

Uruchamianie 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

Utwórz załącznik usługi

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

Sprawdzanie poprawności 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

Dokumentacja