Configura NEG sin servidores

Un grupo de extremos de red (NEG) especifica un grupo de extremos de backend para un balanceador de cargas. Un NEG sin servidores es un backend que apunta a un servicio de Cloud Run, App Engine o Cloud Functions.

Un NEG sin servidores puede representar lo siguiente:

  • Un servicio de Cloud Run o un grupo de servicios que comparten el mismo patrón de URL
  • Una función de Cloud Functions o un grupo de funciones que comparten el mismo patrón de URL
  • Una app de App Engine (estándar o flexible), un servicio específico dentro de una app o, incluso, una versión específica de una app

En esta página se muestra cómo crear un balanceador de cargas de HTTP(S) externo para enrutar solicitudes a backends sin servidores. Aquí, el término “sin servidores” hace referencia a los siguientes productos de computación sin servidores: App Engine, Cloud Functions y Cloud Run (completamente administrado).

Los NEG sin servidores te permiten usar apps sin servidores de Google Cloud con balanceo de cargas de HTTP(S) externo. Después de configurar un balanceador de cargas con el backend de NEG sin servidores, las solicitudes al balanceador de cargas se enrutan al backend de la app sin servidores.

Antes de comenzar

Antes de comenzar:

  1. Lee la Descripción general de los NEG sin servidores.
  2. Implementa un servicio de App Engine, Cloud Functions o Cloud Run (completamente administrado).
  3. Instala el SDK de Google Cloud.
  4. Configura permisos.
  5. Agrega un recurso de certificado SSL.

Implementa un servicio de App Engine, Cloud Functions o Cloud Run (completamente administrado)

En las instrucciones de esta página, se supone que ya tienes un servicio de Cloud Run (completamente administrado), Cloud Functions o App Engine en ejecución.

En el ejemplo de esta página, se usa la guía de inicio rápido de Python de Cloud Run (completamente administrado) a fin de implementar el servicio helloworld en la región us-central1. En el resto de esta página, se muestra cómo configurar un balanceador de cargas de HTTP(S) externo que usa un backend de NEG sin servidores para enrutar las solicitudes al servicio helloworld.

Si aún no implementaste una app sin servidores o si quieres probar un NEG sin servidores con una app de muestra, usa una de las siguientes guías de inicio rápido. Puedes crear una app sin servidores en cualquier región, pero debes usar la misma región más adelante para crear el NEG sin servidores y el balanceador de cargas.

Cloud Run (completamente administrado)

Para crear una aplicación Hello World sencilla, empaquetarla en una imagen de contenedor y, luego, implementarla en Cloud Run (completamente administrado), consulta la Guía de inicio rápido: Compila e implementa.

Si ya subiste un contenedor de muestra a Container Registry, consulta la Guía de inicio rápido: Implementa un contenedor de muestra ya compilado.

Cloud Functions

Consulta Cloud Functions: Guía de inicio rápido de Python.

App Engine

Consulta las siguientes guías de inicio rápido de App Engine para Python 3:

Instala el SDK de Google Cloud

Instala la herramienta de línea de comandos de gcloud. Consulta la Descripción general de gcloud para obtener información conceptual y de instalación sobre la herramienta.

Si no ejecutaste la herramienta de línea de comandos de gcloud antes, primero ejecuta gcloud init para inicializar tu directorio de gcloud.

Configura permisos

Para seguir esta guía, debes crear un NEG sin servidores y un balanceador de cargas de HTTP(S) externo en un proyecto. Debes ser propietario o editor de un proyecto o tener las siguientes funciones de IAM de Compute Engine:

Tarea Función requerida
Crear balanceador de cargas y componentes de herramientas de redes Administrador de redes
Crear y modificar los NEG Administrador de instancias de Compute
Crear y modificar certificados SSL Administrador de seguridad

Reserva una dirección IP externa

Ahora que tus servicios están en funcionamiento, configura una dirección IP externa estática global que tus clientes usen para llegar a tu balanceador de cargas.

Console

  1. Ve a la página Direcciones IP externas en Google Cloud Console.
    Ir a la página Direcciones IP externas
  2. Haz clic en Reservar dirección estática para reservar una dirección IPv4.
  3. Asigna un Nombre de example-ip.
  4. Establece el nivel de red en Premium.
  5. Configura la Versión de IP como IPv4.
  6. Configura el Tipo como Global.
  7. Haz clic en Reservar.

gcloud

gcloud compute addresses create example-ip \
    --ip-version=IPV4 \
    --global

Toma nota de la dirección IPv4 que estaba reservada:

gcloud compute addresses describe example-ip \
    --format="get(address)" \
    --global

Crea un recurso de certificado SSL

Si deseas crear un balanceador de cargas de HTTPS, debes agregar un recurso de certificado SSL al frontend del balanceador de cargas. Crea un recurso de certificado SSL mediante un certificado SSL administrado por Google o un certificado SSL autoadministrado.

  • Certificados administrados por Google. Se recomienda usar certificados administrados por Google, ya que Google Cloud obtiene, administra y renueva estos certificados de manera automática. Si quieres crear un certificado administrado por Google, debes tener un dominio y los registros DNS para ese dominio a fin de que se aprovisione el certificado. Si aún no tienes un dominio, puedes obtener uno en Google Domains. Además, deberás actualizar el registro DNS A del dominio a fin de que apunte a la dirección IP del balanceador de cargas que se creó en el paso anterior (example-ip). Para obtener instrucciones detalladas, consulta Usa certificados administrados por Google.

  • Certificados autofirmados. Si no deseas configurar un dominio en este momento, puedes usar un certificado SSL autofirmado para realizar una prueba.

En este ejemplo, se supone que ya creaste un recurso de certificado SSL.

Si quieres probar este proceso sin crear un recurso de certificado SSL (o un dominio requerido por los certificados administrados por Google), puedes seguir las instrucciones de esta página para configurar un balanceador de cargas de HTTP en su lugar.

Crea el balanceador de cargas de HTTP(S) externo

En el siguiente diagrama, el balanceador de cargas usa un backend de NEG sin servidores para dirigir las solicitudes a un servicio de Cloud Run (completamente administrado) sin servidores. Para este ejemplo usamos la guía de inicio rápido de Python de Cloud Run (completamente administrado) a fin de implementar el servicio helloworld-python.

Balanceo de cargas de HTTPS simple (haz clic para agrandar)
Balanceo de cargas de HTTPS para una app de Cloud Run

Debido a que las verificaciones de estado no admiten los servicios de backend con backends de NEG sin servidores, no necesitas crear una regla de firewall que permita verificaciones de estado si el balanceador de cargas solo tiene backends de NEG sin servidores.

Console

Asigna un nombre al balanceador de cargas

  1. Ve a la página Balanceo de cargas en Google Cloud Console.
    Ir a la página Balanceo de cargas
  2. En Balanceo de cargas de HTTP(S), haz clic en Iniciar configuración.
  3. En Orientado a Internet o solo interno, selecciona De Internet a mis VM.
  4. Haz clic en Continuar.
  5. Para el Nombre del balanceador de cargas, ingresa helloworld-lb.
  6. Mantén la ventana abierta para continuar.

Configura los servicios de backend

  1. Haz clic en Configuración de backend.
  2. En el menú desplegable Create or select a backend service, mantén el puntero del mouse sobre Servicios de backend y, luego, selecciona Crear un servicio de backend.
  3. Establece el Nombre del servicio de backend como helloworld-backend-service.
  4. En Tipo de backend, selecciona Grupo de extremos de red sin servidores.
  5. En el menú desplegable Protocolo, selecciona HTTPS.
  6. En Backends, en la ventana Nuevo backend, selecciona Crear grupo de extremos de red sin servidores.
    1. En Nombre, ingresa helloworld-serverless-neg.
    2. En Región, selecciona us-central1.
    3. Selecciona un Tipo de grupo de extremos de red sin servidores. En este ejemplo, se usa un servicio de Cloud Run (completamente administrado), por lo que debes seleccionar Cloud Run.
      1. Selecciona Seleccionar nombre de servicio.
      2. En el menú desplegable Servicio, selecciona el servicio helloworld.
    4. Haz clic en Crear.
  7. En la ventana Nuevo backend, haz clic en Listo.
  8. Selecciona Habilitar Cloud CDN (opcional).
  9. Haz clic en Crear.

Configura reglas de host y comparadores de rutas de acceso

Las reglas de host y los comparadores de rutas de acceso son componentes de configuración de un mapa de URL del balanceador de cargas de HTTP(S) externo.

  1. Haz clic en Reglas de host y ruta de acceso.
  2. Conserva los hosts y las rutas de acceso predeterminados. Esto significa que todas las solicitudes se dirigen a helloworld-backend-service.

Configura el frontend

  1. Haz clic en Configuración de frontend.
  2. Ingresa un Nombre.
  3. Para crear un balanceador de cargas de HTTPS, debes tener un certificado SSL (gcloud compute ssl-certificates list). Te recomendamos usar un certificado administrado por Google como se describió antes. Para configurar un balanceador de cargas de HTTP(S) externo, completa los campos como se muestra a continuación.

    Verifica que las siguientes opciones estén configuradas con estos valores:

    Propiedad Valor (escribe un valor o selecciona una opción como se especifica)
    Protocolo HTTPS
    Nivel de servicio de red Premium
    Versión de IP IPv4
    Dirección IP example-ip
    Puerto 443
    Certificado Selecciona un certificado SSL existente o crea uno nuevo.

    Si deseas crear un balanceador de cargas de HTTPS, debes tener un recurso de certificado SSL para usar en el proxy HTTPS. Puedes crear un recurso de certificado SSL mediante un certificado SSL administrado por Google o un certificado SSL autoadministrado.
    Para crear un certificado administrado por Google, debes tener un dominio. El registro A del dominio debe resolverse en la dirección IP del balanceador de cargas (en este ejemplo, example-ip). Se recomienda usar certificados administrados por Google porque Google Cloud obtiene, administra y renueva estos certificados de forma automática. Si no tienes un dominio, puedes usar un certificado SSL autofirmado para realizar pruebas.

    Si quieres probar este proceso sin configurar un recurso de certificado SSL (o un dominio según lo requieren los certificados administrados por Google), puedes configurar un balanceador de cargas de HTTP.

    Para crear un balanceador de cargas de HTTP, verifica que las siguientes opciones estén configuradas con estos valores:

    Propiedad Valor (escribe un valor o selecciona una opción como se especifica)
    Protocolo HTTP
    Nivel de servicio de red Premium
    Versión de IP IPv4
    Dirección IP example-ip
    Puerto 80

  4. Haz clic en Listo.

Revisa la configuración

  1. Haz clic en Revisar y finalizar.
  2. Revisa el Backend, las Reglas de host y ruta de acceso y el Frontend.
  3. Haz clic en Crear.
  4. Espera a que se cree el balanceador de cargas.
  5. Haz clic en el nombre del balanceador de cargas (helloworld-lb).
  6. Anota la dirección IP del balanceador de cargas para la siguiente tarea. Se hace referencia a ella como IP_ADDRESS.

gcloud

  1. Crea un NEG sin servidores para tu servicio de Cloud Run (completamente administrado). Para este ejemplo se supone que implementaste un servicio de Cloud Run (completamente administrado) llamado helloworld.
    gcloud compute network-endpoint-groups create helloworld-serverless-neg \
        --region=us-central1 \
        --network-endpoint-type=serverless  \
        --cloud-run-service=helloworld
    
    Si quieres crear un NEG para un servicio de App Engine o una función de Cloud Functions, consulta la guía de referencia de gcloud para gcloud compute network-endpoint-groups create.
  2. Crea un servicio de backend y agrega el NEG sin servidores como un backend al servicio de backend:
    gcloud compute backend-services create helloworld-backend-service \
        --global
    
    gcloud compute backend-services add-backend helloworld-backend-service \
        --global \
        --network-endpoint-group=helloworld-serverless-neg \
        --network-endpoint-group-region=us-central1
    
  3. Crea un mapa de URL para enrutar las solicitudes entrantes al servicio de backend de helloworld-backend-service:
    gcloud compute url-maps create helloworld-url-map \
        --default-service helloworld-backend-service
    
    Este mapa de URL de ejemplo solo se orienta a un servicio de backend que representa un solo servicio de Cloud Run (completamente administrado), por lo que no es necesario configurar reglas de host ni comparadores de rutas de acceso. Si tienes más de un servicio de backend, puedes usar reglas de host para dirigir las solicitudes a diferentes servicios según el nombre del host y configurar comparadores de rutas de acceso para dirigir solicitudes a diferentes servicios según la ruta de la solicitud.
  4. Si quieres crear un balanceador de cargas de HTTPS, debes tener un recurso de certificado SSL para usar en el proxy HTTPS. Puedes crear un recurso de certificado SSL mediante un certificado SSL administrado por Google o un certificado SSL autoadministrado. Se recomienda usar certificados administrados por Google, ya que Google Cloud obtiene, administra y renueva estos certificados de manera automática.
    Para crear un certificado administrado por Google, debes tener un dominio. Si no tienes un dominio, puedes usar un certificado SSL autofirmado para realizar pruebas.

    Si deseas crear un recurso de certificado SSL administrado por Google llamado www-ssl-cert, ingresa el siguiente comando:
    gcloud compute ssl-certificates create www-ssl-cert \
        --domains [DOMAIN]
    
    Si deseas crear un recurso de certificado SSL autoadministrado llamado www-ssl-cert, ingresa el siguiente comando:
    gcloud compute ssl-certificates create www-ssl-cert \
        --certificate [CRT_FILE_PATH] \
        --private-key [KEY_FILE_PATH]
    
  5. Crea un proxy HTTP(S) de destino para enrutar las solicitudes al mapa de URL.

    Para un balanceador de cargas de HTTP, crea un proxy HTTP de destino:
      gcloud compute target-http-proxies create helloworld-http-proxy \
        --url-map=helloworld-url-map
      
    Para un balanceador de cargas de HTTPS, crea un proxy HTTPS de destino. El proxy es la parte del balanceador de cargas que contiene el certificado SSL para el balanceo de cargas de HTTPS, por lo que también debes cargar el certificado en este paso.
    gcloud compute target-https-proxies create helloworld-https-proxy \
        --ssl-certificates=www-ssl-cert \
        --url-map=helloworld-url-map
    
  6. Crea una regla de reenvío global para enrutar las solicitudes entrantes al proxy.

    Para un balanceador de cargas de HTTP, ingresa el siguiente comando:
    gcloud compute forwarding-rules create http-forwarding-rule \
        --address=example-ip \
        --target-http-proxy=helloworld-http-proxy \
        --global \
        --ports=80
    
    Para un balanceador de cargas de HTTPS, ingresa el siguiente comando:
    gcloud compute forwarding-rules create https-forwarding-rule \
        --address=example-ip \
        --target-https-proxy=helloworld-https-proxy \
        --global \
        --ports=443
    

Actualiza los registros DNS del dominio para usar la dirección IP del balanceador de cargas

Si aún no lo hiciste, actualiza el registro DNS A del dominio para que apunte a la dirección IP del balanceador de cargas, a fin de que el tráfico que se envía al Cloud Run existente (completamente administrado) o a las URL del dominio personalizado de App Engine se enruten, en su lugar, mediante el balanceador de cargas.

Por ejemplo, si tienes un dominio personalizado llamado example.com, y todos los servicios de Cloud Run (completamente administrado) se mapean a este dominio, debes actualizar el registro DNS A para que example.com apunte a la dirección IP del balanceador de cargas.

Antes de actualizar los registros DNS, puedes probar la configuración de manera local si fuerzas la resolución de DNS local del dominio personalizado a la dirección IP del balanceador de cargas. Si deseas realizar una prueba local, modifica el archivo /etc/hosts/ en tu máquina local para apuntar example.com a la dirección IP del balanceador de cargas o usa la marca curl --resolve a fin de forzar a curl a usar la dirección IP del balanceador de cargas de la solicitud.

Cuando el registro DNS de example.com se resuelve en la dirección IP del balanceador de cargas de HTTP(S), las solicitudes enviadas a example.com comienzan a enrutarse a través del balanceador de cargas. El balanceador de cargas las envía al servicio de backend relevante según su mapa de URL. Además, si el servicio de backend está configurado con una máscara de URL, el NEG sin servidores usa la máscara para enrutar la solicitud al servicio de Cloud Run adecuado (completamente administrado), Cloud Functions o App Engine.

Si usas certificados administrados por Google, la migración de un servicio existente a un balanceador de cargas de HTTP(S) externo puede generar cierto tiempo de inactividad que suele ser de menos de una hora. Esto se debe a que el certificado SSL del balanceador de cargas de HTTP(S) externo no se aprovisionará hasta que actualices los registros DNS para que apunten a la dirección IP del balanceador de cargas.

Prueba el balanceador de cargas de HTTP(S) externo

Ahora que ya configuraste el balanceador de cargas, puedes comenzar a enviar tráfico a la dirección IP del balanceador de cargas. Si configuraste un dominio, también puedes enviar tráfico al nombre de dominio. Sin embargo, la propagación de DNS puede llevar un tiempo en completarse, por lo que puedes comenzar a usar la dirección IP para realizar pruebas.

  1. Ve a la página Balanceo de cargas en Google Cloud Console.
    Ir a la página Balanceo de cargas
  2. Haz clic en el balanceador de cargas que acabas de crear.
  3. Toma nota de la Dirección IP del balanceador de cargas.
  4. Si creaste un balanceador de cargas de HTTP, puedes probarlo mediante un navegador web en http://IP_ADDRESS. Reemplaza IP_ADDRESS por la dirección IP del balanceador de cargas. Deberías dirigirte a la página principal del servicio helloworld.

    Si creaste un balanceador de cargas de HTTPS, puedes probarlo mediante un navegador web en https://IP_ADDRESS. Reemplaza IP_ADDRESS por la dirección IP del balanceador de cargas. Deberías dirigirte a la página principal del servicio helloworld.

    Si eso no funciona y usas un certificado administrado por Google, confirma que el estado del recurso de certificado sea ACTIVO. Para obtener más información, consulta el estado de los recursos del certificado SSL administrado por Google.

    Si usaste un certificado autofirmado para las pruebas, el navegador mostrará una advertencia. Debes indicar de manera explícita a tu navegador que acepte un certificado autofirmado. Haz clic en la advertencia para ver la página real.

    Como alternativa, puedes usar curl desde la línea de comandos de tu máquina local. Reemplaza IP_ADDRESS por la dirección IPv4 del balanceador de cargas. Deberías dirigirte a la página principal del servicio helloworld.

    Si usas un certificado administrado por Google, prueba el dominio que apunta a la dirección IP del balanceador de cargas. Por ejemplo:

    curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:IP_ADDRESS:443
    

    Si usas un certificado autofirmado, también debes especificar la marca -k. La opción -k de curl permite que curl funcione si tienes un certificado autofirmado. Solo debes usar el parámetro -k para probar tu propio sitio. En circunstancias normales, un certificado válido es una medida de seguridad importante y no se deben ignorar sus advertencias.

  5. Si usas un dominio personalizado, es posible que debas esperar a que se propague la configuración de DNS actualizada (opcional). Luego, prueba el dominio (por ejemplo, https://test.example.com) en el navegador web. Deberías dirigirte a la página principal del servicio helloworld.

Opciones de configuración adicionales

En esta sección se expande el ejemplo de configuración para proporcionar opciones de configuración alternativas y adicionales. Todas las tareas son opcionales. Puedes realizarlas en cualquier orden.

Configura el balanceo de cargas multirregión

En el ejemplo descrito antes, solo tenemos un servicio de Cloud Run (completamente administrado) que funciona como backend. Debido a que el NEG sin servidores solo puede apuntar a un extremo a la vez, no se realiza el balanceo de cargas. El balanceador de cargas de HTTP(S) externo solo funciona como frontend y envía el tráfico al extremo de la app helloworld especificado. Sin embargo, es posible que desees entregar la app de Cloud Run (completamente administrado) desde más de una región a fin de mejorar la disponibilidad de tu servicio y la latencia para los usuarios.

Si un servicio de backend contiene varios NEG, el balanceador de cargas balancea el tráfico mediante el reenvío de solicitudes al NEG sin servidores en la región disponible más cercana. Sin embargo, los servicios de backend solo pueden contener un NEG sin servidores por región. Para que tu servicio de Cloud Run (completamente administrado) esté disponible en varias regiones, deberás configurar el enrutamiento entre regiones. Deberías poder usar un único esquema de URL que funcione en cualquier parte del mundo, pero que entregue las solicitudes de los usuarios desde la región más cercana al usuario. Si la región más cercana no está disponible o tiene poca capacidad, la solicitud se enrutará a una región distinta.

A fin de configurar la entrega multirregión, deberás usar el nivel de red Premium para asegurarte de que todas las implementaciones regionales de Cloud Run (completamente administrado) sean compatibles y estén listas para entregar tráfico desde cualquier región.

Para configurar un balanceador de cargas multirregión, sigue estos pasos:

  1. Configura dos servicios de Cloud Run (completamente administrado) en diferentes regiones. Supongamos que implementaste dos servicios de Cloud Run (completamente administrado): uno en una región de Europa y otro en una región de EE.UU.
  2. Crea un balanceador de cargas de HTTP(S) externo con la siguiente configuración:
    1. Configura un servicio de backend global con dos NEG sin servidores.
      1. Crea el primer NEG en la misma región que el servicio de Cloud Run implementado en Europa.
      2. Crea el segundo NEG en la misma región que el servicio de Cloud Run implementado en EE.UU.
    2. Establece tu configuración de frontend con el nivel de red Premium.

El resto de la configuración puede ser la misma que se describió antes. La configuración resultante se verá de la siguiente manera:

Distribución del tráfico en apps sin servidores (haz clic para ampliar)
Enrutamiento multirregión para apps sin servidores (con conmutación por error)

Configura el enrutamiento regional

Un motivo común para entregar aplicaciones desde varias regiones es a fin de cumplir con los requisitos de localidad de datos. Por ejemplo, es posible que desees asegurarte de que las solicitudes que realizan los usuarios europeos siempre se entreguen desde una región de Europa. Si deseas configurar esto, necesitas un esquema de URL con URL independientes para usuarios de la UE y que no pertenezcan a la UE, y dirigir a los usuarios de la UE a las URL de la UE.

En ese caso, deberías usar el mapa de URL para enrutar solicitudes de URL específicas a sus regiones correspondientes. Con esta configuración las solicitudes creadas para una región nunca se entregarán a otra. Esto proporciona aislamiento entre regiones. Por otro lado, cuando una región falla, las solicitudes no se enrutan a una región diferente. Por lo tanto, esta configuración no aumenta la disponibilidad del servicio.

Para configurar el enrutamiento regional, deberás usar el nivel de red Premium de modo que puedas combinar diferentes regiones en una sola regla de reenvío.

Para configurar un balanceador de cargas con enrutamiento regional, sigue estos pasos:

  1. Configura dos servicios de Cloud Run (completamente administrado) en diferentes regiones. Supongamos que implementaste dos servicios de Cloud Run (completamente administrado): hello-world-eu, en una región de Europa, y hello-world-us, en una región de EE.UU.
  2. Crea un balanceador de cargas de HTTP(S) externo con la siguiente configuración:
    1. Configura un servicio de backend con un NEG sin servidores en Europa. El NEG sin servidores debe crearse en la misma región que el servicio de Cloud Run (completamente administrado) implementado en Europa.
    2. Configura un segundo servicio de backend con otro NEG sin servidores en EE.UU. Este NEG sin servidores debe crearse en la misma región que el servicio de Cloud Run implementado en EE.UU.
    3. Configura tu mapa de URL con las reglas de host y ruta de acceso adecuadas para que un conjunto de URL se enrute al servicio de backend europeo mientras todas las solicitudes se enrutan al servicio de backend de EE.UU.
    4. Establece tu configuración de frontend con el nivel de red Premium.

El resto de la configuración puede ser la misma que se describió antes. La configuración resultante se verá de la siguiente manera:

Distribución del tráfico en apps sin servidores (haz clic para ampliar)
Enrutamiento regional para apps sin servidores (sin conmutación por error)

Usa una máscara para URL

Cuando creas un NEG sin servidores, en lugar de seleccionar un servicio de Cloud Run (completamente administrado), puedes usar una máscara de URL para apuntar a varios servicios que entregan en el mismo dominio. Una máscara de URL es una plantilla de tu esquema de URL. El NEG sin servidores usará esta plantilla para extraer el nombre del servicio de la URL de la solicitud entrante y asignar la solicitud al servicio correspondiente.

Las máscaras de URL son útiles sobre todo si tu servicio se mapea a un dominio personalizado en lugar de mapearse a la dirección predeterminada que proporciona Google Cloud para el servicio implementado. Una máscara de URL te permite orientar varios servicios y versiones con una regla única, incluso cuando tu aplicación usa un patrón de URL personalizado.

Si aún no lo hiciste, asegúrate de leer la Descripción general de NEG sin servidores: Máscaras de URL.

Crea una máscara de URL

A fin de crear una máscara de URL para tu balanceador de cargas, comienza con la URL de tu servicio. Para este ejemplo usaremos una app sin servidores de muestra que se ejecuta en https://example.com/login. Esta es la URL en la que se entregará el servicio login de la app.

  1. Quita http o https de la URL. Quedará example.com/login.
  2. Reemplaza el nombre del servicio por un marcador de posición para la máscara de URL.
    1. Cloud Run (completamente administrado): reemplaza el nombre del servicio de Cloud Run (completamente administrado) por el marcador de posición <service>. Si el servicio de Cloud Run (completamente administrado) tiene una etiqueta asociada, reemplaza el nombre de la etiqueta por el marcador de posición <tag>. En este ejemplo la máscara de URL que queda es example.com/<service>.
    2. Cloud Functions: reemplaza el nombre de la función por el marcador de posición <function>. En este ejemplo la máscara de URL que queda es <function>.example.com.
    3. App Engine: reemplaza el nombre del servicio por el marcador de posición <service>. Si el servicio tiene una versión asociada, reemplaza la versión con el marcador de posición <version>. En este ejemplo la máscara de URL que queda es example.com/<service>.
  3. (Opcional) Si el nombre del servicio (o la función, la versión o la etiqueta) se puede extraer de la porción de la ruta de acceso de la URL, se puede omitir el dominio. La porción de la ruta de acceso de la máscara de URL se distingue por el primer carácter /. Si / no está presente en la máscara de URL, se entiende que la máscara solo representa al host. Por lo tanto, para este ejemplo, la máscara de URL se puede reducir a /<service> o /<function>.

    De manera similar, si se puede extraer el nombre del servicio de la parte del host de la URL, puedes omitir la ruta de acceso por completo de la máscara de URL.

    También puedes omitir cualquier componente de host o subdominio que aparezca antes del primer marcador de posición, y cualquier componente de la ruta de acceso que aparezca después del último marcador de posición. En esos casos, el marcador de posición captura la información requerida del componente.

Los siguientes son algunos otros ejemplos en los que se demuestran estas reglas:

Cloud Run

En esta tabla se supone que tienes un dominio personalizado llamado example.com y que todos tus servicios de Cloud Run (completamente administrado) se mapean a este dominio.

Servicio, nombre de la etiqueta URL de dominio personalizado de Cloud Run (completamente administrado) Máscara de URL
servicio: login https://login-home.example.com/web <service>-home.example.com
servicio: login https://example.com/login/web example.com/<service> o /<service>
servicio: login, etiqueta: test https://test.login.example.com/web <tag>.<service>.example.com
servicio: login, etiqueta: test https://example.com/home/login/test example.com/home/<service>/<tag> o /home/<service>/<tag>
servicio: login, etiqueta: test https://test.example.com/home/login/web <tag>.example.com/home/<service>

Cloud Functions

En esta tabla se supone que tienes un dominio personalizado llamado example.com y que todos tus servicios de Cloud Functions se mapean a este dominio.

Nombre de la función URL de dominio personalizado de Cloud Functions Máscara de URL
login https://example.com/login /<function>
login https://example.com/home/login /home/<function>
login https://login.example.com <function>.example.com
login https://login.home.example.com <function>.home.example.com

App Engine

En esta tabla se supone que tienes un dominio personalizado llamado example.com y que todos tus servicios de App Engine se mapean a este dominio.

Nombre del servicio, versión URL de dominio personalizado de App Engine Máscara de URL
servicio: login https://login.example.com/web <service>.example.com
servicio: login https://example.com/home/login/web example.com/home/<service>, o /home/<service>
servicio: login, versión: test https://test.example.com/login/web <version>.example.com/<service>
servicio: login, versión: test https://example.com/login/test example.com/<service>/<version>

Crea un NEG sin servidores con una máscara de URL

Console

Para un balanceador de cargas nuevo, puedes usar el mismo proceso de extremo a extremo como se describió antes en este tema. Cuando configures el servicio de backend, en lugar de seleccionar un servicio específico, ingresa una máscara de URL.

Si tienes un balanceador de cargas existente, puedes editar la configuración del backend y hacer que el NEG sin servidores apunte a una máscara de URL en lugar de a un servicio específico.

Usa este comando para agregar un NEG sin servidores basado en máscaras de URL a un servicio de backend existente:

  1. Ve a la página Balanceo de cargas en Google Cloud Console.
    Ir a la página Balanceo de cargas
  2. Haz clic en el nombre del balanceador de cargas cuyo servicio de backend quieres editar.
  3. En la página Detalles del balanceador de cargas, haz clic en Editar .
  4. En la página Edit HTTP(S) load balancer, haz clic en Configuración de backend.
  5. En la página de Configuración de backend, haz clic en Editar  en el servicio de backend que deseas modificar.
  6. Haz clic en Agregar backend.
  7. Selecciona Crear grupo de extremos de red sin servidores.
    1. En Nombre, ingresa helloworld-serverless-neg.
    2. En Región, selecciona us-central1.
    3. En Tipo de grupo de extremos de red sin servidores, selecciona la plataforma en la que se crearon tus apps (o servicios o funciones).
      1. Selecciona Usar máscara de URL.
      2. Ingresa una máscara de URL. Para obtener instrucciones sobre cómo crear una máscara de URL, consulta Crea una máscara de URL.
      3. Haz clic en Crear.
  8. En la ventana Nuevo backend, haz clic en Listo.
  9. Haz clic en Actualizar.

gcloud: Cloud Run

Para crear un NEG sin servidores con una máscara de URL de muestra de example.com/<service>, haz lo siguiente:

gcloud compute network-endpoint-groups create helloworld-neg-mask \
    --region=us-central1 \
    --network-endpoint-type=serverless \
    --cloud-run-url-mask="example.com/<service>"

gcloud: Cloud Functions

Para crear un NEG sin servidores con una máscara de URL de muestra de example.com/<function>, haz lo siguiente:

gcloud compute network-endpoint-groups create helloworld-neg-mask \
    --region=us-central1 \
    --network-endpoint-type=serverless \
    --cloud-function-url-mask="example.com/<function>"

gcloud: App Engine

Para crear un NEG sin servidores con una máscara de URL de muestra de example.com/<service>, haz lo siguiente:

gcloud compute network-endpoint-groups create helloworld-neg-mask \
    --region=us-central1 \
    --network-endpoint-type=serverless \
    --app-engine-url-mask="example.com/<service>"

Para obtener información sobre cómo el balanceador de cargas controla los problemas con las discrepancias de la máscara de URL, consulta Soluciona problemas con NEG sin servidores.

Habilita Cloud CDN

Habilitar Cloud CDN para tu servicio de Cloud Run (completamente administrado) te permite optimizar la entrega de contenido mediante el almacenamiento en caché del contenido cerca de tus usuarios.

Puedes habilitar Cloud CDN en el servicio de backend del balanceador de cargas de HTTP(S) externo mediante el comando gcloud compute backend-services update.

  gcloud compute backend-services update helloworld-backend-service \
    --enable-cdn \
    --global

Cloud CDN es compatible con servicios de backend con Cloud Run (completamente administrado), Cloud Functions y backends de App Engine.

Habilita Google Cloud Armor

Google Cloud Armor es un producto de seguridad que brinda protección contra ataques de denegación de servicio distribuido (DSD) a todos los balanceadores de cargas de proxy GCLB. Google Cloud Armor también proporciona políticas de seguridad configurables a los servicios a los que se accede a través de un balanceador de cargas de HTTP(S) externo. Si quieres obtener información sobre las políticas de seguridad de Google Cloud Armor para el balanceo de cargas de HTTP(S), consulta Descripción general de la política de seguridad de Google Cloud Armor.

Si bien Google Cloud Armor se puede configurar para servicios de backend con Cloud Run (completamente administrado), Cloud Functions y backends de App Engine, existen ciertas limitaciones asociadas con esta función, en particular, con Cloud Run (completamente administrado) y App Engine. Los usuarios que tienen acceso a las URL predeterminadas que Google Cloud asignó a estos servicios pueden omitir el balanceador de cargas y dirigirse directamente a las URL del servicio. Para ello, eluden las políticas de seguridad configuradas de Google Cloud Armor.

Si usas Cloud Functions, puedes mitigar esto mediante la configuración de entrada internal-and-gclb para asegurarte de que las solicitudes enviadas a las URL predeterminadas de cloudfunctions.net o cualquier otro dominio personalizado establecido a través de Cloud Functions se bloqueen.

Borra un NEG sin servidores

Si un grupo de extremos de red está vinculado a un servicio de backend, no se puede quitar. Antes de borrar un NEG, asegúrate de que esté desvinculado del servicio de backend.

Para quitar un NEG sin servidores de un servicio de backend, debes especificar la región en la que se creó el NEG. También debes especificar la marca --global, ya que helloworld-backend-service es un recurso global.

gcloud compute backend-services remove-backend helloworld-backend-service \
    --network-endpoint-group=helloworld-serverless-neg \
    --network-endpoint-group-region=us-central1 \
    --global

Para borrar el NEG sin servidores, ingresa el siguiente comando:

gcloud compute network-endpoint-groups delete helloworld-serverless-neg \
    --region=us-central1

Ten en cuenta que si borras un balanceador de cargas con un backend de NEG sin servidores, solo se borrará el servicio de backend asociado al balanceador de cargas. El NEG sin servidores no se borra de forma automática. Deberás borrar de manera manual el NEG sin servidores, como se muestra en esta sección.

Próximos pasos