注: Go 1.11 は、2024 年 1 月 30 日にサポートが終了しました。既存の Go 1.11 アプリケーションは引き続き実行され、トラフィックを受信します。ただし、サポート終了日を過ぎると、ランタイムを使用するアプリケーションの再デプロイが App Engine によってブロックされることがあります。サポートされている最新バージョンの Go に移行することをおすすめします。

アプリケーションのテストとデプロイ

リージョン ID

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

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

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

ローカルでの実行

デプロイ前にアプリケーションの機能をテストするには、普段使用している開発ツールを使用して、アプリケーションをローカル環境で実行します。たとえば、go run コマンドを実行します。

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

アプリケーションをデプロイする前に、次のことを確認してください。

Google Cloud プロジェクトのオーナーが App Engine を有効にしていること。
ユーザーアカウントに必要な権限が含まれていること。

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

gcloud app deploy コマンドを使用して、アプリケーションを App Engine にデプロイします。

デプロイ中に、Cloud Build サービスが App Engine スタンダード環境で実行するアプリケーションのコンテナイメージを作成します。ビルドはアプリのリージョンに作成されます。詳細は、ビルドイメージの管理をご覧ください。

プログラムによってアプリをデプロイするには、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 リファレンスをご覧ください。

複数のサービスのデプロイ

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

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

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

複数のサービスをデプロイするための要件

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

ビルドログの表示

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

ファイルの無視

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

ビルドイメージの管理

新しいバージョンをデプロイするたびに、Cloud Build サービスによってコンテナイメージが作成されます。このコンテナイメージは、アプリのリージョンでビルドされ、App Engine スタンダード環境で動作します。

作成されたコンテナイメージは、Container Registry の app-engine-tmp/app フォルダに保存されます。これらのイメージをダウンロードして、任意の場所に保存できます。また、別の場所で実行することもできます。デプロイが完了したコンテナイメージは、App Engine ではもう必要でなくなります。なお、不要になったイメージは自動的に削除されないので、保存容量の上限に達する前に削除するとよいでしょう。Container Registry 内のイメージを管理する方法については、Container Registry のドキュメントをご覧ください。

アプリケーションの表示

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

gcloud app browse

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

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

新しいバージョンをデプロイしますが、トラフィックが新しいバージョンに自動的にルーティングされないようにするには、次のコマンドを実行します。
```
gcloud app deploy --no-promote
```
次の URL に移動して、新しいバージョンにアクセスします。

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

注: Google Cloud コンソールでバージョン ID を確認するか、--version flag でデプロイするときにバージョン ID を指定できます。また、デプロイ時に Google Cloud CLI でバージョン ID を出力することもできます。
これで、新しいバージョンを App Engine ランタイム環境でテストできるようになりました。ログを確認することでアプリケーションをデバッグできます。詳細については、アプリケーションログの書き込みをご覧ください。

App Engine は、https://PROJECT_ID.REGION_ID.r.appspot.com に送信されたリクエストを、トラフィックを受信するように構成済みのバージョンにルーティングします。
トラフィックが新しいバージョンに送信されるようにするには、Google Cloud コンソールでトラフィックを移行します。

バージョンの管理

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

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

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

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

ビルド環境変数の使用

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

ビルド環境変数は、buildpacks に構成情報を渡すことができるアプリと一緒にデプロイされる Key-Value ペアです。たとえば、コンパイラオプションをカスタマイズできます。こうしたビルド環境変数は、app.yaml ファイルの build_env_variables フィールドを構成することで追加や削除できます。

注: キーの先頭は大文字の ASCII 文字にする必要があります。キーには大文字の ASCII 文字、数字、アンダースコアのみ使用できます。GOOGLE_* 接頭辞を使用した変数キーの作成は避けてください。サポートされているすべての buildpacks 環境変数を表示する。

ローカル開発用サーバーの使用

dev_appserver を使用してアプリをローカルで実行し、本番環境の App Engine で動作するアプリケーションをシミュレートできます。この開発用サーバーは、アプリケーションが実行される環境を部分的にシミュレートします。このため、任意のスタンダード環境ランタイム用に作成されたアプリをテストできます。

Go 1.11 はサポートが終了しているため、最新バージョンの dev_appserver.py を使用してアプリケーションをローカルで実行することはできません。dev_appserver.py を引き続き使用するには、ローカル開発用サーバーの使用の手順を実行してください。

ローカル開発用サーバーの実行

アプリの app.yaml 構成ファイルを作成した後、dev_appserver.py コマンドを使用してローカル開発用サーバーを起動し、アプリをローカルで実行できます。

ユーザーアカウントのアクセス認証情報を取得するには、次のコマンドを実行します。
```
gcloud auth login
```
ローカルアプリケーションで、API アクセス用のユーザー認証情報の使用を一時的に許可します。
```
gcloud auth application-default login
```
ローカル開発用サーバーを起動するには:

app.yaml 構成ファイルを含むディレクトリで、dev_appserver.py コマンドを実行し、プロジェクト ID と app.yaml ファイルへのパスを指定します。
```
python2 DEVAPPSERVER_ROOT/google_appengine/dev_appserver.py/dev_appserver.py --application=PROJECT_ID app.yaml
```
ポートを変更する場合は、--port オプションを含めます。
```
python2 DEVAPPSERVER_ROOT/google_appengine/dev_appserver.py/dev_appserver.py --application=PROJECT_ID app.yaml --port=9999
```
DEVAPPSERVER_ROOT は、devapp_server.py のアーカイブバージョンを抽出するフォルダのパスに置き換えます。アーカイブバージョンの dev_appserver.py のダウンロードと使用の詳細については、ローカル開発用サーバーの使用をご覧ください。

dev_appserver.py コマンドのオプションについて詳しくは、ローカル開発用サーバーのオプションをご覧ください。
ローカル開発用サーバーが起動すると、開発環境がセットアップされ、requirements.txt ファイルにある依存関係が事前にインストールされます。
ローカル開発用サーバーが起動し、リクエストを待機します。ウェブブラウザで http://localhost:8080/ にアクセスして、アプリの動作を確認します。

--port オプションでカスタムポートを指定した場合は、そのポートでブラウザを開くようにしてください。
ローカルサーバーをコマンドラインから停止するには、Control-C キーを押します。

アプリケーションのランタイム環境の検出

コードが本番環境とローカル開発用サーバーのどちらで動作しているのかを確かめるには、GAE_ENV 環境変数を確認します。

if os.getenv('GAE_ENV', '').startswith('standard'):
  # Production in the standard environment
else:
  # Local execution.

Google Cloud サービスでのローカル開発用サーバーの使用

dev_appserver とその他の Google Cloud コンポーネントを統合できます。

Cloud クライアントライブラリ

Google Cloud クライアントライブラリの多くは、GOOGLE_CLOUD_PROJECT 環境変数（通常はご使用の Google Cloud プロジェクト ID）に依存しています。この値を確認するには、gcloud config list project コマンドを実行するか、Google Cloud コンソールでプロジェクトページを参照します。

この環境変数がローカルでの開発時に正しく設定されるようにするには、前述した例に示すように、--application=PROJECT_ID パラメータを使用して dev_appserver を初期化します。

クラウドエミュレータ

Cloud Datastore、Cloud Bigtable、Cloud Pub/Sub のエミュレータでアプリケーションをテストできます。

`requirements.txt` の自動再読み込みと `app.yaml` の変更

ローカル開発用サーバーは、requirements.txt ファイルにある依存関係を自動的にインストールします。dev_appserver では、app.yaml で構成された機能をテストすることもできます。たとえば、アプリの静的ファイルの処理機能をテストできます。dev_appserver が実行されている場合、requirements.txt と app.yaml を変更すると、アプリが自動的に再起動して変更が反映されます。依存関係がダウンロードされてインストールされる間、一時的な遅延が発生する可能性があります。

開発用サーバーでのインスタンス管理とルーティング

インスタンスのアドレスの検出

開発用サーバーは起動時に、すべての手動スケーリングのインスタンスを作成します。自動スケーリングおよび基本スケーリングサービスのインスタンスは動的に管理されます。サーバーは各サービスにポートを割り当て、クライアントはサーバーを使用して、ロードバランシングを行い、インスタンスを自動的に選択します。各サービスに対応するポートの割り当ては、サーバーのログメッセージストリームに表示されます。

次は、3 つのサービスを定義するアプリのポートです。

INFO Starting module "default" running at: http://localhost:8084
INFO Starting module "service1" running at: http://localhost:8082
INFO Starting module "service2" running at: http://localhost:8083

サービスのアドレス（たとえば http://localhost:8082/）を使用すると、サーバーはサービスのインスタンスを作成または選択し、そのインスタンスにリクエストを送信します。

サーバーは、サービスの各インスタンスに一意のポートを割り当てます。管理サーバーを使用して、これらのポートを検出できます。管理サーバーには一意のポートがあり、メッセージログで確認できます。

INFO Starting admin server at: http://localhost:8000

このアドレスにより、管理サーバーのコンソールに移動できます。[Instances] をクリックすると、アプリのインスタンスの動的な状態が表示されます。

手動インスタンスと基本インスタンスのそれぞれに、別々のエントリが表示されます。インスタンス番号は、各インスタンスの一意のポートアドレスとリンクしています。リンクをクリックすると、インスタンスに直接リクエストが送信されます。

ディスパッチファイル

アプリに dispatch.yaml ファイルが含まれている場合、ログメッセージストリームにはディスパッチポートが含まれます。

INFO Starting dispatcher running at: http://localhost:8080

このポートへのリクエストは、ディスパッチファイルのルールに従ってルーティングされます。サーバーでは、ホスト名を含む dispatch.yaml ファイルルール（url: "customer1.myapp.com/*"など）はサポートされません。相対パスのパターンを含むルール（url: "*/fun"）は機能します。そのため、http://localhost/fun/mobile のような URL を使用してインスタンスに接続できます。ホストベースのルールが含まれている dispatch.yaml ファイルを使用してアプリケーションを起動しようとすると、サーバーはログストリームでエラーを報告します。