カスタム ランタイムの構築

カスタム ランタイムでは、すべてのフレキシブル環境でサポートされている別の言語の実装や、Google から提供されるイメージのカスタマイズを行うこともできます。また、受信 HTTP リクエストを処理可能な任意の言語でコードを記述することもできます（例）。カスタム ランタイムを使用すると、フレキシブル環境でインフラストラクチャのスケーリング、モニタリング、ロード バランシングを管理できるため、アプリケーションの構築に集中できます。

カスタム ランタイムを作成するには、次のことが必要です。

app.yaml ファイルの提供

app.yaml 構成ファイルには、少なくとも次の設定が含まれている必要があります。

runtime: custom
env: flex

アプリの設定について詳しくは、app.yaml によるアプリの構成をご覧ください。

Dockerfile の作成

Dockerfile の作成に関する包括的なドキュメントは、Docker ウェブサイトで参照できます。カスタム ランタイムを使用している場合は、独自のベースイメージを使用するか、Google のベースイメージを使用するにかかわらず、Dockerfile が必要になります。

ベースイメージの指定

Dockerfile の最初のコマンドは、通常はベースイメージを指定する FROM コマンドです。ベースイメージは、コンテナの作成とアプリケーションのビルドに使用されます。独自のベースイメージを作成することも、DockerHub などのコンテナ レジストリからベースイメージを選択することもできます。

Dockerfile の名前付けと配置

一般的に、Dockerfile は Dockerfile という名前で、対応する app.yaml ファイルと同じディレクトリに配置されます。ただし、ツール環境に応じて要件が異なる場合もあります。たとえば、Maven、Gradle、Eclipse、IntelliJ プラグインなどの Cloud SDK ベースの Java ツールの場合、Dockerfile を src/main/docker/Dockerfile に配置し、app.yaml ファイルを src/main/appengine/app.yaml に配置する必要があります。詳しくは、ツール環境のドキュメントをご覧ください。

必要なコード構造

このセクションでは、Google が提供するベースイメージと独自のベースイメージのどちらを使用するかを問わず、コードに実装する必要がある動作を説明します。

ポート 8080 のリッスン

App Engine のフロントエンドは、受信リクエストをポート 8080 の適切なモジュールにルーティングします。アプリケーション コードが 8080 でリッスンしていることを確認する必要があります。

ライフサイクル イベントの処理

フレキシブル環境では、特定のライフサイクル イベントがアプリケーションに定期的に送信されます。

アプリケーションのシャットダウン

インスタンスをシャットダウンする必要がある場合、新しい受信リクエストは他のインスタンス（存在する場合）に転送され、現在処理されているリクエストを完了するための時間が与えられます。インスタンスをシャットダウンする場合、フレキシブル環境では通常、STOP（SIGTERM）シグナルをアプリコンテナに送信します。アプリがこのイベントに応答する必要はありませんが、これを使用することで、コンテナをシャットダウンする前に必要なクリーンアップ操作を実行できます。通常の状態では、システムはアプリが停止するまで最大 30 秒待機してから、KILL（SIGKILL）シグナルを送信し、インスタンスを直ちにシャットダウンします。

まれに、停止によって App Engine が 30 秒のシャットダウン時間を確保できず、インスタンスが終了する前に STOP シグナルと KILL シグナルが送信されない可能性があります。この可能性に対応するには、インスタンスの状態を定期的にチェックし、信頼できるデータストアとしてではなく、主にメモリ内キャッシュとして使用するようにします。

ヘルスチェック リクエスト

定期的なヘルスチェック リクエストを使用すると、VM インスタンスが正常にデプロイされたことを確認できます。また、実行中のインスタンスが正常なステータスを維持していることも確認できます。

カスタム ランタイムのビルドとデプロイ

app.yaml ファイルと DOCKER ファイルを構成したら、そのコンテナ イメージを App Engine にビルドしてデプロイできます。

また、Container Registry に保存されているカスタム ランタイムのビルド済みコンテナ イメージをデプロイすることもできます。たとえば、Cloud Build を使用してイメージを別々にビルドし、それらのイメージを Artifact Registry に格納できます。

アプリケーションと Google Cloud Platform の統合

カスタム ランタイムで動作するアプリケーションは、Google Cloud クライアント ライブラリを使用して Google Cloud Platform サービスにアクセスできます。カスタム ランタイムのアプリケーションでは、標準 API を通じてサードパーティのサービスを利用することもできます。

Google Cloud Platform サービスによる認証

アプリケーションのデフォルト認証情報を使用することで、Google API の認証と呼び出しを簡単に行うことができます。

アプリケーションで Cloud Build を使用して Docker イメージをコンパイルする場合は、cloudbuild ネットワークにアプリケーションのデフォルト認証情報をホストし、関連付けられた Google Cloud サービスが認証情報を自動的に検索できるようにします。

認証の詳細については、Google での認証をご覧ください。

Logging

App Engine で実行中のアプリケーションにリクエストが送信されると、リクエストとレスポンスの詳細が自動的に記録されます。そのログは、Google Cloud Console のログ エクスプローラで確認できます。

アプリケーションがリクエストを処理するときに、独自のロギング メッセージを stdout と stderr に書き込むこともできます。これらのファイルは自動的に収集され、ログ エクスプローラで表示できます。サイズを制限するために、stdout と stderr への最新のエントリのみが保持されます。

.log または .json で終わるファイルを使用して、/var/log/app_engine/custom_logs にカスタムログを書き込むこともできます。

アプリケーション コンテナにサードパーティのエージェントを含める場合は、stdout と stderr に、またはカスタムログにログを記録するようにエージェントを構成していることを確認します。これにより、これらのエージェントによって生成されたエラーが Cloud Logging で確認できるようになります。

アプリのリクエストログとアプリケーション ログは Cloud Logging エージェントによって収集され、最長 90 日間、最大 1 GB まで保存されます。ログを長期間保存する場合や 1 GB を超えるサイズを保存する場合は、Cloud Storage にログをエクスポートできます。ログをさらに処理するために、BigQuery や Pub/Sub へエクスポートすることもできます。

その他のログも入手できます。デフォルトで構成されているログの一部を以下に挙げます。

ログ名 ペイロード タイプ 目的
crash.log text 設定が失敗したときに記録される情報。アプリケーションを実行できなかった場合は、このログを確認してください。
monitoring.* text Cloud Monitoring にデータを公開している Docker コンテナから取得した情報。
shutdown.log text シャットダウン時に記録された情報。
stdout テキスト アプリからの標準出力。
stderr テキスト コンテナからの標準エラー。
syslog テキスト Docker コンテナ外部の VM システムログ。