基础:Docker的7个替代方案:一体化解决方案和独立容器工具

爱德华Kisller
2021-05-10 09:21

最后更新:2021年5月6日

码头工人是迄今为止世界上最知名和使用最广泛的集装箱平台。但是在容器领域中还有其他技术,每种技术都有自己的方法和用例。所以,如果你新的集装箱,你会想要考虑这些选择否则,你可能会做出一个以后可能会后悔的IT决定。继续往下读,我们将为您概述六个非docker选项。这些不仅包括完整的解决方案,但是细粒度的这些工具既可以作为Docker的补充,也可以作为完全不同的容器系统的一部分。

让我们来看看七个完整的软件包,它们是Docker目前最直接的竞争对手。

  1. Artifactory码头工人注册表
  2. LXC (Linux)
  3. Hyper-V和Windows容器
  4. rkt(与Kubernetes合作
  5. Podman(开源容器引擎
  6. runC(可移植性解决方案)
  7. Containerd(容器运行时

1.Artifactory码头工人注册表

Artifactory码头工人注册表是一个安全的私有注册表,用于管理Docker映像,提供对远程Docker容器注册表的访问集成建立生态系统。

它可以让你建立无限的Docker注册中心,使用本地、远程和虚拟Docker存储库。工作透明的通过Docker客户端,它管理Docker映像,这些映像是在内部创建并下载的远程Docker资2022世界杯阿根廷预选赛赛程源,例如码头工人中心

局部存储库提供了一种部署和托管内部Docker映像的方法,然后这些映像可以跨组织共享。远程存储库作为在远程URL管理的注册表的缓存代理,例如https://registry-1.docker.io(也就是Docker Hub), Docker映像在这里按需缓存。Artifactory-defined,虚拟存储库聚合来自本地和远程存储库的映像,允许访问驻留在本地Docker存储库上的映像,以及远程映像代理从一个单一的URL通过远程Docker存储库。

Artifactory支持将Docker映像从Artifactory中的一个Docker库提升到另一个Docker库。的相关调用码头工人注册API这样它就可以透明地使用Docker客户机通过Artifactory访问图像。


建立您自己的Docker容器注册表

自由的云现在免费下载


2.LXC (Linux)

LXC是一套低级容器管理工具的一部分LinuxContainers.org开源项目。该技术是Docker的先驱,由规范,背后的坚定Ubuntu

LXC的目标是提供一个独立的应用程序环境,它非常类似于一个成熟的虚拟机(VM),但没有运行自己内核的开销。LXC也遵循Unix进程模型,其中没有中央守护进程。简单地说,不是由一个单一的中央程序管理,每个容器的行为就像由一个独立的程序管理一样。

LXC在许多其他方面的工作方式也与Docker不同。例如,你可以跑步多个流程在LXC容器中运行,而Docker设计用于在每个容器中运行单个进程。尽管如此,Docker在抽象资源方面做得更好,因此,它的容器往往比LXC的容器更可移植。2022世界杯阿根廷预选赛赛程

3.Hyper-V和Windows容器

当微软发布Windows Server 2016,它引入了两种新的容器技术,都为成熟的Windows虚拟机(vm)提供了轻量级的替代方案。第一,Windows的容器,采用了类似于Docker的抽象方法。另一种是hyper - v的容器

Hyper-V容器与VM虚拟化模型,因为每个都可以携带自己的内核。这意味着他们提供更大的可移植性与传统容器相比,因为在其中运行的应用程序不需要与宿主系统兼容。他们也负担得起更好的安全性由于与主机操作系统和其他容器环境的隔离程度提高了。然而,这些好处是有代价的,因为Hyper-V容器携带轻微的提高基础设施足迹而不是Windows和其他依赖于基于共享内核系统的容器。

您可以使用任何一种方式来管理Hyper-V容器码头工人或者是Windows PowerShell,而是每个客人的环境必须基于Windows,但不一定与主机操作系统的版本相同。

4.rkt

凭借其强大的生态系统和强大的接受程度,rkt(原名CoreOS火箭)已经成为Docker最可行的替代品之一。

这种开源技术的核心优势是安全最重要的是,互操作性使用其他系统和框架。例如,它可以运行Docker容器,并使用基于pod的体系结构,直接开箱即用Kubernetes

与LXC一样,rkt不使用守护进程,因此提供了更多细粒度控制在单独的容器级别上。

尽管有这些优势,但自2018年RedHat收购CoreOS以来,rkt的未来方向已经越来越不确定的.此外,2019年8月,云原生计算基金会(CNCF)决定停止对该项目的支持。

⌘⌘⌘⌘⌘⌘⌘⌘⌘⌘

以下也是Docker的替代方案,但它们是完整的、端到端解决方案。相反,它们要么与其他技术协调使用,要么代替Docker系统的特定组件使用。

5.Podman

Podman是一个开源容器引擎,它的作用与码头工人引擎.它之所以与众不同,是因为它隔离而且用户权限特色造就了Podman的本质更安全的

同样,其命令行界面(CLI)命令实际上与Docker CLI所支持的命令完全相同,唯一的例外是使用Podman来代替Docker库。

虽然Docker和Podman CLI命令是相似的,但知道如何告诉区别两者之间的联系将有助于您在幕后与它们合作。码头工人遵循客户机/服务器模型,使用守护进程管理其控制下的所有容器。然而,Podman,像rkt和LXC一样,是函数没有一个中央守护进程。这可以潜在地提高任何给定容器的弹性,通过消除的可能性单点故障(SPOF)。换句话说,如果您的守护进程停止运行,您将失去对容器的控制。相比之下,在Podman中,容器是自给自足,完全孤立环境,可以相互独立地进行管理。

此外,Docker默认给容器用户root权限,非root访问是Podman的标准。

6.runC

runC是一个轻量级的,普遍的操作系统的运行时容器。它最初是一个底层的Docker组件,在底层工作,嵌入到平台架构中。然而,它已经作为一个独立的模块化工具推出。

这个版本背后的想法是改进容器可移植性通过提供一个标准化的、可互操作的容器运行时这两个作为Docker的一部分,独立于Docker。因此,runC可以帮助您避免与特定的技术、硬件或云服务提供商紧密联系在一起。

7.containerd

Linux和Windows均支持containerd基本上是一个守护进程,它充当接口在容器引擎和容器运行时之间。

它提供了一个抽象层,它使管理容器生命周期(例如图像传输、容器执行、快照功能和某些存储操作)变得更容易API请求.这避免了多次低级系统调用的麻烦。由于这些系统调用可能因平台而异,这也使得容器更多可移植的同时允许API基本保持不变。

像runC一样,containd是Docker系统的另一个核心构建块,它已经作为一个独立的开源项目分离出来了。

码头工人的替代品

LXC

Windows hyper - v

rkt

Podman

runC

containerd

解决方案类型

一体化的

一体化的

一体化的

容器引擎

容器运行时

接口/

守护进程

优点

没有守护进程。更适合传统的应用程序设计。

更高级别的隔离和可移植性。

更好的安全性。没有守护进程。高度互操作。

更加安全。

没有守护进程。熟悉CLI命令。

标准化的可互操作容器运行时。

更容易管理容器的生命周期。

缺点

有限的可移植性。

更多的技术实现。

大基础设施足迹。仅Windows。

功能有限。

项目未来的不确定。

容器引擎。

容器运行时。

容器接口。

开源

是的

不是,但与开源兼容

是的

是的

是的

是的

了解更多关于Docker的信息