用 Docker Sandboxes 隔離跑通 ESP32 韌體建置與燒錄流程
Docker Docs · 2026-08-14
Docker 在 2026 年 8 月 14 日發布一篇由 Docker Captain Marco Franzon 撰寫的技術文章，說明如何用官方 espressif/idf Docker 映像檔搭配新推出的 Docker Sandboxes，在隔離環境中建置、燒錄與偵錯 ESP32 韌體。文章依序處理本機建置、多版本並行、AI agent 硬體存取與 CI 整合四個環節。
原本的問題
ESP32 韌體開發長期依賴在主機直接安裝 ESP-IDF 工具鏈，不同專案分別鎖定 v5.3、v5.4 等版本時容易互相污染環境。多板同時開發時 USB 裝置命名不穩定，/dev/ttyUSB0 這類名稱會隨插拔順序改變，讓自動化腳本難以穩定辨識目標板子。
另一個問題是 AI coding agent 的興起：想讓 agent 直接操作序列埠燒錄韌體，又不想把主機完整權限交給它。agent 需要碰到實體硬體，卻不能無限制存取宿主機，這是文章要解決的核心矛盾。
採用的方法
建置階段直接掛載官方映像檔並鎖定 tag：
docker run --rm -v $PWD:/project -w /project \
-u $UID -e HOME=/tmp \
-e IDF_CCACHE_ENABLE=1 -e IDF_GIT_SAFE_DIR='/project' \
espressif/idf:release-v5.4 idf.py build用 -u $UID 避免 root 擁有的建置產物，並搭配掛載的 ccache 目錄加速重複建置。多板環境則用 Linux udev 規則替每片板子指定固定名稱，例如 /dev/esp32-experimental，再透過 Docker Compose 常駐多組建置環境。
硬體存取的關鍵在 Docker Sandboxes：其 CLI 為 sbx，執行 sbx run claude 即可讓 agent 在具備獨立 Docker daemon、檔案系統與網路堆疊的 microVM 中工作。為了讓沙盒內的 agent 仍能碰到實體序列埠，文章採用 RFC2217 協定把序列埠橋接到網路：主機端執行 esp_rfc2217_server -p 4000 /dev/esp32-experimental 對外提供服務，沙盒內再用 idf.py --port 'rfc2217://host.docker.internal:4000?ign_set_control' flash monitor 連線燒錄與監看。Sandbox 提供 open、balanced（預設 deny）、locked down 三種網路政策，並用主機端 proxy 隔離憑證。
實際效果
CI 部分交給官方維護的 esp-idf-ci-action，鎖定 @v1 tag 即可在 GitHub Actions 上指定 esp_idf_version 與 target 兩個參數跑建置：
v5.4、v5.3兩條工具鏈可在同一主機並行，不會互相覆蓋環境變數或套件版本- 多片開發板透過 udev 命名穩定辨識，免除依插拔順序尋找裝置節點
- Docker Sandboxes 目前支援 macOS（Apple Silicon）、Windows 11 與具備 KVM 的 Linux
整體結果是建置、燒錄與 agent 操作都被限制在各自的容器或沙盒邊界內，主機工具鏈不再需要為單一專案而全域安裝，也降低了讓自動化程式直接觸碰序列埠所帶來的風險。
用 Kairos 打造零人工介入的 Kubernetes 升級管線，11 分鐘完成三節點更版
Kairos 官網 · 2026-08-14
CNCF 部落格在 2026 年 8 月 14 日刊出文章，描述如何用不可變作業系統 Kairos 搭配 Gitea、Renovate、Kyverno、Cosign 與 ArgoCD 串出一條全自動升級管線，把三台 control plane 節點從 Hadron v0.3.0 升級到 v0.4.0，全程 11 分鐘且沒有人工介入。
原本的問題
傳統 Kubernetes 節點作業系統升級多半採「原地修補」：SSH 登入、跑套件管理員升級、重開機、逐台驗證，control plane 節點數一多，風險與人力成本會同步疊加。Kairos 走完全不同的路線：它把整個作業系統以 Cosign 簽署的 OCI 映像檔形式分發，升級時不修補既有分割區，而是把新映像寫進非使用中的 A/B 分割區，驗證後重開機切換過去。
採用的方法
管線由六個元件銜接：
- Renovate 監控 quay.io 上 Hadron 映像的新 tag，發現後自動送出變更請求
- Gitea 承接程式碼與 CI 流程
- Kyverno 在 admission 階段驗證映像簽章與政策
- Cosign 提供映像的加密簽章驗證
- ArgoCD 依 GitOps 模式把驗證通過的變更同步進叢集
- kairos-operator 實際執行 A/B 分割區的映像寫入與重開機切換
整個升版動作只是一個 2 行的 diff：更新映像 tag，以及對應 CR metadata 的 name 欄位。作者也記下一個踩坑細節：Renovate 設定檔一開始誤用了不存在的 extractVersionTemplate 欄位，導致版本比對完全沒有作用，後來改成 currentValueTemplate 才能依 SemVer 規則正確抓到新版本。
實際效果
三台 control plane 節點在 11 分鐘內完成滾動升級，作業系統核心版本同步從 7.0.10 升到 7.1.0-hadron，其中映像拉取（324 MB）耗時 25.5 秒。整個流程從 Renovate 發現新版本、Kyverno 政策核可、ArgoCD 同步到 kairos-operator 執行重開機，沒有任何一步需要人工登入節點或手動點擊確認。
平台團隊該不該接管 AI pipeline？CNCF 部落格談 LLMOps 治理分工
Syntasso · 2026-08-03
CNCF 部落格在 2026 年 8 月 13 日刊出文章，質疑「LLMOps 該由誰負責」這個問法本身，主張改問「哪一層由誰治理、有沒有人在協調」，並引用 Daniel Bryant 在 Syntasso 部落格的深入分析來說明 LLMOps 與平台工程的關係。
原本的問題
許多組織在導入大型語言模型應用時，讓 ML／LLM 團隊獨立建立一套與既有 DevOps、平台工程完全脫節的流程，各自維護 model deployment、data management、訓練與微調、監控評估、安全合規等能力。作者把這種現象比作 DevOps 演進初期的影子 IT（shadow IT）：重複造輪子、審計軌跡缺失、政策各行其是，最終應用程式碼與 AI 模型走上兩套互不相干的治理路徑。
採用的方法
文章主張把 LLM pipeline 當成平台能力的一部分，而不是另立第三套堆疊，並提出四個具體治理機制：
- 以治理過的 API 取代 ad hoc script 直接呼叫模型
- 在請求送出前先做政策檢查（pre-request policy enforcement）
- 需要人工核准的關鍵操作走審批工作流程
- 保留完整的稽核軌跡（audit trail）
這些能力被放進一個三層平台模型：應用編排（application choreography）、平台協調（platform orchestration）與基礎設施組合（infrastructure composition），LLMOps 的職責依此拆分到對應層級，而非為 AI 團隊另外複製一套治理架構。
實際效果
文章點名既有 MLOps 工具鏈如 MLflow、Kubeflow、Weights & Biases，以及平台工程常見的 Backstage、Crossplane、Kratix、KusionStack、KubeVela，說明這些工具彼此並不互斥。Backstage 可作為服務目錄的統一入口，Crossplane 與 Kratix 負責基礎設施層的宣告式供給，MLOps 工具鏈則專注模型生命週期管理，四者能在同一治理框架下並存，不需要為 LLM 團隊重建一套平行系統。