Modelo de implementación de API Gateway
Acerca de los componentes de la API
Una API definida en API Gateway consta de dos componentes principales:
Configuración de la API: Es la configuración de la API que se creó cuando subiste una definición de la API. Creas la definición de la API como una especificación de OpenAPI. Si tu API administra servicios de gRPC en Cloud Run, puedes definir tu API con una definición y configuración de un servicio de gRPC.
Cada vez que subes una definición de API, API Gateway crea una nueva configuración de API. Es decir, puedes crear una configuración de API, pero no podrás modificarla más adelante. Si más adelante editas la definición de la API en la especificación de OpenAPI o la definición del servicio de gRPC y, luego, subes la definición de la API editada, crearás una nueva configuración de la API.
Puerta de enlace: Es un proxy escalable de alto rendimiento basado en Envoy que aloja la configuración de API implementada. La implementación de una configuración de API en una puerta de enlace crea la URL externa que los clientes de la API usan para acceder a la API.
En la siguiente imagen, se muestran estos componentes:
Acerca de la implementación de una configuración de API en una puerta de enlace
Implementas una configuración de API en una puerta de enlace para que tus clientes de API puedan acceder a ella:
Una puerta de enlace:
Se implementa en una región específica de GCP. Una región es una región geográfica específica en GCP en la que puedes implementar recursos.
Se debe alojar una configuración de API. No puedes crear una puerta de enlace vacía, es decir, una sin una configuración de API. Sin embargo, después de crear una puerta de enlace, puedes actualizarla para reemplazar una configuración de API por otra.
Solo puedes alojar una única configuración de API. No puedes implementar varios parámetros de configuración de API en la misma puerta de enlace.
Luego, administra cada puerta de enlace implementada por separado. Para cada puerta de enlace, puedes hacer lo siguiente:
- Iniciar, detener o borrar la puerta de enlace
- Visualiza registros y métricas
- Visualiza información de seguimiento
Cómo elegir una región de GCP
Cada puerta de enlace se implementa en una región geográfica específica en GCP. API Gateway admite las siguientes regiones de GCP para la implementación:
asia-northeast1australia-southeast1europe-west1europe-west2us-east1us-east4us-central1us-west2us-west3us-west4
Define el extremo de la configuración de la API implementada
Cuando implementas una configuración de API en una puerta de enlace, API Gateway crea una URL única para la puerta de enlace en el dominio gateway.dev. Luego, tus clientes de API
usarán una URL en el siguiente formato para acceder a la configuración de API implementada:
https://GATEWAY_ID-HASH.REGION_CODE.gateway.dev
donde GATEWAY_ID es el nombre de la puerta de enlace, HASH es el código hash único generado cuando se implementó la API y REGION_CODE es el código de la región de GCP en la que implementaste la puerta de enlace.
Por ejemplo:
my-gateway-a12bcd345e67f89g0h.uc.gateway.dev
Cómo configurar una cuenta de servicio para implementar parámetros de configuración de la API
Una configuración de API implementada en una puerta de enlace se ejecuta con los permisos asociados a la roles otorgados a la cuenta de servicio que se usó para crear la configuración de la API. Por lo tanto, por lo general, se define una cuenta de servicio independiente para crear parámetros de configuración de la API. Luego, esa cuenta de servicio se asigna solo a los roles necesarios para acceder al servicio de backend. De esta manera, puedes limitar los permisos asociados con la configuración de la API.
Además de los roles necesarios para acceder al servicio de backend, la cuenta de servicio debe tener los siguientes permisos:
El permiso
iam.serviceAccounts.actAs. Este permiso se incluye en la función de usuario de cuenta de servicio.Los permisos necesarios para acceder a tu servicio de backend Por ejemplo, si tu backend se implementa como una Cloud Function, la cuenta de servicio debe tener, como mínimo, el rol de Invocador de Cloud Functions. Para un backend de Cloud Run, el rol es Invocador de Cloud Run. Cuando limitas los permisos asociados con la configuración de la API, puedes proteger mejor tus sistemas de backend.
Consulta Configura tu entorno de desarrollo para obtener más información.
Acerca de reducir la escala a cero
API Gateway es un servicio de escala a cero. Esto significa que, cuando no hay tráfico, se borran todas las instancias de la puerta de enlace. Cuando el tráfico aumenta, se crean instancias nuevas según se necesiten para controlar la carga. GCP controla automáticamente el escalamiento a cero. No es necesario que lo configures ni lo administres.
Usa un balanceador de cargas
Cada puerta de enlace implementada en una región contiene un balanceador de cargas integrado para administrar las solicitudes de clientes a la API implementadas en la puerta de enlace. No es necesario que crees un balanceador de cargas independiente para cada puerta de enlace.
Debes crear un balanceador de cargas cuando implementas la misma API en las puertas de enlace ubicadas en en diferentes regiones. Luego, el balanceador de cargas dirige las solicitudes de la API a las diferentes regiones. Consulta Implementa una API en varias regiones a continuación para obtener más información.
Cómo configurar el acceso SSL a una API
API Gateway admite el acceso HTTPS a una API implementada en una puerta de enlace. Debido a que tus APIs se implementan en el dominio gateway.dev, Google crea y administra el certificado SSL en el balanceador de cargas integrado con la puerta de enlace.
No es necesario que crees ni subas tu propio certificado.
Cómo configurar un servidor de nombres de dominio
De forma predeterminada, los clientes de la API realizan solicitudes a un dominio gateway.dev para acceder a una API implementada, como se mostró antes.
Los nombres de dominio personalizados son para API Gateway cuando se usan junto con el balanceo de cargas HTTP(S) para API Gateway PVI. Para personalizar el nombre de dominio, crea un balanceador de cargas para usar tu nombre de dominio personalizado y, luego, dirige las solicitudes al dominio gateway.dev de tu API implementada. Para obtener más información, consulta Usa un dominio personalizado con API Gateway.
Implementa varias configuraciones de API en la misma API
Solo puedes implementar una configuración de API en una puerta de enlace. Sin embargo, puedes implementar varias configuraciones de API en varias puertas de enlace dentro de la misma API.
En esta sección, se describen dos situaciones en las que podrías implementar varios parámetros de configuración de API en varias puertas de enlace dentro de una sola API.
Implementa la configuración de la API en varias puertas de enlace en la misma región
Cuando compilan una API, los desarrolladores de API suelen crear entornos de desarrollo, etapa de pruebas y producción, en los que sucede lo siguiente:
- Los desarrolladores usan el entorno de desarrollo para crear la API.
- El entorno de etapa de pruebas se utiliza para probar la API y preparar el lanzamiento para producción.
- El entorno de producción es donde tus clientes externos de la API pueden acceder a ella.
Para admitir este tipo de entorno de desarrollo, debes definir varias configuraciones de API. Por ejemplo, es posible que tengas varias configuraciones de API en desarrollo, una configuración de API que se está probando en la etapa de pruebas y una configuración de API que se implementó en producción.
API Gateway te permite crear varias configuraciones de API dentro de una sola API y, luego, implementar cada configuración de API en una puerta de enlace diferente:
En este ejemplo, tienes tres configuraciones de API diferentes: dev, stage y prod. Luego, implementarás cada configuración de API en una puerta de enlace diferente, en la que cada puerta de enlace define su propia URL de extremo única.
Implementa una configuración de API en varias regiones
A menudo, implementas una API en varias regiones de GCP. Implementarla en varias regiones ofrece varias ventajas, entre las que se incluyen una menor latencia de solicitud porque estas se dirigen a una API que se ejecuta en una región geográficamente cercana al cliente, y una confiabilidad mejorada porque una falla en una región no afecta a las APIs que se ejecutan en otras regiones.
Para implementar una API en varias regiones, debes implementar una configuración de API en una puerta de enlace de cada región. Cada configuración de API es específica de la región implementada porque tiene que hacer referencia al servicio de backend en esa región.
En la siguiente imagen, las APIs 1 y 2 se implementan en una sola región, y la API 3 se implementa en varias regiones:
En este ejemplo, cada configuración de API implementada en una puerta de enlace para la API 3 tiene un extremo de URL único, en el formato:
https://my-gateway1-a12bcd345e67f89g0h.uc.gateway.dev https://my-gateway2-b12cde345f67g89h0i.en.gateway.dev https://my-gateway3-c12bde345g67h89i0j.uw.gateway.dev
Luego, configura un balanceador de cargas mediante el balanceo de cargas de HTTP(S) para API Gateway PREVIEW a fin de controlar las solicitudes a la API y reenviar la solicitud a la región adecuada. Si deseas obtener más información, consulta Crea implementaciones multirregionales para API Gateway.
Actualiza una API
Para actualizar una API implementada, edita la definición de la API en la especificación de OpenAPI y, luego, sube la especificación. Cuando se sube una especificación nueva, se crea una configuración de API nueva.
API Gateway admite un modelo de actualización sin tiempo de inactividad, lo que significa que tu API continúa controlando las solicitudes durante la implementación de la configuración actualizada de la API. Sin embargo, hay un período mientras se implementa la configuración de la API nueva en el que es posible que la versión anterior de la configuración de la API controle algunas solicitudes.
Si implementaste la configuración de API en varias regiones y puertas de enlace, debes volver a implementar la configuración actualizada de la API en cada región por separado.