容器其中些是遵循OCI标准的而另些不是

　　在过去四年中（2015-2019），云以及分布式计算成为的技术之一，它们从小众技能逐渐变成更被雇主看重的突出技能。容器化技术是云经济和IT生态系统中潮的技术之一。这篇文章可能会帮助您理解有关Docker和容器的一些令人困惑的概念。我们还将看到容器化生态系统在2019年的现状以及演变方向。

　　“不是我们造就了历史，而是历史造就了我们。” -- 马丁·路德·金Docker是当今知名的容器平台之一，它于2013年发布。但是在此之前，隔离和容器化已经被使用。让我们回到1979年，当时我们刚开始使用Chroot Jail，之后便出现了的容器化技术。了解这段历史不但有助于我们理解相关的新概念，也有利于我们理解这项技术。

　　时间退回到1979年，Unix版本7在开发过程中引入Chroot Jail以及Chroot系统调用。Chroot jail被用于“Change Root”，它被认为是早的容器化技术之一。它允许您将进程及其子进程与操作系统的其余部分隔离开来。容器这种隔离的问题是根进程（root process）可以轻松地退出chroot。它从未考虑实现安全机制。FreeBSD Jail于2000年在FreeBSD OS中引入，旨在为简单的Chroot文件隔离带来更多安全性。与Chroot不同，FreeBSD还实现了将进程及其活动隔离到文件系统的特定视图中。

　　当Linux内核具有操作系统级的虚拟化的功能以后，Linux VServer于2001年被推出，它使用了类似chroot的机制与“安全上下文”（“security context”）以及操作系统虚拟化（容器化）相结合来提供虚拟化解决方案。它比简单的chroot更先进，允许您在单个Linux发行版（VPS）上运行多个Linux发行版。

　　与Solaris Containers类似，OpenVZ的个版本于2005年推出。OpenVZ与Linux-VServer一样，使用操作系统级虚拟化，许多托管采用它来隔离和销售VPS。操作系统级虚拟化有一些限制，因为容器共享相同的体系结构和内核版本，当客户需要不同于主机的内核版本的情况下这种缺点就会显现出来。

　　Linux-VServer和OpenVZ需要为内核打补丁以添加一些用于创建隔离容器的控制机制。 OpenVZ的补丁未集成到内核中。

　　2007年，谷歌发布了CGroups，这是一种机制，这种机制能限制和隔离一系列进程的资源使用（CPU，内存，磁盘I / O，网络等）。与OpenVZ 内核相反，CGroups在2007年集成进了Linux内核。

　　LMCTFY在同一内核上的隔离环境中运行应用程序，并且无需补丁，因为它使用CGroup，命名空间和其他Linux内核功能。

　　谷歌是容器化行业的领导者。谷歌的一切都在容器上运行。每周有超过20亿个容器在Google基础架构上运行。

　　Jails，虚拟专用服务器（VPS），区域（Zones），容器和VM使用Jails，Zones，VPS，VM和容器都是为了隔离和资源控制，但每种技术是通过不同的方式实现它，每种方式都有其局限性和优势。

　　到目前为止，我们已经简要介绍了Jail如何工作，并介绍了Linux-VServer如何允许运行隔离的用户空间，其中计算机程序直接在主机操作系统的内核上运行，但程序只能访问其资源的受限子集。

　　Linux-VServer允许运行“虚拟专用服务器”（“Virtual Private Servers”），但必须为主机内核打补丁才能使用它。 （将VPS视为商业名称。）

　　“虚拟机”是在“真实硬件机器”之上模拟虚拟机的通用术语。该术语初由Popek和Goldberg定义为真实计算机的有效，孤立副本。

　　虚拟机可以是“系统虚拟机”或“过程虚拟机”。在我们日常使用VM这个词时，我们通常指的是“系统虚拟机”，它是模拟的是主机硬件来模拟整个操作系统。但是，“进程虚拟机”（“Process Virtual Machine”，有时称为应用虚拟机）是用于模拟执行单个进程的编程环境：Java Virtual Machine（JVM，Java虚拟机）就是一个例子。

　　操作系统级虚拟化也称为容器化。 Linux-VServer和OpenVZ等技术可以运行多个操作系统，同时共享相同的体系架构和内核版本。

　　在guest需要的虚拟机于主机的内核版本的情况时，共享相同的体系结构和内核会有一些限制和缺点。

　　系统容器（例如LXC）提供的环境非常接近您从虚拟机获得的环境，与此同时又省去了运行单独内核和模拟所有硬件所带来的开销。

　　操作系统容器与应用容器操作系统级虚拟化有助于我们创建容器。 LXC和Docker等技术使用这种隔离方式。我们这里有两种类型的容器：

　　当Docker启动时，它使用LXC作为容器运行时，其想法是创建一个API来管理容器运行时，隔离运行应用程序的单个进程，并监督容器的生命周期及其使用的资源。

　　在2013年初，Docker项目是建立一个“标准容器”，我们可以在这个宣言中看到。

　　Docker开始构建一个具有多种功能的单体应用程序，这些功能包括启动云服务器以及构建和运行镜像/容器等等。

　　Docker使用“libcontainer”与Linux内核功能（如：控制组和命名空间）进行交互。

　　让我们使用命名空间和Cgroup（控制组）创建一个容器我在这个例子中使用的是Ubuntu，但对于大多数发行版来说操作应该类似。首先安装CGroup工具和压力测试工具程序（因为我们将进行一些压力测试）。

　　unshare（）允许进程（或线程）与当前和其他进程（或线程）共享的执行上下文解除关联。但是部分执行上下文（例如mount>

　　namespace），当使用fork（2）或vfork（2）去创建新进程时，执行上下文，与此同时，其他部分（例如虚拟内存），可能在使用clone（2）创建进程或线程，通过显式请求共享虚拟内存。现在，使用cgcreate我们来创建一个控制组并定义两个控制器，一个在内存上，另一个在CPU上。

　　如果我们在主机上做同样的事情（不要在16G RAM上模仿），测试永远不会失败，除非你真的没有足够的可用内存：

　　遵循这些步骤有利于你理解Linux工具（如CGroup和其他资源管理功能）是如何在Linux系统中创建和管理隔离的环境。

　　runC实际上是一个直接利用libcontainer的命令行工具，容器无需通过Docker引擎。

　　实际上，libcontainer并没有被抛弃，而是被转移到了runC仓库。

　　让我们创建一个目录（/mycontainer），我们将导出镜像Busybox的内容。

　　BusyBox的大小介于1到5 Mb之间（取决于变体），在制作高效利用空间发行版的时候，是一个非常好的组成部分。

　　BusyBox将许多常见UNIX实用程序的微小版本组合到一个小的可执行文件中。它提供了你通常在GNU fileutils，shellutils等中找到的大多数实用程序的替代工具。BusyBox中的工具程序通常比它们包含所有功能的GNU版本有更少的选项；但包含的选项提供了大部分你所需要的功能，与GNU的对应版本非常相似。BusyBox为任何小型或嵌入式系统提供了相当完善的环境。

　　使用生成的规范JSON文件，您可以自定义容器的运行时。例如，容器我们可以更改要执行的应用程序的参数。

　　行业标准的容器运行时鉴于容器逐渐成为主流，容器生态系统中的不同参与者一直致力于标准化。 标准化是自动化和总结实践的关键。

　　Cotnainerd完全支持启动OCI下的软件并管理这些软件的生命周期。 Containerd（以及其他像cri-o这样的运行时）都是使用runC来运行容器，但Containerd实现了其他更高级功能，如镜像管理和更高级API。

　　使用新架构，我们可以运行“无守护容器”（“daemon-less containers” ），它有两个优点：

　　“既然runC和Containerd都是运行时，为什么运行单个容器时需要两个运行时？”

　　这可能是被问的多的问题之一。在之前讲解为什么Docker将其架构拆分为runC和Containerd时，您会发现这两个都是运行时。

　　如果您是从头开始阅读的，那么您一定注意到有高层级和低层级的运行时。这就是runC和Containerd两者之间的实际差异。 两者都可以称为运行时，但每个运行时都有不同的用途和功能。为了使容器生态系统保持标准化，低层级的容器运行时只允许运行容器。

　　低级运行时（如runC）应该轻巧，快速，并且不会与其他更高层级的容器管理发生冲突。

　　当你创建一个容器时，这个容器实际上同时被containerd和 runC两个运行时同时管理。 您会发现有很多容器运行时，其中一些是遵循OCI标准的而另一些不是，一些是低层级的运行时，而另一些不仅仅是运行时，它们同时实现了工具层来管理容器的生命周期等等：

　　容器运行时接口Kubernetes是当下流行的容器编排系统之一。随着容器运行时数量的不断增加，Kubernetes目标是变得更加灵活，并且与更多的容器运行时（不仅仅是Docker）进行交互。

　　初，Kubernetes使用Docker运行时来运行容器，并且现在它仍然是默认的运行时。

　　但是，CoreOS希望将Kubernetes与RKT运行时一起使用，并为Kubernetes提供补丁，以便将来此运行时可以用来替代Docker运行时。

　　在添加新的容器运行时，Kubernetes不希望改变自己的代码库，于是它决定创建容器运行时接口（CRI或Container Runtime Interface），这是一组API和库，允许在Kubernetes中运行不同的容器运行时。

　　是为Kubernetes CRI接口创建的个容器运行时。 cri-o不是为了取代Docker，而是可以在Kubernetes的特定上下文中使用它而不是Docker运行时。

　　gVisor是由Google开发的项目，它在用户空间中实现了大约200个Linux系统调用，与直接在Linux内核上运行的Docker容器（使用命名空间隔离）相比，具有更高的安全性。

　　Moby项目建立一个单体的Docker平台的项目在某种程度上已被抛弃，并催生了Moby项目，在这个项目中，Docker被拆分成多个组件，例如RunC。

　　Moby帮助开发和运行Docker CE和EE（Moby是Docker上游）以及为其他运行时和平台创建开发和生产环境。

　　OCI是一个轻量级，开放型治理架构的组织，由Docker，CoreOS和容器行业的其他领导者于2015年发起。

　　开放容器计划（OCI）旨在建立软件容器的通用标准，以避免容器生态系统内部可能出现的分裂和分化。

　　使用不同运行时的容器可以与Docker API一起使用。使用Docker创建的容器可以能在任何其他引擎上运行。

　　DockOne微信分享（二七三）：Kubernetes集群在企业内部多租户共享场景下的管理

　　Docker容器使用--net=host的方式启动的，怎么用ssh去连接容器

　　Docker pull下来的镜像文件、创建出来的容器文件都存在本地的什么地方了？

　　Docker迁移，使用一个容器管理多个应用服务进程？还是每个服务进程创建一个容器？
以上信息由无锡珂瑞特重工有限公司整理编辑，了解更多容器,换热器信息请访问http://www.wxwchi.com