Configuraciones de recursos de red de ejemplo
Obtenga más información sobre ejemplos de cómo puede configurar los recursos de red para el desarrollo de gateway de API.
Antes de utilizar el servicio de gateway de API para crear gateways y desplegar API en ellos tenga en cuenta los siguientes puntos:
- Debe tener acceso a un arrendamiento de Oracle Cloud Infrastructure. El arrendamiento debe estar suscrito a una o varias de las regiones en las que el gateway de API esté disponible (consulte Disponibilidad por región).
-
El arrendamiento debe tener una cuota adecuada para los recursos relacionados con el gateway de API (consulte Límites de servicio).
- En el arrendamiento, debe haber un compartimento para los recursos de red necesarios. Si ese compartimento no existe, tendrá que crearlo. Consulte Creación de compartimentos para recursos de red y de gateway de API en el arrendamiento si no existe ninguno.
- El compartimento que contiene los recursos de red debe contener una VCN, una subred regional pública o privada y otros recursos (como un gateway de Internet, una tabla de rutas, listas de seguridad y/o grupos de seguridad de red). Para garantizar una alta disponibilidad, los gateways de API solo se pueden crear en subredes regionales (no en subredes específicas de dominio de disponibilidad). Tenga en cuenta que un gateway de API debe poder acceder a los backends definidos en la especificación de despliegue de API. Por ejemplo, si el backend está en Internet, la VCN debe tener un gateway de Internet para activar el gateway de API para enviar las solicitudes al backend.
-
La VCN debe tener un juego de opciones DHCP que incluya un solucionador de DNS adecuado para asignar nombres de host definidos en una especificación de despliegue de API a direcciones IP. Si este juego de opciones DHCP ya no existe en la VCN, tendrá que crearlo. Seleccione las opciones DHCP definidas para la subred del gateway de API de la siguiente manera:
- Si el nombre de host se publica públicamente en Internet o si el nombre de host pertenece a una instancia de la misma VCN, seleccione un juego de opciones DHCP que tenga Internet y solucionador VCN proporcionados por Oracle como tipo DNS. Esta es la opción por defecto si no selecciona explícitamente un juego de opciones DHCP.
- Si el nombre de host está en su propia red privada o interna (por ejemplo, conectada a la VCN por FastConnect), seleccione un juego de opciones DHCP que tenga un solucionador personalizado como tipo DNS y tenga la URL de un servidor DNS adecuado que pueda resolver el nombre de host en una dirección IP.
Tenga en cuenta que puede cambiar los detalles del servidor DNS en el juego de opciones DHCP especificado para la subred de un gateway de API. El gateway de API se volverá a configurar para utilizar los detalles actualizados del servidor DNS en un plazo de dos horas. Para obtener más información sobre cómo resolver nombres de host en direcciones IP, consulte DNS en su red virtual en la nube y Opciones DHCP.
- En el arrendamiento, debe haber un compartimento para recursos relacionados con el gateway de API (gateways y despliegues de API). Este compartimento puede ser el mismo que contiene los recursos de red, aunque puede ser cualquier otro. Consulte Creación de compartimentos para recursos de red y de gateway de API en el arrendamiento si no existe ninguno. Tenga en cuenta que los recursos relacionados con el gateway de API se pueden alojar en el compartimento raíz. Sin embargo, si espera que varios equipos creen gateways de API, le recomendamos que cree un compartimento independiente para cada equipo.
-
Para crear gateways y desplegar API en ellos, debe pertenecer a uno de los siguientes grupos:
- Grupo de administradores del arrendamiento.
-
Grupo al que las políticas otorgan los permisos adecuados para recursos relacionados con gateway de API y de red. Consulte Creación de políticas para controlar el acceso a recursos relacionados con gateway de API y de red.
- Se deben definir políticas para que los gateways de API que usted cree tengan acceso a recursos adicionales, si fuera necesario. Consulte Creación de una política para que los usuarios de gateway de API tengan acceso a funciones.
En este tema se proporcionan ejemplos de cómo puede configurar los recursos de red para gateways de API con una función sin servidor como backend:
- para un gateway de API pública en una subred pública (consulte Ejemplo 1: Configuración de recursos de red de ejemplo para un gateway de API pública en una subred pública con una función sin servidor como backend HTTP)
- para un gateway de API privada en una subred privada (consulte Ejemplo 2: Configuración de recursos de red de ejemplo para un gateway de API privada en una subred privada con una función sin servidor como backend HTTP)
En estos ejemplos se supone que la función Hola mundo por defecto se ha creado y desplegado en OCI Functions con el nombre Hola Mundo-Fun y que pertenece a la aplicación Hola Mundo-Aplicación (consulte Creación, despliegue y llamada de una función Hola Mundo).
Los ejemplos de esta sección muestran el uso de reglas de seguridad en listas de seguridad para controlar el acceso. Si prefiere los grupos de seguridad de red en lugar de las listas de seguridad, puede especificar reglas de seguridad idénticas para los grupos de seguridad de red.
Ejemplo 1: Configuración de recursos de red de ejemplo para un gateway de API pública en una subred pública con una función sin servidor como backend HTTP
En este ejemplo se supone que desea un gateway de API pública al que se puede acceder directamente desde Internet con una función sin servidor como backend HTTP.
Para lograr esta configuración de ejemplo, cree los siguientes recursos en la secuencia que se muestra con las propiedades que se muestran en la tabla Configuración de recursos de ejemplo que aparece a continuación:
- Una VCN denominada 'acme-vcn1'.
- Un gateway de Internet denominado 'acme-internet-gateway'.
- Una tabla de rutas denominada 'acme-routetable-public'.
- Lista de seguridad denominada 'acme-security-list-public' con una regla de entrada que permite el acceso público al gateway de API y una regla de salida que permite el acceso a OCI Functions.
- Una subred pública denominada 'acme-public-subnet'.
- Un gateway de API denominado 'acme-public-gateway' con un despliegue de API denominado 'acme-public-deployment'.
La ejecución de un comando curl desde Internet en el despliegue de la API devuelve la respuesta que se muestra:
[user@machinename ~]$ curl -X GET https://lak...sjd.apigateway.us-phoenix-1.oci.customer-oci.com/marketing/hello
Hello, world!
Configuración de recursos de red de ejemplo
Recurso | Ejemplo |
---|---|
VCN |
Se crea manualmente y se define de la siguiente manera:
|
Gateway de Internet |
Se crea manualmente y se define de la siguiente manera:
|
Tabla de rutas |
Una tabla de rutas creada manualmente, denominada y definida de la siguiente manera:
|
Opciones de DHCP |
Creadas automáticamente y definidas de la siguiente manera:
|
Lista de seguridad |
Una lista de seguridad creada manualmente (además de la lista de seguridad por defecto), denominada y definida de la siguiente manera:
|
Subred |
Una subred pública regional creada manualmente, denominada y definida de la siguiente manera:
|
Gateway de API |
Un gateway de API pública creado y definido de la siguiente manera:
|
Despliegue de API |
Un despliegue de API creado y definido de la siguiente manera:
|
Ejemplo 2: Configuración de recursos de red para un gateway de API privada en una subred privada con una función sin servidor como backend HTTP
En este ejemplo se supone que desea un gateway de API privada al que solo se puede acceder mediante un bastion host (en lugar de directamente desde Internet) con una función sin servidor como backend HTTP.
Para lograr esta configuración de ejemplo, cree los siguientes recursos en la secuencia que se muestra con las propiedades que se muestran en la tabla Configuración de recursos de ejemplo que aparece a continuación:
- Una VCN denominada acme-vcn2
- Un gateway de Internet denominado acme-internet-gateway
- Un gateway de servicio denominado acme-service-gateway. (En este ejemplo, solo tiene que crear un gateway de servicio porque el gateway de API solo tiene un backend de OCI Functions. Sin embargo, si el gateway de API tiene un backend de OCI Functions y también un backend HTTP en Internet, puede crear un gateway de NAT en lugar de acceder a ambos backends).
- Una tabla de rutas denominada acme-routetable-private
- Lista de seguridad denominada acme-security-list-private con una regla de entrada que permite al host bastion acceder al gateway de API y una regla de salida que permite acceder a OCI Functions.
- Una subred privada denominada acme-private-subnet
- Un gateway de API denominado acme-private-gateway con un despliegue de API denominado acme-private-deployment
- Una tabla de rutas denominada acme-routetable-bastion
- Una lista de seguridad denominada acme-security-list-bastion con una regla de entrada que permite el acceso SSH público al bastion host y una regla de salida que permite al bastion host acceder al gateway de API.
- Una subred pública denominada acme-bastion-public-subnet
- Una instancia informática con una dirección IP pública que actuará como el bastion host denominada acme-bastion-instance
Al realizar el acceso SSH al bastion host, la ejecución de un comando curl en el despliegue de API devuelve la respuesta que se muestra:
[user@machinename ~]$ ssh opc@198.51.100.254
[opc@acme-bastion-instance ~]$ curl -X GET https://pwa...djt.apigateway.us-phoenix-1.oci.customer-oci.com/marketing-private/hello
Hello, world!
Configuración de recursos de ejemplo
Recurso | Ejemplo |
---|---|
VCN |
Se crea manualmente y se define de la siguiente manera:
|
Gateway de Internet |
Se crea manualmente y se define de la siguiente manera:
|
Gateway de servicio |
Se crea manualmente y se define de la siguiente manera:
|
Tablas de rutas |
Dos tablas de rutas creadas manualmente, denominadas y definidas de la siguiente manera:
|
Opciones de DHCP |
Creadas automáticamente y definidas de la siguiente manera:
|
Lista de seguridad |
Dos listas de seguridad creadas manualmente (además de la lista de seguridad por defecto), denominadas y definidas de la siguiente manera:
|
Subred |
Dos subredes regionales creadas manualmente, denominadas y definidas de la siguiente manera:
|
Gateway de API |
Un gateway de API privada creado y definido de la siguiente manera:
|
Despliegue de API |
Un despliegue de API creado y definido de la siguiente manera:
|
Instancia |
Una instancia informática creada y definida de la siguiente manera:
|