Docker基础知识

容器

基本概念

  • 容器是一种计算机虚拟化技术，是云原生体系中的重要组成部分，其代表性的利用包含：Docker、Podman等
  • 容器是轻量的、可执行的独立软件包，其蕴含软件运行所需的所有内容：代码、运行时环境、零碎工具、零碎库和设置
  • 容器赋予了软件独立性（具备很好的可移植性），使其免受外在环境差别（例如，开发和测试环境的差别）的影响，艰深的说就是使得软件能够带环境装置

虚拟机

  • 虚拟机能够实现与容器相似的性能，能够在一种操作系统中运行另外的操作系统，虚拟机不受宿主机环境的影响，虚拟机对于宿主机来说也仅仅是一般的文件，对宿主机的其余部分无影响，然而虚拟机技术有以下的毛病：

    • 资源占用多
    • 体积臃肿
    • 启动慢
  • 以Docker为代表的Linux容器技术（Linux Containers，缩写为LXC）解决了上述问题

容器虚拟机比照

  • 容器虚拟化的是操作系统而不是硬件，容器之间是共享同一套操作系统资源的，一个运行中的容器实质上是一个非凡的过程

    • 容器是一个应用层形象，用于将代码和依赖资源打包在一起。多个容器能够在同一台机器上运行，共享操作系统内核，但各自作为独立的过程在用户空间中运行。与虚拟机相比，容器占用的空间较少（容器镜像大小通常只有几十兆），霎时就能实现启动

  • 虚拟机技术则是虚构出一套硬件后，在其上运行一个残缺操作系统。相对来说容器的隔离级别会稍低一些

    • 虚拟机 (VM) 是一个物理硬件层形象，用于将一台服务器变成多台服务器。管理程序容许多个VM在一台机器上运行。每个VM都蕴含一整套操作系统、一个或多个利用、必要的二进制文件和库资源，因而占用大量空间，耗费大量资源，启动也非常迟缓

  • 容器与虚拟机是能够共存的，不是取代的关系

    • 两者有不同的应用场景。虚拟机更擅长于彻底隔离整个运行环境（隔离更彻底）。例如，云服务提供商通常采纳虚拟机技术隔离不同的用户。而 Docker通常用于隔离不同的利用 ，例如前端，后端以及数据库

      <img src="https://images.demoli.xyz/image-20210808191333415.png" alt="image-20210808191333415" style="zoom:67%;" />

容器劣势

  • 绝对虚拟机来说，容器更加轻量级，耗费资源少，能够疾速启动

  • 可移植性强，在软件开发、测试，运维的各个期间都能统一的运行

    • 因而反对麻利的DevOps开发，缩短生产周期

      所谓的DevOps就是是两个传统角色Dev(Development)和Ops(Operations)的联合，Dev负责开发，Ops负责部署上线，说白了就是要有一个理解Dev的人能把Ops的事干了
  • 绝对强的隔离性，一个容器呈现故障并不会影响其余容器的运行连续性

容器劣势

  • 安全性问题，因为容器的隔离性只是过程级别的隔离，相比拟传统虚拟机，容器潜在的平安危险更高。它们须要多种级别的安全措施

    • 最常说的一个毛病就是在容器外部执行top命令能够看到宿主机的运行状态

跟Namespace状况相似，Cgoups对资源的限度能力也有很多不欠缺的中央，其中被提及最多的是/proc文件系统的问题。/proc目录存储着以后内核运行状态的一系列非凡文件，用户能够通过拜访这些文件，查看零碎以及以后正在运行的过程的信息，比方CPU应用状况、内存占用率等，这些文件也是top指令查看零碎信息的次要数据起源。

然而，如果你在容器里执行top指令，就会发现，它显示的信息竟然还是宿主机的CPU和内存数据。这是因为/proc文件系统并不知道用户通过Cgroups给这个容器做了什么样的资源限度，所以它返回的还是整个宿主机的。那么这个问题会导致，容器内的应用程序读取到的CPU核数、可用内存等信息还是宿主机的，而不是做了限度之后的。这就是容器相比拟于虚拟机另一个不尽如人意的中央

当然，为了解决下面的那个问题。直观的做法就是容器不挂载宿主机的该目录就能够了，能够通过lxcfs来实现隔离，lxcfs在宿主机上保护过程组的信息，而后容器启动的时候将lxcfs保护的过程组信息所在的目录挂载到容器的/proc目录，在容器中获取/proc信息时，实际上获取的是宿主机上对该容器的过程组信息

  • 容器对有状态利用，例如数据存储利用是不敌对的，个别须要将数据与利用拆散，容器一旦关机，其中的数据可能会永恒隐没
  • 容器资源监控，云环境异常简单，因而须要深度监控平安问题

Docker

根底定义

  • Docker是代表性的容器技术，其应用Google公司推出的Go语言进行开发实现，基于Linux内核提供的CGroups性能和Namespace，以及UnionFS等技术实现
  • Docker技术最后齐全基于传统的LXC构建，然而后续又增加了容器构建，分层镜像以及镜像仓库等性能，这使得容器技术真正风行了起来

Docker劣势

  • Docker容器基于分层镜像运行，分层镜像能够实现文件共享，能够尽量升高磁盘用量，更快地实现镜像传输以及容器构建
  • Docker容器基于开放式规范，可能在所有支流Linux版本、Microsoft Windows以及包含VM、裸机服务器和云在内的任何基础设施上运行
  • Docker赋予利用的隔离性不仅限于彼此隔离，还独立于底层的基础设施。Docker默认提供最强的隔离，因而利用呈现问题，也只是单个容器的问题，而不会波及到整台机器
  • Docker提供了丰盛的API，不仅能够在Shell环境下执行操作，也能够应用多种语言进行管制，比方docker-java、go-dockerclient等

Docker劣势

  • 过程治理与传统的Linux容器不同，例如终止子过程之后，须要清理孙过程，而对于这类事件，传统 Linux 容器会自行处理。Docker的使用者能够在开始时更改配置文件和设置性能，从而打消这些顾虑
  • 容器化下，容器与宿主机共享内核，带来安全隐患
  • 在Docker中有些其它Linux子系统和设施未指定命名空间。比方SELinux、Cgroups以及/dev/sd*设施。这意味着，如果攻击者管制了这些子系统，主机也将不保

  • Docker守护过程也可能成为安全隐患。为应用和运行Docker容器，须要应用Docker守护过程，来为容器提供继续运行时环境。而Docker守护过程须要root权限，Docker守护过程有被劫持攻打的危险

    Docker守护程序绑定到Unix套接字而不是TCP端口。默认状况下，Unix套接字由root领有，而非用户只能通过sudo应用它。如果要以非root用户应用Docker，可参考非Root用户应用Docker
    • Podman就不须要应用root权限的守护过程，因而绝对Docker更平安一些

Docker应用场景

  • 面向产品：产品交付
  • 面向开发：简化环境配置
  • 面向测试：多版本测试
  • 面向运维：环境一致性、DevOps
  • 面向架构：自动化扩容（微服务）

Docker与Podman

  • 自从Kubernetes发表不再反对Docker作为容器运行时后，Docker将要被Podman或者Containerd取代的声音就甚嚣尘上

  • Podman能够治理和运行任何合乎OCI（Open Container Initiative）标准的容器和容器镜像。Podman提供了一个与Docker兼容的命令行前端来治理Docker镜像

    Podman的命令行工具与Docker相似，比方构建镜像、启停容器等。甚至能够通过alias docker=podman能够进行替换。因而，即使应用了Podman，依然能够应用Docker.io作为镜像仓库，这也是兼容性最要害的局部

  • 二者的区别如下：

    • Docker须要一个以root执行的守护过程维持运行，带来了安全隐患，Podman不须要守护程序，也不须要root用户运行，绝对平安

    • 在Docker的容器管理体系中，须要多个daemon能力调用到runC（下文有形容），而Podman间接调用runC，通过common这个守护过程作为容器过程的管理工具（不须要root权限）

      在Podman体系中，有个称之为common的守护过程，其运行门路通常是/usr/libexec/podman/conmon，它是各个容器过程的父过程，每个容器各有一个，common的父过程则通常是1号过程。Podman中的common其实相当于Docker体系中的containerd-shim

Docker基本概念

镜像

  • Docker镜像是一个非凡的文件系统，除了提供容器运行时所需的程序、库、资源、配置等文件外，还蕴含了一些为运行时筹备的一些配置参数（如匿名卷、环境变量、用户等）

  • 镜像的设计充分利用联结文件系统的技术，镜像的构建过程就是一层一层叠加文件系统的过程，最顶层的则是镜像运行时，容器外部能够看到的文件内容是镜像的分层文件系统层层叠加的成果

    • 联结文件系统的具体实现包含UnionFS、aufs 、OverlayFS等等

  • 镜像构建时，会一层层构建，前一层是后一层的根底。每一层构建完就不会再产生扭转，后一层上的任何扭转只产生在本人这一层。

    • 比方，删除前一层文件的操作，理论不是真的删除前一层的文件，而是仅在以后层标记为该文件已删除。在最终容器运行的时候，尽管不会看到这个文件，然而实际上该文件会始终追随镜像。因而，在构建镜像的时候，须要额定小心，每一层尽量只蕴含该层须要增加的货色，任何额定的货色应该在该层构建完结前清理掉。
    • 用户构建镜像（Dockerfile）的每一步操作都会构建一个新的层，因而反对在应用Dockerfile进行容器镜像构建时执行构建回滚，因而也能很好地反对应用Docker执行CI/CD时执行疾速版本回退

  • 为什么应用联结文件系统

    • 应用联结文件系统的目标之一是使得镜像的构建能够复用之前的文件，增快构建的速度，同时能够反对镜像的自定义革新，即在原有镜像的根底之上加更多的层，实现镜像的自在定制构建
    • 多个容器能够共享同一个镜像的文件，缩小了容器的启动工夫与空间耗费
    • 能够对最顶层的可读写层（即容器运行时）的状态进行保留（docker commit产生容器的快照镜像），以实现复用
  • 对于镜像的构建，参考[Docker镜像构建]()

容器

  • 镜像和容器在逻辑上的关系，就像是面向对象程序设计中的类和实例一样，镜像是动态的定义，容器是镜像运行时的实体
  • 容器的本质是宿主机上的过程，但与间接在宿主执行的过程不同，容器过程运行于属于本人的独立的命名空间
  • 容器在镜像的根底之上的运行实质上能够了解为在镜像的分层只读文件系统上增加了一个可写层，能够称之为容器的存储层，容器存储层的生存周期和容器一样，容器沦亡时，容器存储层也随之沦亡。因而，任何保留于容器存储层的信息都会随容器删除而失落

  • 在容器内对镜像文件的读写，是基于copy-on-write技术的

    • 所谓的记录删除操作实际上就是对应的文件在容器层就不可见了
    • 越顶层的层优先级越高，这也就是为什么在以后层的批改，会笼罩下边的层的批改的以及所有的增删改查都要放到以后最上层进行操作的起因

  • 依照 Docker 最佳实际的要求，容器不应该向其存储层内写入任何数据 ，容器存储层要放弃无状态化。所有的文件写入操作，都应该应用数据卷（Volume）、或者绑定宿主目录，在这些地位的读写会跳过容器存储层，间接对宿主(或网络存储---比方ceph的rbd插件)产生读写，其性能和稳定性更高。数据卷的生存周期独立于容器，容器沦亡，数据卷不会沦亡。因而，应用数据卷后，容器能够随便删除，数据却不会失落

    • 尽管容器的可读写层的生命周期比拟短，然而能够在应用容器时应用 docker commit 和 push 指令，保留这个被批改过的可读写层，并上传到 Docker Hub上，供其他人应用
    • 参考[容器的长久化计划]()

  • 除了顶层的可读可写层以及底层的只读镜像层之外，还有一个非凡的层--init层，须要被读写，然而又不想被commit提交做增量批改的一个层就是init层（自身应该是只读的镜像层的一部分），专门用来寄存/etc/hosts等信息（启动容器时写入hostname）

  • 容器的生命周期

    • created：初建状态 docker create

    • running：运行状态 docker start或者是docker run

      • 容器启动时的后盾逻辑是怎么的？

        1. docker客户端执行命令，命令通过Unix套接字或者tcp链接的形式申请到docker daemon（也就是dockerd过程）
        2. dockerd过程通过gRpc向containerd这个规范层发出请求，申请创立一个容器
        3. containerd首先判断本地仓库是否有对应的镜像，如果有间接用该镜像创立容器，没有的话，须要先拉取镜像

        4. 创立一个dockerd-shim过程，并以此过程为父过程创立runc过程运行一个容器过程

          1. 容器过程应用namespace进行资源命名空间的限度；应用cgroup实现资源的调配与审计
          2. 容器过程须要挂载对应的联结文件系统（privot_root），也就是镜像层下面加一层可写层
          3. 如果应用的默认的桥接网络的话，会从网桥的子网IP中抉择未应用的IP进行调配

    • stopped：进行状态 docker stop

      • 通过 docker stop 进行容器，其原理是给运行中的容器发 sigterm 信号，如果容器为1号过程承受并解决sigterm，则期待1号过程处理完毕后就退出，如果期待一段时间后还是没有解决，则会通过发送sigkill命令强制终止容器
    • paused：暂停状态 docker pause
    • deleted：删除状态 docker rm

仓库

  • 一个集中的存储、散发镜像的服务，Docker Registry 、Docker Hub就是这样的服务
  • 应用镜像的标签（tag）进行镜像的版本治理
  • 能够应用官网的镜像仓库Docker Hub，或者国内的一些同步的镜像仓库，也能够本人搭建Docker Registry服务，能够联合Docker Auth与keycloak等来执行访问控制与用户管制，参考公有仓库部署

Docker的底层逻辑

虚拟化技术

  • 虚拟化技术是一种资源管理技术，是将计算机的各种实体资源)（CPU、内存、磁盘空间、网络适配器等），予以形象、转换后出现进去并可供宰割、组合为一个或多个电脑配置环境。由此，突破实体构造间的不可切割的阻碍，使用户能够比本来的配置更好的形式来利用这些电脑硬件资源。这些资源的新虚构局部是不受现有资源的架设形式，地区或物理配置所限度。个别所指的虚拟化资源包含计算能力和数据存储

    • 虚拟化的技术是通过硬件的形象实现更好的调配组合硬件资源，实现资源的最大化利用

LXC虚拟化技术

  • LXC，其名称来自Linux 软件容器（Linux Containers）的缩写，一种操作系统层虚拟化（Operating system–level virtualization）技术，实际上是Linux内核容器性能的一个用户空间接口。它将应用软件零碎打包成一个软件容器（Container），内含应用软件自身的代码，以及所须要的操作系统外围和库。通过对立的名字空间和共用API来调配不同软件容器的可用硬件资源，发明出应用程序的独立沙箱运行环境，使得 Linux用户能够容易的创立和管理系统或利用容器

  • 与传统虚拟化技术相比，LXC的劣势在于：

    • 与宿主机应用同一个内核，性能损耗小
    • 不须要指令级模仿
    • 不须要即时(Just-in-time)编译
    • 容器能够在CPU外围的本地运行指令，不须要任何专门的解释机制
    • 防止了准虚拟化和零碎调用替换中的复杂性
    • 轻量级隔离，在隔离的同时还提供共享机制，以实现容器与宿主机的资源共享

  • Docker并不是齐全依赖LXC虚拟化技术，比方镜像的构建与以及容器的构建过程并不是依赖LXC的（Docker在LXC的根底上提供了更加丰盛的性能）

    • 传统的Linux容器应用init零碎来治理多种过程。这意味着，所有应用程序都作为一个整体运行。与此相反，Docker技术激励应用程序各自独立运行其过程，并提供相应工具以实现这一性能
namespace

  • namespace是Linux内核用来隔离内核资源的形式

    • 通过namespace能够让一些过程只能看到与本人相干的一部分资源，而另外一些过程也只能看到与它们本人相干的资源（实现资源的限度与隔离），这两拨过程基本就感觉不到对方的存在。具体的实现形式是把一个或多个过程的相干资源指定在同一个namespace中
    • Linux namespaces是对全局系统资源的一种封装隔离，使得处于不同 namespace 的过程领有独立的全局系统资源，扭转一个namespace中的系统资源只会影响以后namespace里的过程，对其余namespace 中的过程没有影响

  • namespace分为以下几种：

    • PID ns

      • 过程编号的隔离，所以容器中的利用的pid为1

    • Net ns

      • 每个net名字空间有独立的网络设备，IP 地址，路由表，/proc/net 目录

    • User ns

      • 每个名字空间能够有不同的用户和组id, 也就是说能够在名字空间内用外部的用户执行程序而非主机上的用户

    • UTS ns

      • UTS(“UNIX Time-sharing System”) 名字空间容许每个名字空间领有独立的hostname和 domain name, 使其在网络上能够被视作一个独立的节点而非主机上的一个过程

    • Mount ns

      • 相似chroot，将一个过程放到一个特定的目录执行。mnt名字空间容许不同名字空间的过程看到的文件构造不同，这样每个名字空间中的过程所看到的文件目录就被隔离开了。同chroot不同，每个名字空间中的容器在/proc/mounts的信息只蕴含所在名字空间的mount point

    • IPC ns

      • 不同名字空间的交互采纳Linux常见的过程间交互办法(interprocess communication - IPC)，包含信号量、音讯队列和共享内存等
cgroup
  • cgroup是Control Groups的缩写，是Linux内核提供的一种能够限度、调配、记录（统计）、隔离过程组 (process groups)所应用的物理资源(如cpu、memory、i/o等等)的机制

  • 有了namespace之后，为什么还须要cgroup呢：

    • namespace 是为了隔离过程组之间的资源，而 cgroup 是为了对一组过程进行对立的资源监控和限度
    • 应用了namespace之后，容器对应的过程只能看到以后过程对应的命名空间中的资源，然而从宿主机的角度来看，这只是一个一般的过程，能够和其余过程一起竞争资源，能够应用全副的宿主机资源，这显然不合乎容器的概念，因而引入cgroup对容器的资源进行限度与审计
    • 在Linux中，cgroup给用户裸露进去的操作接口是文件系统（其实就是通过写配置文件来配置cgroup），即操作接口是以文件和目录的形式组织在操作系统的/sys/fs/cgroup门路下
  • cgroup的缺点在于前文说的top命令的问题（隔离不彻底）以及只能限度资源耗费的最大值，而不能断绝其余程序占用本人的资源
chroot

  • chroot用来为容器环境挂载特定的根文件系统，chroot（change root filesystem）的作用是指定特定过程的根门路为指定地位，Docker应用此命令指定容器的根目录的地位，同时还会在该目录挂载一个残缺的操作系统的文件系统（即应用联结文件系统，共享的镜像层文件）

    • chroot只扭转以后过程的/，pivot_root扭转以后mount namespace的/。pivot_root能够认为是 chroot的改良版

Docker架构

  • Docker实际上是一个client/server的架构，如下图所示

<img src="https://images.demoli.xyz/image-20210810233212064.png" alt="image-20210810233212064" style="zoom:80%;" />

客户端

  • 平时应用的docker指令就是客户端的一部分，Docker组件向服务端发送申请后，服务端依据申请执行具体的动作将后果返回给Docker，Docker解析服务端的返回后果，并将后果通过命令行规范输入展现给用户。这样一次残缺的客户端服务端申请就实现了

  • 客户端与服务端的通信形式

    • 客户端和服务端能够通过Unix套接字通信

      • 默认的dockerd（Docker服务端）生成的socket文件寄存在 /var/run/docker.sock，此文件只能由root用户或具备sudo权限的用户拜访
    • 采纳TCP的形式与服务端通信，配置格局为：tcp://host:por，为了保障平安，通常还须要应用TLS认证
    • 通过fd文件描述符的形式，配置格局为：fd://，这种格局个别用于systemd治理的零碎中
    • 还能够应用各种语言的sdk与docker的服务端交互，比方docker-java、go-dockerclient等

服务端

  • 服务端实际上是一个叫做dockerd的后盾过程（也就是上图中的docker daemon）

    • 相对来说dockerd更多的就是一个server，用来接管申请和解析申请，真正的容器镜像治理由containerd保护
runc
  • 实际上是Docker的libcontainer这个容器运行时库的改良，是一个用来运行容器的轻量级工具，实现了OCI规范，是利用LXC技术创立容器过程的底层工具
containerd

  • contained通过contained-shim启动并治理runc，能够说contained是真正治理容器的生命周期的组件，因而该组件也被拆分进去作为独自的我的项目保护，K8s不再反对Docker后，能够无缝迁徙到应用containerd作为容器运行时，containerd能够实现以下工作：

    • 镜像治理
    • 治理存储相干资源
    • 治理网络资源

    • 承受dockerd的申请

      • dockerd通过gRPC与containerd通信，因为dockerd与底层的容器运行时runC两头有了 containerd这一OCI规范层，使得dockerd能够确保接口向下兼容
containerd-shim

  • containerd-shim的次要作用是将containerd和真正的容器过程解耦，应用containerd-shim作为容器过程的父过程，从而实现重启Docker时不影响曾经启动的容器过程

    • **-shim的意思是垫片，相似于拧螺丝时夹在螺丝和螺母之间的垫片，相当于是一个中间件的性能，相似的组件还有晚期版本K8s中的docker-shim
    • 当有需要去替换runc运行时工具库时，例如替换为平安容器kata container或Google研发的 gViser，则须要减少对应的shim(kata-shim等)，以上两者均有本人实现的shim
  • containerd和shim并不是父子过程关系，runc启动完容器后自身会间接退出，containerd-shim则会成为容器过程的父过程，负责收集容器过程的状态，上报给containerd，并在容器中pid为1的过程退出后接管容器中的子过程进行清理，确保不会呈现僵尸过程
docker-init

  • 在运行容器时能够指定--init参数，向容器中引入docker-init过程，作为1号过程来治理所有的过程（namespace下的所有子过程），例如回收僵尸过程等等

    • container-shim只在容器中的pid为1的过程退出后才会发挥作用
ctr
  • ctr实际上是containerd-ctr，它是containerd的客户端，次要用来开发和调试，在没有dockerd的环境中，ctr能够充当docker客户端的局部角色，间接向containerd守护过程发送操作容器的申请
docker-proxy
  • 容器端口映射的一些iptables配置，由docker-proxy过程实现

容器和镜像标准接口OCI

  • OCI是Docker公司与CoreOS和Google独特创立的，该接口提供了运行时标准（形容如何运行filesystem bundle）与镜像标准（指定了镜像的格局与相干的镜像操作）

    filesystem bundle(文件系统束): 定义了一种将容器编码为文件系统束的格局，即以某种形式组织的一组文件，并蕴含所有符合要求的运行时对其执行所有规范操作的必要数据和元数据，即config.json 与 根文件系统

  • Runc是OCI的参考实现，是Docker的一部分，也是K8s的Kernel API规范

    • K8s的三层形象：Orchestration API -> Container API -> Kernel API

      • 资源调度与编排的规范就是k8s
      • 容器规范就是CRI
      • 容器底层规范就是OCI

容器运行时接口CRI

  • CRI是一组K8s定义的对于容器和镜像操作的gRPC接口

  • Docker自身（借助dockershim）、containerd（cri-plugin）、cri-o就是这个接口的实现

    • dockershim显然也是一个垫片，用来实现OCI到CRI的兼容，晚期版本的k8s应用dockershim实现对Docker的反对
    • containerd自身是从Docker中分离出来的，默认是实现OCI接口的，然而在用到K8S中后，通过退出CRI-Plugin，使其反对CRI接口
  • 此接口标准是K8S中的容器接口标准

容器技术的倒退瞻望

  • 随着互联网的倒退到万物智联，5G、AIoT 等新技术的涌现，随处可见的计算需要曾经成为事实。针对不同计算场景，容器运行时会有不同需要。KataContainer、Firecracker、gVisor、Unikernel 等新的容器运行时技术层出不穷，别离解决平安隔离性、执行效率和通用性三个不同维度的要求。OCI(Open Container Initiative)规范的呈现，使不同技术采纳统一的形式进行容器生命周期治理，进一步促成了容器引擎技术的继续翻新
  • 基于MicroVM的平安容器占比将逐步减少，提供更强的平安隔离能力。虚拟化和容器技术的交融，已成为将来 重要趋势。在公共云上，阿里云容器服务曾经提供了对基于KataContainer的阿里云的袋鼠容器引擎反对，能够运行不可信的工作负载，实现平安的多租隔离
  • 基于软硬一体设计的秘密计算容器开始展露头角。比方阿里云平安、系统软件、容器服务团队以及蚂蚁金服可信原生团队独特推出了面向秘密计算场景的开源容器运行时技术栈inclavare-containers，反对基于 Intel SGX 秘密计算技术的秘密容器实现，如蚂蚁金服的Occlum、开源社区的Graphene等 Libary OS。它极大升高了秘密计算的技术门槛，简化了可信利用的开发、交付和治理
  • WebAssembly作为新一代可移植、轻量化、利用虚拟机，在 IoT，边缘计算，区块链等场景会有宽泛的利用前景。 WASM/WASI将会成为一个跨平台容器实现技术。近期Solo.io推出的WebAssembly Hub就将 WASM 利用通过OCI镜像规范进行对立治理和散发，从而更好地利用在Istio服务网格生态中

补充

  • 分享一篇有意思的文章：如何辨别以后正在应用的shell环境是物理机、虚拟机还是容器

参考

  • Docker官网文档
  • Redhat-Docker是什么
  • Podman是什么
  • 7种Docker代替工具
  • 深入研究Docker联结文件系统
  • JavaGuide Docker
  • Docker 核心技术 -- Linux Namespace
  • 容器底层-Cgroups 的应用
  • 容器资源的限度设定
  • Docker架构原理以及简略应用
  • 文言Kubernetes Runtime
  • 深刻了解container--容器运行时
  • 罕用虚拟化技术