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, ejecuta primero gcloud init para inicializar tu directorio de gcloud.

Esto es necesario porque no puedes usar Google Cloud Console para crear un NEG sin servidores.

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

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 autoadministrado o un certificado SSL administrado por Google. Se recomienda usar certificados administrados por Google, ya que Google Cloud obtiene, administra y renueva estos certificados de manera automática.

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

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

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 beta 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 beta 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 beta 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 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 autoadministrado o un certificado SSL administrado por Google. 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 las pruebas. 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]
    
    Si deseas crear un recurso de certificado SSL que administra Google, ingresa el siguiente comando: www-ssl-cert
    gcloud compute ssl-certificates create www-ssl-cert \
        --domains [DOMAIN]
    
  5. Crea un proxy HTTPS de destino para enrutar las solicitudes a tu mapa de URL. 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 de contenido nuevo al proxy.
    gcloud compute forwarding-rules create https-content-rule \
        --address=example-ip \
        --target-https-proxy=helloworld-https-proxy \
        --global \
        --ports=443
    

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.

Console

  1. Ve a la página Balanceo de cargas en Google Cloud Console.
    Ir a la página Balanceo de cargas
  2. Para probar tu balanceador de cargas mediante un navegador web, visita https://ip-address, en el que ip-address es la dirección IP del balanceador de cargas. Deberías dirigirte a la página principal del servicio helloworld.

gcloud/mediante curl

Usa el comando curl para probar la respuesta desde la URL. Reemplaza ip-address por la dirección IPv4 del balanceador de cargas. Deberías dirigirte a la página principal del servicio helloworld.

curl https://ip-address

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

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 beta compute network-endpoint-groups create helloworld-serverless-neg \
    --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 beta compute network-endpoint-groups create helloworld-serverless-neg \
    --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 beta compute network-endpoint-groups create helloworld-serverless-neg \
    --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.

Mueve tu dominio personalizado para que lo entregue el balanceador de cargas de HTTP(S) externo

Si las apps de computación sin servidores se mapean a dominios personalizados, es posible que desees actualizar los registros DNS para que el tráfico que se envía a las URL de dominio personalizadas de Cloud Run (completamente administrado), Cloud Functions o App Engine se enrute a través del balanceador de cargas.

Por ejemplo, si tienes un dominio personalizado llamado example.com y todos tus servicios de Cloud Run se mapean a este dominio, debes actualizar el registro DNS de example.com para que 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.

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 de protección contra ataques DSD/WAF perimetral que está disponible para los servicios a los que se accede a través de un balanceador de cargas de HTTP(S) externo. Si deseas obtener información sobre cómo configurar las políticas de seguridad de Google Cloud Armor para el balanceo de cargas de HTTP(S), consulta Configura las políticas de seguridad de Google Cloud Armor.

Puedes adjuntar las políticas de Google Cloud Armor al 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 \
   --security-policy my-policy \
   --global

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 asigna a estos servicios pueden omitir el balanceador de cargas y dirigirse de forma directa a las URL del servicio; de esta forma, eluden las políticas de seguridad habilitadas aquí.

Si usas Cloud Functions, puedes usar la configuración de entrada internal-and-gclb para asegurarte de que se bloqueen las solicitudes que se envían a las URL predeterminadas de cloudfunctions.net o a cualquier otro dominio personalizado configurados a través de Cloud Functions.

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 beta 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, haz lo siguiente:

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

Próximos pasos