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

Last reviewed 2024-12-08 UTC

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

您需要評估每個構件的測試涵蓋率。在進行下一步之前，您應該為所有構件提供適當的測試涵蓋範圍。如果必須手動測試及驗證每個構件，就無法享有自動化帶來的好處。採用強調測試重要性的方法，例如測試推動開發。

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

此外，也請考量您用來管理程式碼集的分支策略。分支策略只是協作模式的一部分，您需要評估團隊內外的更廣泛協作流程。舉例來說，如果您採用彈性的分支策略，但未根據通訊程序進行調整，這些團隊的效率可能會降低。

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

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

規劃及奠定基礎

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

  • 支援 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 實作部署程序。

設計及實作部署程序時，請考量如何將設定檔和密鑰插入工作負載，以及如何管理有狀態工作負載的資料。設定檔和 Secret 插入功能有助於產生不可變動的構件。部署不可變的構件可讓您：

  • 例如，您可以在開發環境中部署構件。接著，在測試及驗證後，將其移至品質查驗環境。最後，您會將這些項目移至正式環境。
  • 由於同一個構件會經過多項測試和驗證活動，因此可降低正式環境發生問題的機率。

如果工作負載為有狀態，建議您為資料佈建及設定必要的永久儲存空間。在 Google Cloud上，您有不同的選項：

最佳化環境

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

這項最佳化疊代作業的需求如下：

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

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

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

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

改用自動部署

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

評估並探索工作負載

根據先前的評估結果，您現在可以專注於部署程序的相關需求：

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

即使您需要支援手動部署步驟，也不代表您的程序無法自動化。在這種情況下，您會自動執行程序的每個步驟，並在適當的位置設定手動核准閘。

支援每天或每小時多次部署，比支援每月或每年幾次部署更複雜。不過，如果不常部署，您在工作負載中應對問題和推出新功能的靈活性和能力可能會降低。因此，在設計及實作全自動部署程序之前，建議您先設定期望和目標。

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

規劃及奠定基礎

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

請為每個執行階段環境設定必要的基礎架構，以支援部署程序。舉例來說，如果您在開發、品質查驗、正式生產前和正式環境中佈建及設定部署程序，就能自由彈性地測試程序變更。不過，如果您使用單一基礎架構部署執行階段環境，環境會更容易管理，但需要變更程序時，彈性會較低。

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

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

在這個階段，您會設定部署程序，在不需手動介入的情況下部署構件，但核准步驟除外。

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

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

  1. 在目標執行階段環境中部署構件。
  2. 將設定檔和 Secret 插入已部署的構件。
  3. 對新部署的構件執行法規遵循測試套件。
  4. 將構件推送至正式環境。

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

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

最佳化環境

自動化部署程序後，您可以執行另一個最佳化疊代。這項疊代作業的需求如下：

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

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

有效率地自動調度管理容器後，您就能視需求實作進階部署模式。例如，您可以實作藍綠部署，提高環境的可靠性，並減少任何問題對使用者的影響。

後續步驟

貢獻者

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