アプリケーションをテストしてデプロイする

リージョン ID

REGION_ID は、アプリの作成時に選択したリージョンに基づいて Google が割り当てる省略形のコードです。一部のリージョン ID は、一般的に使用されている国や州のコードと類似しているように見える場合がありますが、このコードは国または州に対応するものではありません。2020 年 2 月以降に作成されたアプリの場合、REGION_ID.r は App Engine の URL に含まれています。この日付より前に作成されたアプリの場合、URL のリージョン ID は省略可能です。

詳しくは、リージョン ID をご覧ください。

アプリケーションをローカルで実行し、App Engine にデプロイしてテストする方法を説明します。

ローカルで実行する

デプロイ前にアプリケーションをテストするには、普段使用している開発ツールを使用して、アプリケーションをローカル環境で実行します。

アプリケーションをデプロイする前に

アプリケーションをデプロイする前に:

アプリケーションのデプロイ

gcloud app deploy コマンドを使用して、アプリケーションを App Engine にデプロイします。デプロイ中に、Cloud Build サービスがスタンダード環境で実行するアプリケーションのコンテナ イメージを作成します。各ビルドは、Google Cloud プロジェクトと同じリージョンで実行されます。詳細については、ビルドイメージを管理するをご覧ください。

プログラムによってアプリをデプロイする場合は、Admin API を使用します。

サービスをデプロイする

アプリケーションを App Engine にデプロイするには、アプリケーションのサービスの各バージョンと、それぞれの構成ファイルをデプロイします。

アプリケーションのサービスのバージョンをデプロイするには、サービスの app.yaml ファイルがあるディレクトリから次のコマンドを実行します。

gcloud app deploy

このコマンドでファイルを指定しないと、現在のディレクトリにある app.yaml ファイルのみがデプロイされます。デフォルトで、deploy コマンドは、デプロイしたバージョンの一意の ID を生成します。そのバージョンを Google Cloud CLI で使用するように構成した Google Cloud プロジェクトにデプロイし、すべてのトラフィックを新しいバージョンに転送します。

特定のファイルを対象にするか、追加のパラメータを指定すると、コマンドのデフォルトの動作を変更できます。

  • サービスの他の構成ファイルをデプロイするには、各ファイルを個別にターゲットとして指定してデプロイする必要があります。例:
    gcloud app deploy cron.yaml
    gcloud app deploy dispatch.yaml
    gcloud app deploy index.yaml
    
  • 独自のバージョン ID を指定するには、--version フラグを使用します。
  • トラフィックが新しいバージョンに自動的にルーティングされないようにするには、--no-promote フラグを使用します。
  • 特定の Google Cloud プロジェクトにデプロイするには、--project フラグを使用します。

たとえば、app.yaml ファイルで定義されているサービスを特定の Google Cloud プロジェクトにデプロイし、独自のバージョン ID を割り当て、トラフィックが新しいバージョンにルーティングされないようにするには、次のコマンドを実行します。

gcloud app deploy --project PROJECT_ID --version VERSION_ID --no-promote

このコマンドの詳細については、gcloud app deploy リファレンスをご覧ください。

複数のサービスをデプロイする

アプリケーションを構成する複数のサービスをデプロイまたは更新する場合にも、同じデプロイ コマンドを使用します。

開始する前に:

  • 最初にアプリケーションのバージョンの 1 つを default サービスにデプロイする必要があります。これで、後続のサービスを作成してデプロイできるようになります。
  • 各サービスの ID は、対応する app.yaml 構成ファイルで指定する必要があります。サービス ID を指定するには、各構成ファイルに service 要素の定義を追加します。この要素の定義が構成ファイル内にないと、デフォルトでバージョンのデプロイ先は default サービスとなります。

複数のサービスをデプロイする場合は、各サービスの app.yaml ファイルを個別にデプロイします。次のように、1 つの gcloud app deploy コマンドで、複数のファイルを指定できます。

gcloud app deploy service1/app.yaml service2/app.yaml

ビルドログを表示

Cloud Build がストリーミングしたビルドとデプロイのログは、Google Cloud コンソールの Cloud Build のビルド履歴セクションで確認できます。アプリのリージョンのビルドを表示するには、[リージョン] メニューを使用してリージョンでフィルタします。

ビルドイメージを管理する

新しいバージョンをデプロイするたびに、次の処理が行われます。

  1. App Engine は、Cloud Build サービスを使用してコンテナ イメージを作成します。

  2. Cloud Build は、アプリのリージョンでコンテナ イメージをビルドし、App Engine スタンダード環境で実行します。

  3. App Engine は、ビルドされたコンテナ イメージを Artifact Registry に保存します。これらのイメージをダウンロードして、別の場所に保存する、または別の場所で実行できます。

デプロイが完了したコンテナ イメージは、App Engine ではもう必要でなくなります。コンテナ イメージは自動的に削除されません。保存容量の上限に達する前に、不要な画像を削除することをおすすめします。ただし、将来イメージが必要になった場合や、イメージのコピーを保持する場合は、削除する前にコピーをエクスポートする必要があります。Artifact Registry でのイメージの管理について詳しくは、イメージを管理するをご覧ください。

ファイルを無視する

.gcloudignore ファイルを使用すると、サービスをデプロイするときに App Engine にアップロードしないファイルとディレクトリを指定できます。これは、デプロイ時にアップロードする必要のないビルド アーティファクトやその他のファイルを無視する場合に便利です。

アプリケーションを表示する

アプリケーションを App Engine にデプロイした後、次のコマンドを実行してブラウザを起動できます。https://PROJECT_ID.REGION_ID.r.appspot.com にアクセスすると、アプリケーションが表示されます。

gcloud app browse

トラフィック移行前の App Engine でのテスト

新しいバージョンを構成してトラフィックを受信する前に、App Engine でテストを行うことができます。たとえば、default サービスの新しいバージョンをテストする手順は次のとおりです。

  1. 新しいバージョンをデプロイしますが、トラフィックが新しいバージョンに自動的にルーティングされないようにするには、次のコマンドを実行します。

    gcloud app deploy --no-promote

  2. 次の URL に移動して、新しいバージョンにアクセスします。

    https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com

    これで、新しいバージョンを App Engine ランタイム環境でテストできるようになりました。ログを確認することでアプリケーションをデバッグできます。詳細については、アプリケーション ログの書き込みをご覧ください。

    App Engine は、https://PROJECT_ID.REGION_ID.r.appspot.com に送信されたリクエストを、トラフィックを受信するように構成済みのバージョンに転送します。

  3. トラフィックが新しいバージョンに送信されるようにするには、Google Cloud コンソールでトラフィックを移行します。

    バージョンの管理

    デプロイしたバージョンを選択して、[トラフィックを移行] をクリックします。

同じ手順で他のサービスの新しいバージョンをテストできます。この場合、上記の URL の default をサービスの名前に置き換えます。

https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com

特定のサービスとバージョンをターゲットにする方法については、リクエストのルーティング方法をご覧ください。

ビルド環境変数を使用する

Buildpack をサポートするランタイム用のビルド環境変数を設定することもできます。

ビルド環境変数は、アプリのデプロイに使用する Buildpack の構成に指定できる Key-Value ペアです。たとえば、コンパイラ オプションを指定できます。

始める前に、次のことを行います。

  • キーの先頭は大文字の ASCII 文字にする必要があります。キーには大文字の ASCII 文字、数字、アンダースコアのみ使用できます。
  • 接尾辞に GOOGLE_* キーを持つ変数は作成しないでください。
  • 次のキーは Google で使用するために予約されています。
    • GOOGLE_RUNTIME
    • GOOGLE_RUNTIME_VERSION
    • GOOGLE_ENTRYPOINT
    • GOOGLE_DEVMODE
  • Buildpack でサポートされている任意の鍵を使用できます。

Buildpack で環境変数を使用するには、app.yaml ファイルで build_env_variables フィールドを指定します。

Buildpack の詳細については、こちらをご覧ください。

Cloud Trace を使用する

Cloud Trace は、リクエストがアプリケーションを通じてどのように伝播するかを把握するために役立ちます。リクエストごとの詳しいレイテンシ情報の分析や、アプリケーション全体のレイテンシの確認などができます。

Cloud Trace でトレースの詳細を表示するには、トレースを検索して調査するの説明に従います。トレース エクスプローラでフィルタを使用して、特定の App Engine サービスやバージョンでトレースをフィルタできます。