.artifact的子命令是自Podman 5.4版起才有功能。昨天介紹的.image並沒有registry的功能，是由.artifact補足，概念上更接近k8s的標準。.artifact管的不是一般runnable container image，而是OCI Artifact。
在OCI出現之前，是Docker主導了容器市場，但隨後出現了其他競爭技術（如 CoreOS 的 rkt），導致市場面臨格式分裂的風險。所以成立了OCI(Open Container Initiative，開放容器倡議）來解決這個問題，其主要作用包括：

• 防止廠商壟斷（Vendor Lock-in）：確保任何廠商開發的容器工具都能互相相容。
• 確保跨平台通用：在Docker打包的image，可以直接在 Podman、Kubernetes (K8s) 或 AWS/Azure 等任何相容 OCI的平台上完美運行。
• 制定三大核心標準規格：
  • Image Spec（鏡像規格）：規定容器鏡像該如何打包（分層結構、Metadata格式）。
  • Runtime Spec（執行階段規格）：規定如何將解壓後的鏡像運行起來（例如最底層的 runc 或 crun）。
  • Distribution Spec（分發規格）：規定容器鏡像與構件該如何在客戶端與註冊表（Registry）之間進行上傳和下載（這也是 podman artifact 能夠運作的基礎）。

藉由OCI三大核心標準規格看待完Podman Quadlet完整的生態如下：

                       Quadlet
                          │
        ┌─────────────────┼─────────────────┐
        │                 │                 │
     Image類            Runtime類          Distribution類
        │                 │                 │
        │                 │                 │
    .image            .container         .volume
    .build            .pod               .network
    .artifact         .kube

截至昨天發文所走向的路徑是：

.build
   ↓
Build image

.image
   ↓
Pull image

          ↓

      .container
          ↓
     Run container

就是從包版到佈署再到維運的流程。

而.artifact卻是走管理流程，路徑如下：

Registry
   ↓
.artifact
   ↓
OCI artifact store

所以目標不是產出Container，而是管理符合OCI規格的資源，除了Container Image，以下資源類型均能註冊到OCI artifact store：

• SBOM
• signature
• certificate
• WASM
• Helm chart
• 模型
• 設定 bundle
• binary artifact

熟悉Maven的也知道Repositoy的主角不一定jar檔，像pom、so(Share Object)等各種型式的檔案也能被Maven Repository管理。Registry在podman的定位如同Repository在Maven的定位。