Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Acceso privado de Cloud Run al extremo global y al extremo regional de Cloud Storage

1. Introducción

endpoint de API de Google

Las APIs de Cloud de Google Cloud ofrecen diferentes tipos de extremos para acceder a los servicios, que difieren principalmente en la forma en que controlan el enrutamiento de solicitudes, la residencia de datos y el aislamiento regional.

Consulta la documentación del producto sobre los tipos de endpoint de API.

A continuación, se incluye un desglose de los extremos globales, regionales y geográficos:

Extremos globales

Formato: {service}.googleapis.com (p.ej., storage.googleapis.com)
Descripción: Estos extremos proporcionan un único punto de acceso global a un servicio. No especifican una región en la URL.
Enrutamiento: Las solicitudes se enrutan a través de Global Google Front Ends (GFE) y Global Service Load Balancing, que suelen dirigir el tráfico a la región en buen estado más cercana para minimizar la latencia.
Finalización de TLS: Se produce en el GFE más cercano al cliente, que podría estar fuera de la región de Google Cloud en la que residen los datos o los recursos.
Residencia de datos: No se proporcionan garantías para los datos en tránsito. Los datos pueden cruzar los límites regionales después del desencriptado en el GFE.
Aislamiento regional: Limitado. Si bien los backends suelen ser regionales, el punto de entrada y el balanceo de cargas son globales, lo que significa que los problemas en una parte de la infraestructura global podrían afectar los servicios en otras regiones.
Caso de uso: Acceso de uso general en el que la baja latencia para los usuarios dispersos geográficamente es clave y la residencia estricta de datos en tránsito no es una preocupación principal.

Endpoints regionales (REP)

Formato: {service}.{location}.rep.googleapis.com (p.ej., storage.us-east1.rep.googleapis.com)
Descripción: Están diseñados para proporcionar un fuerte aislamiento regional y garantías de residencia de datos. La ubicación (una región específica de Google Cloud) se especifica como un subdominio. Este es el estándar moderno y reemplaza a los extremos geográficos.
Enrutamiento: Usa una pila de frontend completamente regionalizada, incluidos los balanceadores de cargas externos regionales y el balanceo de cargas de servicios regionales . Toda la ruta de solicitud, desde el DNS hasta el backend del servicio, permanece dentro de la región especificada.
Finalización de TLS: Se produce dentro de la región especificada en los balanceadores de cargas externos regionales.
Residencia de datos: Garantiza que los datos permanezcan dentro de la región designada en tránsito y en uso, lo que cumple con los estrictos requisitos de cumplimiento y soberanía.
Aislamiento regional: Fuerte. Las fallas en la infraestructura de frontend de una región no afectan a otras regiones.
Caso de uso: Aplicaciones que requieren residencia estricta de datos, alto aislamiento regional y cumplimiento.

Ten en cuenta que no todas las APIs de Google tienen un extremo regional y consulta aquí todos los extremos regionales compatibles.

Los extremos regionales multirregionales (mREP) también son extremos regionales, como us (Estados Unidos), eu (Unión Europea), etc. (p. ej., storage.us.rep.googleapis.com).

Endpoints geográficos (LEP)

Formato: {location}-{service}.googleapis.com (p.ej., us-east1-storage.googleapis.com)
Descripción: Estos extremos fueron un enfoque anterior para proporcionar acceso específico a la ubicación. La ubicación forma parte del nombre de host principal. Nota: Los extremos geográficos se reemplazan por los extremos regionales.
Enrutamiento: Aún depende de Global Google Front Ends.
Finalización de TLS: Por lo general, se produce en el GFE, que puede no estar en la región especificada en el nombre de host.
Residencia de datos: No se puede garantizar que los datos permanezcan dentro de la región especificada durante el tránsito para el tráfico de Internet pública.
Aislamiento regional: Más débil que los extremos regionales porque usan una infraestructura de frontend global.
Caso de uso: Históricamente, se usaba para algunos casos de acceso regional, pero ahora, por lo general, se desaconseja en favor de los extremos regionales para obtener garantías más sólidas.

Private Service Connect para la API de Google

Private Service Connect es una función de las herramientas de redes de Google Cloud que permite a los consumidores acceder a los servicios del productor. Esto incluye la capacidad de conectarse a las APIs de Google a través de un extremo privado alojado dentro de la VPC del usuario.

Cómo usar el extremo de PSC para acceder a la API de Google:

Extremo de PSC para la API de Google global
Extremo de PSC para la API de Google regional
Usas el extremo de PSC para la API de Google global para acceder de forma privada a la API de Google geográfica.

Cómo usar el backend de PSC para acceder a la API de Google:

Backend de PSC para la API de Google global
Backend de PSC para la API de Google regional
Usas el backend de PSC para la API de Google global para acceder de forma privada a la API de Google geográfica.

Cloud Run envía tráfico a la red de VPC

La salida de VPC directa brinda una infraestructura mejorada y una configuración de salida de VPC más simple a Cloud Run, incluidas las siguientes ventajas:

Configuración: Los servicios y trabajos de Cloud Run pueden enviar tráfico a una red de VPC sin la sobrecarga de administrar un conector de acceso a VPC sin servidores.
Costo: Solo pagas los cargos de tráfico de red, que se reducen a cero al igual que el servicio.
Seguridad: Puedes usar etiquetas de red directamente en las revisiones de servicio para obtener seguridad de red más detallada.
Rendimiento: Menor latencia y mayor capacidad de procesamiento.

Puedes habilitar tu servicio, función, trabajo o grupo de trabajadores de Cloud Run para enviar todo el tráfico a una red de VPC a través de la salida de VPC directa.

2. Qué aprenderás

Cómo crear un extremo de PSC para la API de Google global
Cómo crear un extremo de PSC para la API de Google regional
Cómo cambiar el extremo de API en el código de Cloud Run y configurar las redes para la salida

3. Arquitectura general del lab

4. Pasos de preparación

Roles de IAM necesarios para trabajar en el lab

Comenzarás asignando los roles de IAM necesarios a la cuenta de GCP a nivel del proyecto.

Administrador de redes de Compute (roles/compute.networkAdmin): Este rol te otorga control total de los recursos de redes de Compute Engine.
Administrador de Logging (roles/logging.admin): Este rol te otorga acceso a todos los permisos de Logging y a los permisos dependientes.
Administrador de Service Usage (roles/serviceusage.serviceUsageAdmin): Este rol te permite habilitar, inhabilitar e inspeccionar estados de servicio, inspeccionar operaciones y consumir cuota y facturación para un proyecto de consumidor.
Administrador de DNS (roles/dns.admin): Este rol te proporciona acceso de lectura y escritura a todos los recursos de Cloud DNS.
Administrador de Cloud Run (roles/run.admin): Este rol te otorga control total sobre todos los recursos de Cloud Run.
Administrador de almacenamiento (roles/storage.admin): Este rol te otorga control total de objetos y depósitos.

Habilita las APIs

En Cloud Shell, asegúrate de que tu proyecto esté configurado correctamente y establece las variables de entorno.

En Cloud Shell, haz lo siguiente:

gcloud auth login
gcloud config set project <your project id>
export project_id=<your project id>
export region=<your region>
export zone=$region-a
echo $project_id
echo $region

Habilita todas las APIs de Google necesarias en el proyecto. En Cloud Shell, haz lo siguiente:

gcloud services enable \
  artifactregistry.googleapis.com \
  cloudbuild.googleapis.com \
  run.googleapis.com \
  compute.googleapis.com \
  dns.googleapis.com \
  servicedirectory.googleapis.com \
  networkconnectivity.googleapis.com

Crear VPC

En el proyecto, crea una red de VPC con el modo de subred personalizado. Realiza lo siguiente en Cloud Shell:

gcloud compute networks create mynet \
    --subnet-mode=custom

Crear subredes

En Cloud Shell, haz lo siguiente para crear una subred IPV4:

gcloud compute networks subnets create mysubnet \
    --network=mynet \
    --range=10.0.0.0/24 \
    --region=$region

Crear Cloud NAT y Cloud Router

Cloud NAT se usa para permitir que los trabajos de Cloud Run se conecten a sitios web externos.

gcloud compute routers create $region-cr \
   --network=mynet \
   --region=$region 
gcloud compute routers nats create $region-nat \
    --router=$region-cr \
    --region=$region \
    --nat-all-subnet-ip-ranges \
    --auto-allocate-nat-external-ips

5. Crear un extremo de PSC para Cloud Storage

Crearás dos extremos de PSC para Cloud Storage, uno para el alcance global y el otro para el alcance regional.

Crear un extremo de PSC de alcance global

Con Private Service Connect, puedes crear extremos privados de alcance global con direcciones IP internas globales dentro de tu red de VPC.

Deberás asignar una dirección IP única que no esté definida en tu VPC. Consulta el documento sobre este requisito de dirección IP.

En Cloud Shell, haz lo siguiente para crear una dirección IP. Cambia –addresses=<pscendpointip> para usar la dirección IP que asignaste.

gcloud compute addresses create pscglobalip \
    --global \
    --purpose=PRIVATE_SERVICE_CONNECT \
    --addresses=<pscendpointip> \
    --network=mynet
pscendpointip=$(gcloud compute addresses list --filter=name:pscglobalip --format="value(address)")
echo $pscendpointip

Crea una regla de reenvío para conectar el extremo a los servicios y las APIs de Google.

gcloud compute forwarding-rules create pscendpoint \
    --global \
    --network=mynet \
    --address=pscglobalip \
    --target-google-apis-bundle=all-apis

Verifica p.googleapis.com en Cloud DNS

Cuando creas un extremo, se crean automáticamente las siguientes configuraciones de DNS:

Se crea una zona de DNS privado del Directorio de servicios para p.googleapis.com.
Los registros DNS se crean en p.googleapis.com para algunos servicios y APIs de Google de uso frecuente que están disponibles mediante Private Service Connect y tienen nombres de DNS predeterminados que terminan en googleapis.com.

Los extremos globales se registran en el Directorio de servicios. Usarás storage-[psc endpoint name].p.googleapis.com para acceder a Cloud Storage. Aquí está la documentación del producto para obtener más detalles.

Para verificar si la zona p.googleaps.com ya se creó, ejecuta el comando.

gcloud dns managed-zones list

Si deseas usar el nombre de DNS predeterminado, storage.googleapis.com, crearás una zona privada storage.googleapis.com en Cloud DNS y agregarás un registro de vértice que apunte a la dirección IP del extremo de PSC de alcance global.

Crear un extremo de PSC de alcance regional para Cloud Storage

Necesitarás una IP de la subred de VPC. Ejecuta el siguiente comando. Se asignará una IP de la subred para el extremo de PSC.

gcloud network-connectivity regional-endpoints create psc-regional-endpoint \
    --region=$region \
    --network=projects/$project_id/global/networks/mynet \
    --subnetwork=projects/$project_id/regions/$region/subnetworks/mysubnet \
    --target-google-api=storage.us-central1.rep.googleapis.com

Obtén la dirección IP del extremo creada en el paso anterior.

regionalip=$(gcloud network-connectivity regional-endpoints describe psc-regional-endpoint --region=$region --format="value(address)")
echo $regionalip

Usarás storage.us-central1.rep.googleapis.com para acceder a Cloud Storage. Debes crear una zona privada para storage.us-central1.rep.googleapis.com y el registro de vértice de la dirección IP que acabas de crear para el extremo regional en Cloud DNS.

Crear una zona privada para el extremo regional de Cloud Storage

Usarás storage.[region name].rep.googleapis.com para acceder al extremo regional de Cloud Storage.

Deberás crear una zona privada en Cloud DNS y agregar un registro de vértice que apunte a la dirección IP del extremo regional de Cloud Storage.

En el siguiente comando, us-central1 es la región de ejemplo. Debes crear la zona con el nombre de tu región.

gcloud dns managed-zones create psc-regional-endpoint-zone \
  --description="" \
  --dns-name="storage.us-central1.rep.googleapis.com" \
  --visibility="private" \
  --networks="mynet"

gcloud dns record-sets create storage.us-central1.rep.googleapis.com. \
  --rrdatas=$regionalip \
  --ttl=300 \
  --type=A \
  --zone=psc-regional-endpoint-zone

6. Configurar el trabajo de Cloud Run con el extremo de PSC de alcance global

Obtén el código

Primero, explorarás una aplicación de Node.js para tomar capturas de pantalla de páginas web y almacenarlas en Cloud Storage. Luego, compilarás una imagen de contenedor para la aplicación y la ejecutarás como un trabajo en Cloud Run.

En Cloud Shell, ejecuta el siguiente comando para clonar el código de la aplicación desde este repositorio:

git clone https://github.com/GoogleCloudPlatform/jobs-demos.git

Ve al directorio que contiene la aplicación:

cd jobs-demos/screenshot

Deberías ver el siguiente diseño de archivo:

├── Dockerfile

├── README.md

├── screenshot.js

├── package.json

A continuación, se incluye una breve descripción de cada página.

screenshot.js contiene el código de Node.js para la aplicación. La aplicación toma capturas de pantalla de páginas web y las almacena en Cloud Storage.
package.json define las dependencias de la biblioteca.
Dockerfile define la imagen de contenedor.

Abre el código screenshot.js. Cambiarás el apiEndpoint al extremo global de PSC. Busca el código y reemplaza const storage = new Storage(); por lo siguiente:

const storage = new Storage(
    {
      apiEndpoint:'https://storage-pscendpoint.p.googleapis.com.',
      useAuthWithCustomEndpoint: true
    }
  );

Implementar un trabajo

Antes de crear un trabajo, debes crear una cuenta de servicio que usarás para ejecutarlo.

gcloud iam service-accounts create screenshot-sa --display-name="Screenshot app service account"

Otorga el rol storage.admin a la cuenta de servicio para que pueda usarse en la creación de buckets y objetos.

gcloud projects add-iam-policy-binding $project_id \
  --role roles/storage.admin \
  --member serviceAccount:screenshot-sa@$project_id.iam.gserviceaccount.com

Otorga el rol de Usuario de objetos de almacenamiento , el rol de Escritor de registros y el rol de Administrador de repositorios de Artifact Registry a la cuenta de servicio de Compute predeterminada.

project_number=$(gcloud projects describe $project_id --format="value(projectNumber)")

gcloud projects add-iam-policy-binding $project_id \
  --role roles/storage.objectUser \
  --member serviceAccount:$project_number-compute@developer.gserviceaccount.com

gcloud projects add-iam-policy-binding $project_id \
  --role roles/logging.logWriter \
  --member serviceAccount:$project_number-compute@developer.gserviceaccount.com

gcloud projects add-iam-policy-binding $project_id \
  --role roles/artifactregistry.repoAdmin \
  --member serviceAccount:$project_number-compute@developer.gserviceaccount.com

Habilitarás la salida de VPC directa para que los trabajos de Cloud Run envíen todo el tráfico a una red de VPC.

En Cloud Shell, haz lo siguiente:

gcloud run jobs deploy screenshot-1 \
  --source=. \
  --args="https://example.com" \
  --args="https://cloud.google.com" \
  --tasks=2 \
  --task-timeout=5m \
  --region=$region \
  --set-env-vars=BUCKET_NAME=screenshot-$project_id-$RANDOM \
  --service-account=screenshot-sa@$project_id.iam.gserviceaccount.com \
  --vpc-egress=all-traffic \
  --network=mynet \
  --subnet=mysubnet

Ejecuta el trabajo

En Cloud Shell, haz lo siguiente:

gcloud run jobs execute screenshot-1 --region=$region

Verifica el estado del trabajo y los registros. Ve a la consola de Cloud Run y busca el trabajo. Haz clic en el trabajo y verifica el historial del registro. Verás un resultado de ejecución de trabajo similar al siguiente.

Para obtener registros detallados de la ejecución del trabajo, haz clic en Ver registro en la tarea. Verás registros de trabajo similares a los siguientes.

Se creó un bucket nuevo. Puedes ir a la consola de Cloud Storage y verificar el bucket nuevo creado. Ten en cuenta que, cuando usas el extremo global de Cloud Storage, el bucket es un bucket multirregional. Puedes verificar las imágenes subidas al bucket.

El resultado de la prueba muestra que Cloud Run accedió de forma privada al extremo global de Cloud Storage que cambiaste en el trabajo de Cloud Run:

apiEndpoint:‘https://storage-pscendpoint.p.googleapis.com.'

7. Configurar el trabajo de Cloud Run con el extremo de PSC de alcance regional

En el código, cambiarás el apiEndpoint al extremo de PSC con alcance regional.

Busca el código y reemplaza const storage = new Storage(); por lo siguiente ( usamos us-central1 como ejemplo. Cambia a tu región) :

const storage = new Storage(
    {
      apiEndpoint:'https://storage.us-central1.rep.googleapis.com.',
      useAuthWithCustomEndpoint: true
    }
  );

Implementar un trabajo

Asegúrate de estar en el directorio que contiene la aplicación (jobs-demos/screenshot).

pwd

Habilitarás la salida de VPC directa para que los trabajos envíen todo el tráfico a una red de VPC.

En Cloud Shell, haz lo siguiente:

gcloud run jobs deploy screenshot-2 \
  --source=. \
  --args="https://example.com" \
  --args="https://cloud.google.com" \
  --tasks=2 \
  --task-timeout=5m \
  --region=$region \
  --set-env-vars=BUCKET_NAME=screenshot-$PROJECT_ID-$RANDOM \
  --service-account=screenshot-sa@$project_id.iam.gserviceaccount.com \
  --vpc-egress=all-traffic \
  --network=mynet \
  --subnet=mysubnet

Ejecuta el trabajo

En Cloud Shell, haz lo siguiente:

gcloud run jobs execute screenshot-2 --region=$region

Verifica el estado del trabajo y los registros. Ve a la consola de Cloud Run y busca el trabajo. Haz clic en el trabajo y verifica el historial del trabajo. Verás un resultado de ejecución de trabajo similar al siguiente.

Para obtener registros detallados de la ejecución del trabajo, haz clic en Ver registro. Verás registros de trabajo similares a los siguientes.

Se creó un bucket nuevo. Puedes ir a la consola de Cloud Storage y verificar el bucket nuevo creado. Ten en cuenta que, cuando usas el extremo regional de Cloud Storage, el bucket es un bucket de una sola región. Puedes verificar las imágenes subidas al bucket.

El resultado de la prueba muestra que Cloud Run accedió de forma privada al extremo regional de Cloud Storage que cambiaste en el trabajo de Cloud Run:

apiEndpoint:‘https://storage.us-central1.rep.googleapis.com.'

8. Liberar espacio

Limpia el trabajo de Cloud Run

gcloud run jobs delete screenshot-1 \
  --region=$region --quiet
gcloud run jobs delete screenshot-2 \
  --region=$region --quiet

gcloud iam service-accounts delete screenshot-sa@$project_id.iam.gserviceaccount.com --quiet

Limpia el extremo de PSC

gcloud compute forwarding-rules delete pscendpoint \
    --global --quiet
gcloud network-connectivity regional-endpoints delete psc-regional-endpoint \
    --region=$region --quiet
gcloud compute addresses delete pscglobalip \
    --global --quiet

Libera espacio en Cloud NAT, Cloud Router y las VPCs

gcloud compute routers nats delete $region-nat \
    --router=$region-cr \
    --region=$region --quiet
gcloud compute routers delete $region-cr \
    --region=$region --quiet
gcloud compute networks subnets delete mysubnet \
    --region=$region --quiet
gcloud compute networks delete mynet --quiet

9. Felicitaciones

Probaste correctamente el acceso privado de Cloud Run a Cloud Storage a través del extremo global y el extremo regional.