このページの内容は Apigee に適用されます。Apigee ハイブリッドには適用されません。
Apigee Edge のドキュメントを表示します。
このドキュメントでは、Apigee をインストールして構成する際の一般的なエラーを示し、それらのエラーに対して考えられる解決策について説明します。
新しいインスタンスの作成
このセクションでは、Apigee にリクエストを送信して新しいインスタンスを作成した後に発生する一般的なエラーとその解決策について説明します。
401 (UNAUTHENTICATED)
は、認証情報がタイムアウトした可能性があることを示しています。次の例に示すように、認証トークンの更新を試してください:AUTH="Authorization: Bearer $(gcloud auth print-access-token)"
RANGES_EXHAUSTED
は、最初にリクエストした IP アドレス範囲が承認されず、新しい範囲をリクエストする必要があることを示します。最初にステップ 4: サービス ネットワーキングを構成するで範囲リクエストを作成しました。Apigee が限定公開サービス接続用の IP アドレスを選択する元となる、新しい範囲をリクエストするには:
- 次の
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
という名前の新しい範囲が作成されます。 - 次のコマンドを実行して、接続リクエストを更新します:
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 セールスまでお問い合わせください。
- 間違ったエンドポイントまたはリクエストの URL を入力しました。API 呼び出しのドメインに
409 (Conflict)
は通常、指定した組織名がすでに存在することを示します。組織名は、グローバルに一意である必要があります。組織に別の名前を選択して、コマンドを再実行します(コマンドラインで組織を作成する場合、リクエストのペイロードで名前を指定します。なお、プロジェクトと同じ名前の組織を作成する必要があります。タイプミスがなければ、実際にはエラーは発生しません)。
新しい組織のリクエストのステータスを確認したときに、Apigee から次のようなエラーが返される可能性があります。
403 (Permission Denied)
は、組織がまだ作成されていないことを示します。しばらくしてからもう一度お試しください。新しい組織を初めて作成するときに Apigee が403
を返した場合、API が有効になっていない可能性があります。ステップ 2: Apigee API を有効にするの説明に従って、すべての API が有効になっているかを確認します。
サンプルのデプロイ
ロードバランサが正常でない
サンプル プロキシをデプロイすると、502 (Bad Gateway)
HTTP エラーが返されることがあります。この場合は、次の手順をお試しください。
- Cloud コンソールを開きます。
- ロードバランサの状態を確認します。Cloud コンソールで、[ネットワーク サービス] > [ロード バランシング] を選択します。[ロードバランサ] タブに、プロジェクトのすべてのロードバランサとそのステータスが表示されます。黄色の三角形は、ロードバランサのバックエンド サービスが正常でないことを示します。
- ロードバランサの問題を確認したら、ランタイム インスタンスの VM をチェックして、動作中かつ正常であることを確認します。
- ログファイルを確認して、問題の原因となっている可能性のあるエラーやその他の問題がないかどうかを確認します。ログの有効化と表示の詳細については、ログの表示をご覧ください。
- Cloud コンソールでインスタンス グループに対してローリング再起動を試します。
- [Compute Engine] > [インスタンス グループ] の順に選択します。
- インスタンス グループのリストの [名前] 列で、応答していないインスタンス グループをクリックします。
- 次の例のように、[ローリング再起動 / 置換] をクリックします。
- 次の画面で [再起動] をクリックします。
これにより Envoy インスタンスが再起動されます。
インスタンス IP が正しくない
Apigee インスタンスを削除して再作成すると、Apigee インスタンス IP が変更され、マネージド インスタンス グループ(MIG)テンプレートのエンドポイント IP と同期しなくなる可能性があります。たとえば、MIG テンプレートに削除されたインスタンスの古い IP が残ります。MIG テンプレートは Apigee のプロビジョニング プロセスで作成されています。この場合は、次の操作を行って、正しい Apigee IP で MIG テンプレートを更新します。
Apigee UI を開きます。
- [管理] > [インスタンス] に移動します。
- インスタンスの IP アドレスをメモします。この IP は、後のステップで必要になります。例:
10.117.200.2
Google Cloud コンソールで、[インスタンス テンプレート] ページに移動します。
- インスタンス テンプレートを開きます。ロードバランサにマッピングされているバックエンドで使用されるインスタンス テンプレートを開く必要があります。
- 下にスクロールして、[カスタム メタデータ] セクションで
ENDPOINT
IP を見つけます。 - エンドポイント IP が Apigee UI でメモしたものと異なる場合は、インスタンス テンプレートの IP を Apigee インスタンス IP に合わせて変更する必要があります。インスタンス IP の変更をご覧ください。