NEG Internet HTTPS vers le sud Looker PSC Gitlab autogéré

À propos de cet atelier de programmation

41 minutes

Dernière mise à jour : 2 avril 2025

Rédigé par Deepak Michael

Cette page a été traduite par l'API Cloud Translation.

1. Introduction

Dans cet atelier de programmation, vous allez établir une connexion HTTPS vers le sud avec votre environnement GitLab autogéré à l'aide d'un équilibreur de charge proxy TCP interne et d'un groupe de points de terminaison réseau (NEG) Internet appelé à partir de Looker PSC en tant que consommateur de services.

Private Service Connect est une fonctionnalité de mise en réseau de Google Cloud qui permet aux clients d'accéder à des services gérés en mode privé depuis leur réseau VPC. De même, il permet aux producteurs de services gérés d'héberger ces services dans leurs propres réseaux VPC séparés et de proposer une connexion privée à leurs clients. Par exemple, lorsque vous utilisez Private Service Connect pour accéder à Looker, vous êtes le client du service et Google est le producteur de services, comme illustré dans la figure 1.

Figure 1.

L'accès sud, également appelé PSC inverse, permet au client de créer un service publié en tant que producteur pour autoriser Looker à accéder aux points de terminaison sur site, dans un VPC, aux services gérés et à Internet. Les connexions vers le sud peuvent être déployées dans n'importe quelle région, quel que soit l'emplacement du PSC Looker, comme illustré dans la figure 2.

Figure 2.

Points abordés

Configuration réseau requise
Créer un service producteur Private Service Connect
Créer un point de terminaison Private Service Connect dans Looker
Établir la connectivité avec l'instance GitLab autogérée

Prérequis

Projet Google Cloud avec autorisations de propriétaire
Compte et dépôt GitLab
Instance Looker PSC existante

2. Ce que vous allez faire

Vous allez établir un réseau de producteur, looker-psc-demo, pour déployer un équilibreur de charge proxy TCP interne et un NEG Internet publié en tant que service via Private Service Connect (PSC). Une fois la publication effectuée, vous devrez effectuer les actions suivantes pour valider l'accès au service Producer:

Créer un point de terminaison PSC dans Looker associé au rattachement de service du producteur
Utilisez la console Looker pour créer un projet et tester la connectivité HTTPS avec votre environnement GitLab autogéré.

3. Configuration réseau requise

Vous trouverez ci-dessous le détail des exigences réseau pour le réseau producteur. Le consommateur dans cet atelier de programmation est l'instance PSC Looker.

Composants	Description
VPC (looker-psc-demo)	VPC en mode personnalisé
Sous-réseau NAT du PSC	Les paquets du réseau VPC du client sont traduits à l'aide de la traduction NAT source (SNAT) afin que leurs adresses IP sources d'origine soient converties en adresses IP sources du sous-réseau NAT du réseau VPC du producteur.
Sous-réseau de la règle de transfert PSC	Permet d'allouer une adresse IP à l'équilibreur de charge proxy TCP interne régional.
Sous-réseau PSC NEG	Permet d'allouer une adresse IP au groupe de points de terminaison du réseau.
Sous-réseau proxy réservé	Une adresse IP interne est attribuée à chacun des proxys de l'équilibreur de charge. Les paquets envoyés depuis un proxy vers une VM ou un point de terminaison de backend possèdent une adresse IP source provenant du sous-réseau proxy réservé.
NEG Internet	Ressource utilisée pour définir un backend externe pour l'équilibreur de charge configuré en tant que nom de domaine complet, qui désigne le nom de domaine complet sur site de Gitlab autogéré. Le nom de domaine complet Internet effectue une recherche DNS dans le VPC pour la résolution.
Service de backend	Un service de backend sert de pont entre votre équilibreur de charge et vos ressources de backend. Dans l'atelier, le service de backend est associé au NEG Internet.

4. Topologie de l'atelier de programmation

5. Préparation

Configuration de l'environnement au rythme de chacun

Connectez-vous à la console Google Cloud, puis créez un projet ou réutilisez un projet existant. Si vous n'avez pas encore de compte Gmail ou Google Workspace, vous devez en créer un.

Le nom du projet est le nom à afficher pour les participants au projet. Il s'agit d'une chaîne de caractères non utilisée par les API Google. Vous pourrez toujours le modifier.
L'ID du projet est unique parmi tous les projets Google Cloud et non modifiable une fois défini. La console Cloud génère automatiquement une chaîne unique (en général, vous n'y accordez d'importance particulière). Dans la plupart des ateliers de programmation, vous devrez indiquer l'ID de votre projet (généralement identifié par PROJECT_ID). Si l'ID généré ne vous convient pas, vous pouvez en générer un autre de manière aléatoire. Vous pouvez également en spécifier un et voir s'il est disponible. Après cette étape, l'ID n'est plus modifiable et restera donc le même pour toute la durée du projet.
Pour information, il existe une troisième valeur (le numéro de projet) que certaines API utilisent. Pour en savoir plus sur ces trois valeurs, consultez la documentation.

Vous devez ensuite activer la facturation dans la console Cloud pour utiliser les ressources/API Cloud. L'exécution de cet atelier de programmation est très peu coûteuse, voire sans frais. Pour désactiver les ressources et éviter ainsi que des frais ne vous soient facturés après ce tutoriel, vous pouvez supprimer le projet ou les ressources que vous avez créées. Les nouveaux utilisateurs de Google Cloud peuvent participer au programme d'essai sans frais pour bénéficier d'un crédit de 300 $.

Démarrer Cloud Shell

Bien que Google Cloud puisse être utilisé à distance depuis votre ordinateur portable, nous allons nous servir de Google Cloud Shell pour cet atelier de programmation, un environnement de ligne de commande exécuté dans le cloud.

Dans la console Google Cloud, cliquez sur l'icône Cloud Shell dans la barre d'outils supérieure :

Le provisionnement et la connexion à l'environnement prennent quelques instants seulement. Une fois l'opération terminée, le résultat devrait ressembler à ceci :

Cette machine virtuelle contient tous les outils de développement nécessaires. Elle comprend un répertoire d'accueil persistant de 5 Go et s'exécute sur Google Cloud, ce qui améliore nettement les performances du réseau et l'authentification. Vous pouvez effectuer toutes les tâches de cet atelier de programmation dans un navigateur. Vous n'avez rien à installer.

6. Avant de commencer

Activer les API

Dans Cloud Shell, assurez-vous que l'ID de votre projet est configuré:

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

Activez tous les services nécessaires :

gcloud services enable compute.googleapis.com

7. Créer un réseau VPC de producteur

Réseau VPC

Dans Cloud Shell, procédez comme suit:

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

Créer des sous-réseaux

Le sous-réseau PSC sera associé au rattachement de service PSC à des fins de traduction d'adresse réseau.

Dans Cloud Shell, créez le sous-réseau 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

Dans Cloud Shell, créez le sous-réseau de la règle de transfert du producteur:

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

Dans Cloud Shell, créez le sous-réseau proxy réservé régional du producteur:

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

Réserver l'adresse IP de l'équilibreur de charge

Dans Cloud Shell, réservez une adresse IP interne pour l'équilibreur de charge:

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

Dans Cloud Shell, affichez l'adresse IP réservée.

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

Exemple de résultat :

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

Configurer le NEG Internet

Créez un NEG Internet et définissez –network-endpoint-type sur internet-fqdn-port (nom d'hôte et port où votre backend externe peut être atteint).

Dans Cloud Shell, créez un NEG Internet utilisé pour accéder à l'instance GitLab autogérée, 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

Dans Cloud Shell, mettez à jour le NEG Internet gitlab-self-managed-internet-neg avec le nom de domaine complet gitlabonprem.com et le port 443.

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

Créer des règles de pare-feu réseau

Pour autoriser IAP à se connecter à vos instances de VM, créez une règle de pare-feu qui:

S'applique à toutes les instances de VM que vous souhaitez rendre accessibles à l'aide d'IAP.
Autorise le trafic entrant provenant de la plage d'adresses IP 35.235.240.0/20. Cette plage contient toutes les adresses IP qu'IAP utilise pour le transfert TCP.

Dans Cloud Shell, créez la règle de pare-feu 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. Créer un service producteur

Créer des composants d'équilibreur de charge

Dans Cloud Shell, procédez comme suit:

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

Dans Cloud Shell, créez un proxy TCP cible pour acheminer les requêtes vers votre service de backend:

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

Dans la syntaxe suivante, créez une règle de transfert (équilibreur de charge proxy TCP interne).

Dans Cloud Shell, procédez comme suit:

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

Créer un Rattachement de service

Dans Cloud Shell, créez le rattachement de service gitlab-self-managed-svc-attachment-https, avec une approbation automatique qui permet à Looker Core de se connecter au rattachement de service. Si vous souhaitez contrôler l'accès à l'attachement de service, l'option Approbations explicites est disponible.

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

Ensuite, obtenez et notez le rattachement de service listé dans l'URI selfLink commençant par "projects" pour configurer le point de terminaison PSC dans Looker.

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

Dans Cloud Shell, procédez comme suit:

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

Exemple :

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

Dans Cloud Console, accédez à:

Services réseau → Private Service Connect → Services publiés

9. Établir une connexion à un point de terminaison PSC dans Looker

Dans la section suivante, vous allez associer le rattachement de service des producteurs au PSC Looker Core à l'aide des indicateurs –psc-service-attachment dans Cloud Shell pour un seul domaine.

Dans Cloud Shell, créez l'association psc en mettant à jour les paramètres suivants pour qu'ils correspondent à votre environnement:

INSTANCE_NAME: nom de votre instance Looker (Google Cloud Core).
DOMAIN_1: gitlabonprem.com
SERVICE_ATTACHMENT_1: URI capturé lors de la description du rattachement de service, gitlab-self-managed-svc-attachment-https.
REGION: région dans laquelle votre instance Looker (Google Cloud Core) est hébergée.

Dans Cloud Shell, procédez comme suit:

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

Exemple :

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

Dans Cloud Shell, vérifiez que le statut de connexion des serviceAttachments est "ACCEPTED", puis mettez-le à jour avec votre INSTANCE_NAME PSC Looker.

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

Exemple :

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

Exemple :

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

Valider le point de terminaison PSC dans Cloud Console

Dans Cloud Console, vous pouvez valider la connexion PSC.

Dans Cloud Console, accédez à:

Looker → Instance Looker → Détails

10. Résolution DNS

Dans la section suivante, créez une instance GCE et validez la résolution DNS de l'instance Gitlab autogérée, gitlabonprem.com, en effectuant un PING. Comme prévu, la résolution échoue et nécessite une zone DNS privée pour gitlabonprem.com.

11. Créer une instance GCE

Dans Cloud Shell, créez l'instance GCE utilisée pour valider la résolution 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

Connectez-vous à consumer-vm à l'aide d'IAP dans Cloud Shell pour valider la connectivité au service producteur en effectuant une requête curl. Réessayez en cas de délai avant expiration.

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

À partir de l'OS, effectuez un PING sur gitlabonprem.com. L'échec est attendu.

ping gitlabonprem.com

Exemple :

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

Quittez l'OS pour revenir au terminal Cloud Shell.

exit

12. Créer une zone DNS privée

Dans Cloud Shell, créez la zone privée 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"

Dans Cloud Shell, créez l'enregistrement A composé de l'adresse IP de l'instance GitLab autogérée, 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"

Connectez-vous à consumer-vm à l'aide d'IAP dans Cloud Shell pour valider la connectivité au service producteur en effectuant une requête curl. Réessayez en cas de délai avant expiration.

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

À partir de l'OS, effectuez un PING sur gitlabonprem.com, qui est résolu en 192.168.10.4.

ping gitlabonprem.com

Exemple :

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

Quittez l'OS pour revenir au terminal Cloud Shell.

exit

13. Connectivité hybride

Le nom de domaine complet gitlabonprem.com peut désormais être résolu avec l'adresse IP privée hébergée sur site. Ensuite, vous devez configurer un réseau hybride (par exemple, Interconnect ou VPN haute disponibilité) entre le VPC looker-psc-demo et le réseau sur site pour permettre la connectivité.

Voici les étapes à suivre pour établir la connectivité du NEG hybride avec l'environnement sur site:

Choisir un produit de connectivité réseau | Google Cloud
Dans une architecture en hub et spoke avec l'appairage de VPC, le NEG hybride est déployé dans le même VPC que le Cloud Router (hub).
Assurez-vous que les pare-feu sur site sont mis à jour pour prendre en charge la plage de sous-réseau proxy réservé, car ce sous-réseau sert d'adresse IP source pour la communication avec les charges de travail sur site.
Annoncer le sous-réseau proxy uniquement à partir du routeur Cloud Router en tant qu'annonce de routage personnalisée

14. Tester la connectivité

Dans les étapes suivantes, vous allez utiliser Looker Console pour créer un projet afin de valider la connectivité HTTPS avec gitlabonprem.com en suivant la procédure décrite dans Configurer et tester une connexion Git.

15. Effectuer un nettoyage

Supprimer des composants de l'atelier à partir d'un seul terminal 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. Félicitations

Félicitations ! Vous avez correctement configuré et validé la connectivité à une instance GitLab autogérée à l'aide de la console Looker alimentée par Private Service Connect.

Vous avez créé l'infrastructure du producteur, et appris à créer un NEG Internet, un service de producteur et un point de terminaison PSC Looker qui permettent de se connecter au service de producteur.

NEG Internet HTTPS vers le sud Looker PSC Gitlab autogéré

1. Introduction

Points abordés

Prérequis

2. Ce que vous allez faire

3. Configuration réseau requise

4. Topologie de l'atelier de programmation

5. Préparation

Configuration de l'environnement au rythme de chacun

Démarrer Cloud Shell

6. Avant de commencer

Activer les API

7. Créer un réseau VPC de producteur

Réseau VPC

Créer des sous-réseaux

Réserver l'adresse IP de l'équilibreur de charge

Configurer le NEG Internet

Créer des règles de pare-feu réseau

8. Créer un service producteur

Créer des composants d'équilibreur de charge

Créer un Rattachement de service

9. Établir une connexion à un point de terminaison PSC dans Looker

Valider le point de terminaison PSC dans Cloud Console

10. Résolution DNS

11. Créer une instance GCE

12. Créer une zone DNS privée

13. Connectivité hybride

14. Tester la connectivité

15. Effectuer un nettoyage

16. Félicitations

Et ensuite ?

Autres ressources et vidéos

Documents de référence