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

Last reviewed 2024-12-08 UTC

本文件可協助您規劃和設計遷移路徑，從手動部署轉換為自動化容器化部署，並 Google Cloud使用雲端原生工具和 Google 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：評估及探索工作負載」文件說明如何在遷移期間評估環境，以及如何建立應用程式清單。

您需要針對每個構件評估其測試涵蓋率。您應先為所有構件提供適當的測試涵蓋率，再繼續進行下一個步驟。如果您必須手動測試及驗證每個構件，就無法從自動化中獲得好處。採用強調測試重要性的方法，例如測試驅動式開發。

評估程序時，請考量實際工作環境中可能有多少不同版本的構件。舉例來說，如果某個構件最新版本比您必須支援的執行個體版本早了好幾個版本，您就必須設計出可支援這兩個版本的模型。

也請考量用於管理程式碼庫的分支策略。分支策略只是您需要評估的協作模型的一部分，您需要評估團隊內部和外部的更廣泛協作程序。舉例來說，如果您採用彈性分支策略，但未將其調整為符合通訊程序，這些團隊的效率可能會降低。

在這個評估階段，您也要決定如何讓產生的構件比目前的部署程序更有效率，且更適合進行容器化。提升效率的方法之一，就是評估下列項目：

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

規劃及建立基礎

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

  • 在 Google Cloud 環境中支援工作負載。
  • 連結來源環境和 Google Cloud 環境，完成遷移作業。

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

  1. 建立資源階層。
  2. 設定 Google Cloud的 Identity and Access Management (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 | 雲端解決方案架構師