Exemples de configuration de ressource réseau
Découvrez des exemples de configuration des ressources réseau pour le développement de passerelle d'API.
Pour pouvoir utiliser le service API Gateway afin de créer des passerelles d'API et de déployer des API sur ces dernières en tant que déploiements d'API, vous devez remplir les conditions suivantes :
- Vous devez avoir accès à une location Oracle Cloud Infrastructure. La location doit être abonnée à des régions dans lesquelles API Gateway est disponible (reportez-vous à Disponibilité par région).
-
Votre location doit disposer d'un quota suffisant sur les ressources liées à API Gateway (reportez-vous à Limites de service).
- Votre location doit déjà comporter un compartiment destiné à contenir les ressources réseau requises. Si ce compartiment n'existe pas, vous devez le créer. Reportez-vous à Création de compartiments pour contenir des ressources réseau et des ressources liées à API Gateway dans la location (s'ils n'existent pas déjà).
- Le compartiment propriétaire des ressources réseau doit contenir un VCN, un sous-réseau régional public ou privé et d'autres ressources (par exemple, une passerelle Internet, une table de routage, des listes de sécurité et/ou des groupes de sécurité réseau). Pour garantir une haute disponibilité, les passerelles d'API peuvent uniquement être créées dans des sous-réseaux régionaux (et non dans des sous-réseaux propres à un domaine de disponibilité). Une passerelle d'API doit pouvoir atteindre les back-ends définis dans la spécification de déploiement d'API. Par exemple, si le back-end se trouve sur le réseau Internet public, le réseau cloud virtuel doit disposer d'une passerelle Internet pour permettre à la passerelle d'API d'acheminer les demandes vers le back-end.
-
Le réseau cloud virtuel doit comporter un ensemble d'options DHCP incluant un résolveur DNS approprié pour mettre en correspondance les noms d'hôte définis dans une spécification de déploiement d'API avec les adresses IP. Si cet ensemble d'options DHCP n'existe pas dans le réseau cloud virtuel, vous devez le créer. Sélectionnez l'ensemble d'options DHCP pour le sous-réseau de la passerelle d'API comme suit :
- Si le nom d'hôte est publié publiquement sur Internet ou s'il appartient à une instance située dans le même réseau cloud virtuel, sélectionnez un ensemble d'options DHCP pour lequel le type DNS est défini sur le résolveur Internet et de réseau cloud virtuel fourni par Oracle. Il s'agit de la valeur par défaut si vous ne sélectionnez pas explicitement un ensemble d'options DHCP.
- Si le nom d'hôte se trouve sur votre propre réseau privé ou interne (par exemple, connecté au réseau cloud virtuel via FastConnect), sélectionnez un ensemble d'options DHCP dont le type DNS est défini sur un résolveur personnalisé et qui comporte l'URL d'un serveur DNS approprié pouvant résoudre le nom d'hôte en adresse IP.
Vous pouvez modifier les détails du serveur DNS dans l'ensemble d'options DHCP spécifié pour le sous-réseau d'une passerelle d'API. La passerelle d'API sera reconfigurée pour utiliser les détails mis à jour du serveur DNS dans un délai de deux heures. Pour plus d'informations sur la résolution des noms d'hôte en adresses IP, reportez-vous à DNS dans votre réseau cloud virtuel et à Options DHCP.
- Votre location doit déjà comprendre un compartiment destiné à contenir les ressources liées à API Gateway (passerelles d'API, déploiements d'API). Celui-ci peut être le même compartiment que celui contenant les ressources réseau, mais pas nécessairement. Reportez-vous à Création de compartiments pour contenir des ressources réseau et des ressources liées à API Gateway dans la location (s'ils n'existent pas déjà). Les ressources liées à API Gateway peuvent résider dans le compartiment racine. Toutefois, si plusieurs équipes sont censées créer des passerelles d'API, il est recommandé de créer un compartiment distinct pour chaque équipe.
-
Pour créer des passerelles d'API et y déployer des API, vous devez appartenir à l'un des groupes suivants :
- un groupe d'administrateurs de la location,
-
Un groupe auquel des stratégies accordent les droits d'accès appropriés aux ressources réseau et aux ressources liées à API Gateway. Reportez-vous à Création de stratégies de contrôle d'accès aux ressources réseau et aux ressources liées à API Gateway.
- Des stratégies doivent être définies pour permettre aux passerelles d'API créées d'accéder à des ressources supplémentaires, si nécessaire. Reportez-vous à Création de stratégies de contrôle d'accès aux ressources réseau et aux ressources liées à API Gateway.
Cette rubrique fournit des exemples de configuration des ressources réseau pour les passerelles d'API avec une fonction sans serveur en tant que back-end :
- Pour une passerelle d'API publique dans un sous-réseau public (reportez-vous à Exemple 1 : exemple de configuration de ressource réseau pour une passerelle d'API publique dans un sous-réseau public avec une fonction sans serveur en tant que back-end HTTP),
- Pour une passerelle d'API privée dans un sous-réseau privé (reportez-vous à Exemple 2 : configuration de ressource réseau pour une passerelle d'API privée dans un sous-réseau privé avec une fonction sans serveur en tant que back-end HTTP).
Ces exemples partent du principe que la fonction helloworld par défaut a été créée et déployée dans OCI Functions avec le nom helloworld-func et appartient à l'application helloworld-app (reportez-vous à Création, déploiement et appel d'une fonction Helloworld).
Les exemples de cette section illustrent l'utilisation de règles de sécurité dans les listes de sécurité pour contrôler l'accès. Si vous préférez les groupes de sécurité réseau plutôt que les listes de sécurité, vous pouvez spécifier des règles de sécurité identiques pour les groupes de sécurité réseau.
Exemple 1 : exemple de configuration de ressource réseau pour une passerelle d'API publique dans un sous-réseau public avec une fonction sans serveur en tant que back-end HTTP
Cet exemple part du principe que vous souhaitez utiliser une passerelle d'API publique directement accessible à partir d'Internet, avec une fonction sans serveur en tant que back-end HTTP.
Pour appliquer cet exemple de configuration, créez les ressources suivantes dans l'ordre indiqué, avec les propriétés présentées dans le tableau Exemple de configuration de ressource ci-dessous :
- Un réseau cloud virtuel nommé 'acme-vcn1'.
- Une passerelle Internet nommée 'acme-internet-gateway'.
- Une table de routage nommée 'acme-routetable-public'.
- Une liste de sécurité nommée 'acme-security-list-public', avec une règle entrante permettant l'accès public à la passerelle d'API et une règle sortante permettant l'accès à OCI Functions.
- Un sous-réseau public nommé 'acme-public-subnet'.
- Une passerelle d'API nommée 'acme-public-gateway', avec un déploiement d'API nommé 'acme-public-deployment'.
L'émission d'une commande cURL à partir du réseau Internet public sur le déploiement d'API renvoie la réponse affichée :
[user@machinename ~]$ curl -X GET https://lak...sjd.apigateway.us-phoenix-1.oci.customer-oci.com/marketing/hello
Hello, world!Exemple de configuration des ressources réseau
| Ressource | Exemple |
|---|---|
| Réseau cloud virtuel |
Créée manuellement et définie comme suit :
|
| Passerelle Internet |
Créée manuellement et définie comme suit :
|
| Table de routage |
Une table de routage créée manuellement, nommée et définie comme suit :
|
| Options DHCP |
Créées automatiquement et définies comme suit :
|
| Liste de sécurité |
Une liste de sécurité (en plus de la liste de sécurité par défaut) créée manuellement, nommée et définie comme suit :
|
| Sous-réseau |
Un sous-réseau public régional créé manuellement, nommé et défini comme suit :
|
| Passerelle d'API |
Une passerelle d'API publique créée et définie comme suit :
|
| Déploiement d'API |
Un déploiement d'API créé et défini comme suit :
|
Exemple 2 : configuration de ressource réseau pour une passerelle d'API privée dans un sous-réseau privé avec une fonction sans serveur en tant que back-end HTTP
Cet exemple part du principe que vous souhaitez utiliser une passerelle d'API privée accessible uniquement via un bastion (plutôt que directement à partir d'Internet) avec une fonction sans serveur en tant que back-end HTTP.
Pour appliquer cet exemple de configuration, créez les ressources suivantes dans l'ordre indiqué, avec les propriétés présentées dans le tableau Exemple de configuration de ressource ci-dessous :
- Un réseau cloud virtuel nommé acme-vcn2.
- Une passerelle Internet nommée acme-internet-gateway.
- Une passerelle de service nommée acme-service-gateway. (Dans cet exemple, vous avez uniquement besoin de créer une passerelle de service car la passerelle d'API ne dispose que d'un back-end OCI Functions. Cependant, si la passerelle d'API dispose à la fois d'un back-end OCI Functions et d'un back-end HTTP sur le réseau Internet public, vous pouvez créer une passerelle NAT au lieu d'accéder aux deux back-ends.)
- Une table de routage nommée acme-routetable-private.
- Une liste de sécurité nommée acme-security-list-private, avec une règle entrante permettant au bastion d'accéder à la passerelle d'API et une règle sortante permettant l'accès à OCI Functions.
- Un sous-réseau privé nommé acme-private-subnet.
- Une passerelle d'API nommée acme-private-gateway, avec un déploiement d'API nommé acme-private-deployment.
- Une table de routage nommée acme-routetable-bastion.
- Une liste de sécurité nommée acme-security-list-bastion, avec une règle entrante permettant l'accès SSH public au bastion et une règle sortante permettant au bastion d'accéder à la passerelle d'API.
- Un sous-réseau public nommé acme-bastion-public-subnet.
- Une instance de calcul avec une adresse IP publique pour servir de bastion, appelée acme-bastion-instance.
Par accès SSH au bastion, l'émission d'une commande cURL sur le déploiement d'API renvoie la réponse affichée :
[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!Exemple de configuration de ressource
| Ressource | Exemple |
|---|---|
| Réseau cloud virtuel |
Créée manuellement et définie comme suit :
|
| Passerelle Internet |
Créée manuellement et définie comme suit :
|
| Passerelle de service |
Créée manuellement et définie comme suit :
|
| Tables de routage |
Deux tables de routage créées manuellement, nommées et définies comme suit :
|
| Options DHCP |
Créées automatiquement et définies comme suit :
|
| Liste de sécurité |
Deux listes de sécurité (en plus de la liste de sécurité par défaut) créées manuellement, nommées et définies comme suit :
|
| Sous-réseau |
Deux sous-réseaux régionaux créés manuellement, nommés et définis comme suit :
|
| Passerelle d'API |
Une passerelle d'API privée créée et définie comme suit :
|
| Déploiement d'API |
Un déploiement d'API créé et défini comme suit :
|
| Instance |
Une instance de calcul créée et définie comme suit :
|