1. 總覽
這個程式碼研究室系列 (自助操作教學課程) 旨在引導 Google App Engine (Standard) 開發人員透過一系列遷移作業，協助他們翻新自家應用程式。完成上述作業後，使用者就能針對 Cloud Run、Google Cloud 的容器託管姊妹服務、App Engine 和其他容器託管服務，明確地將應用程式容器化，提高應用程式的可攜性。
本教學課程說明如何使用 Cloud Buildpacks (替代 Docker 的替代方案)，將 App Engine 應用程式容器化，以便部署至 Cloud Run 全代管服務。Cloud Buildpack 可將應用程式容器化，不必管理 Dockerfile 檔案，甚至不知道 Docker。
本程式碼研究室適用於將應用程式從原始內建服務移至 Python 3，以及打算在容器中執行的 Python 2 App Engine 開發人員。本程式碼研究室會從已完成的單元 2 或單元 3 的 Python 3 應用程式開始。
你將瞭解如何
- 使用 Cloud Buildpacks 將應用程式容器化
- 將容器映像檔部署至 Cloud Run
軟硬體需求
- 含有以下項目的 Google Cloud Platform 專案：
- 基本 Python 技能
- 熟悉常見的 Linux 指令
- 對開發和部署 App Engine 應用程式有基本瞭解
- 建議您先完成單元 2 或單元 3 的程式碼研究室，包括移植至 Python 3，再開始本程式碼研究室 (單元 5)。
- 可正常進行容器化的 Python 3 App Engine 應用程式
問卷調查
您會如何使用本程式碼研究室？
2. 背景
App Engine 和 Cloud Functions 等 PaaS 系統為您的團隊和應用程式提供許多便利性。例如，這些無伺服器平台可讓 SysAdmin/DevOps 專注於建構解決方案。您的應用程式可以視需要自動調度資源，使用即付即用的計費模式將資源縮減至零，同時控管成本，而且會使用多種常見的開發語言。
不過，容器也有彈性，而且能選擇任何語言、程式庫和二進位檔。Google Cloud Run 就是為使用者帶來雙贏的局面、無伺服器的便利性和容器的靈活彈性。
瞭解如何使用 Cloud Run 不在本程式碼研究室的範圍內。請參閱 Cloud Run 說明文件。這個步驟的目的是讓您瞭解如何為 Cloud Run (或其他服務) 將 App Engine 應用程式容器化。繼續前，您需要瞭解一些注意事項，主要是因為您的使用者體驗會略有不同，而且您不再接受應用程式程式碼並進行部署，所以您的使用者體驗會略有不同。
您必須學習容器的一些知識，例如建構及部署容器。您也可以決定要將哪些內容放入容器映像檔，包括網路伺服器，因為您之後不會再使用 App Engine 的網路伺服器。如果您不想依循這個路徑，則建議將應用程式保留在 App Engine 上。
在這個教學課程中，您會瞭解如何將應用程式容器化、移除 App Engine 設定檔、管理網路伺服器，包括如何啟動應用程式。
這項遷移作業包含下列步驟：
- 設定/事前作業
- 將應用程式
- 容器化
- 取代設定檔
- 修改應用程式檔案
3. 設定/事前作業
在開始教學課程的主要部分之前，我們先設定專案、取得程式碼，然後部署基準應用程式，以便瞭解要開始使用有效的程式碼。
1. 設定專案
如果您已完成單元 2 或單元 3 的程式碼研究室，建議您重複使用相同的專案 (和程式碼)。或者，您可以建立新的專案，或是重複使用其他現有專案。請確認專案具備有效的帳單帳戶，且 App Engine (應用程式) 已啟用。
2. 取得基準範例應用程式
本程式碼研究室的必要條件之一，是擁有正常運作的模組 2 或 3 範例應用程式。如果沒有相關課程，建議您先完成任一教學課程 (上方連結)，再繼續操作。如果您熟悉其內容，也可以先選取下方的其中一個程式碼資料夾。
無論您使用您自己的還是我們的機器，這就是本教學課程的開始。本程式碼研究室會引導您逐步完成遷移作業，完成之後，應該會與單元 5 FINISH 存放區資料夾中的內容大致相符。
START 檔案 (您的或我們的) 目錄應如下所示：
$ ls
README.md main.py templates
app.yaml requirements.txt
3. (重新) 部署基準應用程式
您目前需執行的準備作業步驟：
- 請重新熟悉
gcloud指令列工具。 - 使用
gcloud app deploy重新部署範例應用程式 - 確認應用程式在 App Engine 上執行，沒有問題
成功執行這些步驟後，就可以將步驟容器化。
4. 將應用程式容器化
Docker 是現今產業的標準容器化平台。如前所述，使用容器的其中一項挑戰是必須控管高效的 Dockerfile，也就是決定容器映像檔建構方式的設定檔。Buildpacks 則是利用自我檢查功能判斷應用程式的依附元件，因此幾乎不需要耗費太多心力，因此建構套件容器能為應用程式盡可能提高效率。
如果您想略過 Docker 的相關程序，或是想將 App Engine 應用程式容器化，以便在 Cloud Run 或其他容器託管平台上執行，這會是最佳選擇。如果您想要瞭解如何使用 Docker 進行應用程式容器化，請在完成此課程後進行單元 4 程式碼研究室。雖然這與先前完全相同，但會使用 Docker，讓您更深入瞭解如何管理容器映像檔。
遷移步驟包括替換 App Engine 設定檔，以及指定應用程式的啟動方式。下表摘要列出各種平台類型適用的設定檔。比較 App Engine 資料欄與 Buildpacks 資料欄 (以及選用的 Docker)：
說明 | App Engine | Docker | 組裝包 |
一般設定 |
|
| ( |
第三方程式庫 |
|
|
|
第三方設定 |
| (不適用) | (不適用) |
啟動 | (不適用) 或 |
|
|
忽略檔案 |
|
|
|
應用程式容器化後，即可部署至 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 服務會建立 service.yaml，看起來與 app.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) 一起出現。如果您想使用其他符合 WSGI 規定的 HTTP 伺服器 (例如 Gunicorn)，截至本文撰寫時使用的是 20.0.4 版本，請將 gunicorn==20.0.4 新增至 requirements.txt。
第三方設定
Buildpacks 不支援 Python 2，因此我們不在此討論。在 Cloud Run 容器中執行的 Python 3 應用程式，與 Python 3 App Engine 應用程式相似。您必須在 requirements.txt 中指定第三方程式庫。
啟動
Python 3 使用者可選擇將 app.yaml 檔案轉換為 handlers 區段的 entrypoint，而非 script: auto 指令。如果您在 Python 3 app.yaml 中使用 entrypoint，則看起來會像這樣：
runtime: python38
entrypoint: python main.py
entrypoint 指令會指示 App Engine 如何啟動您的伺服器。你可以將手錶幾乎直接移到 Procfile 中。摘要說明進入點指令在兩個平台之間移動的位置：這會直接轉譯為以下形式；也顯示等同於 FYI 的 Docker 程式碼：
- 建構套件：
Procfile中的行：web: python main.py - Docker：
Dockerfile中的行：ENTRYPOINT ["python", "main.py"]
如上所述，只要從 Python 執行 Flask 的開發伺服器即可輕鬆完成測試與測試，但開發人員可以選擇在實際工作環境中使用更強大的功能，例如使用 gunicorn 的 Cloud Run 快速入門導覽課程範例。
應用程式檔案
所有模組 2 或模組 3 應用程式均與 Python 2 至 3 完全相容，這表示 main.py 的核心元件沒有變更。您只需要新增幾行啟動程式碼即可在 main.py 底部加入幾行指令來啟動開發伺服器，因為 Cloud Run 需要先開啟通訊埠 8080，才能呼叫您的應用程式：
if __name__ == '__main__':
import os
app.run(debug=True, threaded=True, host='0.0.0.0',
port=int(os.environ.get('PORT', 8080)))
5. 建構及部署
完成 Buildpacks 取代了 App Engine 設定並更新來源檔案後，您即可開始在 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
使用瀏覽器造訪指定網址，確認部署成功！
正如 gcloud 指令所示，使用者可以設定各種預設設定以減少輸出和互動次數，如上所示。舉例來說，如要避免所有互動，您可以改用下列單行部署指令：
$ gcloud beta run deploy SVC_NAME --source . --platform managed --region REGION --allow-unauthenticated
如果使用這個方法，請務必選取相同的服務名稱 SVC_NAME 和所需的 REGION 名稱，而非已建立索引的選單選項 (與先前互動的操作方式不同)。
6. 摘要/清除
確認應用程式在 Cloud Run 中的運作方式與 App Engine 相同。如果您進入本系列課程，但未執行先前的任何程式碼研究室，應用程式本身並不會改變。它會記錄主網頁 (/) 的所有造訪，而且在您造訪此網站足夠的時間後看起來像下面這樣：
您的程式碼現在應與模組 5 存放區資料夾中的程式碼相符。恭喜您完成單元 5 程式碼研究室。
選用：清除
在準備進入下一個遷移程式碼研究室之前，您該如何清除所用資源，以免產生費用？由於現在使用的是其他產品，請務必詳閱 Cloud Run 定價指南。
選用：停用服務
如果還不想進行下一個教學課程，請停用服務，以免產生額外費用。當您準備好前往下一個程式碼研究室時，即可重新啟用。停用的應用程式不會獲得任何流量，不過如果用量超過免費配額，我們就會向您收取 Datastore 用量的費用，因此刪除費用就會低於配額上限。
另一方面，如果您不想繼續進行遷移作業，想要徹底刪除所有資料，可以選擇刪除服務或完全關閉專案。
後續步驟
恭喜，您已經容器化應用程式，教學課程到此結束！下一步就是在單元 4 程式碼研究室 (下方連結) 中，瞭解如何使用 Docker 執行相同的作業，或是進行其他 App Engine 遷移作業：
- 模組 4：透過 Docker 遷移至 Cloud Run
- 將應用程式容器化，讓應用程式透過 Docker 在 Cloud Run 中執行
- 允許您繼續使用 Python 2
- 單元 7：App Engine 推送工作佇列 (如果您使用 [push] 工作佇列，則為必要項目)
- 將 App Engine
taskqueue推送工作新增至模組 1 應用程式 - 協助使用者做好準備，以便遷移至 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，但本程式碼研究室僅適用於 Python 3。
7. 其他資源
App Engine 遷移模組程式碼研究室問題/意見回饋
如果您在本程式碼研究室中發現任何問題，請先搜尋您的問題再提出申請。搜尋及建立新問題的連結：
- App Engine 遷移程式碼研究室適用的問題追蹤工具
遷移資源
下表提供模組 2 和 3 (START) 和單元 5 (FINISH) 的存放區資料夾連結。您也可以透過所有 App Engine 程式碼研究室遷移作業的存放區存取這些資料，可以複製或下載 ZIP 檔案。
Codelab | Python 2 | Python 3 |
(程式碼) | ||
(程式碼) | ||
模組 5 | (不適用) |
App Engine 和 Cloud Run 資源
以下是這項特定遷移作業的其他資源：