Configurazioni delle risorse di rete di esempio
Scopri alcuni esempi di come configurare le risorse di rete per lo sviluppo del gateway API.
Prima di poter utilizzare il servizio Gateway API per creare gateway API e distribuire le API su di essi come distribuzioni API:
- Devi avere accesso a una tenancy di Oracle Cloud Infrastructure. La tenancy deve essere sottoscritta a una o più aree in cui è disponibile API Gateway (vedere Disponibilità per area).
-
La tenancy deve disporre di una quota sufficiente nelle risorse correlate a API Gateway (vedere Limiti del servizio).
- All'interno della tenancy deve essere già presente un compartimento in cui possedere le risorse di rete necessarie. Se un compartimento di questo tipo non esiste già, sarà necessario crearlo. Vedere Crea compartimenti per la proprietà delle risorse di rete e del gateway API nella tenancy, se non esistono già.
- Il compartimento proprietario delle risorse di rete deve contenere una VCN, una subnet regionale pubblica o privata e altre risorse (ad esempio un gateway Internet, una tabella di instradamento, liste di sicurezza e/o gruppi di sicurezza di rete). Per garantire l'alta disponibilità, i gateway API possono essere creati solo nelle subnet regionali (non nelle subnet specifiche di AD). Tenere presente che un gateway API deve essere in grado di raggiungere i backend definiti nella specifica di distribuzione API. Ad esempio, se il backend si trova nella rete Internet pubblica, la VCN deve disporre di un gateway Internet per consentire al gateway API di instradare le richieste al backend.
-
La VCN deve disporre di un set di opzioni DHCP che include un resolver DNS appropriato per mappare i nomi host definiti in una specifica di distribuzione API agli indirizzi IP. Se un set di opzioni DHCP di questo tipo non esiste già nella VCN, sarà necessario crearlo. Selezionare le opzioni DHCP impostate per la subnet del gateway API come indicato di seguito.
- Se il nome host viene pubblicato pubblicamente su Internet o se appartiene a un'istanza nella stessa VCN, selezionare un set di opzioni DHCP con Internet e resolver VCN forniti da Oracle come tipo di DNS. Questa è l'impostazione predefinita se non si seleziona esplicitamente un set di opzioni DHCP.
- Se il nome host si trova nella propria rete privata o interna (ad esempio, connessa alla VCN mediante FastConnect), selezionare un set di opzioni DHCP con resolver personalizzato come tipo di DNS e l'URL di un server DNS appropriato in grado di risolvere il nome host in un indirizzo IP.
Si noti che è possibile modificare i dettagli del server DNS nel set di opzioni DHCP specificato per la subnet di un gateway API. Il gateway API verrà riconfigurato per utilizzare i dettagli aggiornati del server DNS entro due ore. Per ulteriori informazioni sulla risoluzione dei nomi host negli indirizzi IP, vedere DNS in Your Virtual Cloud Network e Opzioni DHCP.
- All'interno della tenancy deve essere già presente un compartimento in cui possedere risorse correlate al gateway API (gateway API, distribuzioni API). Questo compartimento può essere, ma non deve necessariamente essere, lo stesso compartimento che contiene le risorse di rete. Vedere Crea compartimenti per la proprietà delle risorse di rete e del gateway API nella tenancy, se non esistono già. Tenere presente che le risorse correlate a API Gateway possono risiedere nel compartimento radice. Tuttavia, se prevedi che più team creino gateway API, la best practice consiste nel creare un compartimento separato per ogni team.
-
Per creare gateway API e distribuire API su di essi, è necessario appartenere a uno degli elementi riportati di seguito.
- Gruppo Administrators della tenancy.
-
Gruppo a cui i criteri concedono le autorizzazioni appropriate per le risorse di rete e correlate a API Gateway. Vedere Create Policies to Control Access to Network and API Gateway-Related Resources.
- È necessario definire i criteri per concedere ai gateway API creati l'accesso a risorse aggiuntive, se necessario. Vedere Creare un criterio per concedere agli utenti del gateway API l'accesso alle funzioni.
In questo argomento vengono forniti esempi di come configurare le risorse di rete per i gateway API con una funzione serverless come backend:
- per un gateway API pubblico in una subnet pubblica (vedere Esempio 1: Configurazione delle risorse di rete di esempio per un gateway API pubblico in una subnet pubblica con una funzione serverless come backend HTTP)
- per un gateway API privato in una subnet privata (vedere Esempio 2: configurazione delle risorse di rete per un gateway API privato in una subnet privata con una funzione serverless come backend HTTP)
Questi esempi presuppongono che la funzione helloworld predefinita sia stata creata e distribuita in Funzioni OCI con il nome helloworld-func e appartenente all'applicazione helloworld-app (vedere Creazione, distribuzione e richiamo di una funzione Helloworld).
Gli esempi riportati in questa sezione mostrano l'uso delle regole di sicurezza negli elenchi di sicurezza per controllare l'accesso. Se si preferisce i gruppi di sicurezza di rete piuttosto che le liste di sicurezza, è possibile specificare regole di sicurezza identiche per i gruppi di sicurezza di rete.
Esempio 1: configurazione di risorse di rete di esempio per un gateway API pubblico in una subnet pubblica con una funzione serverless come backend HTTP
In questo esempio si presume che si desideri un gateway API pubblico a cui sia possibile accedere direttamente da Internet, con una funzione serverless come backend HTTP.
Per ottenere questa configurazione di esempio, si creano le seguenti risorse nella sequenza mostrata, con le proprietà mostrate nella tabella Configurazione risorse di esempio riportata di seguito:
- Una VCN denominata 'acme-vcn1'.
- Un gateway Internet denominato 'acme-internet-gateway'.
- Tabella di instradamento denominata 'acme-routetable-public'.
- Lista di sicurezza denominata 'acme-security-list-public', con una regola di entrata che consente l'accesso pubblico al gateway API e una regola di uscita che consente l'accesso alle funzioni OCI.
- Una subnet pubblica denominata 'acme-public-subnet'.
- Un gateway API denominato 'acme-public-gateway', con una distribuzione API denominata 'acme-public-deployment'.
L'emissione di un comando curl dalla rete Internet pubblica rispetto alla distribuzione API restituisce la risposta mostrata:
[user@machinename ~]$ curl -X GET https://lak...sjd.apigateway.us-phoenix-1.oci.customer-oci.com/marketing/hello
Hello, world!Configurazione delle risorse di rete di esempio
| Risorse | Esempio |
|---|---|
| VCN |
Creato manualmente e definito come indicato di seguito.
|
| Gateway Internet |
Creato manualmente e definito come indicato di seguito.
|
| Tabella di instradamento |
Una tabella di instradamento creata manualmente, denominata e definita come segue:
|
| Opzioni DHCP |
Creato automaticamente e definito come segue:
|
| Lista di sicurezza |
Una lista di sicurezza creata manualmente (oltre alla lista di sicurezza predefinita), denominata e definita come segue:
|
| subnet |
Una subnet pubblica regionale creata manualmente, denominata e definita come segue:
|
| API Gateway |
Un gateway API pubblico creato e definito come riportato di seguito.
|
| Distribuzione API |
Una distribuzione API creata e definita come riportato di seguito.
|
Esempio 2: configurazione delle risorse di rete per un gateway API privato in una subnet privata con una funzione serverless come backend HTTP
In questo esempio si presume che si desideri un gateway API privato a cui sia possibile accedere solo tramite un bastion host (anziché accedere direttamente da Internet), con una funzione serverless come backend HTTP.
Per ottenere questa configurazione di esempio, si creano le seguenti risorse nella sequenza mostrata, con le proprietà mostrate nella tabella Configurazione risorse di esempio riportata di seguito:
- Una VCN denominata acme-vcn2
- Un gateway Internet denominato acme-internet-gateway
- Un gateway di servizi denominato acme-service-gateway. In questo esempio è sufficiente creare un gateway di servizi, poiché il gateway API dispone solo di un backend Funzioni OCI. Tuttavia, se il gateway API dispone sia di un backend OCI Functions che di un backend HTTP nella rete Internet pubblica, è possibile creare un gateway NAT per accedere a entrambi i backend.
- Una tabella di instradamento denominata acme-routetable-private
- Lista di sicurezza denominata acme-security-list-private, con una regola di entrata che consente all'host bastion di accedere al gateway API e una regola di uscita che consente l'accesso alle funzioni OCI.
- Una subnet privata denominata acme-private-subnet
- Un gateway API denominato acme-private-gateway, con una distribuzione API denominata acme-private-deployment
- Una tabella di instradamento denominata acme-routetable-bastion
- Lista di sicurezza denominata acme-security-list-bastion, con una regola di entrata che consente l'accesso SSH pubblico all'host bastion e una regola di uscita che consente all'host bastion di accedere al gateway API.
- Subnet pubblica denominata acme-bastion-public-subnet
- Un'istanza di computazione con un indirizzo IP pubblico da utilizzare come host bastion, denominato acme-bastion-instance
Avendo la shell SSH nell'host bastion, l'esecuzione di un comando curl sulla distribuzione API restituisce la risposta mostrata:
[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!Esempio di configurazione delle risorse
| Risorse | Esempio |
|---|---|
| VCN |
Creato manualmente e definito come indicato di seguito.
|
| Gateway Internet |
Creato manualmente e definito come indicato di seguito.
|
| Gateway del servizio |
Creato manualmente e definito come indicato di seguito.
|
| Tabelle di instradamento |
Due tabelle di instradamento create manualmente, denominate e definite come segue:
|
| Opzioni DHCP |
Creato automaticamente e definito come segue:
|
| Lista di sicurezza |
Due liste di sicurezza create manualmente (oltre alla lista di sicurezza predefinita), denominate e definite come segue:
|
| subnet |
Due subnet regionali create manualmente, denominate e definite come segue:
|
| API Gateway |
Un gateway API privato creato e definito come riportato di seguito.
|
| Distribuzione API |
Una distribuzione API creata e definita come riportato di seguito.
|
| Istanze |
Una istanza di computazione creata e definita come segue:
|