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

このセクションでは、Apigee をインストールして構成する際の一般的なエラーを示し、そのエラーに対するふさわしい解決策を説明します。

最もよくある問題は、次の HTTP エラーです。

  • 401 (UNAUTHENTICATED) は、認証情報がタイムアウトした可能性があることを示しています。次の例に示すように、認証トークンの更新を試してください。
    AUTH="Authorization: Bearer $(gcloud auth print-access-token)"

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

このセクションでは、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」)と、新しくリクエストされた範囲の名前(この場合は「google-svcs-2」)を指定する必要があります。

    2. 次のコマンドを実行して、接続リクエストを更新します。
      gcloud services vpc-peerings update
        --service=servicenetworking.googleapis.com --network=default
        --ranges=google-svcs,google-svcs-2 --project=$PROJECT_ID

      vpc-peerings update コマンドでも、古い IP アドレス範囲と新しい IP アドレス範囲の両方を指定するようになりました。

      詳細については、gcloud services vpc-peerings update をご覧ください。

Apigee 組織の作成

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

組織作成エラー

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

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

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

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

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

サンプルのデプロイ

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

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

      Compute Engine のローリング再起動

    4. 次の画面で [再起動] をクリックします。

      これにより Envoy インスタンスが再起動されます。