高效 Docker 映射部署以進行低頻寬連線

本文說明在間歇性或低頻寬因特網連線之間部署容器化物聯網 （IoT） 邊緣模組的解決方案。

邊緣處理是一種重要的物聯網 （IoT） 模式，可提供低延遲連線並節省頻寬，例如在行動案例中。 IoT 系統通常會藉由部署軟體容器映像來布建邊緣裝置。 透過間歇性低頻寬因特網連線中斷的容器部署可能會導致行動案例失敗。 帶寬有限、間歇性或低頻寬的IoT案例需要可靠且具彈性的部署功能。

在此範例中，大型物流公司想要改善其全球產品出貨追蹤。 該公司向許多地區運送了各種地面、航空和海上運輸方法的貨物，包括間歇性、低頻寬因特網連線的地區。 根據貨物類型，產品出貨具有各種IoT保險、安全或追蹤裝置，並安裝了不同的功能。 裝置包括 GPS 追蹤器、溫度感測器，以及數據擷取工具。

該公司在最近開發的 Azure IoT Edge 平臺上更新裝置時發生問題。 主要痛點如下：

• 將更新的軟體部署至裝置時，高頻寬耗用量。
• 跨裝置沒有標準化的自動化部署。
• 技術選擇的彈性有限。

為了解決這些問題，開發小組建立了一個解決方案：

• 將每個裝置的部署大小降到最低，以減少頻寬。
• 實作從IoT Edge平臺到異質遠端IoT裝置的標準化Docker容器部署。
• 啟用可靠的部署監視。
• 利用各種 Azure DevOps 和雲端服務，並使用客戶慣用的舊版工具。

解決方案可大幅提升裝置布建程式在有限連線環境中的可靠性與復原能力。 本文說明解決方案詳細數據和解決方案選項評估程式。

客戶需求

客戶有下列需求：

• 解決方案必須支援間歇性低頻寬雲端連線能力。
• 已部署的應用程式必須繼續在本機執行。
• 本地人員必須離線使用功能，或不需要雲端來回延遲。
• 線上時，解決方案必須有效率地使用雲端連線。
• 解決方案必須根據一致定義的商務規則，排定跨產品傳送數據的優先順序。

也有下列詳細需求：

• 圖像檔會透過低頻寬、間歇性連線衛星連線傳輸。
• 傳輸的數據量應最小化。
• 將檔案傳輸至裝置會使用客戶慣用的第三方應用程式。
• 裝置工作負載會在IoT Edge中使用 Docker 映像。
• 影像大小範圍從數十 MB 到數 GB。
• IoT Edge 模組是以 .NET Core 2.2 撰寫。

潛在的使用案例

此解決方案適用於IoT案例，其中軟體容器會透過低頻寬、間歇性連線來提供解決方案。 範例包含：

• 遠端石油、天然氣和採礦監視
• 無線汽車更新
• 不保證任何強式連線的地方

架構

在高頻寬案例中，Azure IoT Edge 會直接從可因特網存取的 Docker 登錄提取映像，例如 Docker 中樞或私人中樞，例如 Azure Container Registry。 這項功能與執行 docker pull <image_name> 命令相同。

由於網路存取可能間歇性，例如衛星因特網連線，Docker 提取方法並不可靠。 如果 Docker 正在提取映射時因特網連線中斷，則不會快取進度。 當因特網連線繼續時，Docker 必須從頭開始再次提取映像。

解決方案會使用替代部署機制、Docker 映像檔案的二進位修補，以減少頻寬並補償間歇性連線。

資料流程

1. 開發人員與原始程式碼存放庫中的邊緣模組原始程式碼互動。
2. Container Registry 會儲存每個模組的 Docker 映像。
3. 指令清單存放庫包含所有工作流程的部署指令清單。
4. 每個模組都有一個 Azure Pipelines 建置管線，其會使用一般 Docker 組建自動建立和註冊模組。
5. 映射到裝置管線會將 Docker 映像部署到目標裝置，如指令清單檔案所定義。
6. 指令清單到裝置管線會將部署指令清單推送至更新裝置的適當 Azure IoT 中樞。
7. 第三方快速檔傳輸解決方案會將檔案從 Azure 儲存體 帳戶傳輸到裝置。
8. 映像重建IoT Edge模組會在裝置上套用收到的修補程式。
9. IoT 中樞 會從影像重建模組接收狀態消息，並設定裝置的部署指令清單。 管線流程的其餘部分會使用此部署指令清單。
10. Azure Functions 會監視 IoT 中樞 訊息串流、更新 SQL 資料庫，並通知使用者成功或失敗。
11. Azure SQL 資料庫 追蹤目標裝置和 Azure 服務在部署期間和之後發生的次數。

元件

• Azure IoT Edge 會在裝置上執行容器化工作負載，提供低延遲連線能力並節省頻寬。
• Azure IoT 中樞 是受控的雲端裝載服務，可作為IoT應用程式與其控制裝置之間的中央訊息中樞。
• Azure Container Registry 是雲端式私人登錄服務，可用來儲存和管理私人 Docker 容器映像和相關成品。
• Azure Pipelines 結合了持續整合 （CI） 和持續傳遞 （CD） 來自動測試及建置程式代碼，並將其寄送至任何目標。
• Azure Functions 是無伺服器計算平臺，可讓您執行事件觸發的程式代碼，而不需要布建或管理基礎結構。
• Azure 儲存體 可為所有類型的商務數據、對象和檔案提供高度可調整、安全、高效能且符合成本效益的記憶體。
• Azure SQL 資料庫 是完全受控的多模型關係資料庫服務，專為雲端建置。
• Docker 是一個開放平臺，可用於開發、運送和執行容器化應用程式。

替代項目

開發小組在決定完整的 Docker 映像差異傳輸解決方案之前，評估了數個選項。 下列各節說明評估替代方案和結果。

小組針對每個選項考慮了下列評估準則：

• 解決方案是否符合需求。
• 是否需要在裝置上實作低、中或大量的邏輯。
• 是否需要在 Azure 中實作低、中或大量的邏輯。
• 傳輸容器映像的頻寬效率，或傳輸的數據與映像大小總計的比例。

帶寬效率包括下列案例：

• 裝置上沒有映像。
• 具有相同基底的映像存在於裝置上。
• 裝置上存在先前應用程式版本的映像。
• 建置在先前基底映像上的應用程式映像存在於裝置上。

小組使用下列案例來評估頻寬效率：

傳輸 Docker 層選項

Docker 容器映像是 唯讀文件系統差異的 UnionFS 掛接，而容器執行時進行變更的另一個可寫入層。 文件系統稱為 層，基本上是資料夾和檔案。 分層堆疊，以形成容器根文件系統的基底。 由於圖層是只讀的，因此如果各影像有共通層，就可以共用相同的圖層。

[傳輸 Docker 層] 選項會重複使用映像之間的層，並且只會將新層傳輸至裝置。 此選項最適用於共用相同基底層、通常是OS或更新現有映像版本的映像。

此方法的缺點包括：

• 協調器必須維護哪些裝置上存在哪些層的相關信息。
• 基底層變更會導致所有後續層的哈希變更。
• 比較需要一致的圖層哈希。
• Docker 儲存和 Docker 負載可能有相依性。

修改 Docker 用戶端選項

此選項著重於修改或包裝 Docker 用戶端，以便在中斷之後繼續層下載。 根據預設，如果因特網連線在中斷約 30 分鐘內還原，Docker 提取會繼續下載。 否則，客戶端會結束並遺失所有下載進度。

這個方法是可行的，但有併發症，包括：

• 裝置上的所有映像都必須向提取映像的 Docker 精靈註冊，才能將頻寬效率最大化。
• 開放原始碼 Docker 項目必須修改以支援此功能，讓開放原始碼維護人員面臨拒絕的風險。
• 透過 HTTP 傳輸數據，而不是客戶偏好的快速檔案傳輸解決方案，需要開發自定義重試邏輯。
• 當基底映像變更時，必須重新傳輸所有圖層。

在邊緣裝置上建置選項

此方法會將映像建置環境移至裝置。 下列資料會傳送至裝置：

• 所建置應用程式的原始程式碼
• 程序代碼相依的所有 NuGet 套件複本
• .NET Core 組建環境和運行時間的 Docker 基底映射
• 關於結束影像的元數據

裝置上的組建代理程序接著會建置映像，並將其註冊至裝置 Docker 管理員。

此解決方案遭到拒絕，因為：

• 仍然需要將大型 Docker 映射移至裝置的方法。 建置 .NET 應用程式的映射大於應用程式映像本身。
• 此方法僅適用於小組具有原始程式碼的應用程式，因此無法使用第三方映像。
• 此選項需要封裝 NuGet 套件，並追蹤其移至裝置的動作。
• 如果映射無法在裝置上建置，小組必須從遠端偵錯組建環境和建立的映像。 遠端偵錯需要大量使用可能有限的因特網連線。

完整映像差異傳輸選項

選擇的方法會將 Docker 映射視為單一二進位檔。 Docker save 命令會將映射導出為 .tar 檔案。 解決方案會導出現有的和新的 Docker 映像，並計算套用時將現有映像轉換成新映射的二進位差異。

解決方案會追蹤裝置上現有的 Docker 映像，並建置二進位差異修補程式，以將現有的映射轉換成新的映像。 系統只會透過低頻寬因特網連線傳輸差異修補程式。 此解決方案需要一些自定義邏輯來建置二進位修補程式，但會將最少的數據量傳送到裝置。

評估結果

下表顯示上述每個解決方案如何根據評估準則來測量。

考量

這些考慮會實作 Azure 妥善架構架構的要素，這是一組可改善工作負載質量的指導原則。 如需詳細資訊，請參閱 Microsoft Azure Well-Architected Framework。

效能效益

此解決方案可大幅降低IoT裝置更新所耗用的頻寬。 下表顯示傳輸效率差異的細目。

影像重建工具作為來源：

舊版作為來源：

卓越營運

下列各節提供解決方案的詳細逐步解說。

原始碼存放庫

開發人員與原始程式碼存放庫中的邊緣模組原始程式碼互動。 存放庫是由包含每個模組程式代碼的資料夾所組成，如下所示：

\- repository root
    - modulea
    - modulea.csproj
    - module.json
    - Program.cs
    - Dockerfile

\- moduleb
    - moduleb.csproj
    - module.json
    - Program.cs
    - Dockerfile

建議的原始程式碼存放庫數目如下：

• 所有工作流程中所有模組的一個存放庫。
• 每個工作流程的一個原始程式碼存放庫。

Container Registry 實例

Container Registry 會儲存每個模組的 Docker 映像。 Container Registry 有兩個可能的組態：

• 儲存所有映像的單一 Container Registry 實例。
• 兩個 Container Registry 實例，一個用來儲存開發、測試和偵錯映射，另一個實例只包含標示為生產就緒的映像。

指令清單存放庫

指令清單存放庫包含所有工作流程的部署指令清單。 範本會根據其工作流程位於資料夾中。 在此範例中，這兩個工作流程是共用基礎結構和容器化應用程式。

\- repository root
     - Workstream1
         - deployment.template.json
     - Workstream2
         - deployment.template.json

Docker 映像建置管線

每個模組都有 Azure Pipelines 組建管線。 管線會使用一般 Docker 組建來建立和註冊模組。 管線負責：

• 原始碼的安全性掃描。
• 建置 Docker 映像之基底映像的安全性掃描。
• 執行模組的單元測試。
• 將來源建置至 Docker 映射。 映射標籤包含 BUILD_BUILDID，因此影像一律可以連結回製作映像的原始程式碼。
• 將映像推送至 Container Registry 實例。
• 建立差異檔案。
• 建立映像的簽章檔案，並將檔案儲存至 Azure 記憶體帳戶。

所有管線實例都是以單 一 YAML 管線定義為基礎。 管線可以使用環境變數對模組採取行動。 只有在特定資料夾中認可變更時，篩選才會觸發每個管線。 當只有一個模組更新時，此篩選會避免建置所有模組。

映射到裝置管線

映射到裝置管線會將 Docker 映像部署到目標裝置，如指令清單檔案所定義。 觸發管線以手動方式啟動部署。

管線定義會指定在容器中執行這些部署。 管線支援映像的變數輸入，以作為容器的基礎。 單一變數可以控制所有管線的部署。

映射包含程序代碼，可決定要建置的修補程式、建置修補程式，並將其散發至檔傳輸工具的 Azure 端。

映像發佈工具需要下列資訊：

• 要部署的映像，由存放庫中的指令清單提供。
• 要部署至哪些裝置，由觸發管線的使用者提供。
• Azure SQL 資料庫所提供的目標裝置上已經有哪一個映像。

管線輸出如下：

• 將修補程式套件組合傳送至文件傳輸工具的 Azure 端，以散發至裝置。
• 標示映像已開始傳輸至每個裝置的 SQL 資料庫專案。
• 新部署集的 SQL 資料庫專案。 這些專案包括排序部署之使用者的名稱和電子郵件位址。

此管線會執行下列步驟：

1. 根據部署指令清單決定所需的映像。
2. 查詢 SQL 以查看哪些映像已在裝置上。 如果所有映像都已存在，管線就會順利終止。
3. 決定要建立的修補程序組合。 演算法會決定哪一個起始映像會產生最小的修補套件組合。
   • 輸入:.tar檔案，其中包含要部署的新映像，以及裝置上現有映射的簽章檔案。
   • 輸出：決定要建立之最小修補程式的現有映像等級。
4. 為每個裝置建立所需的修補程序組合。 建置類似的修補程式一次，並將其複製到所有需要它們的裝置。
5. 將修補程式散發至檔案傳輸工具記憶體帳戶以進行部署。
6. 更新 SQL，將新映像標示為in transit每個目標裝置。
7. 使用部署映像人員的名稱和聯繫人電子郵件，將部署集資訊新增至 SQL。

指令清單到裝置管線

指令清單到裝置管線會將部署指令清單推送至更新裝置的適當 IoT 中樞 連線。 使用者會手動觸發管線，並指定 IoT 中樞 實例的目標環境變數。

管線：

• 決定部署所需的映像。
• 查詢 SQL 以確定所需的映像全都位於目標裝置上。 如果沒有，管線會以 failed 狀態終止。
• 將新的部署指令清單推送至適當的 IoT 中樞。

快速檔案傳輸解決方案

客戶想要繼續使用其第三方快速檔傳輸解決方案，稱為 FileCatalyst，以提供 Azure 與其 IoT 裝置之間的連線。 此解決方案是最終 一致的 檔傳輸工具，這表示傳輸可能需要很長的時間，但最終會完成，而不會遺失任何檔案資訊。

解決方案使用連線 Azure 端的 Azure 儲存體 帳戶，以及客戶針對每個接收映像的裝置的現有檔案傳輸主機 VM。 修補程式套件組合會傳送至執行 IoT 中樞的Linux VM。

影像重建模組

映像重建IoT Edge模組會在裝置上套用收到的修補程式。 每個裝置都會使用 Docker 開放原始碼登錄來裝載自己的本機容器登錄。 映射重建程式會在主機 VM 上執行，這與檔案傳輸 VM 相同。

模組：

1. 接收掛接至容器之資料夾中的修補程式套件組合。
2. 解壓縮修補程式內容以讀取組態檔。
3. 依哈希從本機容器登錄提取基底映像。
4. 將基底映像儲存為 .tar 檔案。
5. 將修補程式套用至基底映像。
6. 將 包含新映像的 .tar檔案載入 Docker。
7. 使用包含易記名稱和標記的組態檔，將新映像推送至本機容器登錄。
8. 將成功訊息傳送至 IoT 中樞。

如果進程在任何時間點失敗，模組會將失敗訊息傳送至 IoT 中樞，以便觸發部署的使用者會收到通知。

IoT 中樞

其中數個部署程式會使用 IoT 中樞。 除了從影像重建模組接收狀態消息之外，IoT 中樞 設定裝置的部署指令清單。 管線流程的其餘部分會使用此指令清單。

Azure Functions

Azure Functions 會監視來自 IoT 中樞 的訊息串流，並在雲端採取動作。

如需成功訊息：

• 函式會將裝置上映像的 SQL 項目狀態從 in transit 更新為 succeeded。
• 如果此映像是最後一個抵達部署集的映像：
  • 函式會通知使用者部署成功。
  • 函式會更新指令清單到裝置管線，以開始使用新的映像。

針對失敗訊息：

• 函式會將裝置上映像的 SQL 項目狀態從 in transit 更新為 failed。
• 函式會通知使用者映像傳輸失敗。

SQL Database

SQL 資料庫會追蹤目標裝置和 Azure 部署服務在部署期間和之後發生的次數。 Azure Functions 和 Azure Pipelines 都使用為與資料庫互動而建立的私人 NuGet 套件。

SQL 資料庫 會儲存下列資料：

• 每個裝置上都有哪些映像。
• 哪些映像會前往每個裝置。
• 要部署的映像屬於集合。
• 排序部署的使用者。

此範例的目標是確保系統為未來的數據儀錶板產生所需的數據。 查詢 IoT 中樞 可以提供下列指令清單到裝置管線的數據：

• 部署的狀態。
• 指定裝置上的影像。
• 具有映像的裝置。
• 成功和失敗傳輸的時間序列數據。
• 以用戶為基礎的部署查詢。

參與者

本文由 Microsoft 維護。 原始投稿人如下。

主體作者：

• Kanio Dimitrov |主要軟體工程負責人

下一步

• 將第一個IoT Edge模組部署至虛擬Linux裝置
• 使用 Linux 容器開發 IoT Edge 模組

相關資源

• Azure IoT Reference Architecture (Azure IoT 參考架構)
• 使用 Azure DevOps 設計 CI/CD 管線
• 適用於產業的低延遲網路連線