リリースノート

このページには、Cloud Endpoints の機能やアップデートのリリースノートが掲載されています。Extensible Service Proxy(ESP)のアップデートについては、GitHub で Endpoints ランタイムのリリースノートをご覧ください。

プロダクトのアップデートに関する最新情報を受け取るには、このページの URL をフィード リーダーに追加してください。

2018 年 9 月

Cloud Endpoints Frameworks v1 がシャットダウンされました

App Engine スタンダード環境用 Cloud Endpoints Frameworks v1 のサポートは、2017 年 8 月 2 日に終了しました。このサービスは 2018 年 9 月 13 日にシャットダウンされ、ドキュメントは削除されました。

Endpoints Frameworks Python: デフォルトのロギングレベルの変更

デフォルトのロギングレベルを変更する機能が Endpoints Frameworks Python に追加されました。詳細については、Python 用 Endpoints Framework でのロギングをご覧ください。

2018 年 8 月

Cloud Endpoints Portal のアップデート

Endpoints Portal が一般提供になりました。このリリースには、次の新機能と拡張機能が含まれています。

API によるカスタム ドキュメントの同期

カスタム ドキュメントをポータルに同期させる API が使用可能になりました。詳細については、API 実装のドキュメントをご覧ください。

カスタム ドキュメントに画像を含める

画像をカスタム コンテンツの Git リポジトリに追加して、その画像を Markdown ファイルの中で参照できます。詳細については、API 実装のドキュメントをご覧ください。

SmartDocs API リファレンス ドキュメントの導入

ポータルに API リファレンス ドキュメントを表示し、[この API を試す] パネルを提供するコンポーネントに対して、「SmartDocs API リファレンス ドキュメント」という名称が付けられました。当初 Endpoints Portal 用に開発された SmartDocs は、Apigee の統合デベロッパー ポータルでも利用できます。

Cloud Endpoints Frameworks v1 のシャットダウンが近づいています

App Engine スタンダード環境用 Cloud Endpoints Frameworks v1 のサポートは、2017 年 8 月 2 日に終了しました。このサービスは 2018 年 9 月 3 日にシャットダウンされる予定であり、ドキュメントは削除されます。停止を回避するには、v1 アプリケーションを移行する必要があります。Endpoints Frameworks v2 へのアプリケーションの移行については、次のガイドを参照してください。

ESP でトレース サンプリングを無効にする

デフォルトでは、ESP は API への少数のリクエストをサンプリングし、Stackdriver Trace にトレースを送信します。トレース サンプリングを無効にする ESP 起動オプションが ESP リリース 1.19.0 で追加されました。このオプションは App Engine フレキシブル環境でのデプロイに使用できます。

詳細については、API 実装に関するドキュメントの「API のトレース」をご覧ください。

App Engine スタンダード環境で使用される Endpoints Frameworks は、API 管理に ESP を使用せず、Stackdriver Trace にトレースデータを送信しません。

2018 年 7 月

Endpoints Portal の新しい役割と権限

Google Cloud Identity and Access Management(Cloud IAM)の役割である Endpoints Portal 管理者と、いくつかの新しい Cloud IAM の権限が利用可能になりました。これらの新しい役割と権限を使用すると、プロジェクト メンバーがどの程度まで Endpoints Portal にアクセスできるかを制御できます。

詳細については、API 実装に関するドキュメントで「Endpoints Portal の権限」をご覧ください。

2018 年 6 月

ライブラリとプラグインのアップデート

  • Endpoints Frameworks for Python ライブラリのバージョン 4.4.0 が拡張され、protorpc ライブラリではなく endpoints ライブラリから message_typesmessagesremote の各クラスをインポートできるようになりました。API を定義するファイル内の import ステートメントを変更することをおすすめします。

    import endpoints
    from protorpc import message_types
    from protorpc import messages
    from protorpc import remote
    

    次のように変更します。

    from endpoints import message_types
    from endpoints import messages
    from endpoints import remote
    

    この import ステートメントの変更はオプションですが、この変更を行うと Endpoints Frameworks ライブラリのコードがすっきりします。

  • Endpoints Frameworks for Java ライブラリのバージョン 2.1.0 では、リクエストに必須パラメータが含まれているかどうかを検証するようになりました。リクエストで必須パラメータが省略されている場合、Endpoints Frameworks はステータス コード HTTP 400, Bad Request を返します。

Endpoints Portal のベータ版リリース

Endpoints Portal を使用して、デベロッパー ポータルを作成します。デベロッパー ポータルとは、ドキュメントを読んだり、API を操作したりするために Cloud Endpoints API のユーザーがアクセスできるウェブサイトです。

詳細については、API 実装に関するドキュメントの「Cloud Endpoints Portal の概要」をご覧ください。

2018 年 3 月

ESP マネージド ロールアウト オプション

ESP の --rollout_strategy=managed オプションが、OpenAPI や gRPC で記述された API で利用できるようになりました。このオプションにより、ESP はデプロイ済みの最新のサービス構成を使用するように構成されます。このオプションを指定すると、新しいサービス構成をデプロイしてから 1 分以内に ESP が変更を検出し、自動的に使用します。ESP が特定の構成 ID でなく、このオプションを使用するように指定することをおすすめします。

このオプションは、Endpoints Frameworks では使用できません。

マネージド ロールアウト オプションは ESP のバージョン 1.7.0 で追加されましたが、gcloud コマンドライン ツールのアップデートにより App Engine フレキシブル環境でも使用できるようになりました。現在、このオプションは gcloud コマンドライン ツールのベータ版でのみ使用できます。app.yaml にこのオプションを追加した後に、gcloud beta app deploy コマンドを使用して API と ESP をデプロイする必要があります。

この新しいオプションを使用して ESP をデプロイする方法については、ご使用の API 実装のドキュメントをご覧ください。

ライブラリとプラグインのアップデート

  • Endpoints Framework for Python ライブラリのバージョン 3.0.0 には、互換性が失われる可能性のある変更が含まれています。
    • 複数の API からなる単一サービスをデプロイできるようになりました。ただし、この機能を使用するときには API 名についての追加制限があります。詳細については、API のデプロイとテストをご覧ください。
    • 以前は、API バージョン文字列がそのままパスに埋め込まれていました。たとえば、バージョン v1 の API echo のパスは /echo/v1 になります。SemVer 標準との互換性がない API バージョン文字列では、引き続きこの方法が適用されます。SemVer 標準と互換性のある文字列の場合は、API のデプロイ時にメジャー バージョン番号が抽出され、パスに埋め込まれます。たとえば、バージョン 2.1.0 の API echo の場合、パスは /echo/v2 のようになります。echo API をバージョン 2.2.0 に更新し、下位互換性のある変更をデプロイすると、このパスは /echo/v2 のままです。これにより、下位互換性のある変更を行うときに、クライアントの既存のパスを変更せずに API バージョン番号を更新できます。しかし、echo API をバージョン 3.0.0 に更新すると(互換性が失われる変更をデプロイするため)、パスは /echo/v3 に変更されます。

2018 年 1 月

Endpoints ダッシュボードで、構成ファイルを以前のバージョンと比較できるようになりました。特定のデプロイに関する問題をトラブルシューティングする際には、構成ファイルの差分の確認が役立つ場合があります。詳細については、API 実装のドキュメントをご覧ください。

ライブラリとプラグインのアップデート

  • Endpoints Framework for Python ライブラリ、バージョン 2.5.0

2017 年 12 月

Endpoints DNS

Endpoints DNS 機能が一般提供になりました。API を呼び出すために使用できる URL を登録するように Endpoints を構成できます。App Engine を使用しないユーザーに、IP アドレスを使用したりドメイン名を登録したりせずに API を呼び出す便利な方法が提供されます。次のような URL で API を呼び出すことができます。

echo-api.endpoints.my-project-id.cloud.goog

詳細については、API 実装に関するドキュメントの「cloud.goog ドメインでの DNS の構成」ページをご覧ください。

SSL を使用する Endpoints DNS

cloud.goog ドメインを使用するように構成された API に対して SSL を有効にする方法を示すサンプルが利用可能になりました。詳細については、API 実装のドキュメントをご覧ください。

2017 年 11 月

特定のコンシューマ プロジェクトのフィルタ

特定のコンシューマ プロジェクトの指標をフィルタする機能が、Endpoints ダッシュボードのアルファ版機能として利用可能になりました。詳細については、API 実装のドキュメントをご覧ください。

ライブラリとプラグインのアップデート

  • Endpoints Framework for Python ライブラリ、バージョン 2.4.5

  • Endpoints Framework Gradle プラグイン、バージョン 1.0.3

  • Endpoints Framework Maven プラグイン、バージョン 1.0.3

2017 年 10 月

割り当てのベータ版リリース

割り当てを使用すると、過剰なリクエスト数から API を保護するための使用制限を指定できます。割り当ての詳細については、API 実装に関するドキュメントの「割り当てについて」のページをご覧ください。

gcloud エンドポイントと gcloud サービス

Cloud SDK コマンド グループの gcloud endpointsgcloud services が一般提供されるようになりました。gcloud エンドポイントと gcloud サービスのコマンド グループは、廃止された gcloud サービス管理の代わりとなります。

ライブラリの更新

  • Endpoints Framework for Python ライブラリのバージョン 2.4.1 が利用できるようになりました。

  • Endpoints Frameworks for Java ライブラリのバージョン 2.0.9 が利用できるようになりました。

2017 年 8 月

API メトリックが Stackdriver で公開されるようになりました。リクエスト率、レイテンシなどをモニタリングできます。アラートの設定については、API 実装に関するドキュメントの「API のモニタリング」のページをご覧ください。

Stackdriver メトリック リストには、メトリックの完全なリストがあります。

2017 年 7 月

IAM API を使用して個々の API へのアクセスをプログラムで許可することができるようになりました。API 実装の詳細については、「API アクセスの概要」のページをご覧ください。

2017 年 5 月

API キーが提供されない場合、Endpoints は呼び出しがプロデューサー プロジェクトに起因すると見なし、バックエンド(gRPC、HTTP)によって使用されるプロトコルを報告するようになりました。

2017 年 4 月

Endpoints では、必要に応じて、API の呼び出しに使用できる URL を登録できるようになりました。App Engine を使用していないユーザーも、この URL を利用すれば IP アドレスを使わずに API を呼び出すことができます。次のような URL で API を呼び出すことができます。

echo-api.endpoints.my-project-id.cloud.goog

詳細については、OpenAPI 構成のページgRPC 構成のページをご覧ください。

2017 年 2 月

Google Cloud Console で API デプロイ履歴を使用できるようになりました。これにより、API 設定のデプロイの履歴を確認できます。この機能は現在ベータ版です。

API デプロイ履歴では、特定の構成をアップロードしたユーザー、アップロードした日時、構成 ID が示されます。これは、API の設定変更の構成 ID と帰属を調べるときに便利です。

新しい画面を表示するには、Cloud Console の Endpoints UI セクションで目的の API に移動し、[デプロイの履歴] タブをクリックします。

2017 年 1 月

クロスオリジン リソース シェアリング(CORS)リクエストをデフォルトで拒否するように Extensible Service Proxy(ESP)の動作が変更になります。CORS リクエストを使用する場合は、明示的に許可するように構成を変更し、2017 年 1 月 2 日までに再デプロイする必要があります。

背景と現在の動作

CORS では、クロスオリジン リクエストを実行する権限があるかどうかを判定するために、ブラウザからサーバーに追加の OPTIONS リクエストが標準で挿入されるようになっていますが、現在の ESP の仕様では OPTIONS リクエストが常に受け入れられます。そのため、現在は、ESP で CORS によるクロスオリジン リクエストが常に許可されます。

変更の内容

クロスオリジン トラフィックを許可するかどうかをサービス プロデューサーが指定できるように ESP が変更になります。今後、ESP はデフォルトですべての OPTIONS リクエストを拒否し、その結果クロスオリジン リクエストはブロックされます。API に対するクロスオリジン リクエストを許可する場合は、サービスの OpenAPI 構成に次のスニペットを追加する必要があります。

...
"host": "echo-api.endpoints.YOUR_PROJECT_ID.cloud.goog",
"x-google-endpoints": [
  {
    "name": "echo-api.endpoints.YOUR_PROJECT_ID.cloud.goog",
    "allowCors": true
  }
],
...

必要な対応

以下にある適切なタブの手順に沿って設定します。

App Engine フレキシブル環境

2017 年 1 月 2 日の ESP 1.0 のリリース以降、フレキシブル環境のすべての API のデプロイに新しいバージョンの ESP が適用され、CORS リクエストがデフォルトで自動的に拒否されるようになります。App Engine アプリケーションは 7 日ごとに自動的に再デプロイされるため、ESP 1.0 のリリース後 7 日以内にアプリが最新バージョンに更新されて再起動され、意図しないクロスオリジン シェアリングから自動的に保護されるようになります。

フレキシブル環境で引き続き CORS リクエストを許可するには、上記の「x-google-endpoints」スニペットを API 構成(OpenAPI 仕様または Swagger ファイル)に追加する必要があります。CORS を使用している場合は、サービスが中断されることがないように、できるだけ早くスニペットを追加し、次のコマンドを使用してサービスを再デプロイすることをおすすめします。そうすれば、新しいバージョンの ESP のロールアウト時に動作が変わることはありません。

gcloud app deploy app.yaml

Kubernetes Engine

この変更について、2017 年 1 月 2 日の ESP 1.0 のリリースで実装を予定しています。

現在 CORS を使用して API に対するクロスオリジン トラフィックを有効にしている場合は、1 月 2 日以降の ESP 1.0 へのアップグレード後に API 構成(OpenAPI 仕様または Swagger ファイル)の変更が必要になります。上記の「x-google-endpoints」スニペットを API の OpenAPI 設定に追加し、次のコマンドを使用して API 設定を再デプロイしてください。

gcloud service-management deploy openapi.yaml

上記の手順により、新しいサービス構成がサービス マネージャーに push されます。次の手順で必要になるため、新しい SERVICE_CONFIG_ID をメモしておいてください。

次に、サービスを再デプロイする必要があります。次のコマンドの ESP-DEPLOYMENT をサービスのデプロイ名に置き換えて実行します。

kubectl edit deployment/ESP-DEPLOYMENT

このコマンドを実行すると、GKE 構成の YAML が開き、デプロイを更新できます。ESP のバージョンを 1.0 に変更し、SERVICE_CONFIG_ID を新しい SERVICE_CONFIG_ID に更新して、デプロイを保存します。

containers:
    - name: esp
      image: gcr.io/endpoints-release/endpoints-runtime:1.0
      args: [
        "--http_port", "8080",
        "--backend", "localhost:8081",
        "--service", "SERVICE_NAME",
        "--version", "SERVICE_CONFIG_ID",
      ]

Compute Engine

この変更について、2017 年 1 月 2 日の ESP 1.0 のリリースで実装を予定しています。

現在 CORS を使用して API に対するクロスオリジン トラフィックを有効にしている場合は、ESP 1.0 へのアップグレード後に API 構成(OpenAPI 仕様または Swagger ファイル)の変更が必要になります。上記の「x-google-endpoints」スニペットを API の OpenAPI 構成に追加し、次のコマンドを使用して API 構成を再デプロイしてください。

gcloud service-management deploy openapi.yaml

上記の手順により、新しいサービス構成がサービス マネージャーに push されます。次の手順で必要になるため、新しい SERVICE_CONFIG_ID をメモしておいてください。

サービスを再デプロイする前に、次のコマンドを使用して VM のメタデータ エントリを更新する必要があります。

gcloud compute instances add-metadata --metadata=endpoints-service-name=SERVICE_NAME,endpoints-service-config-id=SERVICE_CONFIG_ID

その後、VM に SSH 接続し、次のコマンドを実行して ESP を再起動します。

sudo /etc/init.d/nginx restart

init.d スクリプトではなく start_esp.py スクリプトを使用して ESP を起動する場合は、ESP を停止し、新しい SERVICE_CONFIG_ID で start_esp.py コマンドを再実行します。

Compute Engine + Docker

この変更について、2017 年 1 月 2 日の ESP 1.0 のリリースで実装を予定しています。

現在 CORS を使用して API に対するクロスオリジン トラフィックを有効にしている場合は、ESP 1.0 へのアップグレード後に API 構成(OpenAPI 仕様または Swagger ファイル)の変更が必要になります。上記の「x-google-endpoints」スニペットを API の OpenAPI 構成に追加し、次のコマンドを使用して API 構成を再デプロイしてください。

gcloud service-management deploy openapi.yaml

このコマンドにより、新しいサービス構成が Google Service Management にプッシュされます。コマンドから返される API の新しい SERVICE_CONFIG_ID をメモしておいてください。これは次の手順で必要になります。

次に、サービスを再デプロイします。まず、次のコマンドを使用して現在の ESP インスタンス(例: 「esp」)を停止して削除します。現在の ESP インスタンスは、sudo docker ps コマンドを使用して確認できます。

sudo docker stop esp
sudo docker rm esp

その後、次のコマンドを使用して ESP を再デプロイします。-v オプションで新しい SERVICE_CONFIG_ID を指定してください。

sudo docker run --name=esp -d -p 80:8080 --link=echo:echo gcr.io/endpoints-release/endpoints-runtime:1.0 -s [SERVICE_NAME] -v [SERVICE_CONFIG_ID] -a echo:8081
このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

ご不明な点がありましたら、Google のサポートページをご覧ください。