共有 VPC ネットワークの使用

このページの内容は Apigee に適用されます。Apigee ハイブリッドには適用されません。

Apigee Edge のドキュメントはこちらをご覧ください。

重要: このトピックは、VPC ピアリングを有効にして作成された組織にのみ適用されます。Apigee ネットワーキング オプションもご覧ください。

このドキュメントでは、共有 Virtual Private Cloud（VPC）ホストを構成し、それに Apigee とバックエンドのターゲット サービス プロジェクトを接続する方法について説明します。共有 VPC ネットワークを使用すると、一元管理されたネットワーク インフラストラクチャを Google Cloud で実装できます。ホスト プロジェクトで単一の VPC ネットワークを使用して、複数のサービス プロジェクトのリソースを接続できます。

共有 VPC の利点

Apigee ランタイム（Google 管理の VPC で実行）は、お客様が所有する VPC とピアリングされます。このトポロジでは、次の図に示すように、Apigee ランタイム エンドポイントは VPC ネットワークと通信できます。

Apigee アーキテクチャの概要もご覧ください。

多くの場合、上で説明したトポロジはシンプルです。VPC ネットワークは単一の Google Cloud プロジェクトの一部であり、多くの組織ではリソース階層に関するベスト プラクティスに沿って行い、インフラストラクチャを複数のプロジェクトに分割することを推奨しているためです。Apigee テナント プロジェクトが以前と同じように VPC ネットワークにピアリングされ、内部バックエンドが別のプロジェクトの VPC に配置されているネットワーク トポロジを考えてみましょう。次の図のようになります。

図に示されているように、Apigee VPC をバックエンド VPC にピアリングする場合、ネットワーク ピアリングは対称であるため、Apigee VPC ネットワークからバックエンドに（またはその逆に）到達できます。ただし、VPC ピアリングのドキュメントで説明されているように、Apigee テナント プロジェクトはピアリングが推移的ではないため、Apigee VPC とのみ通信できます。これを機能させるには、Apigee VPC に追加のプロキシをデプロイし、ピアリング リンク間でトラフィックをバックエンド VPC に転送します。ただし、この方法では運用上のオーバーヘッドとメンテナンスが増加します。

共有 VPC は、上記の問題に対するソリューションを提供します。共有 VPC によって、ネットワーキング コンポーネントを追加せずに、同じ組織内のその他の Google Cloud プロジェクトにある Apigee ランタイムとバックエンドの間で接続を確立できます。

注: バックエンドが別の Google Cloud 組織、オンプレミス、または別のパブリック クラウドにある場合は、Google Cloud ハイブリッド接続を使用して、ハイブリッド ネットワーク接続と、ルートの伝搬を確立できます。

Apigee による共有 VPC の構成

このセクションでは、Apigee VPC サービス プロジェクトを共有 VPC ホストに接続する方法について説明します。ホスト プロジェクトで定義されたサブネットは、サービス プロジェクトと共有されます。後のセクションで、2 番目の VPC サービス プロジェクトにデプロイされたバックエンド サービス用に 2 番目のサブネットを作成する方法について説明します。次の図は、作成後のアーキテクチャを示しています。

Apigee には、必要なトポロジの作成を簡素化するプロビジョニング スクリプトが用意されています。このセクションの手順に沿ってプロビジョニング スクリプトをダウンロードし、共有 VPC を使用して Apigee を設定します。

前提条件

1. 共有 VPC の概要で説明されているコンセプトを確認する。ホスト プロジェクトとサービス プロジェクトのコンセプトを理解することが重要です。
2. 共有 VPC 用に構成できる新しい Google Cloud プロジェクトを作成する。このプロジェクトはホスト プロジェクトです。プロジェクトの作成と管理をご覧ください。
3. 共有 VPC のプロビジョニングの手順に沿って、共有 VPC 用のプロジェクトをプロビジョニングします。共有 VPC 用のホスト プロジェクトを有効にするには、組織管理者であるか、適切な管理 Identity and Access Management（IAM）ロールが付与されている必要があります。
4. 2 番目の Google Cloud プロジェクトを作成します。このプロジェクトは、サービス プロジェクトです。後で、それをこのホスト プロジェクトにアタッチします。

スクリプトをダウンロードする

Apigee には、必要なトポロジの作成を簡素化するプロビジョニング スクリプトが用意されています。スクリプトを GitHub から pull する必要があります。

1. スクリプトが含まれている GitHub プロジェクトのクローンを作成します。

   git clone https://github.com/apigee/devrel.git

2. プロジェクトの次のディレクトリに移動します。

   cd devrel/tools/apigee-x-trial-provision

3. 次の環境変数を設定します。

   export HOST_PROJECT=HOST_PROJECT_ID
   export SERVICE_PROJECT=SERVICE_PROJECT_ID

   ここで

   • HOST_PROJECT_ID は、前提条件の一つとして作成した共有 VPC ホスト プロジェクトのプロジェクト ID です。
   • SERVICE_PROJECT_ID は、前提条件で作成した Google Cloud サービス プロジェクトのプロジェクト ID です。

ホスト プロジェクトを構成する

1. 次の環境変数を設定します。

export NETWORK=YOUR_SHARED_VPC
export SUBNET=YOUR_SHARED_SUBNET
export PEERING_CIDR=CIDR_BLOCK

ここで

• YOUR_SHARED_VPC: は、共有 VPC ネットワークの名前です。
• YOUR_SHARED_SUBNET は、共有 VPC サブネットの名前です。
• CIDR_BLOCK は、Apigee VPC の CIDR ブロックです。例: 10.111.0.0/23。
2. Apigee VPC ピアリングとファイアウォールを構成するには、次のオプションを指定してスクリプトを実行します。

   ./apigee-x-trial-provision.sh \
       -p $HOST_PROJECT --shared-vpc-host-config --peering-cidr $PEERING_CIDR

   このスクリプトは、ホスト プロジェクトを構成します。出力は次のようになります。ここで、NETWORK と SUBNET は、ホスト プロジェクトの完全修飾パスを表します。

   export NETWORK=projects/$HOST_PROJECT/global/networks/$NETWORK
   export SUBNET=projects/$HOST_PROJECT/regions/us-west1/subnetworks/$SUBNET

3. 出力で返された変数をエクスポートします。

サービス プロジェクトを構成する

このステップでは、サービス プロジェクトを構成します。スクリプトが終了すると、プロビジョニングのテストに使用できるサンプル API プロキシが Apigee 環境に作成されてデプロイされます。

1. apigee-x-trial-provision.sh スクリプトをもう一度実行して、共有ネットワーク設定でサービス プロジェクトをプロビジョニングします。

   ./apigee-x-trial-provision.sh \
       -p $SERVICE_PROJECT

   このスクリプトでは、Apigee 環境にサンプル プロキシが作成され、curl コマンドが STDOUT に出力されて、そのコマンドを呼び出すことでプロビジョニングをテストできます。

2. テスト API プロキシを呼び出します。次に例を示します。

   curl -v https://10-111-111-111.nip.io/hello-world

バックエンド サービス用の別のサービス プロジェクトを構成する

Google Cloud インフラストラクチャを複数のプロジェクトに分割することをおすすめします。Google Cloud ランディング ゾーンのリソース階層を決定するをご覧ください。このセクションでは、バックエンド サービスを別のサービス プロジェクトにデプロイし、共有 VPC ホストにアタッチする方法について説明します。Apigee サービス プロジェクトとバックエンド サービス プロジェクトの両方が共有 VPC ホストにアタッチされているため、Apigee はバックエンド サービスを API プロキシ ターゲットとして使用できます。

前提条件

これらの手順を行うには、共有 VPC の設定で説明したとおり、共有 VPC がすでに設定され、バックエンド サービス プロジェクトと共有されていることを前提としています。

サービス プロジェクトを構成する

このセクションでは、別の共有 VPC サブネットでバックエンド サービスをテストし、ホスト プロジェクトに 2 番目のサブネットを作成して、そのプライベート RFC1918 IP アドレスを Apigee API プロキシのターゲット URL として使用します。

1. バックエンド サービス プロジェクトから、次のコマンドを実行して、使用可能なすべての共有サブネットを確認します。

   gcloud compute networks subnets list-usable --project $HOST_PROJECT  --format yaml
   

   出力例:

   ipCidrRange: 10.0.0.0/20
   network: https://www.googleapis.com/compute/v1/projects/my-svpc-hub/global/networks/hub-vpc
   subnetwork: https://www.googleapis.com/compute/v1/projects/my-svpc-hub/regions/europe-west1/subnetworks/sub1
   

2. 次の環境変数を作成します。

   BACKEND_SERVICE_PROJECT=PROJECT_ID
   SHARED_VPC_SUBNET=SUBNET
   

   ここで

   • PROJECT_ID は、バックエンド サービス用に作成したサービス プロジェクトの名前です。
   • SUBNET は、前のコマンドで出力されたサブネットワークの一つです。
3. このプロジェクトで、テスト用のバックエンド httpbin サービスを作成するには、次のコマンドを使用します。

   gcloud compute --project=$BACKEND_SERVICE_PROJECT instances create-with-container httpbin \
     --machine-type=e2-small --subnet=$SHARED_VPC_SUBNET \
     --image-project=cos-cloud --image-family=cos-stable --boot-disk-size=10GB \
     --container-image=kennethreitz/httpbin --container-restart-policy=always --tags http-server
   

4. API プロキシを作成するの手順に沿って、Apigee API プロキシを作成してデプロイします。
5. ターゲット サービスが実行されている仮想マシン（VM）の内部 IP アドレスを取得します。この IP アドレスは、次のステップでテスト用の API プロキシを呼び出すときに使用します。

   gcloud compute instances list --filter=name=httpbin

6. 構成をテストするには、プロキシを呼び出します。前の手順で取得した VM の内部 IP アドレスを使用します。次の例は、プロキシのベースパスが /myproxy であることを前提としています。次に例を示します。

   curl -v https://INTERNAL_IP/myproxy

   この API 呼び出しは Hello, Guest! を返します。