Apigee のインストールのトラブルシューティング

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

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

このドキュメントでは、Apigee をインストールして構成する際の一般的なエラーを示し、それらのエラーに対して考えられる解決策について説明します。

新しいインスタンスの作成

このセクションでは、Apigee にリクエストを送信して新しいインスタンスを作成した後に発生する一般的なエラーとその解決策について説明します。

401 (UNAUTHENTICATED) は、認証情報がタイムアウトした可能性があることを示しています。次の例に示すように、認証トークンの更新を試してください:
```
AUTH="Authorization: Bearer $(gcloud auth print-access-token)"
```
RANGES_EXHAUSTED は、最初にリクエストした IP アドレス範囲が承認されず、新しい範囲をリクエストする必要があることを示します。最初にステップ 4: サービスネットワーキングを構成するで範囲リクエストを作成しました。
Apigee が限定公開サービス接続用の IP アドレスを選択する元となる、新しい範囲をリクエストするには:
1. 次の gcloud コマンドを実行します:
```
gcloud compute addresses create google-svcs-2
  --project=$PROJECT_ID --global --prefix-length=16
  --description="additional peering range for Google services" --network=default
  --purpose=VPC_PEERING
```
  このコマンドにより、google-svcs-2 という名前の新しい範囲が作成されます。
2. 次のコマンドを実行して、接続リクエストを更新します:
```
gcloud services vpc-peerings update
  --service=servicenetworking.googleapis.com --network=default
  --ranges=google-svcs,google-svcs-2 --project=$PROJECT_ID
```
  注: 最初の範囲の名前（この場合は google-svcs）と、新たにリクエストされる範囲の名前（この場合はgoogle-svcs-2）を指定する必要があります。詳細については、gcloud サービスの VPC ピアリングの更新をご覧ください。

Apigee 組織の作成

次の例は、組織を初めて作成したときに Apigee によって表示される可能性のある一般的なエラーを示しています。

組織作成エラー

これは、必要な API の 1 つ以上が有効になっていないという意味です。次の進む前に、ステップ 2: Apigee API を有効にするに記載されている API がすべて有効になっていることを確認してください。

また、次のいずれかの HTTP エラーが返されることもあります。

401 (UNAUTHENTICATED) は、認証情報がタイムアウトした可能性があることを示しています。次の例に示すように、認証トークンの更新を試してください:
```
AUTH="Authorization: Bearer $(gcloud auth print-access-token)"
```
404 (Not Found) の原因としては、次のことが考えられます。
- 間違ったエンドポイントまたはリクエストの URL を入力しました。API 呼び出しのドメインに apigee.googleapis.com が指定されていることを確認します。
- まだプロジェクトがプロビジョニングされていない可能性があります。Apigee セールスまでお問い合わせください。
409 (Conflict) は通常、指定した組織名がすでに存在することを示します。組織名は、グローバルに一意である必要があります。組織に別の名前を選択して、コマンドを再実行します（コマンドラインで組織を作成する場合、リクエストのペイロードで名前を指定します。なお、プロジェクトと同じ名前の組織を作成する必要があります。タイプミスがなければ、実際にはエラーは発生しません）。

新しい組織のリクエストのステータスを確認したときに、Apigee から次のようなエラーが返される可能性があります。

403 (Permission Denied) は、組織がまだ作成されていないことを示します。しばらくしてからもう一度お試しください。新しい組織を初めて作成するときに Apigee が 403 を返した場合、API が有効になっていない可能性があります。ステップ 2: Apigee API を有効にするの説明に従って、すべての API が有効になっているかを確認します。

サンプルのデプロイ

ロードバランサが正常でない

サンプルプロキシをデプロイすると、502 (Bad Gateway) HTTP エラーが返されることがあります。この場合は、次の手順をお試しください。

Cloud コンソールを開きます。
ロードバランサの状態を確認します。Cloud コンソールで、[ネットワークサービス] > [ロードバランシング] を選択します。[ロードバランサ] タブに、プロジェクトのすべてのロードバランサとそのステータスが表示されます。黄色の三角形は、ロードバランサのバックエンドサービスが正常でないことを示します。
ロードバランサの問題を確認したら、ランタイムインスタンスの VM をチェックして、動作中かつ正常であることを確認します。
ログファイルを確認して、問題の原因となっている可能性のあるエラーやその他の問題がないかどうかを確認します。ログの有効化と表示の詳細については、ログの表示をご覧ください。
Cloud コンソールでインスタンスグループに対してローリング再起動を試します。
1. [Compute Engine] > [インスタンスグループ] の順に選択します。
2. インスタンスグループのリストの [名前] 列で、応答していないインスタンスグループをクリックします。
3. 次の例のように、[ローリング再起動 / 置換] をクリックします。
4. 次の画面で [再起動] をクリックします。
  これにより Envoy インスタンスが再起動されます。

インスタンス IP が正しくない

Apigee インスタンスを削除して再作成すると、Apigee インスタンス IP が変更され、マネージドインスタンスグループ（MIG）テンプレートのエンドポイント IP と同期しなくなる可能性があります。たとえば、MIG テンプレートに削除されたインスタンスの古い IP が残ります。MIG テンプレートは Apigee のプロビジョニングプロセスで作成されています。この場合は、次の操作を行って、正しい Apigee IP で MIG テンプレートを更新します。

Apigee UI を開きます。

Apigee UI に移動
[管理] > [インスタンス] に移動します。
インスタンスの IP アドレスをメモします。この IP は、後のステップで必要になります。例: 10.117.200.2
Google Cloud コンソールで、[インスタンステンプレート] ページに移動します。

[インスタンステンプレート] に移動
インスタンステンプレートを開きます。ロードバランサにマッピングされているバックエンドで使用されるインスタンステンプレートを開く必要があります。
下にスクロールして、[カスタムメタデータ] セクションで ENDPOINT IP を見つけます。
エンドポイント IP が Apigee UI でメモしたものと異なる場合は、インスタンステンプレートの IP を Apigee インスタンス IP に合わせて変更する必要があります。インスタンス IP の変更をご覧ください。