超越 Docker——DevOps 工程师的容器替代方案指南

介绍

自从 Docker 改变了我们打包和部署应用程序的方式以来，容器领域已经发生了相当大的变化。虽然 Docker 至今仍是最广泛使用的选项之一，但一些极具吸引力的替代方案也值得考虑，它们可能更符合您的需求。接下来，我将分享我探索这些替代方案的历程以及我在此过程中学到的经验。

容器运行时的演进

Docker 最初问世时，它将容器的创建、管理和运行时功能整合到一个工具中。这在当时可谓是革命性的。但随着时间的推移，容器技术的应用日趋成熟，团队逐渐意识到需要针对容器化特定方面使用特定的工具，这也催生了其他专业化方向的出现。

了解集装箱标准

容器生态系统基于开放标准——其中最值得注意的是开放容器倡议（OCI）。该倡议规范了以下内容：

这种标准化意味着您不会被任何特定工具所束缚。您可以在一个工具中构建镜像，然后在另一个工具中运行它们。这使您可以选择最适合完成特定任务的工具。

Podman：无守护进程的替代方案

作为一名DevOps工程师，在与容器打交道的高强度工作中，我发现Podman对于那些重视安全性的团队来说简直是颠覆性的——这意味着要避免使用root权限。与Docker相比，Podman是无守护进程的，这在架构上是一个巨大的变革。这种无守护进程的方式神奇地改变了团队在生产环境中处理容器安全的方式。

通过设计保障安全

我第一次为一位注重安全性的客户切换到 Podman 时，这种无守护进程架构就显得非常合理。每个容器都以用户权限运行，而不是作为特权守护进程运行：

Running a container as your user
podman run nginx   # No root, no daemon

# Even rootless containers can bind to privileged ports
podman run -p 80:80 nginx   # Works without root!

在桌面上体验类似 Kubernetes 的体验

但真正令人惊喜的是 Podman 对 pod-native 的支持。它允许在本地系统上尝试类似 Kubernetes 的概念：

# Create a pod with multi containers
podman pod create --name my-app 
podman run --pod my-app -d nginx
podman run --pod my-app -d redis

containerd：Kubernetes 运行时

在运维过大型 Kubernetes 集群之后，我逐渐体会到containerd专注的特性。作为一个轻量级、高性能的容器运行时，它为众多容器平台提供支持，包括间接支持的 Kubernetes。以我的经验来看，containerd 真正做到了面面俱到：高效运行容器。

平台建设

containerd 的这一特性在构建容器平台时尤为突出：

// Simple integration with containerd
client, err := containerd.New("/run/containerd/containerd.sock")
container, err := client.NewContainer(ctx, "nginx",
containerd.WithNewSnapshot("nginx", image),
containerd.WithNewSpec(oci.WithImageConfig(image))

BuildKit：重新构想集装箱建筑

我记得以前容器构建速度很慢，效率也不高，通常是我们 CI/CD 流水线的瓶颈。直到我发现了 BuildKit，一切才发生了改变。BuildKit是 Docker 的新一代构建引擎，但它也可以独立使用。

并行高效构建

BuildKit 最棒的地方在于它能够并行化构建步骤：

Dockerfile
# These stages build concurrently
FROM golang:1.21 AS backend
COPY backend. 
RUN go build

FROM node:18 AS frontend
COPY frontend. 
RUN npm build

FROM alpine 
COPY --from=backend /app/backend.  
COPY --from=frontend /app/dist ./dist

LXC/LXD：系统容器

在与需要完全系统访问权限的遗留应用程序打交道的过程中，我发现了一种不同的容器化方法：使用LXC/LXD。与应用程序容器不同，LXC/LXD 关注的是系统容器，可以将其视为轻量级虚拟机，而不是大多数人所理解的典型容器。

开发环境

LXD 在隔离的开发环境中表现出色：

# Create a full Ubuntu environment
lxc launch ubuntu:20.04 dev-env
lxc exec dev-env -- sudo apt install python3

# Share your project folder
lxc config device add dev-env code disk source=/path/to/code path=/code

监控 GitHub Actions 工作流

CICube是一款 GitHub Actions 监控工具，可提供工作流程的详细洞察，帮助您进一步优化 CI/CD 流水线。借助 CICube，您可以跟踪工作流程的运行情况，了解瓶颈所在，并最大限度地缩短构建时间。立即访问cicube.io并创建免费帐户，更好地优化您的 GitHub Actions 工作流程！

结论

在探索 Docker 替代方案的过程中，我发现容器生态系统的重点更多在于选择适合自身需求的工具，而不是寻找完美的替代品。Podman 的无根架构在保证安全性的同时，也兼顾了其他方面；Containerd 的简洁性使其完美适用于 Kubernetes 环境；BuildKit 革新了镜像构建方式；而 LXC/LXD 则为系统容器化提供了独特的视角。

现代容器工具的妙处在于它们的互操作性：你可以使用 BuildKit 高效构建，在开发环境中使用 Podman 运行，然后在生产环境中部署到 Containerd。这种灵活性得益于 OCI 标准，使我们能够创建真正符合自身需求的工作流程，而不是为了适应单一工具而改变自身需求。