遷移至 Google Cloud：從手動部署遷移至自動化容器化部署

Last reviewed 2024-12-08 UTC

本文可協助您規劃及設計遷移路徑，從手動部署作業改為使用雲端原生工具和 Google CloudGoogle Cloud 代管服務，自動部署容器化應用程式。

本文是下列多部分系列文章之一，探討如何遷移至Google Cloud：

如果您打算採用現代化部署程序，或是要從手動和舊版部署程序遷移至自動化和容器化部署作業，或是正在評估遷移的可能性，並想瞭解遷移的預期情況，本文都能提供實用的參考資料。

開始遷移前，請先評估遷移範圍和目前的部署程序狀態，並設定預期結果和目標。您可以根據目前部署工作負載的方式選擇起點：

  • 您是手動部署工作負載。
  • 您使用設定管理 (CM) 工具部署工作負載。

很難直接從手動部署轉移到全自動化和容器化部署。建議您改為採取下列遷移步驟：

  1. 使用容器自動化調度管理工具進行部署。
  2. 自動部署。

這是理想的遷移路徑，但如果遷移至下一個步驟的好處大於特定情況的成本，您可以在遷移程序中提早停止。舉例來說，如果您不打算自動部署工作負載，則在使用容器自動化調度管理工具部署後，即可停止。日後準備好繼續這趟旅程時，可以隨時返回這份文件。

從一個遷移步驟移至下一個步驟時，會進入轉換階段，您可能會同時使用不同的部署程序。事實上，您不需要為所有工作負載選擇單一部署選項。舉例來說，您可能擁有混合式環境，並使用 CM 工具部署特定工作負載，同時使用容器協調工具部署其他工作負載。

如要進行這項遷移作業，建議您按照「遷移至 Google Cloud：開始使用」一文所述的遷移架構操作。 Google Cloud

以下是遷移流程圖。

列出四個階段的遷移路徑。

您可能會從來源環境遷移至 Google Cloud ，並進行一系列的疊代作業，例如先遷移部分工作負載，再遷移其他工作負載。針對每個個別的遷移疊代作業，您會遵循一般遷移架構的階段：

  1. 評估及探索工作負載和資料。
  2. 規劃並奠定 Google Cloud的基礎。
  3. 將工作負載和資料遷移至 Google Cloud。
  4. 將 Google Cloud 環境調整至最佳狀態。

如要進一步瞭解這個架構的各個階段，請參閱「遷移至 Google Cloud：開始使用」。

為設計有效的遷移計畫，建議您驗證計畫的每個步驟，並確保您有復原策略。如要驗證遷移計畫，請參閱「遷移至 Google Cloud：驗證遷移計畫的最佳做法」。

遷移至容器自動化調度管理工具

如要擺脫手動部署，首先要使用容器自動化調度管理工具部署工作負載。在這個步驟中，您將設計及實作部署程序，以便使用 Kubernetes 等容器自動化調度管理工具，處理容器化工作負載。

如果工作負載尚未容器化，您將需要投入大量心力進行容器化。並非所有工作負載都適合容器化。如果您部署的工作負載不適合雲端或容器化，可能就不值得容器化。基於技術或授權原因，部分工作負載甚至無法支援容器化。

評估及探索工作負載

如要劃定遷移範圍，您必須先列出您產生及部署的構件，以及這些構件對其他系統和構件的依附元件。如要建立這份清單，您必須找來負責設計及實作目前構件生產和部署程序的團隊，並利用他們的專業知識。「遷移至 Google Cloud：評估及探索工作負載」一文說明如何在遷移期間評估環境，以及如何建立應用程式清單。

您需要評估每個構件的測試涵蓋範圍。請務必先為所有構件提供適當的測試涵蓋範圍，再繼續進行下一個步驟。如果必須手動測試及驗證每個構件，就無法享有自動化作業的好處。採用強調測試重要性的方法，例如測試驅動開發。

評估程序時，請考量您在生產環境中可能擁有的構件版本數量。舉例來說，如果 Artifact 的最新版本比您必須支援的執行個體版本新了好幾代，您就必須設計同時支援這兩個版本的模型。

此外，也請考慮您用來管理程式碼基底的分支策略。分支策略只是您需要評估的協作模型之一，您還需要評估團隊內外的廣泛協作程序。舉例來說，如果您採用彈性分支策略，但未將其套用至通訊程序，這些團隊的效率可能會降低。

在這個評估階段，您也會判斷如何讓產生的構件更有效率，且比目前的部署程序更適合容器化。如要提高效率，請評估下列項目：

  • 共同部分：評估構件的共同點。舉例來說，如果您有常見的程式庫和其他執行階段依附元件，不妨考慮將這些項目整合到一個執行階段環境。
  • 執行階段環境需求：評估是否能簡化執行階段環境，減少變異。舉例來說，如果您使用不同的執行階段環境來執行所有工作負載，建議從通用基礎開始，以減輕維護負擔。
  • 不必要的元件：評估構件是否含有不必要的零件。舉例來說，您可能擁有並非絕對必要的公用程式工具，例如偵錯和疑難排解工具。
  • 設定和密鑰注入：根據執行階段環境的需求，評估您設定構件的方式。舉例來說，目前的設定注入系統可能不支援容器化環境。
  • 安全性需求：評估容器安全模式是否符合您的需求。舉例來說，容器化環境的安全模式可能與工作負載的需求衝突，例如工作負載需要超級使用者權限、直接存取系統資源或單一租戶。
  • 部署邏輯規定：評估是否需要導入進階部署程序。舉例來說，如果您需要實作Canary 部署程序，可以判斷容器自動化調度管理工具是否支援該程序。

規劃及奠定基礎

在規劃和建構階段，您會佈建及設定基礎架構，以執行下列操作：

  • 滿足環境中的工作負載需求。 Google Cloud
  • 連線來源環境和 Google Cloud 環境，完成遷移作業。

規劃和建構階段包含下列工作：

  1. 建立資源階層。
  2. 設定 Google Cloud身分與存取權管理 (IAM)。
  3. 設定帳單資訊。
  4. 設定網路連線。
  5. 強化安全性。
  6. 設定記錄、監控和快訊功能。

如要進一步瞭解各項工作，請參閱「遷移至 Google Cloud：規劃及建構基礎」。

為取得管理 Google Cloud 資源所需的彈性，建議您設計Google Cloud 資源階層，支援多個環境，例如開發、測試和生產工作負載。

建立使用者和服務身分時，為確保最佳隔離效果，您至少需要為每個部署程序步驟建立服務帳戶。舉例來說，如果您的程序會執行步驟來產生構件，並管理該構件在存放區中的儲存空間，則至少需要兩個服務帳戶。如要為部署程序佈建及設定開發和測試環境，可能需要建立更多服務帳戶。如果您為每個環境提供不同的服務帳戶組合，就能讓各個環境彼此獨立。雖然這種設定會增加基礎架構的複雜度，並加重營運團隊的負擔，但您可彈性地獨立測試及驗證部署程序中的各項變更。

您也需要佈建及設定服務和基礎架構，以支援容器化工作負載：

使用容器自動化調度管理工具部署新工作負載時，您不必擔心基礎架構佈建問題。舉例來說，您可以使用 Autopilot 自動管理 GKE 叢集設定。

使用容器自動化調度管理工具部署構件

根據您在評估階段和這個步驟的基礎階段收集到的需求，執行下列操作：

  • 將工作負載容器化。
  • 實作部署程序，處理容器化工作負載。

容器化工作負載並非易事。以下是您需要調整和擴充的活動一般清單，以便將工作負載容器化。您的目標是滿足自身需求，例如網路和流量管理、持續性儲存空間、密鑰和設定注入，以及容錯能力需求。本文涵蓋兩項活動：建構一組做為基礎的容器映像檔，以及建構一組工作負載的容器映像檔。

首先，您要自動化構件製作程序，這樣就不必為每次新部署手動製作新映像檔。每次修改原始碼時，系統應會自動觸發構件建構程序，讓您立即收到每次變更的回饋。

請執行下列步驟來生成每張圖片：

  1. 建構映像檔。
  2. 執行測試套件。
  3. 在登錄檔中儲存映像檔。

舉例來說，您可以使用 Cloud Build 建構構件、對構件執行測試套件，並在測試成功後將結果儲存在 Artifact Registry 中。

您也需要建立規則和慣例，以識別構件。製作圖片時，請為每張圖片加上標籤，確保每次執行程序時都能重複。舉例來說，常見的慣例是使用語意版本控制來識別版本，也就是在產生版本時為容器映像檔加上標記。如果產生的圖片仍需修改才能發布，您可以使用 ID 將圖片與程式碼庫中的某個點建立關聯，以便瞭解圖片的產生位置。舉例來說，如果您使用 Git 存放區，可以將提交雜湊做為相應容器映像檔的 ID。當您將提交內容推送至存放區的主要分支時，系統會產生該容器映像檔。

在這個步驟的評估階段，您已收集構件、構件的常見部分，以及構件的執行階段需求相關資訊。有了這些資訊，您就能設計及建構一組基本容器映像檔，以及另一組工作負載映像檔。您可以使用基礎映像檔做為起點，為工作負載建構映像檔。應嚴格控管及支援基本映像檔集，避免不受支援的執行階段環境增生。

從基本映像檔製作容器映像檔時，請記得擴充測試套件，涵蓋映像檔，而不只是每個映像檔內的工作負載。您可以使用 InSpec 等工具，針對執行階段環境執行合規性測試套件。

完成工作負載容器化作業，並實作自動產生這類容器映像檔的程序後，請實作部署程序，以便使用容器自動化調度管理工具。在評估階段，您會使用收集到的部署邏輯需求資訊，設計豐富的部署程序。有了容器協調工具，您就能專心使用現成的機制來編寫部署邏輯，而不必手動實作邏輯。舉例來說，您可以使用 Cloud Deploy 實作部署程序。

設計及實作部署程序時，請考慮如何在工作負載中插入設定檔和密鑰，以及如何管理有狀態工作負載的資料。設定檔和密鑰注入功能有助於產生不可變更的構件。部署不可變更的構件，可執行下列操作：

  • 舉例來說，您可以在開發環境中部署構件。接著，在測試及驗證後，將這些規則移至品質保證環境。最後再移至正式環境。
  • 因為相同的構件經過多次測試和驗證活動，因此可降低實際執行環境發生問題的機率。

如果工作負載是有狀態的，建議您為資料佈建及設定必要的永久儲存空間。在 Google Cloud上，你可以選擇下列做法：

最佳化環境

實作部署程序後，您可以使用容器自動化調度管理工具，開始最佳化部署程序。詳情請參閱「遷移至 Google Cloud：最佳化環境」。

本次最佳化疊代的規定如下：

  • 視需要擴充監控系統。
  • 擴大測試涵蓋範圍。
  • 提升環境安全性。

您擴充監控系統，涵蓋新的構件製作、部署程序，以及所有新的執行階段環境。

如要盡可能有效監控、自動化及編碼程序，建議您擴大測試範圍。在評估階段，您確保至少有最低的端對端測試涵蓋範圍。在最佳化階段，您可以擴充測試套件，涵蓋更多用途。

最後，如要提高環境安全性，可以設定二進位授權，只允許在叢集中部署一組已簽署的映像檔。您也可以啟用 Artifact Analysis，掃描儲存在 Artifact Registry 中的容器映像檔，檢查是否有安全漏洞。

遷移至部署自動化

遷移至容器自動化調度管理工具後，您就可以改用全自動化部署，並擴充構件生產和部署程序，自動部署工作負載。

評估及探索工作負載

以先前的評估為基礎，現在您可以專注於部署程序的相關需求：

  • 手動核准步驟：評估是否需要在部署程序中支援任何手動步驟。
  • 每次部署的單位數：評估您需要支援的每次部署單位數。
  • 導致新部署作業的因素：評估哪些外部系統會與部署程序互動。

如果您需要支援手動部署步驟，不代表程序無法自動化。在本例中，您會自動執行程序的每個步驟，並在適當位置放置手動核准閘道。

與每月或每年支援幾次部署相比，每天或每小時支援多次部署更為複雜。不過，如果部署頻率不高，工作負載的敏捷度可能會降低，您對問題的反應能力和新功能發布能力也可能受到影響。因此，在設計及實作全自動部署程序之前，建議您先設定期望和目標。

此外，也請評估哪些因素會在執行階段環境中觸發新的部署作業。舉例來說，您可能會在開發環境中部署每個新版本，但只有在符合特定品質條件時，才在品質保證環境中部署版本。

規劃及奠定基礎

為了擴充您在上一個步驟中建構的基礎，請佈建及設定服務，以支援自動化部署程序。

為每個執行階段環境設定必要基礎架構，以支援部署程序。舉例來說，如果您在開發、品質保證、實際工作前置和實際工作環境中佈建及設定部署程序，就能自由且彈性地測試程序變更。不過，如果使用單一基礎架構部署執行階段環境，環境管理會比較簡單，但需要變更程序時，彈性較低。

在佈建服務帳戶和角色時，請考慮建立專屬服務帳戶，避免共用職責，藉此隔離環境和工作負載。舉例來說，請勿為不同的執行階段環境重複使用相同的服務帳戶。

透過全自動化程序部署構件

在這個階段，您會設定部署程序，以便在沒有手動介入的情況下部署構件 (核准步驟除外)。

您可以根據這個遷移步驟評估階段收集到的需求，使用 Cloud Deploy 等工具實作自動部署程序。

針對任何指定構件，每個部署程序都應執行下列工作：

  1. 在目標執行階段環境中部署構件。
  2. 在部署的構件中插入設定檔和密鑰。
  3. 針對新部署的構件執行合規性測試套件。
  4. 將構件推行至實際工作環境。

請確認部署程序提供介面，可根據您的需求觸發新的部署作業。

實作自動化部署程序時，程式碼審查是必要步驟，因為這些程序在設計上會納入短暫的意見回饋迴圈。舉例來說，如果您未經任何審查就將變更部署至實際工作環境，實際工作環境的穩定性和可靠性就會受到影響。未經審查、格式錯誤或惡意的變更可能會導致服務中斷。

最佳化環境

部署程序自動化後，即可再次執行最佳化疊代。本次疊代的規定如下：

  • 擴充監控系統，涵蓋支援自動部署程序的基礎架構。
  • 導入更進階的部署模式。
  • 實作急用權限程序。

有效的監控系統可協助您規劃環境的進一步最佳化作業。評估環境行為時，您可以找出任何阻礙效能的瓶頸或其他問題，例如未經授權或意外的存取和利用。舉例來說，您可以設定環境，在特定資源的用量達到門檻時收到快訊。

有效協調容器後，您就能根據需求實作進階部署模式。舉例來說，您可以實作藍/綠部署，提高環境的可靠性，並減少任何問題對使用者的影響。

後續步驟

貢獻者

作者：Marco Ferrari | 雲端解決方案架構師