Container Image（容器映象）

3 秒看懂

容器映象是一個不可變（immutable）、分層建置的只讀檔案包，內含執行一個應用所需的全部內容——程式碼、執行時、系統庫、環境變數和配置檔案。你可以把它理解為容器的”安裝光碟 ISO”：映象是模板，容器是基於映象執行起來的例項。它是整個雲端原生（Cloud Native）技術棧的基石單元。

3 分鐘產業解釋

為什麼重要？

在容器映象出現之前，軟體交付的最大痛點是 “我的機器上能跑，你的不行”——開發環境、測試環境、生產環境之間的依賴差異導致大量部署故障。容器映象把應用及其所有執行時依賴打包成一個標準化的、可版本化的製品（artifact），從根本上解決了環境一致性問題。

產業角色

開發者編寫程式碼
    → Dockerfile 描述建置步驟
        → 建置工具（Docker/BuildKit/Buildah）生成映象
            → 推送至映象倉庫（Registry）
                → 編排平台（Kubernetes）從倉庫拉取映象
                    → 容器執行時（containerd/CRI-O）基於映象建立容器例項

這個鏈條中，映象是連線”建置”與”執行”的核心樞紐。它是 CI/CD 流水線的交付產物，也是 Kubernetes 排程的最小部署單元（Pod 中的每個容器都引用一個映象）。

市場規模感知

映象相關的生態形成了一個龐大的產業：

公共映象倉庫：Docker Hub 擁有超過 數百萬個公開映象倉庫（repository），是全球最大的公共映象分發平台 [Docker 官方公開資料]。
企業級映象倉庫：AWS ECR、Google Artifact Registry、Azure ACR、阿里雲端 ACR、Harbor（CNCF 畢業專案）等構成了企業私有映象管理基礎設施。
映象安全掃描：Trivy（Aqua Security）、Snyk Container、Prisma Cloud（Palo Alto）、Anchore 等工具圍繞映象建置了安全合規產業鏈，市場規模估算在數十億美元量級 [行業估算，口徑不一]。

15 分鐘專家深入

核心技術架構

容器映象的技術規範由 OCI（Open Container Initiative）映象規範 定義 [OCI Image Specification]。一個完整的映象由以下三部分組成：

┌─────────────────────────────────────────────┐
│              OCI Image Layout                │
│                                             │
│  ┌─────────────────┐                        │
│  │   Manifest      │  ← 描述映象的層列表、   │
│  │   (JSON)        │    配置摘要、平台資訊   │
│  └────────┬────────┘                        │
│           │ 引用                             │
│  ┌────────▼────────┐  ┌──────────────────┐  │
│  │  Image Config   │  │   Layer 0        │  │
│  │  (JSON)         │  │   (tar+gzip/zstd)│  │
│  │  - Entrypoint   │  │   Layer 1        │  │
│  │  - Env          │  │   (tar+gzip/zstd)│  │
│  │  - Cmd          │  │   ...            │  │
│  │  - ExposedPorts │  │   Layer N        │  │
│  │  - Architecture │  │   (tar+gzip/zstd)│  │
│  └─────────────────┘  └──────────────────┘  │
│                                             │
│  所有內容通過 SHA-256 摘要進行內容定址        │
└─────────────────────────────────────────────┘

分層（Layering）機制

這是映象最核心的設計哲學：

每一層是一個 tar 歸檔檔案，經壓縮（傳統 gzip，新興 zstd）後以內容雜湊（SHA-256 digest）標識。
層之間是**覆蓋疊加（overlay）**關係：後層的檔案可以覆蓋前層的同路徑檔案。
**聯合檔案系統（Union Filesystem）**如 OverlayFS、FUSE-OverlayFS 在執行時將多層合併為一個統一檢視。
層的共享複用是關鍵優勢：如果兩個映象共享相同的基底層（如 ubuntu:22.04），該層只需儲存和傳輸一次。

# 檢視映象層資訊（示例）
$ docker inspect nginx:latest --format='&#123;&#123;json .RootFS.Layers}}' | jq .

# 輸出為 SHA-256 摘要列表，每一行對應一個層
# sha256:abc...（基礎層）
# sha256:def...（配置層）
# sha256:ghi...（應用層）

Manifest 與 Image Config

Manifest：JSON 格式，宣告映象由哪些層組成、映象配置的 digest、以及媒體型別。支援 Manifest List（或 OCI Index）以實現多架構映象（amd64/arm64/s390x 等）。
Image Config（也稱 config.json）：宣告容器啟動命令（Entrypoint/Cmd）、環境變數（Env）、暴露埠（ExposedPorts）、工作目錄（WorkingDir）、架構（Architecture/OS）、建置歷史（History）等後設資料。

內容定址（Content-Addressable）

所有 blob（層和配置）通過 SHA-256 雜湊摘要 唯一標識。這意味著：

相同內容永遠產生相同的 digest → 可驗證完整性
不同倉庫間可以去重 → 儲存和頻寬高效
映象引用的 digest 不可篡改 → 供應鏈安全基礎

技術原理（最深）

1. 完整的映象 Manifest 格式

OCI Image Manifest v2 / Docker Distribution Manifest v2 Schema 2 的關鍵欄位：

{
  "schemaVersion": 2,
  "mediaType": "application/vnd.oci.image.manifest.v1+json",
  "config": {
    "mediaType": "application/vnd.oci.image.config.v1+json",
    "digest": "sha256:config_hash_here",
    "size": 7023
  },
  "layers": [
    {
      "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "digest": "sha256:layer0_hash",
      "size": 32654
    },
    {
      "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "digest": "sha256:layer1_hash",
      "size": 16724
    }
  ],
  "annotations": {
    "org.opencontainers.image.created": "2024-01-15T10:00:00Z"
  }
}

2. Copy-on-Write (CoW) 與執行時行為

容器啟動時，並不複製映象：

映象層（只讀）
  Layer N   ──┐
  Layer N-1 ──┤
  ...         ├── OverlayFS mount ──→ 統一檢視（merged）
  Layer 1   ──┤
  Layer 0   ──┘
               │
  容器可寫層 ──┘  (thin writable layer, 通常 tmpfs/overlay)

容器執行時僅建立一個薄可寫層。
當容器程序修改已有檔案時，通過 CoW 將該檔案從只讀層複製到可寫層再修改。
容器刪除後，可寫層隨之銷燬，映象層保持不變。
這就是為什麼容器啟動極快（毫秒到秒級）——無需解壓整個映象，只需掛載層。

3. 映象建置快取機制

Dockerfile 指令逐行生成層，建置快取遵循嚴格順序匹配原則：

FROM ubuntu:22.04          # ← Layer 0: 基礎層
RUN apt-get update         # ← Layer 1: 如果這行及以上未變，使用快取
COPY requirements.txt .    # ← Layer 2: 檔案內容變化則快取失效
RUN pip install -r requirements.txt  # ← Layer 3: 上層失效則此層也重建
COPY . /app               # ← Layer 4: 程式碼變化頻繁，放最後

關鍵最佳化原則：將變化頻率低的操作放在前面（如安裝依賴），將變化頻率高的操作放在後面（如複製原始碼），以最大化快取命中率。

4. 多架構映象（Multi-Architecture Image）

通過 Manifest List（Docker Manifest / OCI Index）實現：

OCI Index / Manifest List
  ├── linux/amd64  → manifest → [layers for amd64]
  ├── linux/arm64  → manifest → [layers for arm64]
  └── linux/arm/v7 → manifest → [layers for armv7]

客戶端（如 docker pull）根據本機平台架構自動選擇匹配的 manifest，拉取對應的層。建置多架構映象的工具包括 docker buildx、buildah 等。

5. 映象分發協議

映象倉庫遵循 OCI Distribution Spec（源自 Docker Registry HTTP API V2）：

客戶端                              Registry
  │                                   │
  │  GET /v2//manifests/   │  ← 拉取 manifest（ref 可以是 tag 或 digest）
  │ ──────────────────────────────→   │
  │  ← 200 + Manifest JSON           │
  │                                   │
  │  檢查 manifest 中的 layer digests │
  │  已有層不重複拉取（本地快取）       │
  │                                   │
  │  GET /v2//blobs/    │  ← 逐層拉取缺失的 blob
  │ ──────────────────────────────→   │
  │  ← 200 + blob data               │
  │                                   │

技術演進史

時間	事件	意義
2000 年代	FreeBSD Jail、Linux VServer、OpenVZ	作業系統級虛擬化概念萌芽
2008	LXC（Linux Containers）釋出	第一個完整的 Linux 容器實現
2013.03	Docker 0.1 釋出（dotCloud，後更名 Docker Inc.）	引入映象分層建置 + Dockerfile + Docker Hub，定義了容器映象範式
2014.06	Google 開源 Kubernetes	映象成為編排排程的核心製品
2015.06	OCI（Open Container Initiative）成立	由 Docker、Google、Red Hat、CoreOS 等發起，將映象格式和執行時規範標準化
2015-2017	OCI Image Spec 1.0 釋出	映象格式標準化，打破廠商鎖定
2017	CNCF 接管 containerd	標準化容器執行時，OCI 映象成為”一等公民”
2017-2019	BuildKit 引入（Docker 18.09+）	並行建置、建置快取遠端匯出、更安全的建置（無特權）
2019	Harbor 加入 CNCF 成為畢業專案	開源企業級映象倉庫
2020	Sigstore/Cosign 專案啟動	映象簽名和供應鏈安全
2021-至今	SBOM（軟體物料清單）成為合規要求	`syft`、`cosign attest` 等工具將 SBOM 附加到映象
2022-2023	zstd 壓縮格式逐步支援	更快的映象解壓速度（OCI Image Spec 1.1 / distribution-spec 1.1）
2023-2024	Nixery、Distroless、Wolfi 等最小映象方案興起	安全最小化 + 無 CVE 基礎映象

技術路線對比

映象建置工具對比

特性	Docker (BuildKit)	Buildah	Kaniko	Jib	Bazel (rules_oci)
建置環境	需要 Docker daemon / 或 rootless	daemonless	Kubernetes Pod 內	純 Java/無需容器	無需容器執行時
是否需要 root	rootless 模式不需要	不需要	不需要	不需要	不需要
Dockerfile 支援	完整	完整	大部分	無需 Dockerfile	無需 Dockerfile
快取機制	本地 + registry cache	本地	層快取	基礎映象層快取	精細的增量建置
多架構	`docker buildx` 原生	`buildah bud --arch`	間接支援	不適用	需配置
CI/CD 友好度	高（需 DinD 或 socket 掛載）	高	最高（純 Pod）	高（Java 生態）	高
典型使用者	通用	Red Hat 生態	Google/CI 密集	Java 團隊	大型 monorepo

映象倉庫對比

特性	Docker Hub	AWS ECR	Google Artifact Registry	Azure ACR	Harbor	Quay.io
部署模式	公有 SaaS	雲端託管	雲端託管	雲端託管	私有/自託管	公有 SaaS / 自託管
免費層	1 私有倉庫（已調整政策）	儲存計費	儲存計費	儲存計費	開源免費	有限免費
漏洞掃描	Docker Scout	整合 Inspector	整合 Container Analysis	Defender for Cloud	Trivy 整合	Clair 整合
映象簽名	Docker Content Trust	支援	支援	支援	Cosign/Notary	支援
地理複製	CDN	跨區域複製	跨區域複製	跨區域複製	可配置	可配置
OCI 製品支援	✅	✅	✅	✅	✅	✅

基礎映象對比

基礎映象	大小（估算）	包管理	CVE 面	適用場景
`ubuntu:22.04`	~77 MB	apt	較大	開發/通用
`alpine:3.19`	~7 MB	apk	小（musl libc 相容性需注意）	生產微服務
`debian:bookworm-slim`	~75 MB	apt	中	需要 glibc 的通用場景
`distroless/static`	~2 MB	無	極小	靜態編譯的 Go/Rust
`cgr.dev/chainguard/wolfi`	極小	apk	極低（每日重建）	安全敏感生產環境
`scratch`	0 MB	無	無	完全靜態二進位制

注：大小為 x86_64 架構下壓縮後估算值，實際隨版本變動。

上下游

上游（映象的”原料”）

基礎作業系統映象                    應用執行時
  ├─ Ubuntu/Debian/Alpine/...       ├─ Python / Node.js / JDK / Go
  ├─ Distroless/Wolfi               ├─ nginx / envoy / tomcat
  └─ scratch (空基礎)              └─ 自定義二進位制

        │                               │
        ▼                               ▼
    ┌───────────────────────────────────────┐
    │         Dockerfile / Buildfile         │
    │    描述"基礎映象 + 建置步驟 + 配置"    │
    └───────────────────┬───────────────────┘
                        │ 建置
                        ▼
              Container Image（映象）

下游（映象的”消費者”）

Container Image
    │
    ├──→ 映象倉庫 (Registry) ──→ Kubernetes / Docker Swarm / Nomad
    │                                    │
    │                                    ▼
    │                              容器執行時
    │                              (containerd / CRI-O / runc)
    │                                    │
    │                                    ▼
    │                              容器例項 (Container)
    │
    ├──→ CI/CD 流水線 ──→ 安全掃描 ──→ 映象簽名 ──→ 部署
    │
    ├──→ Serverless 平台 (AWS Lambda, Google Cloud Run, Knative)
    │
    └──→ AI/ML 工作負載 (訓練架構映象、推論服務映象)

在 AI 產業鏈中的角色

映象在 AI 基礎設施中扮演標準化環境封裝的角色：

訓練環境：PyTorch/TensorFlow 官方提供預建置映象（含 CUDA、cuDNN 等 GPU 軟體棧），避免了 GPU 驅動/庫版本配置地獄。
推論部署：模型 + 推論引擎（TensorRT、vLLM、Triton Inference Server）封裝為映象，實現一致的推論環境。
MLOps 流水線：每一步資料處理/訓練/評估都以映象為交付物，確保可復現性。

關鍵指標

技術指標

指標	說明	典型值/範圍
映象大小	壓縮後傳輸大小	幾 MB（alpine+靜態二進位制）到數 GB（ML 架構映象含 CUDA）
層層數	一個映象包含的層數	通常 5-20 層；ML 映象可能更多
拉取時間	從 Registry 拉取完整映象	與網路頻寬/映象大小相關；小映象秒級，大映象分鐘級
建置時間	從 Dockerfile 建置映象	無快取：數分鐘到數十分鐘；有快取：秒級增量
冷啟動時間	首次拉取+啟動容器	拉取時間 + 容器初始化（通常秒級）
層複用率	同一叢集中層的快取命中比例	取決於映象設計，最佳化後可達 80%+ [行業估算]
CVES/映象	映象中包含的已知漏洞數	未經最佳化的 Debian 基礎映象可能有數百個 CVE；distroless 可趨近 0

運營指標

指標	說明
映象推拉頻率	反映 CI/CD 活躍度
倉庫儲存量	企業級通常 TB-PB 級
映象保活策略	未使用映象的清理策略
簽名覆蓋率	生產映象的簽名比例

供需與市場資料

供給端

公共映象倉庫：Docker Hub、GitHub Container Registry（ghcr.io）、各大雲端廠商的公共映象倉庫提供數十萬個預建置映象。
企業級私有倉庫：根據 Snyk 2023 年報告，超過 85% 的企業使用容器映象作為主要的軟體交付格式 [Snyk，估算口徑不一]。
映象安全市場：Trivy、Grype（Anchore）、Docker Scout、Snyk Container 等開源/商業工具形成競爭格局。

需求端

Kubernetes 叢集規模：CNCF 年度調查（2023）顯示 超過 84% 的受訪組織在生產環境使用容器 [CNCF Annual Survey 2023]。
映象體積持續增長：ML/AI 工作負載推動大映象需求，含 CUDA 基礎層的 PyTorch 映象壓縮後可達 數 GB。
供應鏈安全合規：美國行政令 14028（EO 14028, 2021）要求 SBOM，推動映象簽名和掃描需求激增。

關鍵市場資料點

資料點	數值	來源/口徑
Docker Hub 映象拉取量	每月數十億次	Docker Inc. 公開宣傳資料
企業容器採用率	84%+	CNCF Annual Survey 2023
使用 Kubernetes 的組織比例	66%+	CNCF Annual Survey 2023
容器安全市場預估規模	數十億美元（2024）	多家行業報告估算，口徑不一
典型企業映象倉庫規模	TB 級	供應鏈估算，因企業規模差異極大

代表公司與資本對映

映象基礎設施公司

公司/專案	角色	產品/技術	資本狀態
Docker Inc.	容器映象概念創造者	Docker Desktop、Docker Hub、Docker Scout	私有（已轉型盈利，非上市）
CNCF / OCI	標準制定	OCI Image Spec、Distribution Spec	行業聯盟
VMware (Broadcom)	企業容器平台	Tanzu、Harbor（開源但 VMware 有商業化包裝）	Broadcom 2023 年收購 VMware
Mirantis	Docker Enterprise 繼承者	Mirantis Container Runtime、Lens	私有
Red Hat (IBM)	企業 Linux + 容器	Podman、Buildah、Skopeo、Quay、OpenShift	IBM 2019 年以 ~$340 億收購 Red Hat

映象安全公司

公司	產品	資本狀態
Aqua Security	Trivy（開源）、Aqua Platform	私有，融資總額約 $2.65 億 [公開報道估算]
Snyk	Snyk Container	私有，曾估值 $74 億（2022 高峰，此後市場調整）
Sysdig	Sysdig Secure	私有，2022 年估值約 $25 億
Chainguard	Chainguard Images（安全基礎映象）	私有，2022 年融資約 $5000 萬 [公開報道]
Stacklok (Sigstore)	Minder、Sigstore 生態	私有

雲端廠商（映象倉庫作為雲端服務的組成部分）

雲端廠商	映象倉庫服務	備註
AWS	ECR (Elastic Container Registry)	與 ECS/EKS 深度整合
Google Cloud	Artifact Registry	替代舊版 GCR，支援多種製品
Azure	ACR (Azure Container Registry)	與 AKS 整合
阿里雲端	ACR (Container Registry)	國內市場份額領先
騰訊雲端	TCR (Tencent Container Registry)	—
華為雲端	SWR (SoftWare Repository for Container)	—

投資邏輯

看多邏輯

容器是不可逆的基礎設施趨勢：企業數字化轉型持續推動容器採用，映象作為容器的”原子單元”，需求剛性增長。
AI/ML 推動映象複雜度上升：大型模型訓練/推論環境（CUDA、PyTorch、vLLM 等）對映象建置、分發、安全提出了更高要求，催生增量市場。
供應鏈安全是合規剛需：EO 14028、NIST 架構等推動映象簽名、SBOM、漏洞掃描成為強制要求，安全廠商受益。
邊緣計算擴充套件場景：IoT/邊緣場景需要輕量化、安全的映象分發方案（如 Wasm 容器映象），開啟新市場。

風險與挑戰

Docker Inc. 的商業化困境：Docker Desktop 付費化引發社群反彈，Docker Hub 免費層收緊。映象建置/倉庫本身已是高度標準化和低價競爭的基礎設施。
安全掃描同質化嚴重：Trivy 等開源工具覆蓋大量需求，純商業映象掃描面臨開源替代壓力。
WebAssembly (Wasm) 潛在替代：Wasm 作為更輕量的沙箱執行時，其 OCI 相容映象格式可能部分替代傳統容器映象（目前互補多於替代）。
獲利率受壓：映象倉庫本身是高運維成本、低毛利業務，差異化有限。

值得關注的趨勢

OCI 製品（OCI Artifacts）：映象倉庫正從”容器映象的倉庫”演變為”所有 OCI 製品的倉庫”（Helm charts、Wasm 模組、ML 模型、簽名等）。
eStargz / Nydus / OverlayBD：按需拉取（lazy-pulling）技術可大幅降低映象拉取時間和啟動延遲，對大規模 AI 訓練場景有重要價值。
映象不可變基礎設施的延伸：從容器映象到 VM 映象（如 AWS AMI）、再到無伺服器函式包，“不可變映象”範式正在擴充套件。

常見誤讀糾偏

誤讀 1：“映象就是容器”

糾偏：映象是只讀模板，容器是基於映象執行起來的例項。一個映象可以同時執行多個容器例項，就像一個 ISO 可以安裝到多臺機器。類比關係：

映象 (Image)  →  類 (Class)
容器 (Container) →  例項 (Object)

映象是不可變的；容器有可寫層，可以被修改、停止、銷燬。

誤讀 2：“映象越大越完整、越好”

糾偏：恰恰相反。大映象意味著：

更大的攻擊面：包含更多不必要的包 = 更多潛在 CVE
更慢的分發：網路傳輸和儲存成本上升
更慢的冷啟動：首次拉取時間與映象大小正相關

最佳實踐是使用最小化基礎映象（如 distroless、Alpine）並利用**多階段建置（multi-stage build）**將編譯環境與執行環境分離：

# 建置階段（僅用於編譯，不進入最終映象）
FROM golang:1.22 AS builder
WORKDIR /app
COPY . .
RUN CGO_ENABLED=0 go build -o /app/server .

# 執行階段（最小映象）
FROM gcr.io/distroless/static
COPY --from=builder /app/server /server
ENTRYPOINT ["/server"]
# 最終映象僅幾 MB

誤讀 3：“`latest` 標籤意味著最新版本”

糾偏：latest 只是一個預設標籤名，不保證內容是最新的。如果上游映象更新了但沒有重新打 latest 標籤，本地的 latest 就是舊版。此外，latest 標籤是可變的——同一條標籤可以在不同時間指向不同 digest。生產環境應始終使用 digest（SHA-256 雜湊）或明確的版本標籤引用映象：

# ❌ 不推薦（不確定拉的是哪個版本）
docker pull nginx:latest

# ✅ 推薦（精確版本）
docker pull nginx:1.25.3

# ✅ 最佳（不可變引用）
docker pull nginx@sha256:abc123...

誤讀 4：“Docker 映象和 OCI 映象是兩種不同的東西”

糾偏：Docker 早期有自己的映象格式（V1、V2 Schema 1），但自 2015 年 OCI 成立後，Docker 已將映象格式貢獻給 OCI 並採納 OCI 標準。當前 Docker 建置的映象就是 OCI 映象（或與 OCI 相容的 Docker Distribution 格式）。兩者技術上高度相容，行業已趨同於 OCI Image Spec。

學習路徑

入門（1-2 天）

安裝 Docker Desktop，執行 docker pull ubuntu、docker run -it ubuntu bash，體驗基本的映象拉取和容器執行。
學習 Dockerfile 基礎指令（FROM、RUN、COPY、CMD、ENTRYPOINT、EXPOSE）。
建置並推送一個簡單 Web 應用的映象到 Docker Hub。

進階（1-2 周）

理解分層機制：用 docker history 和 docker inspect 檢視映象層。
掌握多階段建置最佳化映象大小。
學習 docker buildx 建置多架構映象。
瞭解 OCI Image Spec 規範原文（重點看 Manifest 和 Config 格式）。
使用 Trivy 對映象進行安全掃描。

專家（持續）

深入 OCI Distribution Spec，理解映象分發協議。
學習 Sigstore/Cosign 進行映象簽名和驗證。
使用 syft 生成映象 SBOM，使用 grype 基於 SBOM 進行漏洞掃描。
評估 Nydus/eStargz 等按需拉取方案在大規模叢集中的應用。
瞭解 WebAssembly 容器映象與 OCI Artifact 的演進。

一句話總結

容器映象是雲端原生軟體交付的原子單元——一個不可變的、分層的、內容定址的只讀檔案包，它標準化了”應用+執行時+依賴”的封裝和分發方式，是從 CI/CD 流水線到 Kubernetes 排程再到 AI 訓練/推論環境的基礎設施基石。

延伸閱讀與來源

OCI Image Specification — 容器映象的技術規範
OCI Distribution Specification — 映象分發協議規範
CNCF Annual Survey 2023 — 容器/Kubernetes 採用率資料
Docker Documentation: Best practices for writing Dockerfiles
NIST SP 800-218 (SSDF) — 安全軟體開發架構（含 SBOM 要求）
Liz Rice, Container Security (O’Reilly, 2020)
Harbor Project (CNCF) — 開源企業級映象倉庫
Trivy (Aqua Security) — 開源映象漏洞掃描工具
Sigstore / Cosign — 映象簽名和供應鏈安全

本文中未標註來源的具體數字均為基於公開技術規範的定性描述或行業估算，讀者請以廠商最新官方資料為準。