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

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

このセクションでは、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 がすべて有効になっていることを確認してください。

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

  • 401 (UNAUTHENTICATED) は、認証情報がタイムアウトした可能性があることを示しています。次の例に示すように、認証トークンの更新を試してください。
    AUTH="Authorization: Bearer $(gcloud auth print-access-token)"
  • 404 (Not Found) の原因としては、次のことが考えられます。
    • 間違ったエンドポイントまたはリクエストの 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 インスタンスが再起動されます。