Espacio del agente a la base de datos autoalojada del NEG zonal

1. Introducción

NOTA: Este codelab ofrece orientación para configurar el acceso a una base de datos autohospedada existente en GCE con un NEG zonal, publicado a través de Private Service Connect. Modifica el codelab según sea necesario para que se ajuste a los requisitos específicos de tu organización.

En este codelab, implementarás un balanceador de cargas de proxy TCP interno y un grupo de extremos de red (NEG) zonal, publicado como un servicio de productor de PSC. El NEG constará de una o más instancias de procesamiento en GCP que autohospeden una base de datos, p. ej., JIRA, Confluence o SharePoint.

Private Service Connect es una función de las 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 su propia red de VPC o de múltiples nubes, y ofrecer una conexión privada a sus consumidores. Por ejemplo, cuando usas Private Service Connect para acceder a un NEG zonal, tú eres el productor del servicio y Google (Agentspace) es el consumidor del servicio.

Qué aprenderás

• Requisitos de red para Agentspace
• Prácticas recomendadas para redes de Agentspace
• Crea un servicio de productor de Private Service Connect

Requisitos

• Proyecto de Google Cloud con permisos de propietario

2. Qué compilarás

Establecerás una red de productores, agentspace-psc-demo, para implementar un balanceador de cargas de proxy TCP interno y un NEG zonal publicado como un servicio a través de Private Service Connect (PSC).

3. Requisitos de red

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

Componentes	Descripción
VPC (agentspace-psc-demo)	VPC en modo personalizado
Subred de NAT de PSC	Los paquetes de la red de VPC del consumidor se traducen mediante 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. La NAT de PSC admite una subred /29 por adjunto de servicio.
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.La subred de la regla de reenvío se considera una subred normal.
Subred del NEG	Se usa para asignar una dirección IP al grupo de extremos de red desde una subred regular.
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 de backend o un grupo de extremos de red tienen una dirección IP de origen de la subred de solo proxy.Se recomienda una subred /23, aunque se admite la subred mínima /26. Se requiere una subred de proxy regional por regió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 zonal.

4. Prácticas recomendadas

• Los NEG zonales admiten una o más instancias de GCE zonales basadas en GCE_VM_IP_PORT.
• Habilita el acceso global en la regla de reenvío del productor antes de crear el adjunto de servicio.
• Habilita el acceso global cuando crees el extremo de Agentspace.
• El balanceador de cargas de proxy TCP interno también admite grupos de instancias administrados y no administrados.
• Los balanceadores de cargas de proxy TCP o de transferencia existentes de Google Cloud se pueden exponer como servicio del productor.

5. Topología del codelab

6. 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.

7. 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]
zone1a=[YOUR-ZONE1a]
zone1b=[YOUR-ZONE1b]
echo $project
echo $region
echo $zone1a
echo $zone1b

Habilita todos los servicios necesarios con el siguiente comando:

gcloud services enable compute.googleapis.com

8. Crea la red de VPC del productor

Red de VPC

En Cloud Shell, haz lo siguiente:

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

Crear subredes

La subred de PSC se asociará con el adjunto de servicio de PSC para los fines de 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 agentspace-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 agentspace-psc-demo --range 172.16.20.0/28 --region $region --enable-private-ip-google-access

Dentro de Cloud Shell, crea la subred del grupo de extremos de red:

gcloud compute networks subnets create neg-subnet --network agentspace-psc-demo --range 172.16.30.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=agentspace-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 zonal-neg-lb-ip \
  --region=$region \
  --subnet=producer-psc-fr-subnet

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

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

Resultado de ejemplo:

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

Configura el NEG zonal

En la siguiente sección, crearás un grupo de extremos de red zonales que contenga una o más combinaciones de dirección IP o dirección IP y puerto de destino:

• La dirección IPv4 interna principal de una interfaz de red de VM
• La dirección IPv4 interna principal de una interfaz de red de VM más un número de puerto de destino
• Una dirección IPv4 interna del rango de direcciones IP de alias asignado a una interfaz de red de VM
• Una dirección IPv4 interna del rango de direcciones IP de alias asignado a una interfaz de red de VM más un número de puerto de destino

La interfaz de red que contiene el extremo GCE_VM_IP_PORT debe estar en la subred del NEG. Cuando omites un número de puerto de un extremo de GCE_VM_IP_PORT, Google Cloud usa el número de puerto predeterminado del NEG para el extremo.

En la arquitectura de referencia, las instancias de GCE asociadas con el NEG zonal constan de lo siguiente:

• database-us-central1-a | us-central1-a | IP: 100.100.10.2 | Puerto: 443
• database-us-central1-a | us-central1-b | IP: 100.100.10.3 | Puerto: 443
• Nombre de la subred: database-subnet-1

Crea el NEG zonal para zone1a

En la siguiente sección, crearás el grupo de extremos de red por zona, p. ej., us-central1-a, y especificarás el nombre de la subred que se usó para crear la instancia de GCE. En la arquitectura de referencia, el nombre de la subred es database-subnet-1.

Dentro de Cloud Shell, crea un NEG zonal:

gcloud compute network-endpoint-groups create us-central-zonal-neg-1a \
    --zone=$zone1a \
    --network=agentspace-psc-demo \
    --subnet=database-subnet-1 \
    --default-port=443

Dentro de Cloud Shell, actualiza el NEG zonal con la IP:puerto de la instancia de GCE implementada en zone1a. En la arquitectura de referencia, la instancia de GCE es 100.100.10.2, puerto 443, implementada en la zona us-central1-a.

gcloud compute network-endpoint-groups update us-central-zonal-neg-1a --zone=$zone1a --add-endpoint instance=database-us-central1-a,port=443

Crea el NEG zonal para zone1b

En la siguiente sección, crearás el grupo de extremos de red por zona, p. ej., us-central1-b, y especificarás el nombre de la subred que se usó para crear la instancia de GCE. En la arquitectura de referencia, el nombre de la subred es database-subnet-1.

Dentro de Cloud Shell, crea un NEG zonal:

gcloud compute network-endpoint-groups create us-central-zonal-neg-1b \
    --zone=$zone1b \
    --network=agentspace-psc-demo \
    --subnet=database-subnet-1 \
    --default-port=443

Dentro de Cloud Shell, actualiza el NEG zonal con la IP:puerto de la instancia de GCE implementada en zone1b. En la arquitectura de referencia, la instancia de GCE es 100.100.10.3, puerto 443, implementada en la zona us-central1-b.

gcloud compute network-endpoint-groups update us-central-zonal-neg-1b --zone=$zone1b --add-endpoint instance=database-us-central1-b,port=443

Crea una verificación de estado regional

Dentro de Cloud Shell, crea una verificación de estado que sondee el puerto de la base de datos local, 443:

gcloud compute health-checks create tcp zonal-443-healthcheck \
    --region=$region \
    --port=443

Crea una política de firewall de red y reglas de firewall

En Cloud Shell, haz lo siguiente:

gcloud compute network-firewall-policies create agentspace-psc-demo-policy --global

gcloud compute network-firewall-policies associations create --firewall-policy agentspace-psc-demo-policy --network agentspace-psc-demo --name agentspace-psc-demo --global-firewall-policy

La siguiente regla de firewall permite el tráfico del rango de la subred de NAT de PSC a todas las instancias de la red.

En Cloud Shell, haz lo siguiente:

gcloud compute network-firewall-policies rules create 2001 --action ALLOW --firewall-policy agentspace-psc-demo-policy --description "allow traffic from PSC NAT subnet to GCE" --direction INGRESS --src-ip-ranges 172.16.10.0/28 --global-firewall-policy --layer4-configs=tcp

La siguiente regla de firewall permite el tráfico del rango de sondeo de verificación de estado a todas las instancias de la red. Ten en cuenta que el puerto de verificación de estado y el puerto de la aplicación deben coincidir.

En Cloud Shell, haz lo siguiente:

gcloud compute network-firewall-policies rules create 2002 --action ALLOW --firewall-policy agentspace-psc-demo-policy --description "allow internal probe health check range to GCE" --direction INGRESS --src-ip-ranges 35.191.0.0/16,130.211.0.0/22 --global-firewall-policy --layer4-configs=tcp:443

La siguiente regla de firewall permite el tráfico desde el rango de la subred de solo proxy a todas las instancias de la red. Ten en cuenta que la subred del proxy y el puerto de la aplicación deben coincidir.

En Cloud Shell, haz lo siguiente:

gcloud compute network-firewall-policies rules create 2003 --action ALLOW --firewall-policy agentspace-psc-demo-policy --description "allow internal tcp proxy health check range to GCE" --direction INGRESS --src-ip-ranges 10.10.10.0/24 --global-firewall-policy --layer4-configs=tcp:443

9. Crea el servicio de productor

Crea componentes del balanceador de cargas

Dentro de Cloud Shell, crea un servicio de backend:

gcloud compute backend-services create producer-backend-svc --region=$region --load-balancing-scheme=INTERNAL_MANAGED --protocol=TCP --region=$region --health-checks=zonal-443-healthcheck --health-checks-region=$region

Dentro de Cloud Shell, asocia el NEG zonal, us-central-zonal-neg-1a, al servicio de backend:

gcloud compute backend-services add-backend producer-backend-svc \
   --network-endpoint-group=us-central-zonal-neg-1a  \
   --network-endpoint-group-zone=$zone1a \
   --balancing-mode=CONNECTION \
   --max-connections-per-endpoint=100 \
   --region=$region

Dentro de Cloud Shell, asocia el NEG zonal, us-central-zonal-neg-1b,al servicio de backend:

gcloud compute backend-services add-backend producer-backend-svc \
   --network-endpoint-group=us-central-zonal-neg-1b  \
   --network-endpoint-group-zone=$zone1b \
   --balancing-mode=CONNECTION \
   --max-connections-per-endpoint=100 \
   --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) con el acceso global habilitado.

En Cloud Shell, haz lo siguiente:

gcloud compute forwarding-rules create producer-zonal-neg-fr \
     --load-balancing-scheme=INTERNAL_MANAGED \
     --network-tier=PREMIUM \
     --network=agentspace-psc-demo \
     --subnet=producer-psc-fr-subnet \
     --address=zonal-neg-lb-ip \
     --target-tcp-proxy=producer-lb-tcp-proxy \
     --target-tcp-proxy-region=$region \
     --region=$region \
     --allow-global-access \
     --ports=443

Validar el estado del backend

Valida el estado (estado verde) del servicio de backend y sus instancias de procesamiento asociadas con la consola de Cloud en la siguiente sección. Navega a lo siguiente:

Servicios de red → Balanceo de cargas → Producer-backend-svc

Crea un adjunto de servicio

Para publicar un servicio, debes crear un adjunto de servicio de Private Service Connect. Puedes publicar el servicio con aprobación automática o explícita.

• Para publicar el servicio y permitir automáticamente que cualquier consumidor se conecte a él, sigue las instrucciones en Publica un servicio con aprobación automática.
• Para publicar el servicio con la aprobación explícita del consumidor, en la configuración de conexión del adjunto de servicio, selecciona Aceptar conexiones para los proyectos seleccionados y deja en blanco el campo Proyectos aceptados.
• Después de generar el adjunto de servicio, los extremos del consumidor que soliciten acceso al servicio del productor entrarán en un estado pendiente de forma inicial. Para autorizar la conexión, el productor debe aceptar el proyecto desde el que se originó la solicitud del extremo del consumidor.

Dentro de Cloud Shell, crea el adjunto de servicio cc-database1-svc-attachment con aprobación automática:

gcloud compute service-attachments create zonal-database1-svc-attachment --region=$region --producer-forwarding-rule=producer-zonal-neg-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 selfLink que comienza con projects para configurar el extremo de PSC en Agentspace.

selfLink: projects/<your-project-id>/regions/<your-region>/serviceAttachments/zonal-database1-svc-attachment

En Cloud Shell, haz lo siguiente:

gcloud compute service-attachments describe zonal-database1-svc-attachment --region=$region

Ejemplo de resultado esperado:

connectionPreference: ACCEPT_AUTOMATIC
creationTimestamp: '2025-07-12T16:00:22.429-07:00'
description: ''
enableProxyProtocol: false
fingerprint: zOpeRQnPWSc=
id: '1784245893044590569'
kind: compute#serviceAttachment
name: zonal-database1-svc-attachment
natSubnets:
- https://www.googleapis.com/compute/v1/projects/$project-svc4/regions/us-central1/subnetworks/producer-psc-nat-subnet
pscServiceAttachmentId:
  high: '119824781489996776'
  low: '1784245893044590569'
reconcileConnections: false
region: https://www.googleapis.com/compute/v1/projects/$project-svc4/regions/us-central1
selfLink: https://www.googleapis.com/compute/v1/projects/$project-svc4/regions/us-central1/serviceAttachments/zonal-database1-svc-attachment
targetService: https://www.googleapis.com/compute/v1/projects/$project-svc4/regions/us-central1/forwardingRules/producer-zonal-neg-fr

En la consola de Cloud, navega a:

Servicios de red → Private Service Connect → Servicios publicados

10. Establece una conexión de extremo de PSC en Agentspace

Asocia el URI del adjunto de servicio de Producers a Agentspace y asegúrate de que esté seleccionado el acceso global. A continuación, se muestra un ejemplo de habilitación del acceso global con la arquitectura de referencia Service Attachment.

Para finalizar la conexión de redes privadas, consulta las fuentes de datos de terceros de Agentspace para obtener más instrucciones.

Valida el extremo de PSC en la consola de Cloud

Para confirmar que se estableció correctamente una conexión de PSC entre Agentspace (el consumidor) y el productor, verifica el proyecto de arrendatario de Agentspace vinculado al servicio del productor. Puedes encontrarlo en “Proyectos conectados”. El ID del proyecto de usuario se asigna de forma aleatoria, pero siempre terminará con "tp".

Desde la consola de Cloud, puedes validar la conexión de PSC. En la consola de Cloud, navega a:

Servicios de red → Private Service Connect → Servicio publicado y, luego, selecciona el servicio zonal-database1-svc-attachment.

11. Limpia

Borra los componentes del lab desde una sola terminal de Cloud Shell

gcloud compute service-attachments delete zonal-database1-svc-attachment --region=$region -q

gcloud compute forwarding-rules delete producer-zonal-neg-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-firewall-policies rules delete 2001 --firewall-policy agentspace-psc-demo-policy --global-firewall-policy -q

gcloud compute network-firewall-policies rules delete 2002 --firewall-policy agentspace-psc-demo-policy --global-firewall-policy -q

gcloud compute network-firewall-policies rules delete 2003 --firewall-policy agentspace-psc-demo-policy --global-firewall-policy -q

gcloud compute network-firewall-policies associations delete --firewall-policy=agentspace-psc-demo-policy  --name=agentspace-psc-demo --global-firewall-policy -q

gcloud compute network-firewall-policies delete agentspace-psc-demo-policy --global -q

gcloud compute network-endpoint-groups delete us-central-zonal-neg-1a --zone=$zone1a -q

gcloud compute network-endpoint-groups delete us-central-zonal-neg-1b --zone=$zone1b -q

gcloud compute addresses delete zonal-neg-lb-ip --region=$region -q

gcloud compute networks subnets delete $region-proxy-only-subnet --region=$region -q

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

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

gcloud compute networks subnets delete neg-subnet --region=$region -q

gcloud compute health-checks delete zonal-443-healthcheck --region=us-central1 -q

gcloud compute networks delete agentspace-psc-demo -q

12. Felicitaciones

Felicitaciones. Configuraste y publicaste correctamente un servicio de Producer con Private Service Connect.

Creaste la infraestructura del productor, aprendiste a crear un NEG zonal y un servicio del productor, y a asociar la vinculación del servicio a Agentspace.

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
• Acceso a todos los codelabs publicados de Private Service Connect

Lecturas y videos adicionales

• Descripción general de Private Service Connect

Documentos de referencia

• Descripción general del balanceador de cargas de red de proxy interno
• Configura un balanceador de cargas de red de proxy interno regional con backends de NEG zonales
• Cómo publicar un servicio con Private Service Connect