1. 概要
この一連の Codelab（セルフペース型のハンズオン チュートリアル）は、Google App Engine（Standard）のデベロッパーが一連の移行手順をご案内し、アプリをモダナイズできるようにすることを目的としています。それが完了したら、ユーザーは、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 を使用してアプリをコンテナ化する
- コンテナ イメージを Cloud Run にデプロイする
必要なもの
- 次の対象を使用した Google Cloud Platform プロジェクト。
- 基本的な Python スキル
- 一般的な Linux コマンドに関する実践的な知識
- App Engine アプリの開発とデプロイに関する基礎知識
- このモジュール（モジュール 5）を開始する前に、モジュール 2 またはモジュール 3 のいずれか（または両方）の Codelab（Python 3 への移植を含む）を完了することをおすすめします。
- コンテナ化可能な、動作中の Python 3 App Engine アプリ
アンケート
この Codelab をどのように使用されますか？
<ph type="x-smartling-placeholder">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 構成ファイルの削除、ウェブサーバーの管理方法、アプリの起動方法について学びます。
この移行の特徴は次のとおりです。
- セットアップ / 事前作業
- アプリケーションのコンテナ化
- 構成ファイルの置換
- アプリケーション ファイルの変更
3. 設定/事前作業
チュートリアルの主要部分に進む前に、まずプロジェクトをセットアップし、コードを取得してから、ベースライン アプリをデプロイします。これで、作業コードを使って作業を開始できます。
1. プロジェクトをセットアップする
モジュール 2 またはモジュール 3 のいずれかの Codelab を完了している場合は、同じプロジェクト（およびコード）を再利用することをおすすめします。あるいは、新しいプロジェクトを作成することも、別の既存のプロジェクトを再利用することもできます。プロジェクトにアクティブな請求先アカウントがあり、App Engine（アプリ）が有効になっていることを確認します。
2. ベースラインのサンプルアプリを取得する
この Codelab の前提条件の一つは、機能するモジュール 2 または 3 のサンプルアプリがあることです。まだ登録していない場合は、先に進む前にチュートリアル（上記のリンク）を完了することをおすすめします。すでにその内容に慣れている場合は、以下のいずれかのコードフォルダを選択して開始できます。
ご自身の方でも私たちの方であれ、このチュートリアルはここから始まります。この Codelab では移行手順が順を追って説明します。移行が完了するまでには、モジュール 5 の FINISH リポジトリ フォルダの内容とほぼ一致しているはずです。
- 開始:
- Cloud NDB: モジュール 2 コード
- Cloud Datastore: モジュール 3 のコード
- 終了: モジュール 5 のコード
- リポジトリ全体（クローン作成または ZIP をダウンロード）
（自分のものまたは私たちのもの）START ファイルのディレクトリは、次のようになります。
$ ls
README.md main.py templates
app.yaml requirements.txt
3. ベースライン アプリを（再）デプロイする
この段階で実施する必要がある残りの事前作業のステップ:
gcloudコマンドライン ツールを学びなおすgcloud app deployを使用してサンプルアプリを再デプロイする- アプリが App Engine で問題なく動作することを確認する
これらのステップを正常に実行したら、コンテナ化する準備は完了です。
4. アプリケーションをコンテナ化する
Docker は現在、業界の標準的なコンテナ化プラットフォームです。前述のように、これを使用する際の課題の 1 つは、効率的な Dockerfile（コンテナ イメージの作成方法を決定する構成ファイル）をキュレートする必要があることです。一方、Buildpack は、イントロスペクションを使用してアプリの依存関係を判断するため、ほとんど労力を必要としません。これにより、アプリに対して Buildpack コンテナが可能な限り効率的になります。
Docker の学習をスキップし、App Engine アプリをコンテナ化して Cloud Run やその他のコンテナ ホスティング プラットフォームで実行したい方に最適です。アプリのコンテナ化に Docker を使用する方法に関心がある場合は、このモジュールの完了後に、モジュール 4 Codelab を受講できます。これと同じですが、Docker を使用してコンテナ イメージの管理方法をより深く理解できます。
移行手順には、App Engine 構成ファイルの置き換えとアプリの起動方法の指定が含まれています。以下の表は、各プラットフォーム タイプに必要な構成ファイルをまとめたものです。[App Engine] 列と Buildpack 列（必要に応じて Docker）を比較します。
説明 | App Engine | Docker | Buildpack |
全般構成 |
|
| （ |
サードパーティ ライブラリ |
|
|
|
サードパーティの構成 |
| 該当なし | 該当なし |
起動 | 該当なしまたは |
|
|
ファイルを無視 |
|
|
|
コンテナ化されたアプリは、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 アプリがない場合は、この移行に慣れるためのサンプル テストアプリなので、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 に追加してください。
サードパーティの構成
Buildpack は Python 2 をサポートしていないため、ここでは説明しません。Cloud Run のコンテナで実行される Python 3 アプリは、サードパーティ ライブラリを requirements.txt で指定する必要があるという点で、Python 3 App Engine アプリと似ています。
起動
Python 3 ユーザーは、handlers セクションで script: auto ディレクティブの代わりに entrypoint が含まれるように app.yaml ファイルを変換することもできます。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"]
前述したように、Flask の開発用サーバーを Python から実行するだけで、テストとステージングは簡単に行えますが、デベロッパーは、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 構成を Buildpacks に置き換え、ソースファイルの更新が完了したら、Cloud Run で実行する準備は完了です。その前に、Service について簡単に説明しましょう。
サービスとアプリの比較
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 に移行するユーザーの準備を行う
- App Engine
- モジュール 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（START）とモジュール 5（FINISH）のリポジトリ フォルダへのリンクを示します。これらのフォルダには、すべての App Engine Codelab 移行のリポジトリからアクセスすることもでき、クローンを作成する、または ZIP ファイルをダウンロードすることができます。
Codelab | Python 2 | Python 3 |
（コード） | ||
（コード） | ||
モジュール 5 | 該当なし |
App Engine リソースと Cloud Run リソース
この特定の移行に関する追加リソースは以下のとおりです。