Exemples de configurations de ressources de réseau
Découvrez des exemples de configuration des ressources de réseau pour le développement de passerelle d'API.
Pour pouvoir utiliser le service Passerelle d'API 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 avoir accès à une location Oracle Cloud Infrastructure. La location doit être abonnée à une ou plusieurs régions dans lesquelles le service Passerelle d'API est disponible (voir Disponibilité par région).
-
La location doit avoir un quota suffisant de ressources connexes au service de passerelle d'API (voir Limites de service).
- Dans la location, un compartiment doit déjà exister pour contenir les ressources de réseau nécessaires. Si un tel compartiment n'existe pas déjà, vous devez le créer. Voir Créer des compartiments pour contenir les ressources de réseau et les ressources du service de passerelle d'API dans la location, s'ils n'existent pas déjà.
- Le compartiment qui détient des ressources de réseau doit contenir un VCN, un sous-réseau régional public ou privé, et d'autres ressources (telles qu'une passerelle Internet, une table de routage, des listes de sécurité ou des groupes de sécurité de réseau). Pour garantir la haute disponibilité, les passerelles d'API peuvent uniquement être créées dans des sous-réseaux régionaux (et non des sous-réseaux propres à un domaine de disponibilité). Notez qu'une passerelle d'API doit pouvoir joindre les éléments dorsaux définis dans la spécification de déploiement d'API. Par exemple, si l'élément dorsal se trouve sur le réseau Internet public, le réseau en nuage virtuel doit comporter une passerelle Internet pour permettre à la passerelle d'API d'acheminer les demandes vers l'élément dorsal.
-
Le réseau en nuage virtuel doit avoir un jeu d'options DHCP comprenant un résolveur de DNS approprié pour mapper les noms d'hôte définis dans une spécification de déploiement d'API à des adresses IP. Si un tel jeu d'options DHCP n'existe pas déjà dans le réseau en nuage virtuel, vous devez le créer. Sélectionnez les options DHCP définies 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 dans le même réseau en nuage virtuel, sélectionnez un jeu d'options DHCP qui spécifient le résolveur Internet et de réseau en nuage virtuel fourni par Oracle comme type de DNS. Il s'agit de la valeur par défaut si vous ne sélectionnez pas explicitement un jeu d'options DHCP.
- Si le nom d'hôte se trouve dans votre propre réseau privé ou interne (par exemple, connecté au réseau en nuage virtuel par FastConnect), sélectionnez un jeu d'options DHCP qui spécifient le résolveur personnalisé comme type de DNS et l'URL d'un serveur DNS approprié pouvant résoudre le nom d'hôte en une adresse IP.
Notez que vous pouvez modifier les détails du serveur DNS dans le jeu 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 du serveur DNS mis à jour dans les deux heures qui suivent. Pour plus d'informations sur la résolution des noms d'hôte en adresses IP, voir DNS dans le réseau en nuage virtuel et Options DHCP.
- Dans la location, un compartiment doit déjà exister pour contenir les ressources liées au service de passerelle d'API (passerelles d'API, déploiements d'API). Ce compartiment peut être celui qui contient les ressources de réseau, mais ce n'est pas obligatoire. Voir Créer des compartiments pour contenir les ressources de réseau et les ressources du service de passerelle d'API dans la location, s'ils n'existent pas déjà. Notez que les ressources liées au service de passerelle d'API peuvent résider dans le compartiment racine. Toutefois, si vous prévoyez que plusieurs équipes vont 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 déployer des API sur ces dernières, vous devez faire partie de l'un des groupes suivants :
- Le groupe d'administrateurs de la location.
-
Un groupe auquel des politiques accordent les autorisations appropriées sur le réseau et les ressources liées au service de passerelle d'API. Voir Créer des politiques pour contrôler l'accès aux ressources de réseau et aux ressources connexes au service de passerelle d'API.
- Des politiques doivent être définies pour accorder aux passerelles d'API que vous créez l'accès à des ressources supplémentaires, au besoin. Voir Créer des politiques pour contrôler l'accès aux ressources de réseau et aux ressources connexes au service de passerelle d'API.
Cette rubrique offre des exemples de configuration des ressources de réseau pour les passerelles d'API avec fonction sans serveur en tant qu'élément dorsal :
- pour une passerelle d'API publique dans un sous-réseau public (voir Exemple 1 : Exemple de configuration de ressources de réseau pour une passerelle d'API publique dans un sous-réseau public avec fonction sans serveur en tant qu'élément dorsal HTTP)
- pour une passerelle d'API privée dans un sous-réseau privé (voir Exemple 2 : Configuration de ressources de réseau pour une passerelle d'API privée dans un sous-réseau privé avec fonction sans serveur en tant qu'élément dorsal HTTP)
Ces exemples supposent que la fonction helloworld par défaut a été créée et déployée dans le service des fonctions pour OCI sous le nom helloworld-func et appartenant à l'application helloworld-app (voir Création, déploiement et appel d'une fonction Helloworld).
Les exemples de cette section montrent 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é de réseau aux listes de sécurité, vous pouvez spécifier des règles de sécurité identiques pour les groupes de sécurité de réseau.
Exemple 1 : Exemple de configuration de ressources de réseau pour une passerelle d'API publique dans un sous-réseau public avec fonction sans serveur en tant qu'élément dorsal HTTP
Cet exemple suppose que vous voulez qu'une passerelle d'API publique accessible directement à partir d'Internet, avec une fonction sans serveur, serve d'élément dorsal HTTP.
Pour réaliser cette 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 ressources ci-dessous :
- Un réseau VCN 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', comportant une règle de trafic entrant qui permet l'accès public à la passerelle d'API et une règle de trafic sortant qui permet l'accès au service des fonctions pour OCI.
- 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 de l'Internet public vers le déploiement d'API retourne la réponse ci-dessous :
[user@machinename ~]$ curl -X GET https://lak...sjd.apigateway.us-phoenix-1.oci.customer-oci.com/marketing/hello
Hello, world!
Exemple de configuration de ressources de réseau
Ressource | Exemple |
---|---|
Réseau en nuage 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é créée manuellement (en plus de la liste de sécurité par défaut), 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 ressources de réseau pour une passerelle d'API privée dans un sous-réseau privé avec une fonction sans serveur en tant qu'élément dorsal HTTP
Cet exemple suppose que vous voulez qu'une passerelle d'API privée accessible uniquement au moyen d'un hôte bastion (plutôt que directement à partir d'Internet), avec une fonction sans serveur, serve d'élément dorsal HTTP.
Pour réaliser cette 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 ressources ci-dessous :
- Un réseau VCN nommé acme-vcn2
- Une passerelle Internet nommée acme-internet-gateway
- Une passerelle de service nommée acme-service-gateway. (Dans cet exemple, vous ne devez créer qu'une passerelle de service, car la passerelle d'API ne dispose que d'un élément dorsal du service des fonctions pour OCI. Cependant, si la passerelle d'API a à la fois un élément dorsal du service des fonctions pour OCI et un élément dorsal HTTP sur le réseau Internet public, vous pouvez créer une passerelle NAT au lieu d'accéder aux deux éléments dorsaux.)
- Une table de routage nommée acme-routetable-private
- Une liste de sécurité nommée acme-security-list-private, comportant une règle de trafic entrant qui permet à l'hôte bastion d'accéder à la passerelle d'API et une règle de trafic sortant qui permet l'accès au service des fonctions pour OCI.
- 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, comportant une règle de trafic entrant qui permet l'accès SSH public à l'hôte bastion et une règle de trafic sortant qui permet à l'hôte 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 servant d'hôte bastion, nommée acme-bastion-instance
Si vous disposez de SSH sur l'hôte bastion, l'émission d'une commande curl vers le déploiement de l'API retourne la réponse ci-dessous :
[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 ressources
Ressource | Exemple |
---|---|
Réseau en nuage 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 créées manuellement (en plus de la liste de sécurité par défaut), 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 :
|