本教學課程說明如何導入新應用程式、為應用程式開發功能，以及使用 Google Kubernetes Engine (GKE) 的現代持續整合/持續推送軟體更新 (CI/CD) 技術，將應用程式部署到正式環境。
本文件是系列文章之一：
- 使用 GKE 進行現代化的持續整合/持續推送軟體更新：軟體推送架構
- 使用 GKE 進行現代化的持續整合/持續推送軟體更新：建構持續整合/持續推送軟體更新系統 (參考架構)
- 使用 GKE 進行現代化的持續整合/持續推送軟體更新：套用開發人員工作流程 (本文件)
在本教學課程中，您將使用 Skaffold、kustomize、Artifact Registry、Config Sync、Cloud Build 和 Cloud Deploy 等工具，開發、建構及部署應用程式。
本文的目標讀者是企業架構師和應用程式開發人員，以及 IT 安全、開發運作和網站穩定性工程 (SRE) 團隊。如要瞭解本文中的概念，建議您先累積一些自動部署工具和程序的經驗。
架構
在本教學課程中，您將導入新的應用程式。接著，您會開發新功能，並在開發、測試和正式環境中部署應用程式。 參考架構包含導入及發布新應用程式所需的基礎架構和工具，工作流程如下圖所示：
從 CI 的程式碼存放區開始，工作流程包含下列步驟：
您透過應用程式存放區分享應用程式原始碼。
將程式碼提交並推送至應用程式存放區時，系統會自動觸發 Cloud Build 中的 CI 管道。CI 程序會建立容器映像檔，並推送至 Artifact Registry。
CI 程序也會在 Cloud Deploy 中為應用程式建立 CD 版本。
CD 發布內容會使用
skaffold為開發環境產生完整轉譯的 Kubernetes 資訊清單，並將其部署至開發環境 GKE 叢集。接著，CD 版本會從開發環境升級至預先發布目標，產生完整轉譯的預先發布資訊清單，並部署至預先發布 GKE 叢集。
接著，CD 版本會從暫存環境升級至實際工作環境，產生完整轉譯的實際工作環境資訊清單，並部署至實際工作環境 GKE 叢集。
如要進一步瞭解這個工作流程中使用的工具和基礎架構，請參閱「Anthos 的新型持續整合/持續推送軟體更新：建立持續整合/持續推送軟體更新系統」。
啟用新應用程式
參考架構包含應用程式工廠。這個出廠設定是一組 Git 存放區 (名為 application-factory-repo) 和下列 Cloud Build 觸發條件：
create-apptf-plantf-applycreate-team
您可以使用應用程式出廠設定，從入門存放區導入新應用程式。應用程式上線程序包含下列步驟：
建立應用程式定義：您可以在 Terraform 檔案中建立應用程式定義，並將其儲存在
application-factory-repo中，做為應用程式目錄。建立應用程式基礎架構：您可以在應用程式定義檔案上執行 Terraform，建立應用程式基礎架構。應用程式基礎架構包含下列項目：
新應用程式的登陸區包括在
acm-gke-infrastructure-repo存放區中定義命名空間、服務帳戶和基本政策。上線新應用程式時，系統只會在開發 GKE 叢集中建立登陸區。這麼做是為了讓開發人員能使用開發環境，並開始進行疊代。預先發布和正式叢集中的登陸區是採用 GitOps 方法建立。本文件稍後會說明這種做法，讓您在準備好升級這些叢集中的版本時，可以參考相關內容。基礎架構入門存放區中的基礎架構存放區，用於代管程式碼，以便在 Cloud Build 中建立 CI 管道、在 Cloud Deploy 中建立 CD 管道，以及建立 Artifact Registry 存放區來儲存構件。
基礎架構 Cloud Build 觸發條件，會擷取基礎架構存放區中的程式碼，並根據定義建立資源。
應用程式存放區 (來自應用程式啟動器存放區)，用於存放應用程式的原始碼。
建立應用程式的 CI/CD 資源：您可以使用應用程式基礎架構，為應用程式建立 CI/CD 資源。
建立應用程式定義：
執行 create-app 觸發條件，在 application-factory-repo 中產生應用程式定義檔。定義檔包含建立應用程式所需資源的宣告式定義。
前往 Google Cloud 控制台的 Cloud Build 頁面：
按一下
create-app觸發條件。按一下「顯示網址預覽」，即可顯示叫用 Webhook 時所需的網址。
在 Cloud Shell 中，對上一個步驟取得的網址發出 curl 要求，並將參數做為酬載傳遞至該網址，藉此叫用觸發程序。
curl "WEBHOOK_URL" -d '{"message": {"app": "sample","runtime": "python","trigger_type": "webhook","github_team": ""}}'
在先前的程式碼範例中：
將
WEBHOOK_URL替換為從觸發程序取得的網址。"app": "sample"指定應用程式名稱。"runtime": "python"會告知應用程式工廠使用 Python 範本建立應用程式存放區。"trigger_type": "webhook"是指應用程式的 CI/CD 管道類型。"github_team": ""是 GitHub 中的團隊，將與為應用程式建立的存放區建立關聯。由於您尚未建立 GitHub 團隊，請將其做為空字串傳遞。
檢查管道的
create-app觸發條件：create-app觸發條件有新的管道。完成後，應用程式定義就會在application-factory-repo中建立。查看應用程式定義檔案：
在網路瀏覽器中前往 GitHub，然後登入帳戶。
按一下圖片圖示，然後按一下
Your organizations。選擇貴機構。按一下存放區
application-factory-repo，前往資料夾apps/python，然後開啟由create-app觸發程序建立的新檔案 (名為sample.tf)。檢查檔案，這個檔案包含用來建立新應用程式的 Terraform 程式碼。
建立應用程式基礎架構：
建立應用程式定義後，請執行觸發條件 tf-apply 來建立應用程式基礎架構。
在 Google Cloud 控制台中：
按一下
tf-apply觸發條件。按一下「顯示網址預覽」，即可顯示叫用 Webhook 時所需的網址。
叫用觸發條件：
curl "WEBHOOK_URL" -d '{}'
在先前的程式碼範例中：
- 將
WEBHOOK_URL替換為從觸發程序取得的網址。
- 將
檢查管道的
tf-apply觸發條件：tf-apply觸發條件有新的管道。等待作業完成。
這個觸發條件會建立應用程式基礎架構。
查看應用程式基礎架構：
查看應用程式基礎架構的各個元件。
登陸區
前往 Cloud Shell 並設定專案。
gcloud config set core/project PROJECT_ID
將
PROJECT_ID替換為您的 Google Cloud 專案 ID。取得開發 GKE 叢集的憑證。
gcloud container clusters get-credentials gke-dev-us-central1 --location us-central1-a檢查應用程式的命名空間。命名空間會以應用程式 (範例) 命名。
kubectl get namespaces sample輸出內容會類似以下內容：
NAME STATUS AGE sample Active 15m
檢查命名空間中的服務帳戶。
kubectl get serviceaccounts -n sample除了預設服務帳戶外，還有其他服務帳戶。輸出內容會類似以下內容：
NAME SECRETS AGE default 0 15m sample-ksa 0 15m
基礎架構存放區
在網路瀏覽器中前往 GitHub，然後登入帳戶。按一下圖片圖示。然後按一下 Your organizations。選擇您的機構，然後按一下 sample-infra 存放區。
這個存放區有四個分支：cicd-trigger、dev、staging 和 prod。此外，這個存放區還包含四個資料夾：cicd-trigger、dev、staging 和 prod。預設分支版本為 cicd-trigger，您可以將程式碼推送至這個分支版本，其他分支版本則有保護規則，因此您無法直接將程式碼推送至這些分支版本。如要將程式碼推送至這些分支，您必須建立提取要求。cicd-trigger 資料夾包含為應用程式建立 CI/CD 資源的程式碼，而 dev、staging 和 prod 資料夾則包含為應用程式不同環境建立基礎架構的程式碼。
基礎架構觸發條件
在 Google Cloud 控制台中：
系統新增了名為「
deploy-infra-sample」的觸發條件。這個觸發條件會連結至存放區
sample-infra，因此當程式碼推送至這個存放區時，系統會叫用觸發條件，找出推送發生的分支，前往該分支上的對應資料夾，並在該處執行 Terraform。舉例來說，如果程式碼推送至cicd-trigger分支版本，觸發條件會在 cicd-trigger 分支版本的 cicd-trigger 資料夾中執行 Terraform。同樣地，當推送至dev分支版本時，觸發條件會在開發分支版本的開發資料夾上執行 Terraform，依此類推。
應用程式存放區
- 前往 GitHub，並找出機構下的存放區。已有名為「
sample」的新存放區。這個存放區會代管原始碼和建構容器的步驟，這些容器位於Dockerfile、kustomize設定中，說明應用程式的必要設定，以及skaffold.yaml，定義 Cloud Deploy 用於 CD 的部署步驟。
建立應用程式 CI/CD 資源
您已建立應用程式的架構，現在請執行觸發條件 deploy-infra-sample，建立應用程式的 CI/CD 資源。您可以透過 Webhook 網址手動叫用觸發程序，也可以將變更提交至 Git 存放區 sample-infra。
如要叫用 Cloud Build 觸發條件，請在存放區的檔案中新增一行。然後推送變更：
如果您從未在 Cloud Shell 中使用過 Git，請使用您的姓名和電子郵件地址設定 Git。Git 會使用這項資訊識別您在 Cloud Shell 中建立的修訂版本的作者身分：
git config --global user.email "GITHUB_EMAIL_ADDRESS" git config --global user.name "GITHUB_USERNAME"
更改下列內容：
GITHUB_EMAIL_ADDRESS：與 GitHub 帳戶相關聯的電子郵件地址GITHUB_USERNAME：與 GitHub 帳戶相關聯的使用者名稱
複製 Git 存放區
sample-infra：git clone https://github.com/GITHUB_ORG/sample-infra cd sample-infra
更改下列內容：
GITHUB_ORG。
系統會簽出預設分支 cicd-trigger。
在 env/cicd-trigger/main.tf 檔案中新增一行，然後提交並推送變更。
echo "" >> env/cicd-trigger/main.tf修訂並推送變更：
git add . git commit -m "A dummy commit to invoke the infrastrucutre trigger" git push cd ..變更推送完成後，Cloud Deploy 觸發條件
deploy-infra-sample就會啟動。
監控觸發條件的狀態：
前往 Cloud Build 記錄頁面查看管道，並等待管道執行完畢。
查看應用程式 CICD 資源
查看為應用程式建立的各種 CI/CD 資源。
在 Google Cloud 控制台中：
前往 Cloud Build 頁面，查看
deploy-app-sample觸發條件。這是 CI 管道觸發程序。並連結至應用程式程式碼存放區
sample。將內容推送至應用程式存放區時，系統會叫用觸發條件，並按照觸發條件設定定義的建構步驟執行作業。如要查看觸發條件在叫用時執行的步驟，請按一下觸發條件名稱，然後點選「開啟編輯器」按鈕。前往 Artifact Registry 頁面，查看名稱為
sample的新存放區。這個構件存放區會儲存應用程式的構件。
前往 Cloud Deploy 管道頁面，查看名稱為
sample的管道。 這個持續部署管道會將應用程式部署到 GKE 叢集。
在開發環境中部署應用程式
觸發條件 deploy-app-sample 會連結至名為 sample 的應用程式存放區。您可以透過 Webhook 網址手動叫用觸發程序，也可以透過推送至應用程式存放區的方式叫用。
在存放區
sample的檔案中新增一行，然後推送變更來叫用 Cloud Build 觸發條件：複製 Git 存放區
sample：在 Cloud Shell 中：
git clone https://github.com/GITHUB_ORG/sample cd sample
將
GITHUB_ORG替換成 GitHub 機構。在
skaffold.yaml檔案中新增一行。echo "" >> skaffold.yaml修訂並推送變更：
git add . git commit -m "A dummy commit to invoke CI/CD trigger" git push變更推送完成後，Cloud Deploy 觸發條件
deploy-app-sample就會啟動。
監控觸發條件的狀態：
前往 Cloud Build 記錄頁面查看管道，並等待管道執行完畢。
觸發條件會執行設定中定義的步驟。第一步是從存放區
sample中的應用程式程式碼建構 Docker 映像檔。最後一個步驟是啟動 Cloud Deploy 管道，將應用程式部署至開發 GKE 叢集。檢查開發叢集中的部署作業：
按一下
sample管道，系統已開始將部署作業傳送至開發 GKE 叢集。等待作業完成。
確認應用程式已成功部署：
取得開發叢集的憑證。
gcloud container clusters get-credentials gke-dev-us-central1 --location us-central1-a連線至 GKE 叢集。
gcloud container clusters get-credentials gke-dev-us-central1 --location us-central1-a && kubectl port-forward --namespace sample $(kubectl get pod --namespace sample --selector="deploy.cloud.google.com/delivery-pipeline-id=sample" --output jsonpath='{.items[0].metadata.name}') 8080:8080在 Cloud Shell 工具列中，按一下
按一下「Web Preview」(網頁預覽)，然後點選「Preview on port 8080」(透過以下通訊埠預覽：8080)：
輸出內容如下：
Hello World!
在 Cloud Shell 中按下
CTRL+C，即可結束通訊埠轉送。
在應用程式中新增功能
開發新功能時，您需要快速將變更部署至開發環境，以便測試及疊代。在本教學課程中，您將變更應用程式程式碼存放區中的內容，並將變更部署至開發環境。
在 Cloud Shell 中，將目錄變更為已複製的
sample存放區：更新應用程式以輸出不同的訊息：
sed -i "s/Hello World/My new feature/g" main.py修訂並推送變更：
git add . git commit -m "Changed the message" git push程式碼推送到 GitHub 存放區後，Webhook 觸發程序
deploy-app-sample就會啟動。在 Cloud Build 記錄頁面監控觸發條件的狀態，並等待完成。
-
按一下
sample管道，系統已開始將部署作業傳送至開發 GKE 叢集。等待作業完成。
確認應用程式已成功部署：
如果您開啟了新的 Cloud Shell，請取得開發叢集的憑證：
gcloud container clusters get-credentials gke-dev-us-central1 --zone us-central1-a連線至 GKE 叢集：
gcloud container clusters get-credentials gke-dev-us-central1 --zone us-central1-a && kubectl port-forward --namespace sample $(kubectl get pod --namespace sample --selector="deploy.cloud.google.com/delivery-pipeline-id=sample" --output jsonpath='{.items[0].metadata.name}') 8080:8080在 Cloud Shell 工具列中，按一下
按一下「Web Preview」(網頁預覽)，然後點選「Preview on port 8080」(透過以下通訊埠預覽：8080)：
輸出內容如下：
My new feature!
在 Cloud Shell 中按下
CTRL+C，即可結束通訊埠轉送。
將變更推行至測試和正式版叢集
將應用程式升級至預先發布和正式版環境之前，您必須在這些環境的 GKE 叢集中，為應用程式建立登陸區。您加入應用程式時，系統會將程式碼新增至開發分支中的 acm-gke-infrastructure-repo，在開發 GKE 叢集中自動建立開發專用的登陸區。
在測試環境和實際工作環境 GKE 叢集中建立登陸區
在暫存 GKE 叢集中建立登陸區：您需要在
acm-gke-infrastructure-repo中，從開發分支建立拉取要求到暫存分支，然後合併。前往 GitHub 並瀏覽至存放區
acm-gke-infrastructure-repo。依序點選Pull requests和New pull request按鈕。在「Base」(基本) 選單中選擇「staging」(預先發布)，在「Compare」(比較) 選單中選擇「dev」(開發)。按一下Create pull request按鈕。通常，有權存取存放區的人會審查變更，然後合併 PR，確保只有預期的變更會升級至預先發布環境。為讓個人試用參考架構，我們放寬了分支保護規則，讓存放區管理員可以略過審查並合併 PR。如果您是存放區管理員，請合併提取要求。否則請管理員合併。
Config Sync 會將存放區
acm-gke-infrastructure-repo暫存分支版本上的變更，同步至暫存 GKE 叢集，進而在暫存 GKE 叢集上為應用程式建立登陸區。在正式版 GKE 叢集中建立登陸區：您需要從暫存環境建立提取要求，然後合併至正式版分支。
依序點選
Pull requests和New pull request按鈕。在「Base」(基本) 選單中選擇「prod」(正式版)，並在「Compare」(比較) 選單中選擇「staging」(測試版)。按一下Create pull request按鈕。如果您是存放區管理員，請合併提取要求。否則請管理員合併。
Config Sync 會將存放區
acm-gke-infrastructure-repo的 prod 分支版本上傳的變更，同步至實際工作環境 GKE 叢集，進而在實際工作環境 GKE 叢集上為應用程式建立登陸區。
將開發環境的變更升級至測試環境
您已在暫存和實際工作環境 GKE 叢集中，為應用程式建立登陸區，現在請將應用程式從開發環境升級至暫存環境。
找出最新版本名稱，並儲存為環境變數：
export RELEASE=$(gcloud deploy targets describe dev --region=us-central1 --format="json" | jq -r '."Active Pipeline"[0]."projects/PROJECT_ID/locations/us-central1/deliveryPipelines/sample"."Latest release"' | awk -F '/' '{print $NF}')
將
PROJECT_ID替換為您的 Google Cloud 專案 ID。確認環境變數是否已設定完成：
echo $RELEASE
在 Cloud Shell 中執行下列指令，將版本從開發環境升級至測試環境：
gcloud deploy releases promote --release=$RELEASE --delivery-pipeline=sample --region=us-central1 --to-target=staging --quiet
檢查暫存部署作業：
按一下
sample管道，系統已開始將部署作業傳送至暫存 GKE 叢集。等待作業完成。確認暫存部署作業是否順利完成：
取得暫存叢集的憑證：
gcloud container clusters get-credentials gke-staging-us-central1 --location us-central1-a連線至 GKE 叢集：
gcloud container clusters get-credentials gke-staging-us-central1 --location us-central1-a && kubectl port-forward --namespace sample $(kubectl get pod --namespace sample --selector="deploy.cloud.google.com/delivery-pipeline-id=sample" --output jsonpath='{.items[0].metadata.name}') 8080:8080在 Cloud Shell 工具列中，按一下
按一下「Web Preview」(網頁預覽)，然後點選「Preview on port 8080」(透過以下通訊埠預覽：8080)：
輸出內容如下：
My new feature!
在 Cloud Shell 中按下
CTRL+C，即可結束通訊埠轉送。
將變更從測試環境推行至實際工作環境
現在，請將發布內容從測試環境推送至實際工作環境。您有兩個實際工作叢集，Cloud Deploy 分別為這兩個叢集設定名為 prod1 和 prod2 的目標。
在 Cloud Shell 中執行下列指令，將版本從測試環境升級至 prod1 叢集：
gcloud deploy releases promote --release=$RELEASE --delivery-pipeline=sample --region=us-central1 --to-target=prod1 --quiet
發布至正式版叢集需要經過核准，因此推出作業會等到您核准後才開始。如要查看這份名單，請按照下列步驟操作：
按一下
sample管道。推出至 prod1 需要核准，且必須具備 clouddeploy.approver 角色才能核准推出作業。由於您是專案擁有者，因此有權核准發布。核准將版本推送至 prod1：
執行下列指令，擷取待核准的推出作業名稱，並儲存至環境變數：
export ROLLOUT=$(gcloud deploy targets describe prod1 --region=us-central1 --format="json" | jq -r '."Pending Approvals"[]' | awk -F '/' '{print $NF}')
核准發布：
gcloud deploy rollouts approve $ROLLOUT --delivery-pipeline=sample --region=us-central1 --release=$RELEASE --quiet
核准後，系統就會開始發布 prod1。在 Cloud Deploy 管道頁面監控進度。
prod1 部署完成後，啟動 prod2 版本。
gcloud deploy releases promote --release=$RELEASE --delivery-pipeline=sample --region=us-central1 --to-target=prod2 --quiet
發布至 prod2 也需要核准。核准將版本推送至 prod2 叢集：
執行下列指令，擷取待核准的推出作業名稱，並儲存至環境變數：
export ROLLOUT=$(gcloud deploy targets describe prod2 --region=us-central1 --format="json" | jq -r '."Pending Approvals"[]' | awk -F '/' '{print $NF}')
核准發布：
gcloud deploy rollouts approve $ROLLOUT --delivery-pipeline=sample --region=us-central1 --release=$RELEASE --quiet
核准後，系統就會開始發布 prod2 版本。在 Cloud Deploy 管道頁面監控進度。
prod1 和 prod2 中的 Cloud Deploy 管道完成後，請確認正式版叢集中的部署作業是否成功。
您在正式環境叢集中建立了多叢集 Ingress，並使用負載平衡器存取正式環境應用程式。這些 Multi Cluster Ingress 設定是使用存放區
sample中的 YAML 檔案 k8s/prod/mci.yaml 和 k8s/prod/mcs.yaml 建立。當您將要求傳送至負載平衡器的 IP 位址時，多叢集 Ingress 會將要求轉送至在兩個不同 GKE 叢集中執行的其中一個應用程式執行個體。列出與負載平衡器相關聯的轉送規則，找出 IP 位址。
gcloud compute forwarding-rules list
輸出內容會類似以下內容：
NAME: mci-qqxs9x-fw-sample-sample-ingress REGION: IP_ADDRESS: 34.36.123.118 IP_PROTOCOL: TCP TARGET: mci-qqxs9x-sample-sample-ingress
開啟網路瀏覽器，並在網址中輸入下列內容：
http://IP_ADDRESS:80
將
IP_ADDRESS替換為負載平衡器的 IP 位址。輸出內容如下：
My new feature!
這項操作可確認應用程式是否已如預期部署至實際工作環境叢集。
測試應用程式的彈性
在本節中，您將重新啟動其中一個正式版 GKE 叢集的節點，測試在正式環境中執行的應用程式的復原能力，且不會影響應用程式。
實際運作的應用程式會使用多叢集 Ingress，並可透過負載平衡器 IP 存取。透過該 IP 存取應用程式時，多叢集 Ingress 會將要求轉送至其中一個應用程式例項，這些例項會在兩個不同的 GKE 叢集上執行。當其中一個 GKE 叢集健康狀態不良，且無法連線至該叢集上執行的應用程式例項時，多叢集 Ingress 會持續將流量傳送至其他 GKE 叢集上執行的應用程式健康例項。這樣一來，叢集停機對使用者來說就毫無影響，應用程式也能持續處理要求。
如要測試復原力，請按照下列步驟操作：
找出在 us-west1 中執行的正式版 GKE 叢集節點集區。
gcloud container clusters describe gke-prod-us-west1 --location=us-west1-a --format=json | jq ".nodePools[0].instanceGroupUrls[]" | tr '"' ' ' | awk -F '/' '{for(i=NF-2; i<=NF; i=i+2) printf ("%s ",$i); print ""}'
輸出結果會與下列內容相似：
us-west1-b gke-gke-prod-us-west1-node-pool-01-6ad4e1ed-grp us-west1-c gke-gke-prod-us-west1-node-pool-01-98407373-grp
輸出內容有兩個資料欄，第一個資料欄是區域，第二個資料欄是與 us-west1 地區中正式版 GKE 叢集節點集區相關聯的執行個體群組名稱。
重新啟動節點集區對應的執行個體群組：
gcloud compute instance-groups managed rolling-action restart INSTANCE_GROUP_1 --zone=ZONE_1 --max-unavailable=100% gcloud compute instance-groups managed rolling-action restart INSTANCE_GROUP_2 --zone=ZONE_2 --max-unavailable=100%
將
INSTANCE_GROUP_1替換為第一個執行個體群組的名稱。將
ZONE_1替換為第一個執行個體群組的區域。將
INSTANCE_GROUP_2替換為第二個執行個體群組的名稱。將
ZONE_2替換為第二個執行個體群組的區域。檢查執行個體群組的狀態。
前往「Instance groups」(執行個體群組) 頁面
這兩個執行個體群組正在重新啟動，其他群組則有綠色勾號。
開啟網路瀏覽器，並在網址中輸入下列內容：
http://IP_ADDRESS:80
將
IP_ADDRESS替換為負載平衡器的 IP 位址。即使其中一個 GKE 叢集發生故障，應用程式仍可正常運作，輸出內容如下：
My new feature!
這表示您的應用程式具有彈性且高可用性。
管理應用程式
您從應用程式工廠建立這個應用程式時，會取得應用程式專用的 Git 存放區、基礎架構和 CI/CD 管道。您已使用這些資源部署應用程式，並新增功能。如要進一步管理應用程式，您只需要與這些 Git 存放區和管道互動，不必更新應用程式工廠。您可以根據需求自訂應用程式的管道和 Git 存放區。應用程式擁有者可以定義哪些人有權存取應用程式的管道和 Git 存放區，以便管理應用程式。