容器完全指南：從入門到實戰

前言

是不是很多人一想到「容器 = Docker」？

其實，在容器技術的世界裡，除了 Docker 之外，還有各種不同的選擇。本文會從容器的基礎概念開始，詳細介紹 Docker 以外的主要容器引擎。

本文可以學到什麼？

容器技術的基本概念
Docker 以外主要容器引擎的特色
各個引擎的使用情境與取捨方式
實際的安裝步驟與使用範例

1. 容器技術的基礎知識

1.1 什麼是容器？

容器是一種將「應用程式及其所有相依套件」打包起來，並在隔離環境中執行的技術。

與虛擬機（VM）相比，有以下特徵：

1.2 什麼是容器引擎？

容器引擎是用來管理容器生命週期（建立、啟動、停止、刪除）的軟體。

主要功能包含：

映像檔管理：建立、儲存、發佈容器映像檔
容器執行：從映像檔啟動並管理容器
網路管理：設定容器之間的網路溝通
儲存管理：資料持久化處理

1.3 容器相關標準規格

容器技術有以下標準規格：

OCI（Open Container Initiative）：針對容器執行格式與映像檔格式的標準
OCI Runtime Spec：容器如何執行的規格
OCI Image Spec：容器映像檔格式的規格
CRI（Container Runtime Interface）：Kubernetes 與容器 Runtime 之間的介面

有這些標準存在，可以確保不同容器引擎之間的相容性。

2. 為什麼需要 Docker 以外的選擇？

Docker 是很優秀的工具，但因為以下原因，大家逐漸開始尋找替代方案：

2.1 授權與成本問題

自 2021 年 9 月起，Docker Desktop 在大型企業的商業用途需要付費
小型團隊仍可免費使用，但依組織規模不同可能產生年度授權費

2.2 架構上的課題

Docker 需要常駐的 Daemon 行程（dockerd）
Daemon 以 root 權限執行，存在資安風險
一旦 Daemon 停止，所有容器都會受到影響

2.3 使用情境的多樣化

在 Kubernetes 環境中，偏好更輕量的 Runtime
在 CI/CD 環境中，希望能在無特權（non-privileged）模式下執行會更安全
在微服務架構中，針對特定用途最佳化的工具更有效

3. 主要容器引擎詳細解說

3.1 Podman

概要

Podman 是 Red Hat 開發的容器引擎，是目前最受歡迎的 Docker 替代方案之一。

主要特點

無 Daemon 的架構（Daemonless Architecture）

不需要背景常駐 Daemon
容器以一般行程的方式執行
提升整體系統穩定性

Rootless 執行

不需要 root 權限即可執行容器
大幅降低安全風險
適合多使用者環境安全使用

與 Docker 的相容性

只要把 docker 指令換成 podman 就能運作
可以直接使用既有的 Dockerfile
與 Docker Hub 等 Registry 相容

Pod 的概念

支援 Kubernetes 相容的 Pod（多容器群組）
往 Kubernetes 遷移較為容易

優點

資安水準高
從 Docker 遷移非常容易
有 Red Hat 的商業技術支援
與 systemd 的整合非常好

缺點

與 Docker Compose 並非完全相容（可用 podman-compose 因應）
Windows 原生支援較有限
生態系尚未如 Docker 成熟

適用情境

重視安全性的環境
開發機上替代 Docker 的選項
CI/CD Pipeline
Linux 環境上的正式上線系統

安裝與快速開始

# macOS（使用 Homebrew）
brew install podman

# Podman Machine（macOS/Windows 用）初始化
podman machine init
podman machine start

# Ubuntu/Debian
sudo apt-get update
sudo apt-get install -y podman

# RHEL/CentOS/Fedora
sudo dnf install -y podman

# 確認版本
podman --version

# 執行 Nginx 容器
podman run -d -p 8080:80 --name web nginx

# 顯示容器列表
podman ps

# 停止並刪除容器
podman stop web
podman rm web

與 Docker 指令對照

# Docker 指令 → Podman 指令
docker run    → podman run
docker ps     → podman ps
docker build  → podman build
docker images → podman images

# 設定 alias 後幾乎可當 Docker 用
alias docker=podman

3.2 containerd

概要

containerd 原本是 Docker 的核心元件之一，目前是 CNCF（Cloud Native Computing Foundation）的專案。

主要特點

輕量且簡潔

僅提供執行容器所需的最小功能
提供低階 API
額外負擔（Overhead）很小

Kubernetes 標準 Runtime

是 Kubernetes 推薦的容器 Runtime
完全符合 CRI（Container Runtime Interface）
許多 Managed Kubernetes 服務採用

業界標準

被 Docker、Kubernetes、AWS ECS、Google Cloud Run 等廣泛使用
符合 OCI 規範
穩定性與信賴度高

優點

非常輕量、效能佳
與 Kubernetes 的相容性極佳
在正式環境有大量實績
作為 CNCF 專案屬中立立場

缺點

內建 CLI 功能基本（進階操作多用 nerdctl）
不算是新手友善工具
不像 Docker 那樣提供整合式開發體驗
映像檔建置功能需搭配其他工具（如 BuildKit）

適用情境

Kubernetes 叢集的容器 Runtime
正式環境中需要輕量 Runtime
需將容器 Runtime 嵌入自家產品時
Cloud Native 架構環境

安裝與快速開始（Ubuntu/Debian 範例）

# 安裝依賴套件
sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl gnupg lsb-release

# 新增 Docker 官方 GPG 金鑰
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

# 設定套件庫
echo "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# 安裝 containerd
sudo apt-get update
sudo apt-get install -y containerd.io

# 啟用 containerd
sudo systemctl enable --now containerd

# 安裝 nerdctl（Docker 風格 CLI）
wget https://github.com/containerd/nerdctl/releases/latest/download/nerdctl-full-1.7.0-linux-amd64.tar.gz
sudo tar Cxzvf /usr/local nerdctl-full-1.7.0-linux-amd64.tar.gz

# 使用 nerdctl 執行容器
sudo nerdctl run -d -p 8080:80 --name web nginx

# 查看容器列表
sudo nerdctl ps

# 查看映像檔列表
sudo nerdctl images

containerd 設定

# 產生預設設定檔
sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml

# 編輯設定（例如改用 systemd cgroup driver）
sudo nano /etc/containerd/config.toml
# [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
#   SystemdCgroup = true

# 重新啟動 containerd
sudo systemctl restart containerd

3.3 CRI-O

概要

CRI-O 是專為 Kubernetes 設計的輕量容器 Runtime，重點就是與 Kubernetes 的緊密整合。

主要特點

Kubernetes 專用設計

專注實作 CRI（Container Runtime Interface）
不包含 Kubernetes 不需要的多餘功能
完全追隨 Kubernetes 版本更新

符合 OCI 標準

完全符合 Open Container Initiative 標準
支援多種 Runtime（runc、crun、Kata 等）
架構彈性高

重視安全性

最小權限原則（Least Privilege）
整合 SELinux、AppArmor
支援 Seccomp Profile

優點

在 Kubernetes 環境中有最佳化效能
強化安全性
Red Hat OpenShift 預設採用
與 Kubernetes 版本同步有保證

缺點

基本上不考慮 Kubernetes 以外使用情境
不適合單機、獨立開發用
文件多半假設你已有 Kubernetes 知識
學習資源相比 Docker 較少

適用情境

Kubernetes 叢集（特別是重視安全性時）
Red Hat OpenShift 環境
企業級 Kubernetes 環境
具嚴格法規／稽核需求的環境

安裝範例（Kubernetes 節點／Ubuntu 20.04）

# 前置作業
sudo apt-get update
sudo apt-get install -y software-properties-common curl

# 新增 CRI-O 套件庫（以 1.28 版本為例）
export OS=xUbuntu_20.04
export VERSION=1.28

echo "deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /" | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
echo "deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /" | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list

curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | sudo apt-key add -
curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | sudo apt-key add -

# 安裝
sudo apt-get update
sudo apt-get install -y cri-o cri-o-runc

# 啟動 CRI-O
sudo systemctl enable --now crio

# 確認狀態
sudo systemctl status crio

# 使用 crictl（CRI 相容 CLI）
sudo crictl version
sudo crictl images
sudo crictl ps

與 Kubernetes 的整合範例

# kubeadm 設定範例（/etc/kubernetes/kubeadm-config.yaml）
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
networking:
  podSubnet: 10.244.0.0/16
---
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
cgroupDriver: systemd
containerRuntimeEndpoint: unix:///var/run/crio/crio.sock

3.4 LXC/LXD（Linux Containers）

概要

LXC 是很早期的 Linux 容器技術，LXD 則是其上層管理工具。它提供介於「虛擬機」與「應用程式容器」之間的「系統容器」。

主要特點

系統容器（System Container）

可以執行一整套完整的 Linux 系統
內含 init 系統（例如 systemd）
使用感受接近虛擬機（VM）

適合長時間執行

適用於有狀態（stateful）的工作負載
可以作為虛擬機的替代方案
支援容器遷移（Migration）

LXD 的附加功能

RESTful API
映像伺服器
叢集管理功能
Snapshot 與備份

優點

比虛擬機更輕量、更快速
可使用完整的 Linux 環境
網路與儲存設定彈性高
有 Canonical 的支援

缺點

與 Docker 類型的「應用程式容器」思維不同
映像檔生態系較小
不太適合典型的 Cloud Native 用途
學習曲線稍高

適用情境

開發、測試環境
當作虛擬機的輕量替代品
有狀態的應用程式
多租戶（multi-tenant）環境

安裝與快速開始（Ubuntu/Debian）

sudo apt-get update
sudo apt-get install -y lxd

# 初始設定（互動式）
sudo lxd init
# 使用預設值一路按 Enter 即可

# 將使用者加入 lxd 群組
sudo usermod -aG lxd $USER
newgrp lxd

# 查看可用映像
lxc image list images: | grep ubuntu

# 建立並啟動 Ubuntu 22.04 容器
lxc launch images:ubuntu/22.04 my-ubuntu

# 查看容器列表
lxc list

# 進入容器 shell
lxc exec my-ubuntu -- /bin/bash

# 停止容器
lxc stop my-ubuntu

# 刪除容器
lxc delete my-ubuntu

實戰範例：建置 Web 伺服器

# 使用 Ubuntu 22.04 建立 Nginx 伺服器
lxc launch images:ubuntu/22.04 webserver

# 進入容器
lxc exec webserver -- bash

# 在容器內安裝 Nginx
apt update
apt install -y nginx
systemctl enable nginx
exit

# 設定 Port Forwarding
lxc config device add webserver myport80 proxy listen=tcp:0.0.0.0:8080 connect=tcp:127.0.0.1:80

# 在瀏覽器開啟 localhost:8080

3.5 Buildah

概要

Buildah 是專門用來建置容器映像檔的工具。

它可以不透過 Docker Daemon，甚至不必使用 Dockerfile，而以腳本方式建置映像檔。

主要特點

專注於 Build

只負責映像檔建置
執行容器則交給 Podman 等其他工具
符合「單一責任原則」

不一定需要 Dockerfile

可用 Shell Script 完整描述建置流程
更細緻的操作控制
當然也仍可使用 Dockerfile

控制映像檔層（Layer）

可控制在何時產生 Layer
容易縮小映像檔尺寸
Cache 策略更彈性

優點

容易最佳化映像檔大小
可以在 rootless 環境下建置
容易與腳本／自動化流程結合
可善用既有 Shell Script 資產

缺點

相對於 Dockerfile，學習成本略高
容器執行需靠其他工具
社群規模仍小於 Docker
文件資源較少

適用情境

CI/CD Pipeline
映像檔大小優化很重要時
Build 流程複雜，需要細緻控制時
Dockerfile 難以表達需求的 Build 情境

3.6 Kata Containers

概要

Kata Containers 是一種「混合型」容器 Runtime，利用 VM 做隔離，但又保留容器的便利性。簡單說：兼具容器的輕量與虛擬機的高安全等級。

主要特點

以硬體虛擬化提供隔離

每個容器在自己專屬的輕量 VM 中執行
於 Kernel 層級完全隔離
能有效避免鄰近租戶攻擊（noisy neighbor）

與容器 API 相容

完全符合 OCI 與 CRI
可與 containerd、CRI-O 整合
可直接使用既有容器映像檔

使用輕量 VM 技術

使用 QEMU 或 Cloud Hypervisor 等
啟動時間約數百毫秒（比傳統 VM 快很多）
盡量降低記憶體額外開銷

優點

安全等級極高
非常適合多租戶環境
能符合嚴謹的法規／稽核需求
能與 Kubernetes 無縫整合

缺點

比一般容器「重」（需要啟動 VM）
必須支援硬體虛擬化（Intel VT-x / AMD-V 等）
設定較複雜
除錯較困難

適用情境

多租戶雲端環境
安全性要求極高的系統
需要執行不信任的程式碼
金融、醫療等高規範產業

3.7 gVisor

概要

gVisor 是 Google 開發的 User-space Kernel，

在應用程式與宿主機 Kernel 之間再加上一層安全防護。

主要特點

User-space Kernel

截獲 Linux System Call
限制對宿主機 Kernel 的直接存取
使用 Go 實作的自家 Kernel（Sentry）

與 OCI 相容

可與 Docker、containerd、Kubernetes 整合
既有容器映像檔可直接使用
可作為 runc 的替代 Runtime

沙箱（Sandbox）執行

大幅減少 System Call 攻擊面
保護宿主機 Kernel 不被直接攻擊
降低容器逃逸（container escape）風險

優點

高安全性
不需硬體虛擬化（比 Kata Containers 輕量）
已在 Google Cloud Run 等服務實戰部署
應用程式相容性相當高

缺點

有效能額外負擔（尤其 I/O）
並非所有 System Call 都被支援
除錯難度較高
記憶體使用量可能增加

適用情境

Serverless 環境（例如 Google Cloud Run）
多租戶 SaaS
執行不信任的程式碼
任何以安全性為優先的容器環境

3.8 Firecracker

概要

Firecracker 是 AWS 開發的超輕量 microVM 技術，

是 AWS Lambda 與 Fargate 的底層技術之一。

主要特點

microVM

基於 KVM 的極小虛擬機
啟動時間小於 125 ms
記憶體 Overhead 小於 5 MB

重視安全性

以 VM 等級完整隔離
精簡的 Device Model
將攻擊面壓到最低

針對 Serverless 最佳化

高密度執行（一台 Host 可跑上千個 microVM）
快速 Snapshot 功能
透過 REST API 管理

優點

啟動極快
VM 等級的安全隔離
極輕量（CPU / 記憶體效率高）
在 AWS 上有大量實際使用案例

缺點

只能在 Linux Host 上執行（x86_64 / aarch64）
不直接與 OCI 容器相容
設定較低階，操作較複雜
社群規模小於 Docker

適用情境

Function as a Service（FaaS）平台
多租戶環境
Edge Computing
短時間執行的工作負載

3.9 systemd-nspawn

概要

systemd-nspawn 是整合在 systemd 裡的作業系統層級容器技術。

適合用來建立輕量的容器環境、除錯或隔離開發環境。

主要特點

與 systemd 原生整合

systemd 內建（多數現代 Linux 免額外安裝）
能與 systemd-machined 整合
可透過 journalctl 做統一 Log 管理

OS-level 虛擬化

可視為加強版的 chroot
隔離行程、網路、檔案系統
啟動非常輕量快速

偏向系統容器用途

可執行完整 Linux 系統
包含 init（systemd）
很適合作為開發／測試環境隔離工具

優點

只要有 systemd 就能用，安裝成本低
與 systemd 工具整合良好
輕量、簡單
很適合除錯與測試使用

缺點

不適合作為典型應用程式容器平台
沒有像 Docker 那樣的映像檔生態系
不太適合 Cloud Native 用途
官方文件相對較少

適用情境

開發與除錯環境
系統測試
在乾淨環境中驗證行為
與 systemd 相關的開發

3.10 Singularity/Apptainer

概要

Singularity（現稱 Apptainer）是專為 HPC（High Performance Computing，高效能運算）

與科學運算設計的容器平台，在研究機構與超級電腦環境相當普及。

主要特點

HPC 特化設計

可整合 MPI、GPU（CUDA、ROCm）
針對平行計算環境最佳化
在超級電腦上有大量實績

安全模型

預設 rootless 執行
以一般使用者權限執行容器
適合共用 HPC 環境

重視再現性

使用 SIF（Singularity Image Format）格式
單一不可變映像檔
方便確保科學研究可重現

Docker 相容性

可將 Docker 映像檔轉為 SIF
可從 Docker Hub 取得映像檔
可重用 Dockerfile 設計概念

優點

在 HPC 環境中實績豐富
rootless 執行安全性高
對 GPU、MPI 支援良好
與科學計算工作流程高度相容
單一映像檔易於分發與管理

缺點

對一般容器用途來說可能有點「太重」
與 Kubernetes 的整合較有限
社群規模仍小於 Docker
不特別適合典型 Web 開發情境

適用情境

HPC／超級電腦環境
機器學習、AI 研究
生物資訊（Bioinformatics）
科學計算工作流程
需要嚴謹再現性的研究專案