API バックエンドをデプロイする

OpenAPI   |  gRPC

このページでは、API のバックエンド コードと Extensible Service Proxy（ESP）を Google Kubernetes Engine と Compute Engine にデプロイする方法について説明します。

デプロイの手順は API をホストするプラットフォームによって異なりますが、どのプラットフォームの場合も必ずサービス名を ESP に提供し、オプションでデプロイ済みの最新の Cloud Endpoints サービス構成を使用するよう ESP に指定します。この情報を使用して、ESP は API の Endpoints 構成を取得できます。これにより、ESP がリクエストとレスポンスをプロキシして、Cloud Endpoints が API を管理できるようになります。

前提条件

このページの説明は、次のことを前提としています。

• Google Cloud プロジェクトが作成されていること。
• Endpoints を構成済みであること。
• Endpoints 構成をデプロイ済みであること。

デプロイの準備

Compute Engine

Endpoints で API を管理するには、API 用のバックエンド サーバーコードと ESP をインストールして構成する必要があります。Container Registry から無料で入手できる ESP Docker イメージを実行できるようにするため、Compute Engine VM インスタンスに Docker をインストールする必要があります。

デプロイする前に:

API と ESP を Compute Engine にデプロイする前に、次の手順を実行してください。

1. VM インスタンスを作成、構成、起動します。
2. Docker Enterprise Edition（EE）または Docker Community Edition（CE）を VM インスタンスにインストールします。
3. バックエンド サーバーコード用の Docker コンテナを作成します。
4. コンテナを Artifact Registry に push するか、または別のレジストリに push します。

5. 次のことを正常に行えることを確認します。

   • VM インスタンスに接続します。
   • Docker イメージを実行して、VM インスタンス上でバックエンド サーバーを起動します。docker run リファレンスをご覧ください。
   • リクエストを API に送信します。

GKE

Google Cloud コンソールでクラスタを作成すると、クラスタのサービス アカウントに付与される OAuth スコープに、Endpoints に必要な次のスコープがデフォルトで組み込まれます。

• Service Control: 有効
• サービス管理: 読み取り専用

gcloud container clusters create コマンド、またはサードパーティの構成ファイルを使用してクラスタを作成する場合は、次のスコープを指定していることを確認してください。

• "https://www.googleapis.com/auth/servicecontrol"
• "https://www.googleapis.com/auth/service.management.readonly"

詳細については、アクセス スコープとはをご覧ください。

デプロイする前に:

デプロイ マニフェスト ファイルに小さなセクションを追加すれば、コンテナ化されたアプリケーションとともにコンテナ クラスタ上で ESP Docker イメージを実行できます。ESP を使用して API を GKE にデプロイする前に、次の手順を実行してください。

1. コンテナ化されたアプリケーションをコンテナ クラスタにデプロイします。GKE のドキュメントに記載されている一般的な手順は、次のとおりです。

   1. アプリケーションを Docker イメージにパッケージ化します。
   2. イメージをレジストリにアップロードします。
   3. コンテナ クラスタを作成します。
   4. アプリケーションをクラスタにデプロイします。
   5. アプリケーションをインターネットに公開します。

2. 次のことを正常に行えることを確認します。

   • API のサーバーを起動します。
   • リクエストを API に送信します。

API と ESP のデプロイ

Compute Engine

Docker を使用して API と ESP を Compute Engine にデプロイするには:

1. VM インスタンスに接続します。INSTANCE_NAME は、実際の VM インスタンスの名前に置き換えます。

   gcloud compute ssh INSTANCE_NAME
   

2. esp_net という独自のコンテナ ネットワークを作成します。

   sudo docker network create --driver bridge esp_net
   

3. バックエンド サーバーコードのイメージのインスタンスを実行し、esp_net コンテナ ネットワークに接続します。

   sudo docker run \
       --detach \
       --name=YOUR_API_CONTAINER_NAME \
       --net=esp_net \
       gcr.io/YOUR_PROJECT_ID/YOUR_IMAGE:1
   

   • YOUR_API_CONTAINER_NAME は、実際のコンテナ名に置き換えます。
   • YOUR_PROJECT_ID は、イメージを push したときに使用した Google Cloud プロジェクト ID に置き換えます。
   • YOUR_IMAGE は、イメージの名前に置き換えます。

4. API のサービス名を取得します。これは、サービス構成 YAML ファイルの name フィールドで指定した名前です。

5. ESP Docker イメージのインスタンスを実行します。

   sudo docker run \
       --detach \
       --name=esp \
       --publish=80:9000 \
       --net=esp_net \
       gcr.io/endpoints-release/endpoints-runtime:1 \
       --service=SERVICE_NAME \
       --rollout_strategy=managed \
       --http2_port=9000 \
       --backend=grpc://YOUR_API_CONTAINER_NAME:8000
   

   • SERVICE_NAME は、実際のサービス名に置き換えます。
   • YOUR_API_CONTAINER_NAME は、API のコンテナの名前に置き換えます。

   --rollout_strategy=managed オプションを指定すると、デプロイ済みの最新のサービス構成を使用するように ESP が構成されます。このオプションを指定すると、新しいサービス構成をデプロイしてから 5 分以内に ESP が変更を検出し、自動的に使用します。ESP が特定の構成 ID でなく、このオプションを使用するようにしてください。

特定の構成 ID を使用するように ESP を構成する場合は、次の操作を行います。

1. --version オプションを追加し、その値を特定の構成 ID に設定します。

2. --rollout_strategy=managed オプションを削除するか、--rollout_strategy を fixed に設定します。fixed オプションを指定すると、--version で指定したサービス構成を使用するように ESP が構成されます。

3. docker run コマンドをもう一度実行します。

--rollout_strategy=managed と --version の両方のオプションを指定すると、ESP は --version で指定した構成で起動しますが、その後は管理モードで実行され、最新の構成を取得します。

ESP が特定の構成 ID をあまり長期間使用しないようにすることをおすすめします。これは、更新したサービス構成をデプロイするときに、新しい構成を使用するために ESP を再起動する必要があるためです。

特定の構成 ID を削除するには:

1. docker run の ESP フラグで、--version オプションを削除します。

2. --rollout_strategy=managed オプションを追加します。

3. ESP を再起動するため、docker run コマンドを実行します。

ESP の起動時に指定できるオプションの完全なリストについては、ESP 起動オプションをご覧ください。

GKE

ESP を GKE にデプロイするには:

1. API のサービス名を取得します。

2. デプロイ マニフェスト ファイル（deployment.yaml として参照されます）を開き、次のコードを containers セクションに追加します。

         containers:
         - name: esp
           image: gcr.io/endpoints-release/endpoints-runtime:1
           args: [
             "--http2_port=9000",
             "--service=SERVICE_NAME",
             "--rollout_strategy=managed",
             "--backend=grpc://127.0.0.1:8000"
           ]
           ports:
             - containerPort: 9000
   

   SERVICE_NAME は、API のサービス名に置き換えます。

3. kubectl create コマンドを使用して、Kubernetes Service を起動します。

       kubectl create -f deployment.yaml
   

特定の構成 ID を使用するように ESP を構成する場合は、次の操作を行います。

1. デプロイ マニフェスト ファイルに --version オプションを追加し、特定の構成 ID を設定します。

2. --rollout_strategy=managed を削除するか、--rollout_strategy を fixed に設定します。fixed オプションを指定すると、--version で指定したサービス構成を使用するように ESP が構成されます。

3. Kubernetes サービスを起動します。kubectl create -f deployment.yaml

--rollout_strategy=managed と --version の両方のオプションを指定すると、ESP は --version で指定した構成で起動しますが、その後は管理モードで実行され、最新の構成を取得します。

ESP が特定の構成 ID をあまり長期間使用しないようにすることをおすすめします。これは、更新したサービス構成をデプロイするときに、新しい構成を使用するために ESP を再起動する必要があるためです。

特定の構成 ID を削除するには:

1. デプロイ マニフェスト ファイルで、--version オプションを削除します。

2. --rollout_strategy=managed 個追加します。

3. Kubernetes サービスを起動します。kubectl create -f deployment.yaml

ESP の起動時に指定できるオプションの完全なリストについては、ESP 起動オプションをご覧ください。

API の活動を追跡する

ESP と API バックエンドをデプロイした後は、curl や Postman のようなツールを使用して、API にリクエストを送信できます。正常なレスポンスが返されない場合は、レスポンス エラーのトラブルシューティングをご覧ください。

いくつかのリクエストを送信した後、次のことが可能になります。

• API のアクティビティ グラフを表示するには、[エンドポイント] > [サービス] に移動します。グラフにリクエストが反映されるまでしばらくかかります。

  [Endpoints] の [サービス] ページに移動

• Cloud Logging ページで API のリクエスト ログを確認します。

  [ログ エクスプローラ] ページに移動

次のステップ

• Compute Engine での Endpoints のトラブルシューティング
• GKE での Endpoints のトラブルシューティング