.proto ファイルと gRPC API 構成ファイルを構成してからデプロイすると、API の管理に必要な情報が Cloud Endpoints で認識されるようになります。Endpoints の構成をデプロイするには、gcloud
endpoints services deploy コマンドを使用します。このコマンドは、Google の基礎的なサービス プラットフォームである Service Infrastructure を使用します。このプラットフォームは、Endpoints やその他のサービスで API やサービスを作成、管理するために使用されます。このページでは、構成ファイルを Endpoints にデプロイする方法を説明します。
要件
このページの説明は、次のことを前提としています。
自分が編集者またはオーナーの役割を持つ Google Cloud プロジェクトを作成済みであること。最初のデプロイ後に、より制限の厳しい Service Config 編集者の役割を付与できます。詳細については、API へのアクセス権の付与と取り消しをご覧ください。
以下を含む Endpoints の構成が完了していること。
カスタム ドメイン名（
example.comなど）を使用する場合は、gRPC 構成ファイルをデプロイする前にドメイン名を検証する必要があります。
Google Cloud CLI のデプロイの準備
gcloud コマンドライン ツールを使用して構成をデプロイします。コマンドの詳細については、gcloud リファレンスをご覧ください。
デプロイの準備を行うには:
- gcloud CLI をインストールして初期化する
- gcloud CLI を更新します。
gcloud components update
- gcloud CLI がデータやサービスにアクセスできるように承認されていることを確認します。
gcloud auth login
新しいブラウザタブが開き、アカウントの選択を求めるプロンプトが表示されます。
- デフォルト プロジェクトを設定します。
[YOUR-PROJECT-ID]を実際の GCP プロジェクト ID に置き換えます。gcloud config set project [YOUR-PROJECT-ID]
- API バックエンドを Kubernetes または Kubernetes Engine のいずれかにデプロイする場合は、次のコマンドを実行して、アプリケーションのデフォルト認証情報として使用する新しいユーザー認証情報を取得します。ユーザー認証情報は
kubectlを承認するために必要です。gcloud auth application-default login
新しいブラウザタブが開き、アカウントの選択を要求するプロンプトが表示されます。
構成ファイルのデプロイ
api_descriptor.pbファイルとapi_config.yamlファイルがあるディレクトリにいることを確認します。gcloudコマンドライン ツールが現在使用しているデフォルト プロジェクトが、エンドポイント構成をデプロイする Google Cloud プロジェクトであることを確認します。それには、次のコマンドを使用して返されるプロジェクト ID を確認してください。これは、間違ったプロジェクト内にサービスが作成されないようにするためです。gcloud config list project
デフォルト プロジェクトを変更する必要がある場合は、次のコマンドを実行します。
gcloud config set project YOUR_PROJECT_ID
- Google Cloud CLI を使用して、
proto descriptorファイルと構成ファイルをデプロイします。gcloud endpoints services deploy api_descriptor.pb api_config.yaml
サービスが作成され構成されるに従い、ターミナルには Service Management からの情報が出力されます。デプロイが完了すると、次のようなメッセージが表示されます。
Service Configuration [CONFIG_ID] uploaded for service [bookstore.endpoints.example-project.cloud.goog]
CONFIG_ID は、デプロイによって作成される一意の Endpoints サービス構成 ID です。例:
Service Configuration [2017-02-13r0] uploaded for service [bookstore.endpoints.example-project.cloud.goog]
上記の例では、
2017-02-13r0はサービス構成 ID で、bookstore.endpoints.example-project.cloud.googはサービス名です。サービス構成 ID は、日付スタンプとそれに続くリビジョン番号で構成されます。Endpoints の構成を同じ日に再デプロイすると、サービス構成 ID のリビジョン番号が増分されます。
サービスの構成が複数の YAML ファイルに定義されている場合には、これらのファイルをすべて deploy コマンドに渡します。たとえば、Bookstore の基本構成は api_config.yaml にありますが、api_config_http.yaml をデプロイすると、サービスで HTTP コード変換を有効にできます。これは、この機能の追加構成です。
gcloud endpoints services deploy api_descriptor.pb api_config.yaml api_config_http.yaml
YAML ファイルに矛盾する値が含まれていると、最後に指定したファイルの値で他のファイルの値が上書きされます。Endpoints で複数の YAML ファイルがどのように統合されるかについては、gRPC サービスを構成するをご覧ください。
エラー メッセージが表示された場合は、エラーのトラブルシューティングについて、Endpoints 構成のデプロイのトラブルシューティングをご覧ください。
再デプロイ
.proto またはサービス構成 YAML ファイルになんらかの変更を加えるたびに、ファイルを再デプロイしてください。これにより、Extensible Service Proxy（ESP）が API のサービス構成の最新バージョンを認識するようになります。すでに rollout オプションを managed に設定して ESP をデプロイしている場合は、ESP の再起動や再デプロイは不要です。rollout=managed オプションを指定すると、デプロイ済みの最新のサービス構成を使用するように ESP が構成されます。このオプションを指定すると、新しいサービス構成をデプロイしてから 5 分以内に ESP が変更を検出し、自動的に使用します。ESP が特定の構成 ID でなく、このオプションを使用するようにしてください。
最初の Endpoints 構成のデプロイ後に、ユーザー、サービス アカウント、グループに対して、Endpoints 構成を再デプロイできる役割を付与できます。詳細については、API へのアクセス権の付与と取り消しをご覧ください。