容器（27）---下一代容器Buildah、Podman与Docker

0x1 常见的容器技术简介

1)Buildah

image.png

Buildah是一个命令行工具，他提供了一种灵活、可脚本编程式的构建容器镜像的功能，并且其构建出的镜像符合OCI（开放容器标准），可以与通过Docker方式构建出的镜像兼容，即通过Buildah构建出的镜像可以通过Docker与Kubernetes运行。Buildah 可以轻松与脚本集成并生成构建流水线，最大优势在于构建镜像的过程不再需要运行Docker的守护进程。

特点

Buildah支持通过其原生命令来构建容器镜像，支持对云原生应用程序中所需的部分进行定制。Buildah通过一种简单且安全的方式来构建容器镜像，并且可以避免安装那些最终容器镜像不需要的组建，例如yum，dnf等，消除了镜像的过于臃肿。另外，由于Buildah无需类似Docker守护进程的支持，它也可以更加方便的在容器里面执行。
Buildah在构建镜像期间，支持对外部卷进行读写操作，这样在构建过程中可以引用外部卷中的镜像文件，而在生成最终镜像时却不用将外部卷的内容装载到最终镜像中。

构建过程

buildah通过脚本或者命令来构建容器镜像过程如下：
1：获取基础镜像openjdk:8-jdk-alpine

buildah from openjdk

2：将jar包拷贝到镜像中

buildah copy  openjdk-working-container   demo-1.0.0-SNAPSHOT.jar  /tmp/demo-1.0.0-SNAPSHOT.jar

3：配置容器启动入口点

buildah config --entrypoint  "java -jar /tmp/demo-1.0.0-SNAPSHOT.jar"  openjdk-working-container

4：通过commit命令将其保存为镜像文件

buildah commit  openjdk-working-container  buildah-demo-image

image.png

buildah通过dockerfile构建容器镜像过程如下，直接通过buildah build-using-dockerfile替代docker build指令便可实现，

image.png

与Docker异同

Buildah也可以作为docker build 命令的一种替换。通常我们通过Docker根据Dokcerfile构建容器镜像时需要通过docker build命令，如 " docker build -t hello . "，然而通过Buildah的build-using-dockerfile（或bud）可以实现与docker build的等价替换，即 " bud -t hello . "等价于" docker build -t hello . "，可以轻松地实现与现有Dockerfile构建脚本的结合使用。同样构建结束之后，我们可以通过" buildah images "命令查看通过Buildah构建出的容器镜像，通过" buildah push {repository} "命令将容器镜像文件推送到远程仓库。
虽然 "docker build" 与 "build-using-dockerfile" 命令最终都可以构建出容器镜像，但是构建构建过程略有不同。通过Docker构建镜像时，每执行一条Dockerfile中的指令，都会对上一层生成的镜像通过增加扩充的形式生成新的一层。而Buildah则是通过无缓冲的形式进行构建，从头至尾依次执行构建脚本文件中的命令，最终生成容器镜像文件，这种构建方式可以十分有效的提高构建效率，在构建复杂的容器镜像时优势尤为明显，但缺失了中间缓存层会造成在每次构件时都会重复执行构建指令。

2) Podman

image.png

Podman 原来是 CRI-O 项目的一部分，后来被分离成一个单独的项目叫 libpod。Podman 的使用体验和 Docker 类似，不同的是 Podman 没有 daemon。以前使用 Docker CLI 的时候，Docker CLI 会通过gRPC API 去跟 Docker Engine 说「我要启动一个容器」，然后 Docker Engine 才会通过 OCI Container runtime（默认是 runc）来启动一个容器。这就意味着容器的进程不可能是 Docker CLI 的子进程，而是 Docker Engine 的子进程。

Podman 比较简单粗暴，它不使用 Daemon，而是直接通过 OCI runtime（默认也是 runc）来启动容器，所以容器的进程是 podman 的子进程。这比较像 Linux 的 fork/exec 模型，而 Docker 采用的是C/S（客户端/服务器）模型。与 C/S 模型相比，fork/exec 模型有很多优势，比如：
系统管理员可以知道某个容器进程到底是谁启动的。
如果利用 cgroup 对 podman 做一些限制，那么所有创建的容器都会被限制。
SD_NOTIFY : 如果将 podman 命令放入 systemd 单元文件中，容器进程可以通过 podman 返回通知，表明服务已准备好接收任务。
socket 激活 : 可以将连接的 socket 从 systemd 传递到 podman，并传递到容器进程以便使用它们

3) Docker技术

image.png

4) LXD技术

LXD, 是一种基于LXC(Linux 容器）的虚拟技术。而LXC 也是Docker的基础，但不同于Docker的是，Docker是对应用的虚拟化，而LXD则是在OS层面虚拟化靠齐。

image.png

5) LXC技术

image.png

LXC（LinuX Containers）Linux容器，一种操作系统层虚拟化技术，为Linux内核容器功能的一个用户空间接口。它将应用软件系统打包成一个软件容器（Container），内含应用软件本身的代码，以及所需要的操作系统核心和库。透过统一的名字空间和共享API来分配不同软件容器的可用硬件资源，创造出应用程序的独立沙箱运行环境，使得Linux用户可以容易的创建和管理系统或应用容器。
在Linux内核中，提供了cgroups功能，来达成资源的隔离。它同时也提供了名称空间隔离的功能，使应用程序看到的操作系统环境被区隔成独立区间，包括进程树，网络，用户id，以及挂载的文件系统。但是cgroups并不一定需要启动任何虚拟机。
LXC利用cgroups与名称空间的功能，提供应用软件一个独立的操作系统环境。LXC不需要Hypervisor这个软件层，软件容器（Container）本身极为轻量化，提升了创建虚拟机的速度。

而Docker本质来说不是容器，而是容器的管理工具，最初的Docker也是基于LXC实现的。

LXC关键技术点：
chroot，根切换，从容器内的角度来看，仿佛真的有自己的根树
namespaces：名称空间，负责将资源隔离，比如pid，网络，mnt，user，uts等
CGroups：控制组，负责控制资源的分配