Beispiele für Netzwerkressourcenkonfigurationen
Hier finden Sie Beispiele, wie Sie Netzwerkressourcen für die API-Gateway-Entwicklung konfigurieren können.
Bevor Sie den API-Gateway-Service zur Erstellung von API-Gateways und zur Bereitstellung von APIs als API-Deployments in ihnen verwenden können, müssen Sie Folgendes sicherstellen:
- Sie müssen Zugriff auf einen Oracle Cloud Infrastructure-Mandanten haben. Der Mandant muss über ein Abonnement für mindestens eine der Regionen verfügen, in denen API-Gateway verfügbar ist (siehe Verfügbarkeit nach Region).
-
Ihr Mandanten muss über eine ausreichende Quota für API-Gateway-bezogene Ressourcen verfügen (siehe Limits).
- In Ihrem Mandanten muss bereits ein Compartment vorhanden sein, das über die erforderlichen Netzwerkressourcen verfügt. Wenn ein solches Compartment noch nicht vorhanden ist, müssen Sie es erstellen. Siehe Compartments für eigene Netzwerkressourcen und API-Gateway-Ressourcen im Mandanten erstellen, falls noch nicht vorhanden.
- Das Compartment, das über Netzwerkressourcen verfügt, muss ein VCN, ein öffentliches oder privates regionales Subnetz und weitere Ressourcen (wie ein Internetgateway, eine Routentabelle, Sicherheitslisten und/oder Netzwerksicherheitsgruppen) enthalten. Um High Availability sicherzustellen, können API-Gateways nur in regionalen Subnetzen (und nicht in AD-spezifischen Subnetzen) erstellt werden. Beachten Sie, dass ein API-Gateway in der Lage sein muss, die Backends zu erreichen, die in der API-Deployment-Spezifikation definiert sind. Beispiel: Wenn sich das Backend im öffentlichen Internet befindet, muss das VCN über ein Internetgateway verfügen, damit das API-Gateway Anforderungen an das Backend weiterleiten kann.
-
Das VCN muss über ein Set von DHCP-Optionen mit einem geeigneten DNS-Resolver verfügen, um Hostnamen, die in einer API-Deployment-Spezifikation definiert sind, IP-Adressen zuzuordnen. Wenn im VCN noch kein solches DHCP-Optionsset vorhanden ist, müssen Sie eines erstellen. Wählen Sie das DHCP-Optionsset für das Subnetz des API-Gateways wie folgt aus:
- Wenn der Hostname öffentlich im Internet veröffentlicht wird oder der Hostname zu einer Instanz in demselben VCN gehört, wählen Sie ein DHCP-Optionsset aus, bei dem der von Oracle bereitgestellte Internet- und VCN-Resolver als DNS-Typ festgelegt ist. Hierbei handelt es sich um den Standardwert, wenn Sie kein DHCP-Optionsset explizit auswählen.
- Wenn sich der Hostname in Ihrem eigenen privaten oder internen Netzwerk befindet (z.B. bei einer VCN-Verbindung über FastConnect), wählen Sie ein DHCP-Optionsset aus, bei dem "Benutzerdefinierter Resolver" als DNS-Typ festgelegt und die URL eines geeigneten DNS-Servers angegeben ist, der den Hostnamen in eine IP-Adresse auflösen kann.
Beachten Sie, dass Sie die DNS-Serverdetails im DHCP-Optionsset ändern können, das für das Subnetz eines API-Gateways angegeben ist. Das API-Gateway wird neu konfiguriert, sodass die aktualisierten DNS-Serverdetails innerhalb von zwei Stunden verwendet werden. Weitere Informationen zum Auflösen von Hostnamen in IP-Adressen finden Sie unter DNS im virtuellen Cloud-Netzwerk und DHCP-Optionen.
- In Ihrem Mandanten muss bereits ein Compartment vorhanden sein, das über API-Gateway-bezogene Ressourcen (API-Gateways, API-Deployments) verfügt. Dieses Compartment kann (muss aber nicht) dasselbe Compartment sein, das die Netzwerkressourcen enthält. Siehe Compartments für eigene Netzwerkressourcen und API-Gateway-Ressourcen im Mandanten erstellen, falls noch nicht vorhanden. Beachten Sie, dass sich die API-Gateway-bezogenen Ressourcen im Root-Compartment befinden können. Wenn Sie jedoch damit rechnen, dass mehrere Teams API-Gateways erstellen, sollten Sie ein separates Compartment für jedes Team erstellen.
-
Um API-Gateways zu erstellen und APIs in ihnen bereitzustellen, müssen Sie Mitglied in einer der folgenden Gruppen sein:
- Der Administratorengruppe des Mandanten.
-
Einer Gruppe, der durch Policys die entsprechenden Berechtigungen für Netzwerk- und API-Gateway-bezogene Ressourcen erteilt wurden. Siehe Policys für die Kontrolle des Zugriffs auf Netzwerk- und API-Gateway-bezogene Ressourcen erstellen.
- Policys müssen definiert werden, damit den API-Gateways, die Sie erstellen, bei Bedarf Zugriff auf zusätzliche Ressourcen erteilt werden kann. Siehe Policys für die Kontrolle des Zugriffs auf Netzwerk- und API-Gateway-bezogene Ressourcen erstellen.
In diesem Thema finden Sie Beispiele, wie Sie Netzwerkressourcen für API-Gateways mit einer serverlosen Funktion als Backend konfigurieren können:
- Für ein öffentliches API-Gateway in einem öffentlichen Subnetz (siehe Beispiel 1: Beispiel für eine Netzwerkressourcenkonfiguration für ein öffentliches API-Gateway in einem öffentlichen Subnetz mit einer serverlosen Funktion als HTTP-Backend)
- Für ein privates API-Gateway in einem privaten Subnetz (siehe Beispiel 2: Netzwerkressourcenkonfiguration für ein privates API-Gateway in einem privaten Subnetz mit einer serverlosen Funktion als HTTP-Backend)
In diesen Beispielen wird angenommen, dass die Standardfunktion "helloworld" in OCI Functions mit dem Namen "helloworld-func" erstellt und bereitgestellt wurde und zur Anwendung "helloworld-app" gehört (siehe Hloworld-Funktion erstellen, bereitstellen und aufrufen).
Die Beispiele in diesem Abschnitt zeigen die Verwendung von Sicherheitsregeln in Sicherheitslisten zur Kontrolle des Zugriffs. Wenn Sie Netzwerksicherheitsgruppen gegenüber Sicherheitslisten bevorzugen, können Sie identische Sicherheitsregeln für Netzwerksicherheitsgruppen angeben.
Beispiel 1: Beispiel für eine Netzwerkressourcenkonfiguration für ein öffentliches API-Gateway in einem öffentlichen Subnetz mit einer serverlosen Funktion als HTTP-Backend
In diesem Beispiel wird davon ausgegangen, dass Sie ein öffentliches API-Gateway, auf das direkt über das Internet zugegriffen werden kann, mit einer serverlosen Funktion als HTTP-Backend konfigurieren möchten.
Erstellen Sie für diese Beispielkonfiguration die folgenden Ressourcen in der dargestellten Reihenfolge und mit den in der Tabelle "Beispielressourcenkonfiguration" aufgeführten Eigenschaften:
- Ein VCN mit dem Namen "acme-vcn1".
- Ein Internetgateway mit dem Namen "acme-internet-gateway".
- Eine Routentabelle mit dem Namen "acme-routetable-public".
- Eine Sicherheitsliste mit dem Namen "acme-security-list-public", einer Ingress-Regel, die öffentlichen Zugriff auf das API-Gateway ermöglicht, und einer Egress-Regel, die den Zugriff auf OCI Functions ermöglicht.
- Ein öffentliches Subnetz mit dem Namen "acme-public-subnet".
- Ein API-Gateway mit dem Namen "acme-public-gateway" und einem API-Deployment mit dem Namen "acme-public-deployment".
Die Ausgabe eines curl-Befehls aus dem öffentlichen Internet für das API-Deployment gibt die angezeigte Antwort zurück:
[user@machinename ~]$ curl -X GET https://lak...sjd.apigateway.us-phoenix-1.oci.customer-oci.com/marketing/hello
Hello, world!Beispielkonfiguration einer Netzwerkressource
| Ressource | Beispiel |
|---|---|
| VCN |
Manuell erstellt und wie folgt definiert:
|
| Internetgateway |
Manuell erstellt und wie folgt definiert:
|
| Routentabelle |
Eine manuell erstellte Routentabelle, die wie folgt benannt und definiert wurde:
|
| DHCP-Optionen |
Automatisch erstellt und wie folgt definiert:
|
| Sicherheitsliste |
Eine (zusätzlich zur Standardsicherheitsliste) manuell erstellte Sicherheitsliste, die wie folgt benannt und definiert wurde:
|
| Subnetz |
Ein manuell erstelltes regionales öffentliches Subnetz, das wie folgt benannt und definiert wurde:
|
| API-Gateway |
Ein öffentliches API-Gateway, das wie folgt erstellt und definiert wurde:
|
| API-Deployment |
Ein API-Deployment, das wie folgt erstellt und definiert wurde:
|
Beispiel 2: Netzwerkressourcenkonfiguration für ein privates API-Gateway in einem privaten Subnetz mit einer serverlosen Funktion als HTTP-Backend
In diesem Beispiel wird davon ausgegangen, dass Sie ein privates API-Gateway, auf das nur über einen Bastionhost (und nicht direkt über das Internet) zugegriffen werden kann, mit einer serverlosen Funktion als HTTP-Backend konfigurieren möchten.
Erstellen Sie für diese Beispielkonfiguration die folgenden Ressourcen in der dargestellten Reihenfolge und mit den in der Tabelle "Beispielressourcenkonfiguration" aufgeführten Eigenschaften:
- Ein VCN mit dem Namen "acme-vcn2"
- Ein Internetgateway mit dem Namen "acme-internet-gateway"
- Ein Servicegateway mit dem Namen "acme-service-gateway". (In diesem Beispiel müssen Sie nur ein Servicegateway erstellen, da das API-Gateway nur ein OCI Functions-Backend hat. Wenn das API-Gateway jedoch sowohl ein OCI Functions-Backend als auch ein HTTP-End im öffentlichen Internet hat, können Sie stattdessen ein NAT-Gateway erstellen, um auf beide Backend zuzugreifen.)
- Eine Routentabelle mit dem Namen "acme-routetable-private"
- Eine Sicherheitsliste mit dem Namen acme-security-list-private, einer Ingress-Regel, die dem Bastionhost den Zugriff auf das API-Gateway ermöglicht, und einer Egress-Regel, die den Zugriff auf OCI Functions ermöglicht.
- Ein privates Subnetz mit dem Namen "acme-private-subnet"
- Ein API-Gateway mit dem Namen "acme-private-gateway" und einem API-Deployment mit dem Namen "acme-private-deployment"
- Eine Routentabelle mit dem Namen "acme-routetable-bastion"
- Eine Sicherheitsliste mit dem Namen "acme-security-list-bastion", einer Ingress-Regel, die öffentlichen SSH-Zugriff auf den Bastionhost zulässt, und einer Egress-Regel, mit der der Bastionhost auf das API-Gateway zugreifen kann.
- Ein öffentliches Subnetz mit dem Namen "acme-bastion-public-subnet"
- Eine Compute-Instanz mit einer öffentlichen IP-Adresse, die als Bastionhost fungiert, und dem Namen "acme-bastion-instance"
Wenn SSH-Zugriff auf den Bastionhost gewährt wurde, gibt die Ausgabe eines curl-Befehls für das API-Deployment die angezeigte Antwort zurück:
[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!Beispielressourcenkonfiguration
| Ressource | Beispiel |
|---|---|
| VCN |
Manuell erstellt und wie folgt definiert:
|
| Internetgateway |
Manuell erstellt und wie folgt definiert:
|
| Servicegateway |
Manuell erstellt und wie folgt definiert:
|
| Routentabellen |
Zwei manuell erstellte Routentabellen, die wie folgt benannt und definiert sind:
|
| DHCP-Optionen |
Automatisch erstellt und wie folgt definiert:
|
| Sicherheitsliste |
Zwei (zusätzlich zur Standardsicherheitsliste) manuell erstellte Sicherheitslisten, die wie folgt benannt und definiert wurden:
|
| Subnetz |
Zwei manuell erstellte regionale Subnetze, die wie folgt benannt und definiert wurden:
|
| API-Gateway |
Ein privates API-Deployment, das wie folgt erstellt und definiert wurde:
|
| API-Deployment |
Ein API-Deployment, das wie folgt erstellt und definiert wurde:
|
| Instanz |
Eine Compute-Instanz, die wie folgt erstellt und definiert wurde:
|