このページでは、API のバックエンド コードと Extensible Service Proxy(ESP)を Google Kubernetes Engine と Compute Engine にデプロイする方法について説明します。
デプロイの手順は API をホストするプラットフォームによって異なりますが、どのプラットフォームの場合も必ずサービス名を ESP に提供し、オプションでデプロイ済みの最新の Cloud Endpoints サービス構成を使用するよう ESP に指定します。この情報を使用して、ESP は API の Endpoints 構成を取得できます。これにより、ESP がリクエストとレスポンスをプロキシして、Cloud Endpoints が API を管理できるようになります。
前提条件
このページの説明は、次のことを前提としています。
デプロイの準備
Compute Engine
Endpoints で API を管理するには、API 用のバックエンド サーバーコードと ESP をインストールして構成する必要があります。Container Registry から無料で入手できる ESP Docker イメージを実行できるようにするため、Compute Engine VM インスタンスに Docker をインストールする必要があります。
デプロイする前に:
API と ESP を Compute Engine にデプロイする前に、次の手順を実行してください。
- VM インスタンスを作成、構成、起動します。
- Docker Enterprise Edition(EE)または Docker Community Edition(CE)を VM インスタンスにインストールします。
- バックエンド サーバーコード用の Docker コンテナを作成します。
- コンテナを Container Registry に push するかまたは別のレジストリに push します。
次のことを正常に行えることを確認します。
- 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 にデプロイする前に、次の手順を実行してください。
コンテナ化されたアプリケーションをコンテナ クラスタにデプロイします。GKE のドキュメントに記載されている一般的な手順は、次のとおりです。
- アプリケーションを Docker イメージにパッケージ化します。
- イメージをレジストリにアップロードします。
- コンテナ クラスタを作成します。
- アプリケーションをクラスタにデプロイします。
- アプリケーションをインターネットに公開します。
次のことを正常に行えることを確認します。
- API のサーバーを起動します。
- リクエストを API に送信します。
API と ESP のデプロイ
Compute Engine
Docker を使用して API と ESP を Compute Engine にデプロイするには:
VM インスタンスに接続します。
INSTANCE_NAME
は、実際の VM インスタンスの名前に置き換えます。gcloud compute ssh INSTANCE_NAME
esp_net
という独自のコンテナ ネットワークを作成します。sudo docker network create --driver bridge esp_net
バックエンド サーバーコードのイメージのインスタンスを実行し、
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
は、イメージの名前に置き換えます。
API のサービス名を取得します。これは、サービス構成 YAML ファイルの
name
フィールドで指定した名前です。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 を構成する場合は、次の操作を行います。
--version
オプションを追加し、その値を特定の構成 ID に設定します。--rollout_strategy=managed
オプションを削除するか、--rollout_strategy
をfixed
に設定します。fixed
オプションを指定すると、--version
で指定したサービス構成を使用するように ESP が構成されます。docker run
コマンドをもう一度実行します。
--rollout_strategy=managed
と --version
の両方のオプションを指定すると、ESP は --version
で指定した構成で起動しますが、その後は管理モードで実行され、最新の構成を取得します。
ESP が特定の構成 ID をあまり長期間使用しないようにすることをおすすめします。これは、更新したサービス構成をデプロイするときに、新しい構成を使用するために ESP を再起動する必要があるためです。
特定の構成 ID を削除するには:
docker run
の ESP フラグで、--version
オプションを削除します。--rollout_strategy=managed
オプションを追加します。ESP を再起動するため、
docker run
コマンドを実行します。
ESP の起動時に指定できるオプションの完全なリストについては、ESP 起動オプションをご覧ください。
GKE
ESP を GKE にデプロイするには:
API のサービス名を取得します。
デプロイ マニフェスト ファイル(
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 のサービス名に置き換えます。kubectl create
コマンドを使用して、Kubernetes Service を起動します。kubectl create -f deployment.yaml
特定の構成 ID を使用するように ESP を構成する場合は、次の操作を行います。
デプロイ マニフェスト ファイルに
--version
オプションを追加し、特定の構成 ID を設定します。--rollout_strategy=managed
を削除するか、--rollout_strategy
をfixed
に設定します。fixed
オプションを指定すると、--version
で指定したサービス構成を使用するように ESP が構成されます。Kubernetes サービスを起動します。
kubectl create -f deployment.yaml
--rollout_strategy=managed
と --version
の両方のオプションを指定すると、ESP は --version
で指定した構成で起動しますが、その後は管理モードで実行され、最新の構成を取得します。
ESP が特定の構成 ID をあまり長期間使用しないようにすることをおすすめします。これは、更新したサービス構成をデプロイするときに、新しい構成を使用するために ESP を再起動する必要があるためです。
特定の構成 ID を削除するには:
デプロイ マニフェスト ファイルで、
--version
オプションを削除します。--rollout_strategy=managed
個追加します。Kubernetes サービスを起動します。
kubectl create -f deployment.yaml
ESP の起動時に指定できるオプションの完全なリストについては、ESP 起動オプションをご覧ください。
API の活動を追跡する
ESP と API バックエンドをデプロイした後は、curl
や Postman のようなツールを使用して、API にリクエストを送信できます。正常なレスポンスが返されない場合は、レスポンス エラーのトラブルシューティングをご覧ください。
いくつかのリクエストを送信した後、次のことが可能になります。
API のアクティビティ グラフを表示するには、[エンドポイント] > [サービス] に移動します。グラフにリクエストが反映されるまでしばらくかかります。
Cloud Logging ページで API のリクエスト ログを確認します。