Autocruise

English Abstract: Docker will fully retire Docker Content Trust (DCT) and the Notary v1 service at notary.docker.io on December 8, 2026. This article traces how DCT came about in 2015 and why it is being retired a decade later, then describes the evidence chain that replaces it: digests that pin exactly which image is deployed, signatures that prove who published it, and admission policies that let a cluster run only images that can show both. It introduces the two signing tools named in Docker's migration guidance, Notation from the Notary Project and Cosign from Sigstore, with a few basic commands for each, and compares their trust models so teams can choose a path before the shutdown. 2015 年，Docker 以 The Update Framework（TUF）與 Notary v1 推出 Docker Content Trust（DCT）， DOCKER_CONTENT_TRUST=1 是許多團隊第一次替 image 映像檔加上簽章的方式。Docker 在 2026 年 6 月宣布，DCT 與 notary.docker.io 上的 Notary v1 服務將於 2026 年 12 月 8 日全面停用，理由是上游的 Notary v1 已無人維護。官方同時提到，目前只有不到 0.05% 的 Docker Hub pull 仍依賴 DCT。這個數字背後所代表...

English Abstract: Docker has published its first official skills for AI coding agents at github.com/docker/skills. The collection follows the open Agent Skills format, so the same SKILL.md directories work in Claude Code, Codex, Cursor, Gemini CLI and GitHub Copilot CLI. This post walks through what the twelve skills cover, how to install them, what a skill actually contains using docker-build-strategies and docker-destructive-guardrails as examples, the release engineering behind the repository, and how to verify that an agent is really applying the rules. The project is still at version 0.x and several skills are marked experimental. Docker 在 2026 年 9 月推出 Docker Skills，寫成 Agent 能直接載入的技能包。本文介紹 Docker Skills 的內容、安裝方式、一個 skill 實際長什麼樣子，以及如何驗證 Agent 真的照著做。 版本說明：本文依據 2026 年 10 月下旬的 repository 內容撰寫。Docker Skills 於 2026-09-22 發布 0.1.0，撰文時最新正式版為 0.3.1，仍在 0.x 階段，部分 skill 標示 experimental，指令與結構可能變動，請以官方文件為準。 （一）Docker Skills 是什麼 Docker Skills 是 Docker 官方維護的一組「知識型 skill」，原始碼放在 github....

English Abstract: This post wraps up the three-part Docker × AI Agent series. Each article added one defensive layer for containers that run autonomous AI agents: kernel isolation with MicroVM sandboxes, network and credential isolation with an internal-only Docker network and an egress proxy, and resource circuit breaking with cgroups and ulimit. It summarizes the three layers side by side and traces how each one builds on earlier Autocruise posts on Docker proxy configuration, Docker engine ulimits, and Docker credential stores. 近期連續三篇 Docker × AI Agent 系列文，應對的是同一個課題：當容器裡執行的不再是行為固定的微服務，而是會自行產生程式碼、呼叫 Shell 的 AI Agent，「在容器就安全」這個假設要怎麼修正。三篇文章各自補上一道防線，構築成防禦縱深，本文把它們整理在一起，作為此系列的索引。 （一）在 Docker 容器中執行 AI Agent，需要哪三道防線？ 在 Docker 容器中執行 AI Agent，需要同時具備 Kernel 隔離、網路與憑證隔離、資源熔斷三道防線，分別對應 Agent 突破隔離、帶走機密與耗盡資源三種風險。 防線 處理的風險 關鍵設定 Kernel 隔離 共用宿主機 Kernel、runc 漏洞、掛載 docker.sock sbx MicroVM、K8s RuntimeClass 網路與憑證隔離 /proc/self/environ、DNS 隧道、.env 外洩 internal: true 、Egress Prox...

English Abstract: This article revisits Linux ulimit and Docker cgroups as hard resource limits for AI agent containers. It explains why per-UID nproc limits can cause cross-container outages, why --pids-limit is the container-level fork-bomb guard, and how to scope CPU-time limits to individual child processes so that a runaway script is terminated without killing the agent itself. 在先前的文章中，探討過 AI Agent 的本質其實就是 SRE 熟悉的控制迴圈（Loop Engineering）。近期的容器系列文也分別透過 MicroVM 沙盒 與 Egress Proxy，處理了核心隔離與金鑰保護的問題。要讓 AI Agent 在容器中安全運作，仍缺最後一塊拼圖： 運算資源的防呆與熔斷（Resource Circuit Breaking） 。 若 Agent 在自我修正的迴圈中寫出無窮迴圈腳本、意外觸發 Fork Bomb（無限衍生子行程），或開啟數萬個未關閉的檔案連線，單靠 Prompt 提示或應用層的 Timeout 無法攔截。此時就需要 Linux 與 Docker 中最經典的底層工具：ulimit 與 cgroups。 (1) 從「放寬限制」到「收緊牢籠」 過去撰寫 Docker 與 Linux ulimit 調校指南時，情境多半是為了應付高併發流量，例如 Nginx 或 Elasticsearch 出現 Too many open files 錯誤。當時的維運重點，是透過 --ulimit nofile=65535:65535 撐開系統限制，釋放硬體效能。 AI Agent 時代的思維則需要反過來： 傳統微服務（行為已知） ：調高 ulimit，避免系統預設值成為流量瓶頸。 AI Agent（行為未知） ：收緊 ulimit 與 cgr...