VPC ピアリングを使用せずに評価組織をプロビジョニングする

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

Apigee Edge のドキュメントを表示する。

このドキュメントでは、VPC ピアリングを使用せずにコマンドラインから Apigee 評価組織をインストールして構成する方法について説明します。評価組織は 60 日後に期限切れになり、他の制限が適用される場合もあります。評価組織と有料組織の比較もご覧ください。

制限事項

このドキュメントで説明する VPC 以外のピアリングのインストールオプションにはいくつかの制限があります。

VPC Service Controls はサポートされていません。
限定公開 DNS ピアリングはサポートされていません。

VPC 以外のピアリングでサポートされている機能とネットワークアプローチの一覧については、ネットワーキングオプションの選択方法をご覧ください。

ステップの概要

プロビジョニングの手順は次のとおりです。

ステップ 1: 環境変数を定義する: gcloud を設定して環境変数を定義します。Google Cloud CLI は、認証、ローカルの構成、デベロッパーワークフロー、Google Cloud APIs の操作を管理します。
ステップ 2: API を有効にする: Apigee では、いくつかの Google Cloud APIs を有効にする必要があります。
ステップ 3: 組織を作成する: Apigee 組織（組織とも呼ばれます）は、Apigee の最上位コンテナです。すべての環境と環境グループ、ユーザー、API プロキシ、関連リソースが含まれています。
ステップ 4: ルーティングを構成する: API への外部アクセスまたは内部専用アクセスを許可します。
ステップ 5: サンプル API プロキシを呼び出す: API プロキシをデプロイして呼び出し、プロビジョニングをテストします。

ステップ 1: 環境変数を定義する

gcloud を設定し、後の手順で使用する環境変数を定義します。

前提条件に記載されている要件を完了していることを確認してください。
gcloud CLI がインストールされている必要があります。インストールする必要がある場合は、gcloud CLI をインストールするをご覧ください。
gcloud CLI の初期化で説明しているように、gcloud CLI を初期化します。CLI がすでに初期化されている場合は、前提条件で作成した Google Cloud プロジェクトが gcloud のデフォルトプロジェクトとして設定されていることを確認します。
次の環境変数を定義します。
```
AUTH="Authorization: Bearer $(gcloud auth print-access-token)"
PROJECT_ID="YOUR_PROJECT_ID"
RUNTIME_LOCATION="YOUR_RUNTIME_LOCATION"
ANALYTICS_REGION="YOUR_ANALYTICS_REGION"
```
各要素の意味は次のとおりです。
- AUTH は、署名なしトークンを含む Authentication ヘッダーを定義します。このヘッダーは、Apigee API を呼び出すときに使用します。トークンは一定期間経過すると期限切れになります。期限が切れた場合は、同じコマンドを使用して簡単に再生成できます。詳細については、print-access-token コマンドのリファレンスページをご覧ください。
- PROJECT_ID は、前提条件で作成した Cloud プロジェクト ID です。
- RUNTIME_LOCATION は、Apigee インスタンスが配置されている物理的な場所です。使用可能なランタイムロケーションのリストについては、Apigee のロケーションをご覧ください。
  
  注: RUNTIME_LOCATION には、ゾーン名ではなくリージョン名を使用してください。たとえば、us-west1 はリージョン名、us-west1-a はリージョン内のゾーンです。リージョンとゾーンの識別もご覧ください。
- ANALYTICS_REGION は、Apigee 分析データが保存される物理的なロケーションです。使用可能な Apigee API Analytics のリージョンのリストについては、Apigee のロケーションをご覧ください。
  
  RUNTIME_LOCATION と ANALYTICS_REGION は同じリージョンにできますが、同じである必要はありません。ただし、同じであれば、パフォーマンス上のメリットが得られることがあります。

（省略可）設定した値をエコーして作業内容を確認します。コマンドを変数で使用する場合は、変数名の前にドル記号（$）を付けます。

echo $AUTH
echo $PROJECT_ID
echo $RUNTIME_LOCATION
echo $ANALYTICS_REGION

echo コマンドに対するレスポンスは次のようになります。

Authorization: Bearer ya29.a123456678940B63hPSAMPLEsampleKKYVsample0f3pWDWZDuH2-hENkNa
TvgZ1PD977TMvv6edBQPJezdHw040880Ol_LoD5ZDkt-i-knizia_KhA9L20sSvztL81-SAMPLE42ELPMASk2_
1CxN
my-cloud-project
us-west1
us-west1

ステップ 2: API を有効にする

このタスクに必要な権限

Apigee プロビジョナーに、このタスクを完了するために必要な権限を含む事前定義ロールを付与できます。または、権限をきめ細かく指定して必要最小限の権限を付与することもできます。事前定義ロールと API 有効化権限をご覧ください。

Apigee では、いくつかの Google Cloud APIs を有効にする必要があります。services enable コマンドを実行して有効にします。
```
gcloud services enable apigee.googleapis.com \
  cloudkms.googleapis.com --project=$PROJECT_ID
```
（省略可）処理を確認するには、services list コマンドを使用して、有効な API をすべて表示します。
```
gcloud services list
```
レスポンスには、有効にした API（Apigee、Cloud KMS、Compute Engine）を含む、有効になっているすべての API が表示されます。

ステップ 3: 組織を作成する

組織は、Apigee Edge の最上位コンテナです。組織にはすべての API プロキシと関連リソースが含まれています。詳細については、組織についてをご覧ください。

このタスクに必要な権限

Apigee プロビジョナーに、このタスクを完了するために必要な権限を含む事前定義ロールを付与できます。または、権限をきめ細かく指定して必要最小限の権限を付与することもできます。詳しくは、以下をご覧ください。

provisionOrganization API を使用して新しい評価組織を作成します。
注: provisionOrganization API では、評価組織のみを作成できます。本番環境の組織は作成できません。
```
 suppresswarning="true">curl "https://apigee.googleapis.com/v1/projects/$PROJECT_ID:provisionOrganization"  \
  -H "$AUTH" \
  -X POST \
  -H "Content-Type:application/json" \
  -d '{
    "analyticsRegion":"'"$ANALYTICS_REGION"'",
    "runtimeLocation":"'"$RUNTIME_LOCATION"'",
    "disableVpcPeering":"true",
  }'
```
各要素の意味は次のとおりです。
- -d には、リクエストのデータペイロードを定義します。このペイロードには、次のものを含める必要があります。
  - ANALYTICS_REGION: 分析データを保存する物理的な場所を指定します。
  - RUNTIME_LOCATION: Apigee インスタンスが配置されている物理的な場所です。
  - disableVpcPeering: このプロビジョニングフローでは VPC ピアリングを使用しないため、このフラグを true に設定する必要があります。デフォルト: false
Apigee が LRO を起動して評価組織を作成します。このオペレーションは、完了するまでに最大 40 分かかります。
作成リクエストのステータスを確認するには、次の例のように Apigee List organizations API に GET リクエストを送信します。
```
curl -H "$AUTH" "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID"
```
次のレスポンスが表示された場合、組織の作成はまだ完了していません。
```
{
"error": {
"code": 403,
"message": "Permission denied on resource \"organizations/apigee-docs-m\" (or it may not exist)",
"status": "PERMISSION_DENIED"
}
}
```
成功した場合、レスポンスオブジェクトに "state": "ACTIVE" が表示されます。次の手順に進みます。

ステップ 4: ルーティングを構成する

このステップでは、クライアントアプリケーションが Apigee と通信する方法を構成します。クライアントから Apigee へのトラフィックは「ノースバウンド」トラフィックとも呼ばれます。ノースバウンドの構成オプションには次が含まれます。

アクセスタイプ	構成とデプロイプロセスの説明
PSC を使用する内部アクセス	Private Service Connect（PSC）を使用して、任意の Google Cloud プロジェクトから API プロキシへの内部アクセスのみを許可します。 PSC を使用すると、サービスプロデューサー（Apigee）とサービスコンシューマー（ピアリングされた VPC プロジェクトと自身が制御する 1 つ以上の他の Cloud プロジェクト）間のプライベート接続が可能になります。この方式では、リクエストはサービスエンドポイントまたはリージョンの内部ロードバランサを経由して、サービスアタッチメントという単一のアタッチメントポイントに到達します。この構成により、内部クライアントは、ネットワークが有効になっている任意のマシンから Apigee API プロキシリクエストを送信できます。
PSC を使用する外部アクセス	Private Service Connect（PSC）を使用して API プロキシへの外部アクセスを許可します。 Private Service Connect（PSC）を使用して、サービスプロデューサー（Apigee）とサービスコンシューマー（ピアリングされた VPC プロジェクトと自身が制御する 1 つ以上の他のクラウドプロジェクト）間のプライベート接続を有効にします。この方式では、リクエストはグローバル外部ロードバランサまたはリージョン外部ロードバランサを経由して、サービスアタッチメントという単一のアタッチメントポイントに到達します。この構成では、ネットワークが有効になっている任意のマシンから Apigee API プロキシリクエストを送信できます。

アクセスタイプ

構成とデプロイプロセスの説明

PSC を使用する内部アクセス

Private Service Connect（PSC）を使用して、任意の Google Cloud プロジェクトから API プロキシへの内部アクセスのみを許可します。

PSC を使用すると、サービスプロデューサー（Apigee）とサービスコンシューマー（ピアリングされた VPC プロジェクトと自身が制御する 1 つ以上の他の Cloud プロジェクト）間のプライベート接続が可能になります。この方式では、リクエストはサービスエンドポイントまたはリージョンの内部ロードバランサを経由して、サービスアタッチメントという単一のアタッチメントポイントに到達します。この構成により、内部クライアントは、ネットワークが有効になっている任意のマシンから Apigee API プロキシリクエストを送信できます。

PSC を使用する外部アクセス

Private Service Connect（PSC）を使用して API プロキシへの外部アクセスを許可します。

Private Service Connect（PSC）を使用して、サービスプロデューサー（Apigee）とサービスコンシューマー（ピアリングされた VPC プロジェクトと自身が制御する 1 つ以上の他のクラウドプロジェクト）間のプライベート接続を有効にします。この方式では、リクエストはグローバル外部ロードバランサまたはリージョン外部ロードバランサを経由して、サービスアタッチメントという単一のアタッチメントポイントに到達します。この構成では、ネットワークが有効になっている任意のマシンから Apigee API プロキシリクエストを送信できます。

それぞれのルーティング方法については、次のタブで説明します。

内部ルーティング（PSC）

このセクションでは、Private Service Connect（PSC）を使用して、任意の Google Cloud プロジェクトから API プロキシへの内部アクセスのみを許可する方法について説明します。

PSC を使用して内部アクセスを構成するには、次のオプションがあります。

サービスエンドポイント: リクエストは、サービスエンドポイントを通過し、サービスアタッチメントという単一のアタッチメントポイントに送信されます。
内部リージョンロードバランサ: リクエストは、リージョン内部 HTTP(S) ロードバランサを通過します。グローバルロードバランシングとリージョンロードバランシングもご覧ください。

ご使用の構成に応じて以下のタブを選択し、次の操作を行います。

サービスエンドポイント

このタスクに必要な権限

Apigee プロビジョナーに、このタスクを完了するために必要な権限を含む事前定義ロールを付与できます。または、権限をきめ細かく指定して必要最小限の権限を付与することもできます。事前定義ロールとアクセスルーティング権限をご覧ください。

サービスアタッチメントに PSC サービスエンドポイントを作成する

Apigee インスタンスからサービスアタッチメントを取得します。

curl -i -X GET -H "$AUTH" \
  "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances"

次のサンプル出力では、serviceAttachment 値が太字で表示されています。

{
  "instances": [
    {
      "name": "us-west1",
      "location": "us-west1",
      "createdAt": "1645731488019",
      "lastModifiedAt": "1646504754219",
      "diskEncryptionKeyName": "projects/my-project/locations/us-west1/keyRings/us-west1/cryptoKeys/dek",
      "state": "ACTIVE",
      "runtimeVersion": "1-7-0-20220228-190814",
      "consumerAcceptList": [
        "my-project"
      ],
      "serviceAttachment": "projects/bfac74a67a320c43a12p-tp/regions/us-west1/serviceAttachments/apigee-us-west1-crw1"
    }
  ]
}

注: Apigee 組織の作成に使用したプロジェクトの ID は常に consumerAcceptList リストに表示されます。上の出力例では、リスト内の唯一のプロジェクトです。

Private Service Connect エンドポイントを作成するの説明に従って、前の手順でインスタンスレスポンスの本文から取得したサービスアタッチメントを指す PSC サービスエンドポイントを作成します。
サービスエンドポイントの IP アドレスをメモして覚えておきます。API プロキシを呼び出して設定をテストするときに、後で IP アドレスが必要になります（例: 10.138.0.2）。

Apigee のプロビジョニングが完了しました。サンプルプロキシをデプロイするに移動します。

内部リージョン LB

このタスクに必要な権限

制限事項: PSC 構成に関する次の制限事項に注意してください。

この構成では、グローバル外部 HTTP(S) ロードバランサ（従来）はサポートされていません。
複数の PSC NEG を使用するフェイルオーバーの場合、アクティブなヘルスチェックはサポートされません。代わりに外れ値検出を使用してください。
制限は、PSC を介して Apigee インスタンスに接続できる Google Cloud プロジェクトの数と、プロジェクトごとに作成できる PSC NEG 接続の数に適用されます。詳細については、Private Service Connect（PSC）の上限をご覧ください。
Google Cloud プロジェクトが consumerAcceptList から削除されても、削除されたプロジェクトの既存の PSC NEG は引き続き機能します。ただし、新しい NEG は拒否されます。既存の NEG を consumerAcceptList から削除する場合は、関連するプロジェクトを削除する必要があります。また、Apigee インスタンスを再作成できます。これによって Apigee プロジェクトでサービスアタッチメントを再作成されます。

ステップ 8a: 環境変数を設定する

このセクションの手順では、環境変数を使用して、繰り返し使用される文字列を参照します。環境変数を定義するで変数が設定されていることを確認してください。

さらに、次の環境変数を設定します。

コマンドターミナルで次の環境変数を定義します。

NEG_NAME=YOUR_NEG_NAME"
TARGET_SERVICE=YOUR_TARGET_SERVICE"
NETWORK_NAME=YOUR_NETWORK_NAME"
SUBNET_NAME=YOUR_SUBNET_NAME"

各要素の意味は次のとおりです。

NEG_NAME: ネットワークエンドポイントグループの名前。
TARGET_SERVICE: 接続するサービスアタッチメント。例: projects/bfac7497a40c32a12p-tp/regions/us-west1/serviceAttachments/apigee-us-west1-crw7
NETWORK_NAME:（省略可）NEG を作成するネットワークの名前。このパラメータを省略すると、default プロジェクトネットワークが使用されます。
SUBNET_NAME: プロデューサーへのプライベート接続に使用されるサブネットの名前。サブネットサイズは小さくすることができます。PSC NEG にはサブネットから 1 つの IP のみが必要です。Apigee の場合、リージョンごとに必要な PSC NEG は 1 つだけです。サブネットは、VM または他のエンティティによって共有され、使用できます。サブネットが指定されていない場合、ネットワークエンドポイントは、ネットワークエンドポイントグループが作成されたリージョン内の任意のサブネットワークに属している可能性があります。
注: --network パラメータを指定する場合は、--subnet も指定する必要があります。

ステップ 8b: プロキシ専用サブネットを作成する

gcloud compute networks subnets create testproxyonlysubnet \
  --purpose=REGIONAL_MANAGED_PROXY --role=ACTIVE --region=$RUNTIME_REGION --network=$NETWORK_NAME \
  --range=100.0.0.0/24 --project=$PROJECT_ID

ステップ 8c: ネットワークエンドポイントグループ（NEG）を作成する

前の手順で作成したインスタンスからサービスアタッチメントを取得します。

curl -i -X GET -H "$AUTH" \
"https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances"

次のサンプル出力では、serviceAttachment 値が太字で表示されています。

{
"instances": [
  {
    "name": "us-west1",
    "location": "us-west1",
    "createdAt": "1645731488019",
    "lastModifiedAt": "1646504754219",
    "diskEncryptionKeyName": "projects/my-project/locations/us-west1/keyRings/us-west1/cryptoKeys/dek",
    "state": "ACTIVE",
    "runtimeVersion": "1-7-0-20220228-190814",
    "consumerAcceptList": [
      "my-project"
    ],
    "serviceAttachment": "projects/bfac7497a40c32a12p-tp/regions/us-west1/serviceAttachments/apigee-us-west1-crw7"
  }
]
}

前の手順でインスタンスのレスポンス本文から取得したサービスアタッチメントを参照する Private Service Connect NEG を作成します。

gcloud compute network-endpoint-groups create $NEG_NAME \
--network-endpoint-type=private-service-connect \
--psc-target-service=$TARGET_SERVICE \
--region=$RUNTIME_LOCATION \
--project=$PROJECT_ID

ステップ 8d: リージョン内部ロードバランサを構成する

ロードバランサに内部 IPv4 アドレスを予約します。

gcloud compute addresses create ADDRESS_NAME \
--ip-version=IPV4 --subnet=$SUBNET_NAME \
  --region=$RUNTIME_LOCATION --project=$PROJECT_ID

ADDRESS_NAME は、IP アドレスリソースの名前に置き換えます。

予約済み IP アドレスを表示するには、次のコマンドを実行します。

gcloud compute addresses describe ADDRESS_NAME \
--format="get(address)" --region=RUNTIME_LOCATION --project=$PROJECT_ID

NEG のバックエンドサービスを作成します。

gcloud compute backend-services create BACKEND_SERVICE_NAME \
--load-balancing-scheme=INTERNAL_MANAGED \
--protocol=HTTPS \
--region=$RUNTIME_REGION \
--project=$PROJECT_ID

BACKEND_SERVICE_NAME は、バックエンドサービスの名前に置き換えます。

NEG をバックエンドサービスに追加します。
```
gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
--network-endpoint-group=NEG_NAME \
--region=$RUNTIME_LOCATION \
--project=$PROJECT_ID
```
次のように置き換えます。
- BACKEND_SERVICE_NAME: バックエンドサービスの名前。
- NEG_NAME: ネットワークエンドポイントグループの名前。
HTTPS ターゲットプロキシで使用する SSL 証明書リソースが必要です。

セルフマネージド SSL 証明書リソースを作成するには、次のコマンドを使用します。セルフマネージド SSL 証明書を作成するには、ローカル秘密鍵ファイルとローカル証明書ファイルが必要です。これらのファイルを作成する必要がある場合は、セルフマネージド SSL 証明書の使用の手順 1 をご覧ください。

注: Google マネージド証明書は、内部ロードバランサではサポートされていません。
```
gcloud compute ssl-certificates create CERTIFICATE \
--certificate LB_CERT \
--private-key LB_PRIVATE_KEY
--region=RUNTIME_LOCATION --project=$PROJECT_ID
```
次のように置き換えます。
- CERTIFICATE: 証明書の名前。
- LB_CERT: セルフマネージド証明書の PEM 形式の証明書ファイルのパス。
- LB_PRIVATE_KEY: セルフマネージド証明書の PEM 形式の秘密鍵ファイルのパス。
ロードバランサの URL マップを作成します。

URL マップでは、デフォルトのバックエンドサービスを参照する必要があります。作成したバックエンドサービスをデフォルトとして設定します。
```
gcloud compute url-maps create URL_MAP_NAME \
    --default-service=DEFAULT_BACKEND_SERVICE_NAME \
    --global --project=$PROJECT_ID
```
次のように置き換えます。
- URL_MAP_NAME: URL マップの名前。
- DEFAULT_BACKEND_SERVICE_NAME: ロードバランサのデフォルトバックエンドサービスの名前。このデフォルトは、指定されたホスト名に一致するホストルールがない場合に使用されます。
SSL 証明書リソースを使用して、ターゲット HTTPS プロキシを作成します。
```
gcloud compute target-https-proxies create PROXY_NAME \
--url-map=URL_MAP_NAME \
--ssl-certificates=CERTIFICATE \
--region=$RUNTIME_LOCATION --project=$PROJECT_ID
```
次のように置き換えます。
- PROXY_NAME: ターゲット HTTPS プロキシの名前。
- URL_MAP_NAME: URL マップの名前。
- CERTIFICATE: 証明書リソースの名前。

転送ルールを作成します。

gcloud compute forwarding-rules create FWD_RULE \
--load-balancing-scheme=INTERNAL_MANAGED \
--address=ADDRESS_NAME \
--target-https-proxy=PROXY_NAME \
--ports=443 \
--target-https-proxy-region=$RUNTIME_REGION \
--region=$RUNTIME_REGION
--project=$PROJECT_ID

次のように置き換えます。

FWD_RULE: 転送ルールの名前。
ADDRESS_NAME: 転送ルールに使用するために予約した IP アドレスリソース。
PROXY_NAME: ターゲット HTTPS プロキシの名前。

Apigee のプロビジョニングが完了しました。サンプルプロキシをデプロイするに移動します。

外部ルーティング（PSC）

このセクションでは、Apigee と管理している VPC 間の通信を許可するために Private Service Connect（PSC）を使用して外部ルーティングを構成する方法について説明します。外部クライアントから Apigee ランタイムインスタンスにリクエストを送信する前に、この操作を行う必要があります。

このタスクに必要な権限

Apigee プロビジョナーに、このタスクを完了するために必要な権限を含む事前定義ロールを付与できます。または、権限をきめ細かく指定して必要最小限の権限を付与することもできます。事前定義されたロールとアクセスルーティング権限をご覧ください。

制限事項: PSC 構成に関する次の制限事項に注意してください。

この構成では、グローバル外部 HTTP(S) ロードバランサ（従来）はサポートされていません。
複数の PSC NEG を使用するフェイルオーバーの場合、アクティブなヘルスチェックはサポートされません。代わりに外れ値検出を使用してください。
制限は、PSC を介して Apigee インスタンスに接続できる Google Cloud プロジェクトの数と、プロジェクトごとに作成できる PSC NEG 接続の数に適用されます。詳細については、Private Service Connect（PSC）の上限をご覧ください。
Google Cloud プロジェクトが consumerAcceptList から削除されても、削除されたプロジェクトの既存の PSC NEG は引き続き機能します。ただし、新しい NEG は拒否されます。既存の NEG を consumerAcceptList から削除する場合は、関連するプロジェクトを削除する必要があります。また、Apigee インスタンスを再作成できます。これによって Apigee プロジェクトでサービスアタッチメントを再作成されます。

ステップ 8b: NEG を作成してロードバランサを構成する

グローバルロードバランサまたはリージョンロードバランサを作成できます。

グローバル外部 LB

グローバル外部 HTTP(S) ロードバランサ（EXTERNAL_MANAGED に設定されたロードバランシングスキーム）を構成します。

Private Service Connect NEG はリージョナルですが、この構成の他のロードバランシングコンポーネントはグローバルです。

環境変数を定義するで、環境変数が設定されていることを確認します。

前の手順で作成したインスタンスからサービスアタッチメントを取得します。

curl -i -X GET -H "$AUTH" \
      "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances"

次のサンプル出力では、serviceAttachment 値が太字で表示されています。

{
      "instances": [
        {
          "name": "us-west1",
          "location": "us-west1",
          "host": "10.82.192.2",
          "port": "443",
          "createdAt": "1645731488019",
          "lastModifiedAt": "1646504754219",
          "diskEncryptionKeyName": "projects/my-project/locations/us-west1/keyRings/us-west1/cryptoKeys/dek",
          "state": "ACTIVE",
          "peeringCidrRange": "SLASH_22",
          "runtimeVersion": "1-7-0-20220228-190814",
          "ipRange": "10.82.192.0/22,10.82.196.0/28",
          "consumerAcceptList": [
            "875609189304"
          ],
          "serviceAttachment": "projects/bfac7497a40c32a12p-tp/regions/us-west1/serviceAttachments/apigee-us-west1-crw7"
        }
      ]
    }

前の手順でインスタンスのレスポンス本文から取得したサービスアタッチメントを参照する Private Service Connect NEG を作成します。
```
    gcloud compute network-endpoint-groups create $NEG_NAME \
      --network-endpoint-type=private-service-connect \
      --psc-target-service=$TARGET_SERVICE \
      --region=$RUNTIME_LOCATION \
      --network=NETWORK_NAME \
      --subnet=SUBNET_NAME \
      --project=$PROJECT_ID
    
```
次のように置き換えます。
- NETWORK_NAME:（省略可）NEG を作成するネットワークの名前。このパラメータを省略すると、default プロジェクトネットワークが使用されます。
- SUBNET_NAME: プロデューサーへのプライベート接続に使用されるサブネットの名前。サブネットサイズは小さくすることができます。PSC NEG にはサブネットから 1 つの IP のみが必要です。Apigee の場合、リージョンごとに必要な PSC NEG は 1 つだけです。サブネットは、VM または他のエンティティによって共有され、使用できます。サブネットが指定されていない場合、ネットワークエンドポイントは、ネットワークエンドポイントグループが作成されたリージョン内の任意のサブネットワークに属している可能性があります。
  注: --network パラメータを指定する場合は、--subnet も指定する必要があります。
- PROJECT_ID: すでに Apigee 組織に関連付けられている Cloud プロジェクト、または Apigee ランタイムインスタンスが作成されたときに consumerAcceptlist に含まれている Cloud プロジェクト。
ロードバランサにグローバル外部 IPv4 アドレスを予約します。
```
gcloud compute addresses create ADDRESS_NAME \
  --ip-version=IPV4 --global --project=$PROJECT_ID
```
ADDRESS_NAME は、IP アドレスリソースの名前に置き換えます。

予約済み IP アドレスを表示するには、次のコマンドを実行します。
```
gcloud compute addresses describe ADDRESS_NAME \
  --format="get(address)" --global --project=$PROJECT_ID
```

NEG のバックエンドサービスを作成します。

gcloud compute backend-services create BACKEND_SERVICE_NAME \
  --load-balancing-scheme=EXTERNAL_MANAGED \
  --protocol=HTTPS \
  --global --project=$PROJECT_ID

BACKEND_SERVICE_NAME は、バックエンドサービスの名前に置き換えます。

バックエンドサービスを NEG に追加します。
```
gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --network-endpoint-group=NEG_NAME \
  --network-endpoint-group-region=$REGION \
  --global --project=$PROJECT_ID
```
次のように置き換えます。
- BACKEND_SERVICE_NAME: バックエンドサービスの名前。
- NEG_NAME: ネットワークエンドポイントグループの名前。
- REGION: ネットワークエンドポイントグループのリージョン。
ロードバランサの URL マップを作成します。

URL マップでは、デフォルトのバックエンドサービスを参照する必要があります。作成したバックエンドサービスをデフォルトとして設定します。
```
gcloud compute url-maps create URL_MAP_NAME \
  --default-service=DEFAULT_BACKEND_SERVICE_NAME \
  --global --project=$PROJECT_ID
```
次のように置き換えます。
- URL_MAP_NAME: URL マップの名前。
- DEFAULT_BACKEND_SERVICE_NAME: ロードバランサのデフォルトバックエンドサービスの名前。このデフォルトは、指定されたホスト名に一致するホストルールがない場合に使用されます。
ターゲット HTTPS プロキシを作成します。

HTTPS ターゲットプロキシで使用する SSL 証明書リソースが必要です。SSL 証明書リソースは、Google マネージド SSL 証明書またはセルフマネージド SSL 証明書を使用して作成できます。このうち、Google Cloud が自動的に取得、管理、更新する Google マネージド証明書をおすすめします。

Google マネージド証明書を作成するには、ドメインが必要です。

次のコマンドを使用して、Google マネージド SSL 証明書リソースを作成します。
```
gcloud compute ssl-certificates create CERTIFICATE \
  --domains DOMAIN --project=$PROJECT_ID
```
次のように置き換えます。
- CERTIFICATE: 証明書の名前。
- DOMAIN: ロードバランサのドメイン名。
セルフマネージド SSL 証明書リソースを作成するには、次のコマンドを使用します。セルフマネージド SSL 証明書を作成するには、ローカル秘密鍵ファイルとローカル証明書ファイルが必要です。これらのファイルを作成する必要がある場合は、セルフマネージド SSL 証明書の使用の手順 1 をご覧ください。
```
gcloud compute ssl-certificates create CERTIFICATE \
  --certificate LB_CERT \
  --private-key LB_PRIVATE_KEY --project=$PROJECT_ID
```
次のように置き換えます。
- CERTIFICATE: 証明書の名前。
- LB_CERT: セルフマネージド証明書の PEM 形式の証明書ファイルのパス。
- LB_PRIVATE_KEY: セルフマネージド証明書の PEM 形式の秘密鍵ファイルのパス。
SSL 証明書リソースを使用して、ターゲット HTTPS プロキシを作成します。
```
gcloud compute target-https-proxies create PROXY_NAME \
  --url-map=URL_MAP_NAME \
  --ssl-certificates=CERTIFICATE --project=$PROJECT_ID
```
次のように置き換えます。
- PROXY_NAME: ターゲット HTTPS プロキシの名前。
- URL_MAP_NAME: URL マップの名前。
- CERTIFICATE: 証明書リソースの名前。
転送ルールを作成します。
```
gcloud compute forwarding-rules create FWD_RULE \
  --load-balancing-scheme=EXTERNAL_MANAGED \
  --network-tier=PREMIUM \
  --address=ADDRESS_NAME \
  --target-https-proxy=PROXY_NAME \
  --ports=443 \
  --global --project=$PROJECT_ID
```
次のように置き換えます。
- FWD_RULE: 転送ルールの名前。
- ADDRESS_NAME: 転送ルールに使用するために予約した IP アドレスリソース。
- PROXY_NAME: ターゲット HTTPS プロキシの名前。

Apigee のプロビジョニングが完了しました。サンプルプロキシをデプロイするに移動します。

リージョン外部 LB

リージョン外部 HTTP(S) ロードバランサを構成します。外部 HTTP(S) ロードバランサの概要もご覧ください。

環境変数を定義するで変数が設定されていることを確認してください。
プロキシ専用サブネットを作成します。
注: これは 1 回限りのオペレーションです。このプロキシ専用サブネットは、Envoy ベースのリージョンロードバランサ用の Google Cloud プロジェクトごとに 1 回だけ必要です。Envoy ベースのロードバランサのプロキシ専用サブネットもご覧ください。
```
gcloud compute networks subnets create SUBNET_NAME \
  --purpose=REGIONAL_MANAGED_PROXY --role=ACTIVE \
  --region=$RUNTIME_LOCATION --network=NETWORK_NAME \
  --range=100.0.0.0/24 --project=$PROJECT_ID
```
- SUBNET_NAME は、サブネットの名前に置き換えます。
- （省略可）サブネットが作成されるネットワークの名前を NETWORK_NAME に置き換えます。このパラメータを省略すると、デフォルトのプロジェクトネットワークが使用されます。

前の手順で作成したインスタンスからサービスアタッチメントを取得します。

curl -i -X GET -H "$AUTH" \
        "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances"

次のサンプル出力では、serviceAttachment 値が太字で表示されています。

{
        "instances": [
          {
            "name": "us-west1",
            "location": "us-west1",
            "host": "10.82.192.2",
            "port": "443",
            "createdAt": "1645731488019",
            "lastModifiedAt": "1646504754219",
            "diskEncryptionKeyName": "projects/my-project/locations/us-west1/keyRings/us-west1/cryptoKeys/dek",
            "state": "ACTIVE",
            "peeringCidrRange": "SLASH_22",
            "runtimeVersion": "1-7-0-20220228-190814",
            "ipRange": "10.82.192.0/22,10.82.196.0/28",
            "consumerAcceptList": [
              "875609189304"
            ],
            "serviceAttachment": "projects/bfac7497a40c32a12p-tp/regions/us-west1/serviceAttachments/apigee-us-west1-crw7"
          }
        ]
      }

ネットワークエンドポイントグループを作成します。
```
gcloud compute network-endpoint-groups create NEG_NAME \
        --network-endpoint-type=private-service-connect \
        --psc-target-service=TARGET_SERVICE \
        --region=$RUNTIME_LOCATION --project=$PROJECT_ID
```
次のように置き換えます。
- NEG_NAME: ネットワークエンドポイントグループの名前。
- TARGET_SERVICE: 接続するサービスアタッチメントの名前。例: projects/bfac7497a40c32a12p-tp/regions/us-west1/serviceAttachments/apigee-us-west1-crw7

NEG のバックエンドサービスを作成します。

gcloud compute backend-services create BACKEND_SERVICE_NAME \
  --load-balancing-scheme=EXTERNAL_MANAGED \
  --protocol=HTTPS \
  --region=$RUNTIME_LOCATION  \
  --project=$PROJECT_ID

BACKEND_SERVICE_NAME は、バックエンドサービスの名前に置き換えます。

バックエンドサービスを NEG に追加します。
```
gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --network-endpoint-group=NEG_NAME \
  --region=$RUNTIME_LOCATION  \
  --project=$PROJECT_ID
```
次のように置き換えます。
- BACKEND_SERVICE_NAME: バックエンドサービスの名前。
- NEG_NAME: ネットワークエンドポイントグループの名前。
ロードバランサの URL マップを作成します。

URL マップでは、デフォルトのバックエンドサービスを参照する必要があります。作成したバックエンドサービスをデフォルトとして設定します。
```
gcloud compute url-maps create URL_MAP_NAME \
  --default-service=DEFAULT_BACKEND_SERVICE_NAME \
  --region=$RUNTIME_LOCATION  \
  --project=$PROJECT_ID
```
次のように置き換えます。
- URL_MAP_NAME: URL マップの名前。
- DEFAULT_BACKEND_SERVICE_NAME: ロードバランサのデフォルトバックエンドサービスの名前。このデフォルトは、指定されたホスト名に一致するホストルールがない場合に使用されます。
ターゲット HTTPS プロキシを作成します。

HTTPS ターゲットプロキシで使用する SSL 証明書リソースが必要です。

セルフマネージド SSL 証明書リソースを作成するには、次のコマンドを使用します。セルフマネージド SSL 証明書を作成するには、ローカル秘密鍵ファイルとローカル証明書ファイルが必要です。これらのファイルを作成する必要がある場合は、セルフマネージド SSL 証明書の使用の手順 1 をご覧ください。

注: Google マネージド証明書は、外部ロードバランサではサポートされていません。
```
gcloud compute ssl-certificates create CERTIFICATE \
  --certificate LB_CERT \
  --private-key LB_PRIVATE_KEY --region=$RUNTIME_LOCATION \
  --project=$PROJECT_ID
```
次のように置き換えます。
- CERTIFICATE: 証明書の名前。
- LB_CERT: セルフマネージド証明書の PEM 形式の証明書ファイルのパス。
- LB_PRIVATE_KEY: セルフマネージド証明書の PEM 形式の秘密鍵ファイルのパス。

作成された Apigee 環境グループにドメインを追加します。環境グループの名前は eval-group です。

curl "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/envgroups/eval-group" \
      -H "$AUTH" \
      -X PATCH \
      -H "Content-Type:application/json" \
      -d '{
        "hostnames":["'"DOMAIN"'"]
      }'

環境グループオペレーションのステータスを確認します。

curl -H "$AUTH" \
      "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/envgroups/eval-group/attachments"

SSL 証明書リソースを使用して、ターゲット HTTPS プロキシを作成します。
```
gcloud compute target-https-proxies create PROXY_NAME \
  --url-map=URL_MAP_NAME --region=$RUNTIME_LOCATION \
  --ssl-certificates=CERTIFICATE --project=$PROJECT_ID
```
次のように置き換えます。
- PROXY_NAME: ターゲット HTTPS プロキシの名前。
- URL_MAP_NAME: URL マップの名前。
- CERTIFICATE: 証明書リソースの名前。
ロードバランサにリージョン外部アドレスを予約します。ネットワーク階層は STANDARD に設定する必要があります。
```
gcloud compute addresses create ADDRESS_NAME \
      --region=$RUNTIME_LOCATION --network-tier=STANDARD \
      --project=$PROJECT_ID
```
ADDRESS_NAME は、IP アドレスリソースの名前に置き換えます。

予約済み IP アドレスを表示するには、次のコマンドを実行します。
```
gcloud compute addresses describe ADDRESS_NAME \
      --format="get(address)" --region=$RUNTIME_LOCATION \
      --project=$PROJECT_ID
```

転送ルールを作成します。

gcloud compute forwarding-rules create FWD_RULE \
  --load-balancing-scheme=EXTERNAL_MANAGED \
  --network-tier=STANDARD \
  --address=ADDRESS_NAME \
  --target-https-proxy=PROXY_NAME \
  --ports=443  --region=$RUNTIME_LOCATION \
  --target-https-proxy-region=$RUNTIME_LOCATION --project=$PROJECT_ID

次のように置き換えます。

FWD_RULE: 転送ルールの名前。
ADDRESS_NAME: 転送ルールに使用するために予約した IP アドレスリソース。
PROXY_NAME: ターゲット HTTPS プロキシの名前。

Apigee のプロビジョニングが完了しました。サンプル API プロキシを呼び出すに移動します。

ステップ 5: サンプル API プロキシを呼び出す

プロビジョニング時に hello-world という API プロキシが作成され、デプロイされます。このステップでは、このプロキシを呼び出して新しい評価組織をテストします。

このタスクに必要な権限

プロキシの作成とデプロイには、最小限の権限が必要です。Apigee 組織管理者ロールが付与されている場合は、このタスクを完了できます。他の適用可能なロールについては、Apigee のロールをご覧ください。

内部ルーティングで API プロキシを呼び出す

ステップ 5 でサービスエンドポイント オプションを使用して内部ルーティングを選択した場合、内部専用アクセスでの API プロキシの呼び出しの手順に沿って操作します。

外部ルーティングで API プロキシを呼び出す

ステップ 5 で外部ルーティング オプションを選択した場合は、このセクションの手順に沿って操作してください。

ドメインの DNS エントリを設定します。このタスクを実行するには、次の 2 つの方法があります。
- 登録事業者側でドメインを指す A レコードを作成します。たとえば、ドメインが sales.example.com で IP が 10.23.0.2 の場合は、sales.example.com のレコードがアドレス 10.23.0.2 を参照するようにします。
  予約済み IP アドレスを表示するには、次のコマンドを実行します。
```
gcloud compute addresses describe ADDRESS_NAME \
    --format="get(address)" --region=$RUNTIME_LOCATION \
    --project=$PROJECT_ID
```
- Google Cloud DNS を使用して URL を IP アドレスにマッピングします。

hello-world プロキシがデプロイされていることを確認します。

curl -i -H "$AUTH" \
  "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/environments/eval/apis/hello-world/revisions/1/deployments"

API プロキシを呼び出します。
次のコマンドを実行して、ネットワークが有効になっている任意のマシンから API プロキシにリクエストを送信します。
```
curl -i -H "Host: DOMAIN" \
  https://DOMAIN/hello-world
```
ここで、ステップ 5: ルーティングを構成するで説明したように、DOMAIN は、証明書に含まれ環境グループに追加したドメインです。必要に応じて、この API を使用して環境グループから DOMAIN 値を取得できます。
```
curl -i -H "$AUTH" \
  "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/envgroups"
```
成功すると、サンプル API プロキシはレスポンスを返します。
```
Hello, Guest!
```
トラブルシューティングのヒント:

handshake エラーが発生した場合は、SSL 証明書のステータスを確認します。セルフマネージド証明書と Google マネージド証明書のトラブルシューティングについては、SSL 証明書のトラブルシューティングをご覧ください。
登録ドメインに、ステップ 5 で作成したグローバル外部 IPv4 アドレスの IP アドレスを指す A レコードがあることを確認します。予約済み IP アドレスを表示するには、次のコマンドを実行します。
```
gcloud compute addresses describe ADDRESS_NAME \
              --format="get(address)" --region=$RUNTIME_LOCATION \
              --project=$PROJECT_ID
```
ドメイン構成を解決できない場合は、次のコマンドでプロキシを呼び出してみてください。
```
curl  -H Host:DOMAIN --resolve \
  DOMAIN:443:EXTERNAL_IP_ADDRESS  \
  https://DOMAIN:443/hello-world -k
```
注: DNS の変更はすぐに公開されますが、反映されるまでに時間がかかる場合があります。この遅延のため、サンプルプロキシを呼び出すには最大 1 時間かかる場合があります。

次: API プロキシの構築とデプロイの詳細については、最初のプロキシの構築の概要をご覧ください。

VPC ピアリングを使用せずに評価組織をプロビジョニングする

制限事項

ステップの概要

ステップ 1: 環境変数を定義する

ステップ 2: API を有効にする

このタスクに必要な権限

ステップ 3: 組織を作成する

このタスクに必要な権限

ステップ 4: ルーティングを構成する

内部ルーティング（PSC）

サービス エンドポイント

このタスクに必要な権限

サービス アタッチメントに PSC サービス エンドポイントを作成する

内部リージョン LB

このタスクに必要な権限

ステップ 8a: 環境変数を設定する

ステップ 8b: プロキシ専用サブネットを作成する

ステップ 8c: ネットワーク エンドポイント グループ（NEG）を作成する

ステップ 8d: リージョン内部ロードバランサを構成する

外部ルーティング（PSC）

このタスクに必要な権限

ステップ 8b: NEG を作成してロードバランサを構成する

グローバル外部 LB

リージョン外部 LB

ステップ 5: サンプル API プロキシを呼び出す

このタスクに必要な権限

内部ルーティングで API プロキシを呼び出す

外部ルーティングで API プロキシを呼び出す

サービスエンドポイント

サービスアタッチメントに PSC サービスエンドポイントを作成する

ステップ 8c: ネットワークエンドポイントグループ（NEG）を作成する