本文將說明最佳做法，協助您為環境邊緣執行的裝置設計及實作可靠的自動佈建和設定程序，例如：
如果您要為邊緣裝置、裸機系統和伺服器設計佈建和設定程序，或是想進一步瞭解這些裝置類型的佈建和設定最佳做法，請參閱本文。
本文並未列出所有可用的最佳做法，也無法保證您一定能成功佈建及設定邊緣和裸機系統與伺服器。而是協助您激發討論，瞭解佈建和設定程序可能有哪些變更和改善空間。
本文是系列文件之一，提供 Google Cloud上的 IoT 架構相關資訊。本系列的其他文件包括：
- 已連結裝置架構總覽 Google Cloud
- Google Cloud獨立 MQTT 代理程式架構
- IoT 平台產品架構 Google Cloud
- 裝置在 Pub/Sub 架構上 Google Cloud
- 在 Google Cloud 上執行 IoT 後端的最佳做法
- 自動佈建及設定邊緣和裸機系統與伺服器的最佳做法 (本文)
手動佈建及設定大量裝置容易發生人為錯誤，且無法隨著裝置數量增加而擴充。舉例來說，您可能會忘記執行重要的佈建或設定工作，或是依賴部分或完全未記錄的程序。全自動且可靠的佈建和設定程序有助於解決這些問題。此外，這些服務還能協助您管理每部裝置的生命週期，從製造、停用，到最終處置。
術語
如要瞭解如何為裝置實作及建構自動佈建和設定程序，請務必瞭解下列詞彙：
- 邊緣裝置：部署在環境邊緣的裝置，靠近要處理的資料。
- 佈建程序：您必須完成的一系列工作，才能準備好設定裝置。
- 設定程序：您必須完成的一系列工作，讓裝置在特定環境中運作。
- 設定管理：您持續執行的工作集，用於管理環境和裝置的設定。
- 基本映像檔：由貴公司或裝置/OS 製造商製作的最低限度作業系統 (OS) 或韌體映像檔。
- 黃金映像檔：您為裝置建立或從基本映像檔準備的不可變更 OS 或韌體映像檔。黃金映像檔包含裝置完成指派工作所需的所有資料和設定資訊。您可以準備各種黃金映像檔，以完成不同工作。黃金映像檔類型的同義詞包括「風味」、「衍生版本」和「原型」。
- 銀色映像檔：您為裝置準備的 OS 或韌體映像檔，方法是對黃金映像檔或基本映像檔套用最少的變更。執行 Silver 映像檔的裝置會在首次啟動時，根據裝置必須支援的使用案例需求，完成佈建和設定。
- 種子裝置：可啟動環境的裝置，不需外部依附元件。
- 網路開機：這組技術可讓裝置從網路取得軟體和任何相關設定資訊，而非從連接裝置的儲存系統取得。
為協助您設定目標及避免常見問題，請套用下列各節所述的佈建和設定最佳做法。
自動執行佈建和設定程序
裝置首次啟動時，或在任何必要時刻，都應僅使用內部安裝的軟體映像檔，自行佈建及設定。
為避免在佈建和設定程序中實作所需邏輯，您可以使用相關工具，取得自動化調度管理和實作這些程序所需的基元。舉例來說，您可以搭配指令碼或設定管理工具 (例如 Ansible、Puppet 或 Chef)，使用 cloud-init 和 NoCloud 資料來源，針對本機主機執行作業。
如要設計可靠的佈建和設定程序，請確保這些程序中執行的所有步驟和工作都有效，最好是自動執行。舉例來說，您可以使用自動化合規性測試架構 (例如 InSpec)，確認佈建和設定程序是否正常運作。
這項最佳做法可協助您避免單點故障，並在需要完成裝置佈建和設定時，免除手動介入的需要。
避免使用特殊用途裝置
設計邊緣裝置時，請盡量減少用途和專業領域的差異。這項建議並非指所有邊緣裝置都必須相同或共用相同用途，而是應盡可能同質。舉例來說，您可以根據裝置需要支援的工作負載類型，定義裝置原型。然後，您就可以根據這些原型裝置的屬性部署及管理裝置。
為確保您遵循這項最佳做法，請確認可以從特定原型隨機挑選裝置，然後執行下列操作：
- 請將裝置視為同類型的其他裝置。這代表你具備作業效率。
- 更換為相同原型裝置，無須額外自訂。這表示您已正確導入這些原型。
這項最佳做法可確保減少裝置群組的差異，進而減少環境中的片段，以及佈建和設定程序中的片段。
使用種子裝置啟動環境
在佈建及設定裝置時，您可能會遇到循環依附元件問題：裝置需要支援基礎架構才能佈建及設定自身，但由於您仍須佈建及設定基礎架構，因此基礎架構尚未就位。
您可以使用種子裝置解決這個問題。種子裝置具有暫時的特殊用途。完成專為特殊用途設計的任務後，裝置的行為和狀態會符合相關原型。
舉例來說，如果您使用 cloud-init 自動初始化裝置，可能需要透過下列方式設定 cloud-init NoCloud 資料來源：
- 透過檔案系統將 NoCloud 資料來源資料提供給種子裝置。
等待種子裝置完成自己的佈建和設定，包括透過網路將 NoCloud 資料來源資料提供給其他裝置。
種子裝置上的佈建和設定程序會等待，直到符合捨棄種子裝置臨時特殊用途的條件為止。這類情況包括：
- 環境中是否有其他裝置透過網路提供 NoCloud 資料來源資料？
- 叢集中是否有足夠的節點？
- 第一次備份是否已完成？
- 災難復原站點是否已準備就緒？
從種子裝置透過網路下載 NoCloud 資料來源資料，並佈建及設定其他裝置。部分裝置必須能夠透過網路提供 NoCloud 資料來源資料。
種子裝置上的佈建和設定程序會繼續執行，因為種子裝置已符合捨棄特殊用途的條件：機群中有其他裝置透過網路提供 NoCloud 資料來源資料。
種子裝置的佈建和設定程序會捨棄特殊用途，因此種子裝置與相同原型裝置的其他裝置並無不同。
這項最佳做法可確保您即使沒有支援基礎架構，也能啟動環境，且不會違反「避免使用專用裝置」最佳做法。
盡量減少裝置的狀態
設計邊緣裝置時，請盡量減少儲存有狀態資訊的需求。邊緣裝置的硬體資源可能有限，或部署在惡劣環境中。盡量減少運作所需的有狀態資訊，可簡化佈建、設定、備份和復原程序，因為您可以同質處理這類裝置。如果無狀態邊緣裝置開始故障且無法復原，舉例來說，您可以換成相同原型架構的裝置，盡量減少中斷或資料遺失的情況。
這項最佳做法可協助您避免因資料遺失或程序過於複雜而導致的意外問題。大部分的複雜性來自於需要支援異質裝置群組。
自動建構作業系統和韌體映像檔
為避免裝置首次啟動時需要進行昂貴的佈建和設定作業，並節省裝置資源，請先自訂 OS 和韌體映像檔，再提供這些映像檔。舉例來說，您可以直接在映像檔中安裝依附元件，而不必在每個裝置首次啟動時安裝。
準備裝置的 OS 和韌體映像檔時，請從基礎映像檔開始。自訂基礎映像檔時，您可以執行下列操作：
- 製作黃金圖片。黃金映像檔包含映像檔中的所有依附元件，因此裝置不必在首次啟動時安裝這些依附元件。製作黃金映像檔可能是一項複雜的工作，但可讓裝置在佈建和設定期間節省時間和資源。
- 製作銀色圖像。與黃金映像檔不同，執行白銀映像檔的裝置會在首次啟動時完成所有佈建和設定程序。製作銀級映像檔的複雜程度可能低於金級映像檔，但執行銀級映像檔的裝置在佈建和設定期間，會耗費更多時間和資源。
您可以在持續整合與持續部署 (CI/CD) 程序中自訂 OS 和韌體映像檔，並在驗證後自動將自訂映像檔提供給裝置。您可以使用 Cloud Build、GitHub Actions、GitLab CI/CD 或 Jenkins 等工具實作 CI/CD 程序，執行下列一連串工作：
- 對自訂圖片執行自動驗證。
- 將自訂圖片發布至存放區，供裝置取得。
如果 CI/CD 環境和您需要建構映像檔的 OS 或韌體使用不同的硬體架構，可以使用 QEMU 等工具模擬這些架構。舉例來說，您可以在 x86_64 架構上模擬 ARM 系列的硬體架構。
如要自訂 OS 或韌體映像檔，您必須能夠修改這些映像檔，並在測試環境中驗證修改內容，然後再安裝到邊緣裝置。使用 chroot 等工具，您可以在執行指令前虛擬變更根目錄，但不會實際變更。
這項最佳做法可協助您自訂 OS 和韌體映像檔，再將映像檔提供給裝置。
可靠地協調裝置上執行的工作負載
如果裝置支援異質工作負載，您可以使用下列工具自動化調度管理這些工作負載，並管理其生命週期：
- 工作負載自動化調度管理系統：使用工作負載自動化調度管理系統 (例如 Kubernetes)，適合用於具有複雜自動化調度管理或生命週期管理需求的工作負載。這些系統也適合用於跨多個元件的工作負載。在這兩種情況下，您都不必自行實作自動化調度管理和工作負載生命週期管理邏輯。如果裝置資源有限，可以安裝比標準 Kubernetes 資源需求更少的輕量型 Kubernetes 發行版本，例如 MicroK8s、K3s 或使用邊緣設定檔安裝的 Google Distributed Cloud。
Init 系統：使用 init 系統 (例如 systemd) 適用於具有下列特徵的工作負載：
- 簡單的自動化調度管理需求
- 缺乏資源來支援工作負載自動化調度管理系統
- 無法放入容器的工作負載
建立工作負載協調系統後，您也可以使用該系統執行佈建和設定程序中的工作。如果您需要在佈建和設定程序中執行設定管理工具，可以像使用任何其他工作負載一樣，使用工作負載協調系統。
這項最佳做法可確保您能協調裝置上執行的工作負載。
驗證、驗證及連線裝置
如要確認裝置是否需要連線至外部系統 (例如其他裝置或後端)，請參閱下列小節的建議。
這項最佳做法有助於：
- 為裝置設計安全的通訊管道。
- 避免潛在後門繞過裝置的安全範圍。
- 確認裝置不會公開未經授權的介面，以免遭到攻擊者利用。
強制執行的連線做法
- 在交換任何資訊前，請先驗證提出資訊要求的其他方。
- 確認傳輸的資訊不會透過非預期的管道傳輸。
- 依賴受信任的執行環境處理密碼，例如加密金鑰、驗證金鑰和密碼。
- 使用任何 OS 或韌體映像檔前，請先驗證完整性和真實性。
- 驗證使用者提供的任何設定是否有效、完整且真實。
- 不要安裝不必要的軟體，並移除裝置上已有的軟體，以減少受攻擊面。
- 限制使用權限作業和帳戶。
- 如果裝置外殼必須防範實體操控和竄改，請確認外殼的完整性。
應避免的連線方式
- 請勿透過未加密的管道傳輸私密資訊。
- 請避免開放特殊權限，例如：
- 虛擬或實體序列埠和序列主控台，即使只有在有人實際竄改裝置時才能存取這些埠，也可能遭到濫用。
- 可回應來自網路的要求，並執行具備權限作業的端點。
- 請勿在作業系統或韌體映像檔、設定或原始碼中，使用硬式編碼憑證。
- 請勿揭露任何資訊，以免對手收集資訊來取得更高權限。舉例來說，您應該加密裝置上的資料，並關閉生產裝置上不必要的追蹤和記錄系統。
- 禁止使用者和工作負載執行任意程式碼。
監控裝置
收集裝置狀態資訊時，不需手動介入，這對環境的可靠性至關重要。確認裝置會自動回報所有必要資料。收集及監控資料的主要原因有兩個：
- 確保裝置正常運作。
- 主動發現問題並執行預防性維護。
舉例來說，您可以使用 Cloud Monitoring 收集監控指標和事件。
為協助您調查及排解問題，建議您設計及實作相關程序，以便在裝置正常運作期間監控裝置的程序之外，收集高解析度的診斷資料，例如詳細的監控、追蹤和偵錯資訊。收集高解析度診斷資料並透過網路傳輸，在裝置資源 (例如運算、資料儲存和電力) 方面可能相當昂貴。因此，建議您只在需要時，才為需要進一步調查的裝置啟用程序，以收集高解析度的診斷資料。舉例來說，如果其中一個裝置無法正常運作，且裝置回報的例行監控資料不足以徹底診斷問題，您可以為該裝置啟用高解析度資料收集功能，讓裝置回報更多資訊，協助您調查問題原因。
這項最佳做法可確保裝置不會處於不明狀態，並提供足夠的資料，讓您判斷裝置的效能是否良好。
支援無人值守啟動和升級
設計佈建和設定程序時，請確保裝置能自動啟動，且您已備妥必要的基礎架構。導入無人值守的開機機制，同時支援首次開機和無線更新，可提高基礎架構的維護性。使用無人值守啟動功能，可免除在每部裝置啟動或升級時手動操作。 手動處理大量裝置容易出錯，因為操作人員可能會遺漏或錯誤執行動作，也可能沒有足夠時間為機群中的每部裝置執行必要動作。
此外，您也不必預先準備每部裝置，即可啟動正確的 OS 或韌體映像檔。舉例來說，您可以發布新版 OS 或韌體映像檔，並將該版本設為裝置從網路取得啟動指令時可選擇的選項之一。
這項最佳做法可確保裝置能執行自動化無人看管的啟動和升級作業。
設計及實作彈性程序
即使佈建和設定程序完全自動化，仍可能發生錯誤，導致這些程序無法正確完成，進而使裝置處於不一致的狀態。請導入重試和備用機制，確保裝置能從這類故障中復原。如果裝置無法完成佈建和設定程序中的工作，例如，裝置應會自動嘗試從失敗中復原。裝置從故障中復原或回復正常運作後，可以從程序失敗的點繼續執行程序。
這項最佳做法可協助您設計及導入彈性佈建和設定程序。
支援裝置的整個生命週期
設計佈建和設定程序時，請確保這些程序可以管理整個裝置生命週期。有效管理裝置生命週期包括規劃終止和處置，即使裝置預計運作時間相對較長也一樣。
如果沒有管理裝置生命週期，可能會導致下列問題：
- 持續高昂的費用：在佈建和設定程序完成後，才導入生命週期管理支援功能，可能會增加費用。如果在設計初期就規劃這項支援，或許可以降低這些成本。如果您的佈建和設定程序不支援裝置的整個生命週期，例如您可能必須手動介入每部裝置，才能妥善處理裝置生命週期的每個階段。手動介入的成本可能很高，而且通常無法擴大規模。
- 僵化程度提高：不支援生命週期管理最終可能導致無法更新或管理裝置。如果沒有安全且有效率的裝置關機機制，管理裝置生命週期和最終處置可能會很困難。
後續步驟
- 請參閱已連結裝置架構 Google Cloud。
- 如需更多參考架構、圖表和最佳做法，請瀏覽 Cloud 架構中心。 。
貢獻者
作者：Marco Ferrari | 雲端解決方案架構師