ネットワーク・リソース構成例
APIゲートウェイ開発用のネットワーク・リソースの構成方法の例をご紹介します。
APIゲートウェイ・サービスを使用してAPIゲートウェイを作成し、APIデプロイメントとしてAPIをデプロイする前に:
- Oracle Cloud Infrastructureテナンシへのアクセス権が必要です。テナンシは、APIゲートウェイが使用可能な1つ以上のリージョンにサブスクライブされている必要があります(リージョン別の可用性を参照)。
-
テナンシにはAPIゲートウェイ関連リソースに対する十分な割当てが必要です(サービス制限を参照)。
- テナンシ内に、必要なネットワーク・リソースを所有するコンパートメントがすでに存在する必要があります。そのようなコンパートメントが存在しない場合は、作成する必要があります。テナンシの所有ネットワーク・リソースおよびAPIゲートウェイ・リソースへのコンパートメントの作成(まだ存在しない場合)を参照してください。
- ネットワーク・リソースを所有するコンパートメントには、VCN、パブリックまたはプライベートのリージョン・サブネット、およびその他のリソース(インターネット・ゲートウェイ、ルート表、セキュリティ・リスト、ネットワーク・セキュリティ・グループなど)が含まれている必要があります。高可用性を確保するために、APIゲートウェイはリージョナル・サブネット(AD固有のサブネットではない)でのみ作成できます。APIゲートウェイは、APIデプロイメント仕様で定義されたバック・エンドに到達できる必要があります。たとえば、バック・エンドがパブリック・インターネット上にある場合、VCNには、APIゲートウェイでリクエストをバック・エンドにルーティングできるようにインターネット・ゲートウェイが必要です。
-
VCNには、APIデプロイメント仕様で定義されたホスト名をIPアドレスにマップするための適切なDNSリゾルバを含むDHCPオプションのセットが必要です。そのようなDHCPオプション・セットがVCNに存在していない場合は、作成する必要があります。次のように、APIゲートウェイのサブネットに対するDHCPオプション・セットを選択します:
- ホスト名がインターネット上で公開されている場合、またはホスト名が同じVCN内のインスタンスに属している場合は、DNSタイプとしてOracle提供のInternet and VCN Resolverを持つDHCPオプション・セットを選択します。DHCPオプション・セットを明示的に選択しない場合は、これがデフォルトです。
- ホスト名が独自のプライベート・ネットワークまたは内部ネットワーク上にある場合(たとえば、FastConnectによってVCNに接続されている場合)は、DNSタイプとしてCustom Resolverを持ち、ホスト名をIPアドレスに解決できる適切なDNSサーバーのURLを持つDHCPオプション・セットを選択します。
DNSサーバーの詳細は、APIゲートウェイのサブネットに指定されたDHCPオプション・セットで変更できます。APIゲートウェイは、2時間以内に更新されたDNSサーバーの詳細を使用するように再構成されます。ホスト名をIPアドレスに解決する方法の詳細は、仮想クラウド・ネットワークのDNSとDHCPオプションを参照してください。
- テナンシ内に、APIゲートウェイ関連リソース(APIゲートウェイ、APIデプロイメント)を所有するコンパートメントがすでにある必要があります。このコンパートメントには、ネットワーク・リソースを含むものと同じコンパートメントを使用できますが使用する必要はありません。テナンシの所有ネットワーク・リソースおよびAPIゲートウェイ・リソースへのコンパートメントの作成(まだ存在しない場合)を参照してください。APIゲートウェイ関連リソースは、ルート・コンパートメントに配置できます。ただし、複数のチームがAPIゲートウェイを作成することが予想される場合、ベスト・プラクティスは各チームに別個のコンパートメントを作成することです。
-
APIゲートウェイを作成し、それらにAPIをデプロイするには、次のいずれかに属している必要があります:
- テナンシの管理者グループ。
-
ネットワークおよびAPIゲートウェイ関連リソースに適切な権限を付与するポリシーのグループ。ネットワークおよびAPIゲートウェイ関連リソースへのアクセスを制御するポリシーの作成を参照してください。
- 必要に応じて、作成するAPIゲートウェイに追加リソースへのアクセス権を付与するようにポリシーを定義する必要があります。ネットワークおよびAPIゲートウェイ関連リソースへのアクセスを制御するポリシーの作成を参照してください。
このトピックでは、バック・エンドとしてサーバーレス・ファンクションを使用するAPIゲートウェイのネットワーク・リソースを構成する方法の例を示します:
- パブリック・サブネット内のパブリックAPIゲートウェイの場合(例1: HTTPバック・エンドとしてのサーバーレス・ファンクションを使用するパブリック・サブネット内のパブリックAPIゲートウェイのネットワーク・リソース構成の例を参照)
- プライベート・サブネットのプライベートAPIゲートウェイの場合(例2: HTTPバック・エンドとしてサーバーレス・ファンクションを使用するプライベート・サブネットのプライベートAPIゲートウェイのネットワーク・リソース構成を参照)
これらの例では、helloworld-funcという名前でOCI関数にデフォルトのhelloworldファンクションが作成されてデプロイされ、helloworld-appアプリケーションに属しているものとします(Helloworldファンクションの作成、デプロイおよび起動を参照)。
この項の例は、セキュリティ・リストでのセキュリティ・ルールを使用したアクセスの制御を示しています。ネットワーク・セキュリティ・グループをセキュリティ・リストより優先する場合は、ネットワーク・セキュリティ・グループに同じセキュリティ・ルールを指定できます。
例1: HTTPバック・エンドとしてのサーバーレス・ファンクションを使用するパブリック・サブネット内のパブリックAPIゲートウェイのネットワーク・リソース構成の例
この例では、パブリックAPIゲートウェイがインターネットから直接アクセスできるようにし、サーバーレス・ファンクションをHTTPバック・エンドとして使用すると想定します。
この例の構成を実現するには、次に示すサンプル・リソース構成の表に示されているプロパティを使用し、示されている順序で次のリソースを作成します:
- 「acme-vcn1」という名前のVCN。
- 「acme-internet-gateway」という名前のインターネット・ゲートウェイ。
- 「acme-routetable-public」という名前のルート表。
- 「acme-security-list-public」という名前のセキュリティ・リスト。APIゲートウェイへのパブリック・アクセスを許可するイングレス・ルールおよびOCIファンクションへのアクセスを許可するエグレス・ルールを使用します。
- 「acme-public-subnet」という名前のパブリック・サブネット。
- 「acme-public-gateway」という名前のAPIゲートウェイ。「acme-public-deployment」という名前のAPIデプロイメントを使用します。
APIデプロイメントに対してパブリック・インターネットからcurlコマンドを発行すると、次のレスポンスが返されます:
[user@machinename ~]$ curl -X GET https://lak...sjd.apigateway.us-phoenix-1.oci.customer-oci.com/marketing/hello
Hello, world!ネットワーク・リソース構成の例
| リソース | 例 |
|---|---|
| VCN |
手動で作成され、次のように定義されます:
|
| インターネット・ゲートウェイ |
手動で作成され、次のように定義されます:
|
| ルート表 |
1つのルート表が手動で作成され、次のように名前が付けられ、定義されます:
|
| DHCPオプション |
自動的に作成され、次のように定義されます:
|
| セキュリティ・リスト |
(デフォルトのセキュリティ・リストに加えて) 1つのセキュリティ・リストが手動で作成され、次のように名前が付けられ、定義されます:
|
| サブネット |
1つのリージョナル・パブリック・サブネットが手動で作成され、次のように名前が付けられ、定義されます:
|
| APIゲートウェイ |
1つのパブリックAPIゲートウェイが作成され、次のように定義されます:
|
| APIデプロイメント |
1つのAPIデプロイメントが作成され、次のように定義されます:
|
例2: HTTPバック・エンドとしてサーバーレス・ファンクションを使用するプライベート・サブネットのプライベートAPIゲートウェイのネットワーク・リソース構成
この例では、プライベートAPIゲートウェイが(インターネットから直接アクセスするのではなく)要塞ホストを介してのみアクセスできるようにし、サーバーレス・ファンクションをHTTPバック・エンドとして使用すると想定します。
この例の構成を実現するには、次に示すサンプル・リソース構成の表に示されているプロパティを使用し、示されている順序で次のリソースを作成します:
- acme-vcn2という名前のVCN
- acme-internet-gatewayという名前のインターネット・ゲートウェイ
- acme-service-gatewayという名前のサービス・ゲートウェイ。この例では、APIゲートウェイにはOCIファンクション・バック・エンドのみが含まれるため、サービス・ゲートウェイの作成のみが必要です。ただし、パブリック・インターネット上で、APIゲートウェイにOCIファンクション・バック・エンドとHTTPバック・エンドの両方がある場合は、両方のバック・エンドにアクセスするかわりにNATゲートウェイを作成できます。)
- acme-routetable-privateという名前のルート表
- acme-security-list-privateという名前のセキュリティ・リスト。要塞ホストにAPIゲートウェイへのアクセスを許可するイングレス・ルールおよびOCIファンクションへのアクセスを許可するエグレス・ルールを使用します。
- acme-private-subnetという名前のプライベート・サブネット
- acme-private-gatewayという名前のAPIゲートウェイ。acme-private-deploymentという名前のAPIデプロイメントを使用します
- acme-routetable-bastionという名前のルート表
- acme-security-list-bastionという名前のセキュリティ・リスト。要塞ホストへのパブリックSSHアクセスを許可するイングレス・ルールおよび要塞ホストにAPIゲートウェイへのアクセスを許可するエグレス・ルールを使用します。
- acme-bastion-public-subnetという名前のパブリック・サブネット
- acme-bastion-instanceと呼ばれる、要塞ホストとして機能するパブリックIPアドレスを持つコンピュート・インスタンス
SSHを要塞ホストに配置して、APIデプロイメントに対してcurlコマンドを発行すると、次のレスポンスが表示されます:
[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!リソース構成の例
| リソース | 例 |
|---|---|
| VCN |
手動で作成され、次のように定義されます:
|
| インターネット・ゲートウェイ |
手動で作成され、次のように定義されます:
|
| サービス・ゲートウェイ |
手動で作成され、次のように定義されます:
|
| ルート表 |
2つのルート表が手動で作成され、次のように名前が付けられ、定義されます:
|
| DHCPオプション |
自動的に作成され、次のように定義されます:
|
| セキュリティ・リスト |
(デフォルトのセキュリティ・リストに加えて) 2つのセキュリティ・リストが手動で作成され、次のように名前が付けられ、定義されます:
|
| サブネット |
2つのリージョナル・サブネットが手動で作成され、次のように名前が付けられ、定義されます:
|
| APIゲートウェイ |
1つのプライベートAPIゲートウェイが作成され、次のように定義されます:
|
| APIデプロイメント |
1つのAPIデプロイメントが作成され、次のように定義されます:
|
| インスタンス |
1つのコンピュート・インスタンスが作成され、次のように定義されます:
|