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

このページでは、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 をインストールして構成する必要があります。Compute Engine VM インスタンスに Docker をインストールして、Container Registry から無料で入手できる ESP Docker イメージを実行できるようにする必要があります。

デプロイする前に:

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

  1. VM インスタンスを作成、構成、起動します。
  2. Docker Enterprise Edition(EE)または Docker Community Edition(CE)を VM インスタンスにインストールします。
  3. バックエンド サーバーコード用の Docker コンテナを作成します。
  4. コンテナを Container Registry に push するか、別のレジストリに push します。
  5. 次のことを正常に行えることを確認します。

GKE

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

  • Service Control: 有効
  • Service Management: 読み取り専用

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_strategyfixed に設定します。fixed オプションを指定すると、--version で指定したサービス構成を使用するように ESP が構成されます。

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

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

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_strategyfixed に設定します。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 にリクエストを送信できます。正常なレスポンスが返されない場合は、レスポンス エラーのトラブルシューティングをご覧ください。

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

次のステップ