モジュール 5: Cloud Buildpacks を使用して Google App Engine から Cloud Run に移行する

1. 概要

この一連の Codelab（ご自分のペースで進められる実践型のチュートリアル）は、一連の移行についてガイダンスを実施することにより、Google App Engine（標準）のデベロッパーがアプリをモダナイズできるよう支援することを目的としています。それが完了したら、ユーザーは、Cloud Run、App Engine への Google Cloud のコンテナ ホスティング姉妹サービス、その他のコンテナ ホスティング サービス用に明示的にコンテナ化することで、アプリの移植性を高めることができます。

このチュートリアルでは、Docker の代替手段である Cloud Buildpacks を使用して、Cloud Run フルマネージド サービスにデプロイする App Engine アプリをコンテナ化する方法について説明します。Cloud Buildpacks は、Dockerfile ファイルを管理したり、Docker について何も知らなくても、アプリをコンテナ化します。

この Codelab は、アプリを元の組み込みサービスから移行して Python 3 に移植し、コンテナで実行しようとしている Python 2 App Engine デベロッパーを対象としています。この Codelab は、完了したモジュール 2 またはモジュール 3 の Python 3 アプリから始まります。

注: Cloud Buildpacks は Python 3.7 以降（Go 1.10 以降、Node.js 10 以降、Java 8 と 11、.NET Core 3.1 以降も含む）のみをサポートしています。つまり、Python 2 App Engine アプリは、Cloud Buildpacks を使用する前に 3.x に移植する必要があります。2.x アプリをコンテナ化する場合は、Docker を使用する必要があります。このチュートリアルはスキップして、モジュール 4 の Codelab: Google App Engine から Docker を使用した Cloud Run への移行に進むことをおすすめします。

方法を学ぶ対象

• Cloud Buildpacks を使用してアプリをコンテナ化する
• コンテナ イメージを Cloud Run にデプロイする

必要なもの

• 次の対象を使用した Google Cloud Platform プロジェクト。
  • 有効な GCP 請求先アカウント
  • 有効な App Engine
• 基本的な Python スキル
• 一般的な Linux コマンドに関する実践的な知識
• App Engine アプリの開発とデプロイに関する基礎知識
• この演習（モジュール 5）を開始する前に、モジュール 2 または モジュール 3 の Codelab（または両方）を完了し、Python 3 に移植することをおすすめします。
• コンテナ化する準備ができている動作中の Python 3 App Engine アプリ
  • モジュール 2 Cloud NDB サンプル
  • モジュール 3 Cloud Datastore サンプル

アンケート

この Codelab をどのように使用されますか？

全体を通して読むだけ 内容を読んで演習をやり遂げる

2. 背景情報

App Engine や Cloud Functions などの PaaS システムは、チームやアプリケーションに多くの利便性をもたらします。たとえば、これらのサーバーレス プラットフォームを使用すると、SysAdmin や DevOps はソリューションの構築に集中できます。アプリは必要に応じて自動的にスケールアップし、従量課金制でゼロまでスケールダウンして費用を管理できます。また、さまざまな一般的な開発言語を使用します。

しかし、コンテナの柔軟性も魅力的であり、任意の言語、ライブラリ、バイナリを選択できます。サーバーレスの利便性とコンテナの柔軟性の両方をユーザーに提供することが、Google Cloud Run の目的です。

Cloud Run の使用方法の学習は、この Codelab の範囲外です。Cloud Run のドキュメントをご覧ください。ここでは、Cloud Run（または他のサービス）用に App Engine アプリをコンテナ化する方法を説明します。先に進む前に知っておくべきことがいくつかあります。主に、ユーザー エクスペリエンスが少し異なり、アプリケーション コードを取得してデプロイしなくなるため、少し低レベルになります。

代わりに、コンテナの構築やデプロイなど、コンテナに関することを学ぶ必要があります。また、App Engine のウェブサーバーを使用しなくなるため、ウェブサーバーを含め、コンテナ イメージに含めるものを決定できます。このパスに沿いたくない場合は、アプリを App Engine に保持しても構いません。

このチュートリアルでは、アプリのコンテナ化、App Engine 構成ファイルの削除、ウェブサーバーの管理（アプリの起動方法を含む）について学習します。

この移行では、次の手順に着目します。

1. セットアップ / 事前作業
2. アプリケーションのコンテナ化
   • 構成ファイルの置換
   • アプリケーション ファイルの変更

3. セットアップ/事前作業

チュートリアルの主要部分に進む前に、まずプロジェクトをセットアップし、コードを取得してから、ベースライン アプリをデプロイします。これで、作業コードを使って作業を開始できます。

1. プロジェクトをセットアップする

モジュール 2 または モジュール 3 の Codelab を完了している場合は、同じプロジェクト（とコード）を再利用することをおすすめします。または、新しいプロジェクトを作成するか、別の既存のプロジェクトを再利用することもできます。プロジェクトにアクティブな請求先アカウントがあり、App Engine（アプリ）が有効になっていることを確認します。

2. ベースライン サンプルアプリを入手する

この Codelab の前提条件の 1 つは、機能するモジュール 2 または 3 のサンプルアプリを用意することです。まだお持ちでない場合は、先に進む前にいずれかのチュートリアル（上のリンク）を完了することをおすすめします。すでに内容に精通している場合は、以下のいずれかのコードフォルダから開始してください。

ご自分のコードと Google で用意したコードのいずれを使用される場合も、このチュートリアルはここから開始します。この Codelab では、移行の手順を説明します。完了すると、モジュール 5 の FINISH リポジトリ フォルダの内容とほぼ一致するはずです。

• START:
  • Cloud NDB: モジュール 2 コード
  • Cloud Datastore: モジュール 3 コード
• 終了: モジュール 5 コード
• リポジトリ全体（クローン作成または ZIP をダウンロード）

開始ファイル（ご自身または Google のもの）のディレクトリは次のようになります。

$ ls
README.md               main.py                 templates
app.yaml                requirements.txt

3. ベースライン アプリを（再）デプロイする

この段階で実施する必要がある残りの事前作業のステップ:

1. gcloud コマンドライン ツールを学びなおす
2. gcloud app deploy を使用してサンプルアプリを再デプロイする
3. アプリが App Engine で問題なく実行されることを確認する

これらの手順を正常に実行したら、コンテナ化の準備が整います。

4. アプリケーションをコンテナ化する

Docker は、今日の業界における標準のコンテナ化プラットフォームです。前述のように、このツールを使用する際の課題の 1 つは、コンテナ イメージのビルド方法を決定する構成ファイルである効率的な Dockerfile を作成するのに手間がかかることです。一方、Buildpacks は、イントロスペクションを使用してアプリの依存関係を特定するため、手間がかかりません。これにより、Buildpacks コンテナがアプリにとって可能な限り効率的になります。

Docker についての学習をスキップして、Cloud Run や他のコンテナ ホスティング プラットフォームで実行するために App Engine アプリをコンテナ化したい場合は、ここで学ぶことができます。アプリのコンテナ化に Docker を使用する方法に関心がある場合は、この Codelab を完了した後でモジュール 4 の Codelab を受講してください。このチュートリアルと同じですが、Docker を使用してコンテナ イメージの管理方法をより深く理解できます。

移行手順には、App Engine 構成ファイルの置き換えと、アプリの起動方法の指定が含まれます。次の表に、各プラットフォーム タイプで想定される構成ファイルを示します。App Engine 列と Buildpack 列（必要に応じて Docker）を比較します。

説明	App Engine	Docker	Buildpacks
全般構成	app.yaml	Dockerfile	（service.yaml）
サードパーティ ライブラリ	requirements.txt	requirements.txt	requirements.txt
サードパーティの構成	app.yaml（プラス appengine_config.py、lib [2.x のみ]）	該当なし	該当なし
起動	該当なしまたは app.yaml（entrypoint を使用する場合）	Dockerfile	Procfile
ファイルを無視	.gcloudignore と .gitignore。	.gcloudignore、.gitignore、.dockerignore	.gcloudignore と .gitignore。

アプリをコンテナ化すると、Cloud Run にデプロイできます。Google Cloud の他のコンテナ プラットフォーム オプションには、Compute Engine、GKE、Anthos があります。

全般構成

App Engine はアプリケーションを自動的に起動しますが、Cloud Run は起動しません。Procfile は、app.yaml entrypoint ディレクティブと同様の役割を果たします。サンプルアプリの場合、Procfile は python main.py を実行して Flask 開発サーバーを起動します。必要に応じて、gunicorn などの本番環境ウェブサーバーを使用することもできます。その場合は、requirements.txt に追加してください。Buildpacks を使用してソースコードからデプロイする方法については、この Cloud Run ドキュメント ページをご覧ください。

app.yaml entrypoint ディレクティブを Procfile に移動するだけで済みます。ない場合は、この移行にユーザーが慣れるためのサンプル テストアプリなので、当面は Flask 開発サーバーを使用してください。アプリは、ユーザーが最もよく知っている特定の起動コマンドになります。内部的には、Cloud Run サービスは app.yaml に似た service.yaml を作成します。自動生成された service.yaml は、次のようなリンクにアクセスして確認できます。ただし、サービス SVC_NAME と REGION の場合は、https://console.cloud.google.com/run/detail/REGION/SVC_NAME/yaml/view にアクセスしてください。

サードパーティ ライブラリ

requirements.txt ファイルを変更する必要はありません。Flask は、Datastore クライアント ライブラリ（Cloud Datastore または Cloud NDB）と一緒に用意する必要があります。Gunicorn のような別の WSGI 準拠の HTTP サーバー（これを記載する現時点でのバージョンは 20.0.4）を使用する場合は、gunicorn==20.0.4 を requirements.txt に追加してください。

サードパーティの構成

Buildpacks では Python 2 はサポートされていないため、ここでは説明しません。Cloud Run のコンテナで実行される Python 3 アプリは、サードパーティ ライブラリを requirements.txt で指定する必要があるという点で、Python 3 App Engine アプリと似ています。

スタートアップ

Python 3 ユーザーは、app.yaml ファイルを変換して、handlers セクションに script: auto ディレクティブではなく entrypoint を含めることができます。Python 3 の app.yaml で entrypoint を使用する場合、次のようになります。

runtime: python38
entrypoint: python main.py

entrypoint ディレクティブは、App Engine にサーバーの起動方法を指示します。ほぼそのまま Procfile に移行できます。両方のプラットフォームでエントリポイント ディレクティブがどこに配置されるかをまとめると、次のようになります。参考として、Docker の同等のものも示します。

• Buildpacks: Procfile の行: web: python main.py
• Docker: Dockerfile の行: ENTRYPOINT ["python", "main.py"]

テストとステージングでは、上記のように Python から Flask の開発サーバーを実行するだけで済みますが、開発者は本番環境用に gunicorn を使用する Cloud Run クイックスタート サンプルなど、より強力なものを選択できます。

アプリケーション ファイル

モジュール 2 またはモジュール 3 アプリはすべて Python 2 ～ 3 と互換性があるため、main.py のコア コンポーネントは変更されません。数行のスタートアップ コードを追加するだけです。Cloud Run でアプリを呼び出すためにはポート 8080 を開いておく必要があるため、main.py の下部に 1 対の行を追加して開発環境サーバーを起動します。

if __name__ == '__main__':
    import os
    app.run(debug=True, threaded=True, host='0.0.0.0',
            port=int(os.environ.get('PORT', 8080)))

5. ビルドとデプロイ

App Engine 構成が Buildpack に置き換えられ、ソースファイルの更新が完了したら、Cloud Run で実行する準備が整います。その前に、サービスについて簡単に説明します。

サービスとアプリ

App Engine は主にアプリケーションをホストするために作成されていますが、マイクロサービスのコレクションから構成されるウェブサービスやアプリケーションをホスティングするためのプラットフォームでもあります。Cloud Run では、実際のサービスかウェブ インターフェースを備えたアプリケーションかに関係なく、すべてがサービスであるため、アプリケーションではなくサービスのデプロイメントとして使用を検討します。

App Engine アプリが複数のサービスで構成されている場合を除き、アプリケーションをデプロイするときに、何も名前をつける必要はありません。これは、サービス名を考える必要のある Cloud Run によって異なります。ただし、App Engine の appspot.com ドメインにはプロジェクト ID（例: https://PROJECT_ID.appspot.com）と、おそらくリージョン ID の略語（例: http://PROJECT_ID.REGION_ID.r.appspot.com）を使用します。

ただし、Cloud Run サービスのドメインには、サービス名、リージョン ID の略語、ハッシュが含まれますが、プロジェクト ID は含まれません（例: https://SVC_NAME-HASH-REG_ABBR.a.run.app）。つまり、サービス名の検討を始めましょう。

サービスをデプロイする

次のコマンドを実行して、コンテナ イメージをビルドし、Cloud Run にデプロイします。プロンプトが表示されたら、リージョンを選択し、テストを容易にするために未認証接続を許可して、必要に応じてリージョンを選択します。ここで、SVC_NAME はデプロイするサービスの名前です。

$ gcloud run deploy SVC_NAME --source .
Please choose a target platform:
 [1] Cloud Run (fully managed)
 [2] Cloud Run for Anthos deployed on Google Cloud
 [3] Cloud Run for Anthos deployed on VMware
 [4] cancel
Please enter your numeric choice:  1

To specify the platform yourself, pass `--platform managed`. Or, to make this the default target platform, run `gcloud config set run/platform managed`.

Please specify a region:
 [1] asia-east1
 [2] asia-east2
 [3] asia-northeast1
 [4] asia-northeast2
 [5] asia-northeast3
 [6] asia-south1
 [7] asia-southeast1
 [8] asia-southeast2
 [9] australia-southeast1
 [10] europe-north1
 [11] europe-west1
 [12] europe-west2
 [13] europe-west3
 [14] europe-west4
 [15] europe-west6
 [16] northamerica-northeast1
 [17] southamerica-east1
 [18] us-central1
 [19] us-east1
 [20] us-east4
 [21] us-west1
 [22] us-west2
 [23] us-west3
 [24] us-west4
 [25] cancel
Please enter your numeric choice: <select your numeric region choice>

To make this the default region, run `gcloud config set run/region REGION`.

Allow unauthenticated invocations to [SVC_NAME] (y/N)?  y

Building using Buildpacks and deploying container to Cloud Run service [SVC_NAME] in project [PROJECT_ID] region [REGION]
✓ Building and deploying... Done.
  ✓ Uploading sources...
  ✓ Building Container... Logs are available at [https://console.cloud.google.com/cloud-build/builds/BUILD-HASH?project=PROJECT_NUM].
  ✓ Creating Revision...
  ✓ Routing traffic...
Done.
Service [SVC_NAME] revision [SVC_NAME-00014-soc] has been deployed and is serving 100 percent of traffic.
Service URL: https://SVC_NAME-HASH-REG_ABBR.a.run.app

ブラウザで指定された URL にアクセスして、デプロイが成功したことを確認します。

gcloud コマンドが示すように、ユーザーは以下に示すように、さまざまなデフォルト設定をセットして出力とインタラクティビティを下げることができます。たとえば、すべてのインタラクションを回避するには、代わりに次の 1 行のデプロイ コマンドを使用できます。

$ gcloud beta run deploy SVC_NAME --source . --platform managed --region REGION --allow-unauthenticated

これを使用する場合は、上記でインタラクティブに行ったようなインデックス付きメニューの選択ではなく、必ず同じサービス名 SVC_NAME と目的の REGION の名前を選択してください。

6. 概要/クリーンアップ

アプリが App Engine と同様に Cloud Run で動作することを確認します。先行するいずれの Codelab の取り組みも行わずにこのシリーズに進んだ場合、アプリ自体は変更されません。このアプリは、メインのウェブページ（/）へのすべての訪問を登録します。一定回数以上サイトにアクセスすると、ウェブページは次のように表示されます。

これで、コードはモジュール 5 リポジトリ フォルダのコードと一致するようになりました。このモジュール 5 の Codelab はこれで終了です。

オプション: クリーンアップ

次の移行 Codelab に進む準備が整うまで、課金されるのを回避するためのクリーンアップを行うにはどうすればよいでしょうか。別のプロダクトを使用しているため、Cloud Run の価格ガイドをご確認ください。

省略可: サービスを無効にする

次のチュートリアルに進む準備がまだ完了していない場合は、サービスを無効にすることで追加料金が発生しないようにできます。次の Codelab に進む準備ができた時点で、再度有効にできます。アプリが無効になっている間、料金のかかるトラフィックは発生しません。ただし、もう 1 つの課金対象は、Datastore の使用量です。無料割り当て量を超過した場合は課金が発生するため、上限を超えないよう削除してください。

また、移行を続けず、完全に削除したい場合は、サービスを削除するか、プロジェクトを完全にシャットダウンしてください。

次のステップ

これでアプリのコンテナ化が完了しました。これでチュートリアルは終了です。ここからは、モジュール 4 Codelab（以下のリンク）から Docker を使用して同じ操作を行うか、別の App Engine の移行を行う方法を学びます。

• モジュール 4: Docker を使用して Cloud Run に移行する
  • Docker を使用して、Cloud Run で実行できるようにアプリをコンテナ化します。
  • Python 2 を引き続き使用できるようにする
• モジュール 7: App Engine の push タスクキュー（[push] タスクキューを使用する場合に必要）
  • App Engine taskqueue プッシュタスクをモジュール 1 アプリに追加する
  • モジュール 8 で Cloud Tasks に移行するユーザーの準備を行う
• モジュール 3:
  • Cloud NDB から Cloud Datastore に Datastore アクセスをモダナイズする
  • これは、Python 3 App Engine アプリと App Engine 以外のアプリに使用されるライブラリです
• モジュール 6: Cloud Firestore への移行。
  • Cloud Firestore に移行して Firebase の機能にアクセスします。
  • Cloud Firestore は Python 2 をサポートしていますが、この Codelab は Python 3 でのみ利用できます。

7. 参考情報

App Engine 移行モジュールの Codelab に関する問題 / フィードバック

この Codelab に問題が見つかった場合は、提出する前にまず問題を検索してください。新しい問題の検索と登録を行うためのリンク:

• App Engine 移行 Codelab の Issue Tracker
  • 問題を検索する
  • 新しい問題やフィードバックを提出する

移行に関するリソース

モジュール 2 と 3（開始）とモジュール 5（終了）のリポジトリ フォルダへのリンクを以下の表に示します。これらのフォルダには、すべての App Engine Codelab 移行のリポジトリからアクセスすることもでき、クローンを作成する、または ZIP ファイルをダウンロードすることができます。

Codelab	Python 2	Python 3
モジュール 2	コード	（コード）
モジュール 3	（コード）	コード
モジュール 5	該当なし	コード

App Engine と Cloud Run のリソース

この特定の移行に関する追加リソースは以下のとおりです。

• コンテナ
  • Google Cloud Run
  • Google Cloud Build
  • Google Cloud Container Registry
  • Docker
  • Cloud Buildpacks リリース投稿
  • Cloud Buildpacks デプロイ投稿
  • Cloud Buildpacks リポジトリ
  • CNCF Buildpacks 仕様
  • App Engine から Cloud Run ツールへ - 独自の service.yaml を生成
• 全般
  • Google Cloud Platform での Python
  • Google Cloud Python クライアント ライブラリ