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

このページでは、API のバックエンド コードと Extensible Service Proxy(ESP)を Google Kubernetes Engine、Compute Engine、App Engine フレキシブル環境にデプロイする方法について説明します。

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

前提条件

前提として、このページでは次の点を想定しています。

デプロイの準備

App Engine

Endpoints で管理される API をデプロイする手順は、App Engine フレキシブル環境にアプリケーションをデプロイする場合とほぼ同じですが、構成手順が少し多くなります(後述)。App Engine のドキュメントに従って、次のことを行います。

API を App Engine にデプロイするには、gcloud app deploy コマンドを使用します。このコマンドは、Container Builder サービスを使用してコンテナ イメージを自動的にビルドし、そのイメージを App Engine フレキシブル環境にデプロイします。

デプロイする前に:

Compute Engine

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

デプロイする前に:

API と ESP を Compute Engine にデプロイする前に行う必要がある手順の概要を次に示します。一般的に、Compute Engine でバックエンド サーバーコードを実行するために通常行うすべての手順を行います。

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

GKE

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

  • サービス コントロール: 有効
  • サービス管理: 読み取り専用

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

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

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

デプロイする前に:

デプロイ マニフェスト ファイルに小さなセクションを追加することで、コンテナ化されたアプリケーションとともにコンテナ クラスタ上で ESP Docker イメージを実行できます。以下は、API と ESP を GKE にデプロイする前に行う必要がある手順の概要です。一般に、GKE でバックエンド サーバーコードを実行するために通常行うすべての手順を行います。

  1. コンテナ化されたアプリケーションをコンテナ クラスタにデプロイします。GKE のドキュメントに記載されている一般的な手順は、次のとおりです。
    1. アプリを Docker イメージにパッケージ化します。
    2. イメージをレジストリにアップロードします。
    3. コンテナ クラスタを作成します。
    4. アプリをクラスタにデプロイします。
    5. アプリをインターネットに公開します。
  2. 次のことを正常に行えることを確認します。
    • API のサーバーを起動します。
    • リクエストを API に送信します。

API と ESP のデプロイ

App Engine

App Engine に API と ESP をデプロイするには:

  1. API のサービス名を取得します。これは、OpenAPI ドキュメントの host フィールドに指定した名前と同じです。
  2. app.yaml ファイルを編集して、サービス名を含む endpoints_api_service というセクションを追加します。チュートリアルapp.yaml ファイルをモデルとして使用できます。
    Python
    endpoints_api_service:
      # The following values are to be replaced by information from the output of
      # 'gcloud endpoints services deploy openapi-appengine.yaml' command.
      name: ENDPOINTS-SERVICE-NAME
      rollout_strategy: managed
    Go
    endpoints_api_service:
      # The following values are to be replaced by information from the output of
      # 'gcloud endpoints services deploy openapi-appengine.yaml' command.
      name: ENDPOINTS-SERVICE-NAME
      rollout_strategy: managed
    PHP
    endpoints_api_service:
      # The following values are to be replaced by information from the output of
      # 'gcloud endpoints services deploy openapi-appengine.yaml' command. If you have
      # previously run the deploy command, you can list your existing configuration
      # ids using the 'configs list' command as follows:
      #
      #     gcloud endpoints configs list --service=YOUR-PROJECT-ID.appspot.com
      #
      name: ENDPOINTS-SERVICE-NAME
      rollout_strategy: managed
    Ruby
    endpoints_api_service:
      # The following values are to be replaced by information from the output of
      # 'gcloud endpoints services deploy openapi-appengine.yaml' command.
      name: ENDPOINTS-SERVICE-NAME
      rollout_strategy: managed
    NodeJS
    endpoints_api_service:
      # The following values are to be replaced by information from the output of
      # 'gcloud endpoints services deploy openapi-appengine.yaml' command.
      name: ENDPOINTS-SERVICE-NAME
      rollout_strategy: managed

    ENDPOINTS-SERVICE-NAME は、API のサービス名に置き換えます。次に例を示します。

    endpoints_api_service:
      name: example-project-12345.appspot.com
      rollout_strategy: managed
      

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

    アプリケーションがマイクロサービスに基づいている場合は、すべての app.yaml ファイルに endpoints_api_service セクションを含める必要があります。

  3. app.yaml ファイルを保存します。
  4. バックエンド コードと ESP を App Engine にデプロイします。
    gcloud app deploy
    

endpoints_api_service セクションを app.yaml ファイルに追加したので、gcloud app deploy コマンドは App Engine フレキシブル環境とは別のコンテナに ESP をデプロイして構成します。すべてのリクエスト トラフィックは ESP 経由でルーティングされ、ESP はバックエンド サーバーコードを実行するコンテナとの間でリクエストとレスポンスの送受信を行います。

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

  1. app.yaml ファイルの endpoints_api_service セクションに config_id フィールドを追加し、その値を特定の構成 ID に設定します。
  2. rollout_strategy: managed を削除するか、rollout_strategyfixed に設定します。fixed オプションを使用すると、ESP は、config_id に指定されたサービス構成を使用します。
  3. gcloud app deploy を実行して、API と ESP を再デプロイします。

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

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

  1. app.yaml ファイルから config_id オプションを削除します。
  2. rollout_strategy: managed オプションを追加します。
  3. gcloud app deploy コマンドを実行します。

rollout_strategy: managed オプションを使用する場合は、app.yaml ファイルに config_id: YOUR_SERVICE_CONFIG_ID を含めないでください。gcloud app deploy で次のエラーが発生します。

config_id is forbidden when rollout_strategy is set to "managed".

API を App Engine フレキシブル環境に初めてデプロイする場合、仮想マシン(VM)や他のインフラストラクチャが設定されていると、遅延が発生することがあります。詳細については、App Engine ドキュメントのデプロイの成功を確認するをご覧ください。

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.0
    • YOUR_API_CONTAINER_NAME は、コンテナ名に置き換えます。
    • YOUR_PROJECT_ID は、イメージを push したときに使用した GCP プロジェクト ID に置き換えます。
    • YOUR_IMAGE は、実際のイメージ名に置き換えます。
  4. API のサービス名を取得します。これは、OpenAPI ドキュメントの host フィールドに指定した名前と同じです。
  5. ESP Docker イメージのインスタンスを実行します。
    sudo docker run \
        --name=esp \
        --detach \
        --publish=80:8080 \
        --net=esp_net \
        gcr.io/endpoints-release/endpoints-runtime:1 \
        --service=SERVICE_NAME \
        --rollout_strategy=managed \
        --backend=YOUR_API_CONTAINER_NAME:8080
    • SERVICE_NAME は、実際のサービス名に置き換えます。
    • YOUR_API_CONTAINER_NAME は、API のコンテナ名に置き換えます。

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

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

  1. --version オプションを追加し、その値を特定の構成 ID に設定します。
  2. --rollout_strategy=managed オプションを削除するか、--rollout_strategyfixed に設定します。fixed オプションを使用すると、ESP は、--version に指定されたサービス構成を使用します。
  3. docker run コマンドを再度実行します。

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

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

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

  1. docker run の ESP フラグで、 --version オプションを削除します。
  2. --rollout_strategy=managed オプションを追加します。
  3. docker run コマンドを発行して ESP を再起動します。

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

GKE

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

  1. API のサービス名を取得します。これは、OpenAPI ドキュメントの host フィールドに指定した名前と同じです。
  2. デプロイ マニフェスト ファイル(deployment.yaml ファイル)を開き、次のコードを containers セクションに追加します。
    containers:
    - name: esp
      image: gcr.io/endpoints-release/endpoints-runtime:1
      args: [
        "--http_port=8081",
        "--backend=127.0.0.1:8080",
        "--service=SERVICE_NAME",
        "--rollout_strategy=managed"
      ]

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

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

  3. kubectl create コマンドを使用して、Kubernetes サービスを起動します。
    kubectl create -f deployment.yaml

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

  1. デプロイメント マニフェスト ファイルに --version オプションを追加し、特定の構成 ID を設定します。
  2. --rollout_strategy=managed を削除するか、--rollout_strategyfixed に設定します。fixed オプションを使用すると、ESP は、--version に指定されたサービス構成を使用します。
  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 へリクエストを送信できます。正常なレスポンスが返されない場合は、レスポンス エラーのトラブルシューティングをご覧ください。

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

次のステップ

このページは役立ちましたか?評価をお願いいたします。

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

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