NEG de Internet de PSC de Looker con dirección sur de HTTPS autoadministrado por Gitlab

1. Introducción

NOTA: Looker admite productores de Southbound en cualquier región. Para el acceso de salida a Looker, el extremo o el backend del consumidor deben estar en la misma región que la instancia de PSC de Looker.

En este codelab, realizarás una conexión HTTPS de salida a tu entorno autoadministrado de GitLab con un balanceador de cargas de proxy TCP interno y un grupo de extremos de red (NEG) de Internet invocado desde PSC de Looker como consumidor de servicios.

Private Service Connect es una función de las herramientas de redes de Google Cloud que permite a los consumidores acceder a los servicios administrados de forma privada desde su red de VPC. Del mismo modo, permite a los productores de servicios administrados alojar estos servicios en sus propias redes de VPC independientes y ofrecer una conexión privada a sus consumidores. Por ejemplo, cuando usas Private Service Connect para acceder a Looker, eres el consumidor del servicio y Google es el productor de servicios, como se destaca en la figura 1.

Figura 1:

El acceso de salida, también conocido como PSC inverso, permite que el consumidor cree un servicio publicado como productor para permitir que Looker acceda a extremos locales, en una VPC, a servicios administrados y a Internet. Las conexiones de salida se pueden implementar en cualquier región, independientemente de dónde se implemente el PSC de Looker, como se destaca en la figura 2.

Figura 2:

Qué aprenderás

• Requisitos de red
• Crea un servicio de productor de Private Service Connect
• Crea un extremo de Private Service Connect en Looker
• Establece la conectividad con la instancia autoadministrada de GitLab

Requisitos

• Proyecto de Google Cloud con permisos de propietario
• Cuenta y repositorio de GitLab
• Instancia existente del PSC de Looker

2. Qué compilarás

Establecerás una red de productor, looker-psc-demo, para implementar el balanceador de cargas de proxy TCP interno y el NEG de Internet publicado como un servicio a través de Private Service Connect (PSC). Una vez que se publique, realizarás las siguientes acciones para validar el acceso al servicio de Producer:

• Crea un extremo de PSC en Looker asociado con el adjunto de servicio del productor
• Usa la consola de Looker para crear un proyecto nuevo y probar la conectividad HTTPS a tu entorno autoadministrado de GitLab.

NOTA: El instructivo no proporciona pruebas para implementar una instancia autoadministrada de GitLab

3. Requisitos de red

A continuación, se desglosan los requisitos de red para la red del productor. En este codelab, el consumidor es la instancia de PSC de Looker.

Componentes	Descripción
VPC (looker-psc-demo)	VPC en modo personalizado
Subred de NAT de PSC	Los paquetes de la red de VPC del consumidor se traducen con NAT de origen (SNAT) para que sus direcciones IP de origen originales se conviertan en direcciones IP de origen de la subred NAT en la red de VPC del productor.
Subred de la regla de reenvío de PSC	Se usa para asignar una dirección IP al balanceador de cargas de proxy TCP interno regional.
Subred del NEG del PSC	Se usa para asignar una dirección IP al grupo de extremos de red.
Subred de solo proxy	A cada uno de los proxies del balanceador de cargas se le asigna una dirección IP interna. Los paquetes enviados desde un proxy a una VM o un extremo de backend tienen una dirección IP de origen de la subred de solo proxy.
NEG de Internet	Es un recurso que se usa para definir un backend externo para el balanceador de cargas configurado como un FQDN que denota el FQDN local autoadministrado de GitLab. El FQDN de Internet realiza una búsqueda de DNS dentro de la VPC para la resolución.
Servicio de backend	Un servicio de backend actúa como puente entre tu balanceador de cargas y tus recursos de backend. En el instructivo, el servicio de backend está asociado con el NEG de Internet.

NOTA: En nuestra configuración, se implementa un NEG de Internet configurado con un FQDN en la VPC del consumidor para resolver la dirección IP de la instancia autoadministrada de GitLab ubicada de forma local. De forma predeterminada, el NEG de Internet realizará una búsqueda de DNS en el FQDN proporcionado. Por lo tanto, si el FQDN de tu instancia autoadministrada de GitLab se puede resolver desde una instancia de GCE, no es necesario realizar ninguna otra acción. Si no se puede resolver el FQDN, deberás implementar una zona privada de Cloud DNS junto con un registro A de la dirección IP del servidor autoadministrado de GitLab. En el instructivo, configuraremos una zona de DNS privada para gitlabonprem.com y un registro A que apunte al servidor autoadministrado de GitLab.

4. Topología del codelab

5. Configuración y requisitos

Configuración del entorno de autoaprendizaje

1. Accede a Google Cloud Console y crea un proyecto nuevo o reutiliza uno existente. Si aún no tienes una cuenta de Gmail o de Google Workspace, debes crear una.

• El Nombre del proyecto es el nombre visible de los participantes de este proyecto. Es una cadena de caracteres que no se utiliza en las APIs de Google. Puedes actualizarla cuando quieras.
• El ID del proyecto es único en todos los proyectos de Google Cloud y es inmutable (no se puede cambiar después de configurarlo). La consola de Cloud genera automáticamente una cadena única. Por lo general, no importa cuál sea. En la mayoría de los codelabs, deberás hacer referencia al ID de tu proyecto (suele identificarse como PROJECT_ID). Si no te gusta el ID que se generó, podrías generar otro aleatorio. También puedes probar uno propio y ver si está disponible. No se puede cambiar después de este paso y se usa el mismo durante todo el proyecto.
• Recuerda que hay un tercer valor, un número de proyecto, que usan algunas APIs. Obtén más información sobre estos tres valores en la documentación.

Precaución: El ID del proyecto es único a nivel global y no lo puede usar nadie más después de que lo hayas seleccionado. Eres el único usuario de ese ID. Incluso si se borra un proyecto, no se puede volver a usar el ID.

Nota: Si usas una cuenta de Gmail, puedes dejar la ubicación predeterminada como Sin organización. Si usas una cuenta de Google Workspace, elige una ubicación adecuada para tu organización.

2. A continuación, deberás habilitar la facturación en la consola de Cloud para usar las APIs o los recursos de Cloud. Ejecutar este codelab no costará mucho, tal vez nada. Para cerrar recursos y evitar que se generen cobros más allá de este instructivo, puedes borrar los recursos que creaste o borrar el proyecto. Los usuarios nuevos de Google Cloud son aptos para participar en el programa Prueba gratuita de $300.

Inicia Cloud Shell

Si bien Google Cloud y Spanner se pueden operar de manera remota desde tu laptop, en este codelab usarás Google Cloud Shell, un entorno de línea de comandos que se ejecuta en la nube.

En Google Cloud Console, haz clic en el ícono de Cloud Shell en la barra de herramientas en la parte superior derecha:

El aprovisionamiento y la conexión al entorno deberían tomar solo unos minutos. Cuando termine el proceso, debería ver algo como lo siguiente:

Esta máquina virtual está cargada con todas las herramientas de desarrollo que necesitarás. Ofrece un directorio principal persistente de 5 GB y se ejecuta en Google Cloud, lo que permite mejorar considerablemente el rendimiento de la red y la autenticación. Todo tu trabajo en este codelab se puede hacer en un navegador. No es necesario que instales nada.

6. Antes de comenzar

Habilita las APIs

En Cloud Shell, asegúrate de que tu ID del proyecto esté configurado:

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

Habilita todos los servicios necesarios con el siguiente comando:

gcloud services enable compute.googleapis.com

7. Crea la red de VPC del productor

Red de VPC

Dentro de Cloud Shell, haz lo siguiente:

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

Crear subredes

La subred de PSC se asociará con el adjunto de servicio de PSC para la traducción de direcciones de red.

Dentro de Cloud Shell, crea la subred de NAT de 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

Dentro de Cloud Shell, crea la subred de la regla de reenvío del productor:

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

Dentro de Cloud Shell, crea la subred de solo proxy regional del productor:

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

Reserva la dirección IP del balanceador de cargas

En Cloud Shell, reserva una dirección IP interna para el balanceador de cargas:

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

Dentro de Cloud Shell, consulta la dirección IP reservada.

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

Resultado de ejemplo:

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

Configura el NEG de Internet

Crea un NEG de Internet y establece –network-endpoint-type en internet-fqdn-port (el nombre de host y el puerto en el que se encuentra el backend externo).

Dentro de Cloud Shell, crea un NEG de Internet que se use para acceder a la instancia autoadministrada de GitLab, 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

NOTA: La validación del certificado requiere que fqdn=gitlabonprem,port=443 admita HTTPS.

Dentro de Cloud Shell, actualiza el NEG de Internet gitlab-self-managed-internet-neg con el FQDN gitlabonprem.com y el puerto 443.

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

Crea reglas de firewall de red

Para permitir que IAP se conecte a tus instancias de VM, crea una regla de firewall que cumpla con lo siguiente:

• Se aplica a todas las instancias de VM a las que deseas acceder mediante IAP.
• Permite el tráfico de entrada desde el rango de IP 35.235.240.0/20. Este rango contiene todas las direcciones IP que IAP usa para el reenvío de TCP.

Dentro de Cloud Shell, crea la regla de firewall de 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. Crea el servicio de productor

Crea componentes del balanceador de cargas

Dentro de Cloud Shell, haz lo siguiente:

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

En Cloud Shell, crea un proxy TCP de destino para enrutar las solicitudes a tu servicio de backend:

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

En la siguiente sintaxis, crea una regla de reenvío (balanceador de cargas de proxy TCP interno).

En Cloud Shell, haz lo siguiente:

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

Crea un adjunto de servicio

Dentro de Cloud Shell, crea el adjunto de servicio, gitlab-self-managed-svc-attachment-https, con aprobación automática que permita la conectividad de Looker Core al adjunto de servicio. Si deseas controlar el acceso a la vinculación de servicio, se admite la opción de aprobaciones explícitas.

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

A continuación, obtén y anota el adjunto de servicio que se indica en el URI de selfLink que comienza con projects para configurar el extremo de PSC en Looker.

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

Dentro de Cloud Shell, haz lo siguiente:

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

Ejemplo:

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

En la consola de Cloud, navega a:

Servicios de red → Private Service Connect → Servicios publicados

9. Establece una conexión de extremo de PSC en Looker

En la siguiente sección, asociarás el adjunto de servicio de Producers con el PSC de Looker Core a través de las marcas –psc-service-attachment en Cloud Shell para un solo dominio.

NOTA: Cada vez que ejecutes un comando de actualización con marcas –psc-service-attachment, debes incluir todas las conexiones que desees habilitar, incluidas las que ya estaban habilitadas anteriormente. Consulta la documentación del PSC de Looker para ver un ejemplo.

NOTA: La marca domain=gitlabonprem.com es obligatoria para establecer una conexión HTTPS a gitlabonprem.com

NOTA: Debes habilitar la instancia de PSC de Looker antes de continuar.

Dentro de Cloud Shell, crea la asociación de PSC actualizando los siguientes parámetros para que coincidan con tu entorno:

• INSTANCE_NAME: Es el nombre de tu instancia de Looker (Google Cloud Core).
• DOMAIN_1: gitlabonprem.com
• SERVICE_ATTACHMENT_1: Es el URI capturado cuando se describe el adjunto de servicio, gitlab-self-managed-svc-attachment-https.
• REGION: Es la región en la que se aloja tu instancia de Looker (Google Cloud Core).

Dentro de Cloud Shell, haz lo siguiente:

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

Ejemplo:

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

Dentro de Cloud Shell, valida que el valor de connectionStatus de serviceAttachments sea "ACCEPTED" y actualiza INSTANCE_NAME de tu PSC de Looker.

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

Ejemplo:

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

Ejemplo:

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

Valida el extremo de PSC en la consola de Cloud

Desde la consola de Cloud, puedes validar la conexión de PSC.

En la consola de Cloud, navega a:

Looker → Instancia de Looker → Detalles

10. resolución de DNS

En la siguiente sección, crea una instancia de GCE y valida la resolución de DNS en la instancia autoadministrada de GitLab, gitlabonprem.com, con un PING. Como se esperaba, la resolución fallará y requerirá una zona de DNS privado para gitlabonprem.com.

11. Crea una instancia de GCE

Dentro de Cloud Shell, crea la instancia de GCE que se usa para validar la resolución de 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

Accede a consumer-vm con IAP en Cloud Shell para validar la conectividad con el servicio de productor realizando un curl. Vuelve a intentarlo si se agota el tiempo de espera.

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

Desde el SO, realiza un PING a gitlabonprem.com. Se espera que falle.

ping gitlabonprem.com

Ejemplo:

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

Sal del SO para regresar a la terminal de Cloud Shell.

exit

12. Crea una zona de DNS privado

Dentro de Cloud Shell, crea la zona privada de 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"

Dentro de Cloud Shell, crea el registro A que consta de la dirección IP de la instancia autoadministrada de GitLab, 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"

Accede a consumer-vm con IAP en Cloud Shell para validar la conectividad con el servicio de productor realizando un curl. Vuelve a intentarlo si se agota el tiempo de espera.

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

Desde el SO, realiza un PING a gitlabonprem.com, que se resuelve en 192.168.10.4.

ping gitlabonprem.com

Ejemplo:

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

Sal del SO para regresar a la terminal de Cloud Shell.

exit

13. Conectividad híbrida

Ahora, el FQDN gitlabonprem.com se puede resolver con la dirección IP privada alojada de forma local. A continuación, se debe configurar la conexión de redes híbridas (p.ej., Interconnect, VPN con alta disponibilidad) entre la VPC de looker-psc-demo y la red local para habilitar la conectividad.

A continuación, se indican los pasos necesarios para establecer la conectividad del NEG híbrido con las instalaciones locales:

• Elige un producto de Conectividad de red | Google Cloud
• En una arquitectura de concentrador y radio con intercambio de tráfico entre VPCs, el NEG híbrido se implementa en la misma VPC que Cloud Router (concentrador).
• Asegúrate de que los firewalls locales estén actualizados para admitir el rango de subred de solo proxy, ya que esta subred actúa como la dirección IP de origen para la comunicación con las cargas de trabajo locales.
• Anuncia la subred solo de proxy desde Cloud Router como un anuncio de ruta personalizado.

14. Prueba de conectividad

En los siguientes pasos, usarás la consola de Looker para crear un proyecto y validar la conectividad HTTPS a gitlabonprem.com con el procedimiento que se describe en Cómo configurar y probar una conexión Git.

NOTA: Asegúrate de configurar la conexión de Git con el FQDN local definido cuando aplicas el adjunto de servicio a Looker Core. Si no se usa el mismo FQDN local en el paso de configuración de Git, se producirá un error de conexión.

15. Limpia

Borra los componentes del lab desde una sola terminal de 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. Felicitaciones

Felicitaciones. Configuraste y validaste correctamente la conectividad a una instancia autoadministrada de GitLab con la consola de Looker potenciada por Private Service Connect.

Creaste la infraestructura del productor y aprendiste a crear un NEG de Internet, un servicio del productor y un extremo de PSC de Looker que permitieron la conectividad con el servicio del productor.

Cosmopup cree que los codelabs son increíbles.

¿Qué sigue?

Consulta algunos codelabs sobre los siguientes temas:

• Usa Private Service Connect para publicar y consumir servicios
• Conéctate a servicios locales a través de redes híbridas con Private Service Connect y un balanceador de cargas de proxy TCP interno
• Acceso a todos los codelabs publicados de Private Service Connect

Lecturas y videos adicionales

• Configura y prueba una conexión de Git | Looker | Google Cloud
• Descripción general de Private Service Connect

Documentos de referencia

• Configura un balanceador de cargas de red de proxy interno regional con un backend externo
• Crea una instancia de Private Service Connect de Looker (Google Cloud Core)
• Cómo publicar un servicio con Private Service Connect