Google Cloud 上的 CI/CD
隨著雲原生服務和數位轉型浪潮的崛起，越來越多的企業或組織開始嘗試將服務重構成雲原生應用服務之外，也越來越多組織開始嘗試使用公有雲或其他 PAAS、SAAS …等不同類型的代管服務．除此之外，今年 (2022) 也越來越多組織開始進行各式各樣的數位轉型，大量開出雲端相關職缺，試圖保持組織在各自領域的領先優勢或競爭力．組織在進行服務重構及轉型的同時，可能已有既有的 CI/CD pipeline ，亦或者沒有．而不管是考慮導入、轉換或調整 CI/CD pipeline，對於組織來說是一件需要考慮眾多面向的重大議題，甚至牽扯到組織文化的轉變，由於相關內容過於龐大，此篇文章不深入討論．我們想討論的是，在組織轉型的過程中，GCP所提供的雲原生 CI/CD pipeline 相關代管服務，也就是 Cloud Build、Cloud Deploy 以及 Cloud Run 有何優勢以及其能夠為組織帶來什麼好處。
Cloud Build
在一般的開發流程中，開發人員通常會在本地開發應用服務新的功能或需求，並在本地依需求安裝 docker 或是 k8s 環境；當開發完成後，開發人員會嘗試在本地 build (docker build 或 podman build…等)，然後在本地透過 docker 或 k8s 執行 build 好的 image，初步測試確認沒有問題後，將寫好的 code push 到 Source code management (SCM)，接著可能會觸發 CI/CD pipeline 一系列的動作，而透過一系列的檢查、測試及執行順利完成後，會產出一個新的 artifact (image) 並推送至 repository，到這裡，我們可以廣義地說這是一個 CI 的段落。
而透過 Cloud Build，當開發人員寫好原始碼並將其推送至 Cloud Source Repositories (GCP 的 SCM 全代管服務)，可以在 Cloud Build 撰寫一個事件，當原始碼 push 上 SCM 後 (或其他事件) 自動透給 GCP 的運算資源 build artifact，並將artifact 推送至 Artifact Registry (前身為 Container Registry) 或 Docker Hub…等 repository．至此，透過一系列的 CI 代管服務，不管是管理或開發人員，再也不需要管理 CI 服務或 Server ，以及底層的基礎設施，僅需專注在各自負責的領域 (維運及開發) 即可．此外，Cloud Build 還提供其他彈性的功能，比如：開發人員在將原始碼推送至 SCM 前，通常都需要測試、驗證及除錯，這時可以透過 Cloud Build 的 local build 功能，先在本地進行 build 及相關測試，確認沒有問題，推送原始碼後再透過 Cloud Build 進行後續一系列的動作；Cloud Build 是 GCP 全代管服務並透過 Internet 進行相關運作，如果組織想要使用 private IP 或更進一步地控制 Cloud Build 的資源，可透過 Cloud Build 的 Private pool 進行實作，設定完成後，先從地端透過 Interconnect 或 VPN 連接至 GCP 的對應專案，即可連到透過 peering 連接 GCP 管理 service producer network 環境內的 worker。
Cloud Run
Knative 是 Google 以及其他 50+ 不同組織合力貢獻的開源專案，其用途為在 Kubernetes 上執行無伺服器的應用服務，Cloud Run 即是一套基於 Knative 的全代管無伺服器容器平台；換句話說，不像 GKE，使用者 (平台管理者或是開發人員) 無需管理 worker node 及複雜的 yaml 檔案部署設定，只需透過 Cloud console 點選幾下即可輕鬆部署及測試應用服務，讓相關人員可以更專注在應用服務上．也因為這個特性，Cloud Run 可以當作一個快速驗證的平台，開發人員可以將 build 好的 artifact 透過 Cloud Run 執行，無須考慮 Kubernetes cluster 維運及 yaml 檔撰寫…等問題，測試完成後再將部署其上的服務消滅即可．此外，Cloud Run 獨特的 scale-to-zero 功能，可以在應用服務沒有服務流量時，將 instance 降至 0，待服務流量進來時，再啟動應用服務提供使用者使用。
Cloud Deploy
如果說 Cloud Build 是屬於 CI (Continuous Integration) 的範疇，那 Cloud Deploy 即是屬於 CD (Continuous Deployment 或 Continuous Delivery) 的範疇．透過代管服務 Cloud Deploy，可將應用服務的 artifact，透過自定義的部署流水線 (delivery pipeline) 從 repository 部署到目標環境中；接著，我們可以將服務 promote (rollout) 到 release pipeline 的下一個目標 (部署到另一個環境中) 或是從 pipeline 某個目標 rollback 到上一個目標．而藉由 Cloud Deploy，我們不用再建立及維運 CD 服務或 Server，僅需設定及操作 Cloud Deploy 來管理我們的部署流水線即可。
Google 全代管服務，助企業解決 CI/CD 或維運的需求
CI/CD 看似僅僅是一條流水線，但實際上因應每一個不同的組織需求都會衍生出不同的樣貌，產生出千變萬化的結果，如同文章開頭所述，其是一門非常複雜的學問，短短的千字文章不足道完．Google 提供了 Cloud Build、Cloud Deploy 以及 Cloud Run…等 ready to go 的全代管服務試圖解決組織的 CI/CD 或維運的需求，但符不符合組織需求？在怎樣的情境下使用？這些問題在每個組織都有不同的答案，需要審慎評估及考量．本文簡單介紹了 Cloud Build、Cloud Run 以及 Cloud Deploy 的功能及特點，希望能讓讀者對這三樣服務有初步的了解及認識，對於往後評估 CI/CD pipeline 解決方案時也能有更多樣的可能性可供選擇。
發布日期: 2022-04 | Solomon
