Docker替代产品

梅钟园

podman

  Podman 是 RedHat 开发的一个无守护程序的开源 Linux 原生容器引擎，用于构建、运行和管理 Linux OCI 容器与容器镜像。

  尽管 Podman 提供了一个类似于 Docker 的命令行界面，但它的操作方式并不相同。

  Docker 和 Podman 之间的一个显著区别是，Docker 运行一个持久的、自给自足的运行时来管理其对象或称为 dockerd 的守护进程；

而 Podman 并不依赖守护进程来工作，相反，Podman 将容器作为子进程启动，

它还直接与注册表和使用运行时进程的 Linux 内核进行交互，也正因如此，Podman 被称为无守护进程的容器技术。

  没有守护进程提高了 Podman 作为容器引擎的灵活性，消除了对单个进程的依赖。Podman 与 Docker 的另一大不同就是它不需要 root 权限。

  这一特点提供了一个额外的安全缓冲区，限制了某些可能操纵关键系统设置并使容器和包含的应用程序易受攻击的潜在危险进程。

此外，Podman 可以运行 pod-- 包含一个或多个容器的集合，作为一个单一实体管理，并利用共享的资源池。通过这项能力，Podman 用户可以将他们的工作负载转移到 Kubernetes。

lxd

  LXD 一个专为 LXC Linux 容器设计的开源容器引擎。LXC 使用户能够在隔离的容器或类似于虚拟机的虚拟环境中运行应用程序，而无需承担管理单个内核的技术负担。

  LXD 提供了一个用于连接 LXC 软件库的接口，同时创建了一个守护进程，负责处理网络、数据存储和管理多个 LXC 容器。

  尽管 LXC 可以作为独立工具运行，但它拥有有限的功能子集。LXD 提供了这些附加功能，因此依赖于 LXC 工作。

  LXD 与 Docker 的主要区别如下。与 Docker 建议每个容器只有单个进程的设计模式不同，LXC/LXD 中的容器可以运行多个进程。

  此外，Docker 容器可移植性更强，为与 LXD 相比，Docker 有效地抽象了资源。最后，Docker 支持在 Windows 和 macOS 环境上运行，但 LXD 只支持 Linux。

containerd

  containerd 是一个高级容器运行时，它通过在底层运行 runc 以提供操作系统和容器引擎之间的接口。

  runc 是一个支持 Windows 和 Linux 的守护进程，它抽象了特定于操作系统的功能，使运行和监督容器以及管理图像传输和存储变得更加容易。

  containerd 提供的这种抽象级别功能消除了进行若干低级系统调用的复杂性，使得容器的可移植性得以实现。然而，与 Docker 不同，containerd 不处理镜像的构建或卷的创建。

  有趣的是，containerd 是 Docker 的默认运行时，现在它是一个独立的工具，就像 runc 一样。

  这也使得 containerd 像 Kubernetes 一样成为一个方便的编排工具，containerd 也是最受欢迎的 Docker 替代品之一。

buildah

  Buildah 是红帽基金会为容器化系统开发的一个 OCI 镜像构建工具。它是一个提供类似于在 Docker 中运行 docker build 的功能的工具。

  Buildah 经常与 Podman 一起使用，互作补充，例如，Podman 在后台使用 Buildah 功能的子集来实现其构建过程。

  它可以从 Dockerfile 或 Containerfile 中构建镜像，并生成与使用 Docker 创建的镜像相同的镜像，因为这些镜像是符合 OCI 的。

  此外，它还提供了对镜像层的细粒度控制，允许在一个单一层中进行多次修改提交。

  它还提供了从头开始构建镜像的能力，即不包含任何内容的镜像，这让用户可以自由地只添加运行应用程序所需的软件包。最后，与 Docker 不同的是，在 Buildah 中，用户只能看到他们构建的镜像。

buildkit

  BuildKit 是第二代构建镜像的 Moby 项目，在较新的 Docker 版本中作为实验性功能提供。与 Docker 一样，它使用守护程序运行。

  不过，标准 Docker 构建和 BuildKit 之间的主要区别之一是，前者是逐层构建，后者提供并行构建处理。

  这个功能提高了性能，使构建速度更快。BuildKit 还允许跳过未使用的阶段，改善增量构建，并允许无根构建。此外，BuildKit 使用一个缓存来减少重建图像每一层的需要。

kaniko

  Kaniko 是一个谷歌镜像构建工具，它可以从 Dockerfile 构建镜像。

  它和 Buildah 一样是无守护进程的，但更侧重于在 Kubernetes 中构建镜像。

  Kaniko 对于本地开发实例来说不是很方便，因为它通常作为镜像与 Kubernetes 等容器编排器一起运行。

  对于 Kubernetes 集群中的持续集成和交付管道，Kaniko 可以成为一个实用的工具。

runc

  RunC 以前是嵌入到 Docker 架构中的一个模块，在 2015 年作为独立工具发布。

  此后，它成为一个广泛使用的、标准化的、可互操作的容器运行时。

  DevOps 团队可以将其作为 Docker 或其他定制容器引擎的一部分。RunC 属于容器化生态系统中的容器运行时部分。

  容器运行时是处理容器运行的容器引擎中使用的较低级别的组件。

  尽管 Docker 为组织在容器化过程中所需的各个方面提供了一个全面的工具包，但某些 DevOps 功能可能需要探索其他替代方案。

  但是，在选择任何此类选项时也需牢记此类替代方案所运行的主机操作系统及其使用情况。

-- 以上内容为转载分享内容 --