用容器釘死 ESP-IDF 版本：Docker 官方教學示範 ESP32 韌體的可重現建置與 Sandboxes 隔離測試
docs.espressif.com / docs.docker.com · 2026-08-14
Docker 官方部落格在 2026 年 8 月 14 日發布教學，示範如何用官方 espressif/idf 映像檔搭配新推出的 Docker Sandboxes（sbx CLI），建立可重現的 ESP32 韌體開發環境。核心作法來自 Espressif 官方文件 ESP-IDF Docker image guide：以 release-vX.Y tag 取代 latest，避免工具鏈版本漂移。教學同時展示如何用 Docker Sandboxes 讓 AI coding agent 在隔離環境中操作硬體相關的建置與燒錄流程。
背景
ESP32 韌體開發長期受工具鏈版本不一致所苦：不同開發者本機安裝的 ESP-IDF、Xtensa/RISC-V 交叉編譯器、Python 環境版本經常不同，導致「在我機器上可以 build」的經典問題。官方映像檔提供三種 tag 策略：latest 追蹤 master 分支、vX.Y 對應特定 release、release-vX.Y 追蹤 release 分支。文件明確指出「這功能推出之前發布的 ESP-IDF 版本，沒有對應的 Docker 映像檔版本」，並建議透過 Docker Hub 查詢目前可用的 tag 清單。
核心改動
教學的建置指令直接把整個工具鏈鎖進容器，本機不需要安裝任何 ESP-IDF 相依套件：
docker run --rm -v $PWD:/project -w /project \
-u $UID -e HOME=/tmp \
espressif/idf:release-v5.4 idf.py build燒錄與監控則需要把序列埠裝置掛進容器，Linux 上以 --device 搭配 dialout 群組 GID 授權；macOS／Windows 由於無法直接掛載 USB 裝置，改用 esp_rfc2217_server 建立序列橋接後，由容器內的 idf.py 透過 rfc2217://host.docker.internal:4000 連線。編譯快取則靠掛載具名 volume 搭配 IDF_CCACHE_ENABLE=1 環境變數持久化，避免每次容器重建都重新編譯整個工具鏈。
教學另一半聚焦在 sbx CLI：每個 sandbox 各自擁有獨立的 Docker daemon、檔案系統與網路，讓 AI agent（範例用 sbx run claude）可以在不觸碰宿主機的前提下建置容器、安裝套件、修改檔案。啟動、列出、刪除都是單一指令：
sbx run claude— 在新 sandbox 啟動 agentsbx run claude ~/firmware/new-feature— 指定工作目錄啟動sbx ls— 列出現有 sandboxsbx rm <name>— 刪除 sandbox
影響範圍
對嵌入式團隊而言，CI 與本機環境用同一組 image tag 幾乎消除了工具鏈版本造成的建置不一致，教學也連結了 esp-idf-ci-action 作為 GitHub Actions 整合範例。Docker Sandboxes 的隔離模型則把「AI agent 需要真的執行建置指令、甚至操作硬體介面」這件事變得可控——agent 出錯或跑飛，影響範圍被限制在單一 microVM 內，不會波及開發者的實體序列埠或宿主檔案系統。
Kairos 用 NodeOpUpgrade 自訂資源實現零人力 Kubernetes 控制平面升級
kairos.io · 2026-08-14
CNCF 部落格在 2026 年 8 月 14 日刊出案例，描述如何在 Kairos Hadron 不可變 Linux 之上，用 kairos-operator 提供的 NodeOpUpgrade 自訂資源，把三台 K3s HA 節點的控制平面升級全程自動化，全程 11 分鐘、零人工 SSH 介入。核心機制記載於 Kairos 官方文件與 kairos-io/kairos-operator 專案。此案例把 GitOps 依賴更新、鏡像簽章驗證、A/B 分割切換整合成單一管線。
背景
Kairos 是一套不可變（immutable）Linux 發行版，升級方式不是就地修補，而是把新的 OS 映像檔寫入未使用中的 A/B 分割區後重開機切換，回滾只需要重新開機回舊分割區。這個模型天生適合搭配 cosign 簽章的映像檔，形成完整的供應鏈驗證。案例中的叢集使用 OpenTofu 佈建基礎設施、Cilium 作為 CNI、Kyverno 做 admission 控制、ArgoCD 做 GitOps 同步，Renovate 負責自動偵測相依套件更新。
規格細節
NodeOpUpgrade 是對底層 NodeOp 資源的封裝，使用者只需指定目標映像檔與少數選項，operator 就會自動產生對應的升級腳本與設定。關鍵欄位包括：
image— 目標 Kairos 版本的容器映像檔（必填）nodeSelector— 用 label selector 篩選要升級的節點concurrency— 同時升級的節點數，設為1可確保 etcd 維持多數決stopOnFailure— 第一個節點失敗即中止，等同 canary 模式force— 略過版本比對，強制對所有節點執行
範例 YAML 展示了案例中實際採用的保守設定：
apiVersion: operator.kairos.io/v1alpha1
kind: NodeOpUpgrade
metadata:
name: kairos-upgrade
spec:
image: quay.io/kairos/opensuse:leap-15.6-standard-amd64-generic-v3.4.2-k3sv1.30.11-k3s1
nodeSelector:
matchLabels:
kairos.io/managed: "true"
concurrency: 1
stopOnFailure: trueoperator 收到資源後，先依 label selector 列出節點並把 master 節點排在最前面，再對每個節點跑一個短暫的 preflight Pod 比對目標映像檔版本與節點上 /etc/kairos-release 的版本，版本相同的節點會被直接略過。確認需要升級後才依序執行 cordon、升級 Job（內含負責寫入分割區的 InitContainer）、透過 nsenter 觸發重開機，最後 uncordon 讓節點回到可排程狀態。
影響範圍
案例中的管線串接 Renovate 偵測依賴更新、ArgoCD 同步出新的 NodeOpUpgrade 資源、kairos-operator 依序處理三個節點，整個控制平面升級在 11 分鐘內完成且無人工介入。因為 concurrency: 1 逐台處理並在每一步驗證節點狀態，etcd quorum 全程維持，失敗時 stopOnFailure 也能即時中止而非讓錯誤擴散到整個叢集。
OpenTelemetry 用「實體事件」補上指標、日誌、追蹤都答不了的「當下有哪些資源存在」
opentelemetry.io · 2026-08-14
OpenTelemetry 官方部落格在 2026 年 8 月 14 日發文，說明如何消費（consume）新定義的 entity events（實體事件）——一種把基礎設施庫存與拓樸描述成事件溯源（event-sourced）、雙時態（bi-temporal）串流的資料模型。規格源自 OTEP 0256，已隨 v1.58.0（2026-06-22 發布）納入正式規格，實作細節則記載在 entity events 規格頁。這填補了 metrics／logs／traces 三種既有訊號都無法回答的問題：此刻到底有哪些服務、主機、程序存在。
背景
OTEP 0256 一開始就排除了把實體資料塞進既有 Resource 概念的方案。文件指出這樣做會製造尷尬的問題：究竟該由 logs、spans 還是 metrics 哪一種訊號承載「僅描述實體、與具體遙測無關」的狀態？節點之間的關聯（relationship）又該如何表示？因此規格選擇獨立出一種訊號，專門描述實體本身及其生命週期，而不是附掛在其他訊號上。
規格細節
一個實體由三個欄位定義：type（字串，終生不變，如 service、host）、id（string 到 attribute 的 map，構成身分識別，且至少要有一個鍵值）、attributes（可隨時間變化的描述性屬性）。傳輸層面上，實體事件是一種特殊的 OTLP log record，透過 EventName 欄位區分兩種事件：
entity.state— 實體建立、屬性變更，或單純的心跳（確認實體仍存在）entity.delete— 實體從系統中移除
Log record 中，entity.id 對應不可變的識別屬性，entity.description 則承載可變動、甚至是巢狀 map／array 的描述性資料（例如 Kubernetes ConfigMap 內容、雲端 metadata）。拓樸關係內嵌在 state 事件本身：entity.relationships 陣列裡的每一筆紀錄，都指定關係類型（如 scheduled_on、contains）與目標實體的 type／id，消費端據此重建出有向的實體關係圖。
entity.report.interval 欄位告知消費端該實體預期多久回報一次心跳，因為規格明確聲明「實體消失時不保證會送出 entity.delete 事件」，消費端需要靠逾時（timeout）而非單純等刪除事件來判斷實體是否已經不存在。文件也強調規格雖已定案，但實際欄位命名與屬性內容仍在演進中。
影響範圍
對監控與 CMDB 類系統而言，實體事件串流讓「基礎設施庫存」第一次有了原生的 OTLP 表示法，而不必額外接第三方 CMDB 或自建拓樸抓取器。因為是事件溯源加雙時態設計，消費端可以重放歷史，回答「某個時間點叢集拓樸長什麼樣」，而不只是查詢當下快照。