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

点击图片访问链接

自从 Docker 引入后，容器环境已经发生了相当大的变化。虽然 Docker 今天仍然广为使用，但一些不错的选择也非常值得考虑，可能更符合您的需求。我想和大家分享一下探索这些选择时的一些体会。

    标题：容器技术的发展历程
    2013: Docker 发布
          ：统一的容器工具链
          ：内置的仓库和命令行工具
    2015: OCI 成立
          ：镜像规格
          ：运行时规范
    2016: containerd
          ：Kubernetes 运行时
          ：性能重点
    2017: BuildKit
          ：并发构建
          ：多平台兼容
    2018: Podman 1.0
          ：无守护进程架构
          ：无特权容器
    2020: 现代时期
          ：桌面替代方案
          ：多运行时支持

进入或退出全屏

当 Docker 第一次出现时，它是一种技术，能够将容器的创建和运行时管理功能集成到一个工具中。这在当时相当具有开创性，但随着时间的推移，容器使用的成熟，变得很明显，团队需要特定的工具来应对容器化中的特定需求，这便促进了专门化的替代工具。

了解容器规范

容器生态系统建立在开放标准之上，其中最著名的是[开放容器倡议（OCI）]。这其中包括标准化了……

这一标准化意味着你不必局限于某一特定工具。你可以用一个工具构建镜像，然后在另一个工具中运行它们。这给你提供了选择的自由，使用最适合完成特定任务的工具。

作为使用容器的DevOps工程师工作时，我发现Podman在那些重视安全性的团队中，Podman是一个真正的变革者——这意味着避免使用根权限带来的风险。与Docker相比，Podman没有守护进程，这是一次重要的架构转变。无守护进程的方法神奇地改变了团队在生产环境中，尤其是在进行容器安全管理的方式。

第一次为客户切换到Podman时，这个客户非常注重安全。这种没有“守护进程”的架构显得非常合理。每个容器都以你当前用户的权限运行，而不是以特权“守护进程”的形式运行：

    以你的用户身份运行容器
    podman run nginx   # 无需 root 权限，也没有守护进程

    # 即使是无根容器也能绑定到特权端口
    podman run -p 80:80 nginx   # 也可以无需 root 权限运行！

全屏显示，退出全屏

在桌面上也能体验到类似Kubernetes的操作感受

最令人惊喜的是 Podman 中内置的 pod 支持。它允许在本地系统上尝试像 Kubernetes 一样的概念。

    # 创建一个包含多个容器的 pod
    podman pod create --name my-app 
    podman run --pod my-app -d nginx
    podman run -d redis

这里我们

    # 创建一个包含多个容器的 pod
    podman pod create --name my-app 
    podman run --pod my-app -d nginx
    podman run -d redis

全屏模式,退出全屏

在运行大型 Kubernetes 集群之后，你就会爱上 containerd 这种专注于一件事情的方法。它是一个轻量级且高性能的容器运行时，驱动了许多容器平台，其中包括间接地驱动 Kubernetes。根据我的经验，containerd 确实做到了这一点：它只做好一件事，即高效地运行容器。

平台构建

在构建容器平台时，containerd 的亮点在于

    // 简单地与 containerd 集成
    client, err := containerd.New("/run/containerd/containerd.sock")
    container, err := client.NewContainer(ctx, "nginx",
    containerd.WithNewSnapshot("nginx", image),
    containerd.WithNewSpec(oci.WithImageConfig(image)))

    // 该代码段展示了如何简单地与 containerd 进行集成，包括创建一个新的容器并配置其快照和规范。

进入全屏，退出全屏

我记得那时容器构建速度慢，效率也不高，通常是我们CI/CD管道中的瓶颈。直到我发现了BuildKit，我的生活从此改变。BuildKit是Docker的下一代构建工具，不过也可以独立使用。

高效并行的构建

BuildKit最好的地方就是它能够并行化构建步骤：

Dockerfile
# 这些阶段将并行构建
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。系统容器更像是一种轻量级的虚拟机，而不是大多数人通常认为的容器，与应用程序容器相比，它们有不同的侧重点。

开发环境

LXD容器在独立的开发环境中非常出色：

# 创建一个完整的Ubuntu环境如下：
启动一个Ubuntu 20.04的容器，并命名为dev-env
lxc launch ubuntu:20.04 dev-env
在dev-env容器中安装Python3，使用命令：`sudo apt install python3`
lxc exec dev-env -- sudo apt install python3

# 共享你的项目文件夹，如下所示
将你的项目文件夹挂载到容器中，使用命令：`lxc config device add dev-env code disk source=/path/to/code path=/code`
lxc config device add dev-env code disk source=/path/to/code path=/code

进入全屏模式，退出全屏

CICube 是一个GitHub Actions监控工具，它为你提供详细的洞察，帮助你进一步优化你的CI/CD流水线。使用CICube，你可以追踪工作流运行，了解瓶颈所在，并进一步优化构建时间。立即访问 cicube.io 并创建一个免费账号，来更好地优化你的GitHub Actions工作流！

在寻找Docker替代品的过程中，我发现容器生态系统更多地是关于挑选适合您需求的正确工具，而不是找到完美的替代品。Podman的无根特性带来了安全而无任何妥协，Containerd的简洁性非常适合Kubernetes环境中的使用，BuildKit改变了我们构建镜像的方法，而LXC/LXD则提供了一种独特的方式来实现系统容器化。

现代容器工具最酷的地方在于互相操作：用BuildKit来高效构建，用Podman在开发中运行它们，并在生产中部署到Containerd。这种灵活性得益于OCI标准，使我们能够创建真正符合我们需求的流程，而无需去适应一个工具。