简年6：一个关于 Linux 容器化的脑洞

于是突然脑洞一开，如果把整个 Linux 系统的模块都放进容器中运行的话，Linux 就可以变得非常好玩了。

为了方便大家理解这个脑洞，先上张图，下面的图片把两个不同的桌面环境同时无缝运行在一个桌面，包括软件和整套桌面：

图中通过共享宿主机显示服务来达到同时运行的效果，接下来的脑洞中会尝试把所有模块都放进容器中，包括显示服务。

当前 Linux 的软件“碎片化”可以说是 Linux 普及的一大拦路虎，发行版之间各自为政，软件分发渠道不一。另一方面，Linux 在目录结构上也没有严格的规定，安装一个软件往往因为开发者的习惯而不同，装好的软件在电脑磁盘中如同垃圾一样七零八落。尽管有 NixOS 这样的发行版在努力，但声势不大，难成气候。

所以如果把 Linux 模块容器化之后，虽然不能够从根本上解决上面的问题，但是因为隔离了文件系统，一些依赖以及碎片化的软件得到了一定遏制。最重要的是，如果模块容器化之后，Linux 在部署、备份上将极为方便。

脑洞不能只是脑洞，我们来看一下如何实现吧。（本文为一边写一边找资料一边 *** 作验证，至于结果嘛，看下去吧。）

内核肯定不用容器化了，Docker 靠的就是 Linux 内核支撑，Linux 内核更换也方便，无需 Docker 容器包装，那么除此之外的其他东西，就都交给 Docker 来做的话，需要考虑哪些方面呢？

内核启动的第一个进程，即 PID 1 是整个系统的关键部分，我能想到的两个系统是 CoreOS 和 RancherOS，这两者都是针对 Docker 而开发的特别发行版。

之所以使用到它们当然是看上了它们对 Docker 的深度整合，CoreOS 使用 systemd 管理容器（似乎），而 RancherOS 更加彻底，直接使用 Docker 管理系统，Docker 甚至是 RancherOS 的 PID 1。

因为本文的脑洞是让 Docker 容器作为一个桌面运行，也就是 run as a Desktop OS，而不是把 GUI 程序运行在容器中然后显示在正常 *** 作系统上，也就是 run on a Desktop OS。

要了解两者差别，需要认识到 X 服务在 Linux 下工作的大致原理。

在此之前，你需要对 GUI 这个名称有个认识，GUI 全称是图形用户界面（Graphical User Interface），我们平时使用的大部分软件，例如浏览器、办公软件、聊天软件等都是有图形界面的。

而 Docker 运行 GUI 软件的技术早就已经不是什么新鲜事了。大部分都是直接通过共享宿主系统的 X11 服务实现 GUI 界面的呈现。而我的脑洞中，是从头到尾对 Linux 系统的包装，这自然也包括显示服务，这意味着我们不可以使用宿主机的显示服务来显示 GUI 程序。

以 X11 为例，在 X11 协议中，分为 X11 服务端和 X11 客户端两个部分。X11 服务端是用于驱动具体显示硬件将数据进行展示的模块，而 X11 客户端则接收应用程序和用户的 *** 作，并产生刷新屏幕信息的命令发送给服务端。服务端与客户端可以是在同一个主机上，也可以通过网络相连。如下图所示：

接下来，我们遇到一个问题，因为没有显示驱动，我们无法显示界面，即便依靠 GPU 处理也无法显示出来，这个时候就需要一个小玩意了。

Xvfb的全称是 “X virtual frame buffer”，是一种 X11 服务端的特殊实现。说比较特殊是因为 Xvfb 不需要实际的显示装置和硬件驱动，它将渲染的图像内容保存在内存中，最初的应用场景主要是用于自动化测试等不需要看到执行界面的地方，作为完整 X 服务的替代。

在前面已经提过，之所以考虑到使用这个工具，还有一个很重要的原因：轻量。Xvfb的所有文件放在一起只有大约 10MB 的大小（加上一些额外依赖的包，实际增加镜像的体积大概在几十 MB）。这样一种轻量级的 X11 服务器用在 Docker 里面使用实在是在合适不过了，此外，Xvfb也与 CoreOS、RancherOS 不支持图形显示、没有显示器驱动的情况十分契合。

现在还有个关键性的问题：怎样把内存里的渲染数据表现出来。为此，我们需要引入另一个 Linux 下的工具软件X11vnc，它提供了将 X11 服务端内容获取出来并展现到远程的用户控制端的功能。

这样我们通过VNC客户端就可以看到界面了。

但是我们饶了一圈，似乎又回来了，到头来我还是要通过VNC客户端显示内容啊，这和直接用宿主机显示服务有什么区别啊？！

等会，区别还是有的，在本文中显示的界面少了两次协议转换，直接通过 x11vnc 转发出去，效果十分逼真，延迟感受基本体会不到。

依据这个思路，我们准备在容器里面从零搭建整个 X11 的世界。不过，要是安装标准的 X11 服务，加上它的各种依赖，少说需要几百 MB 的额外空间，其他啥都没装就把镜像变大好几倍了，工程着实浩大。好在开源界已经有了许多种轻量级 X11 服务替代品，例如Xdummy、Xvfb和Xpra。这些平时不太显眼的宝藏在容器中可以大有作为。当然不嫌弃的话还是 X 大法好，值得一提的是Wayland 与 X 作为显示服务却有本质不同，Wayland直接让软件与硬件交流，我们没有机会对 Wayland 封装，所以这么一看 X 老大爷还是挺有趣的。

作为一个需要对外提供显示图形环境的容器，有一些基本的基础环境需要解决。例如：

这些内容就像一个基本的 *** 作系统。用户可以自由选择显示服务，并自由组合桌面环境，也就是说同时运行 Gnome 和 Kde完全没有问题。

由于 CoreOS 使用了只读的系统分区，想在系统上直接安装一个 X11 服务是行不通的。

但是 RancherOS 不同，我们可以在下面链接中看到，老外已经做了个测试，使用一个仅有几十 MB 的系统跑一个桌面容器，运行良好。

https://forums.rancher.com/t/rancheros-and-sound-module-missing-dev-snd/1799/5

通过更换系统内核，加装基本配置，一个模块容器化的 Linux 似乎就在眼前啊。

以上都是脑洞，也许有空时我会动手验证下，所以记录一下，保存下来，笑。

1、不安全的镜像：镜像是一个包含应用/服务运行所必需的 *** 作系统和应用文件的集合，用于创建一个或多个容器，它们之间紧密联系，镜像的安全性将会影响容器安全。根据镜像创建和使用方式，通常有三个因素影响镜像安全：a、基础镜像不安全：镜像通常是开发者基于某个基础镜像创建的，无论是攻击者上传的恶意镜像，还是现有镜像存在的安全缺陷，基于它创建的镜像都将会是不安全的。 b、使用包含漏洞的软件：开发者经常会使用软件库的代码或软件，如果它们存在漏洞或恶意代码，一旦被制作成镜像，也将会影响容器的安全。c、镜像被篡改：容器镜像在存储和使用的过程中，可能被篡改，如被植入恶意程序和修改内容。一旦使用被恶意篡改的镜像创建容器后，将会影响容器和应用程序的安全。2、容器技术风险：容器隔离依赖于 Linux 内核 namespaces 和 cgroups 等特性，从攻击者的角度出发，可以利用内核系统漏洞，容器运行时组件和容器应用部署配置等多个维度发起针对性的逃逸和越权攻击。K8s、Docker等开源软件近年来也相继爆出不少的高危漏洞，这都给攻击者提供了可乘之机。3、东西向流量防护：传统的企业应用安全模型通常基于内部架构不同的信任域来划分对应的安全边界，在信任域内的东西向服务交互被认为是安全的。而上云后企业应用需要在 IDC 和云上部署和交互，在物理安全边界消失后，如何在零信任的网络安全模型下构建企业级容器安全体系是云服务商需要解决的重要问题。以Docker环境为例，它支持Bridge、Overlay和Macvlan等网络，尽管实现方式不同，但有一个共同和普遍的问题：如果容器之间未进行有效隔离和控制，则一旦攻击者控制某台主机或某台容器，可以以此为跳板，攻击同主机或不同主机上的其他容器，也就是常提到的“东西向攻击”，甚至有可能形成拒绝服务攻击。4、访问控制：由于云环境的特殊性，云原生架构下的数据泄露风险远远大于传统环境。因此，需要充分利用云原生架构下的认证授权体系，结合应用自身的权限控制，严格遵循最小权限法则配置云上资源的访问控制和容器应用的权限。例如，如非必要尽量避免使用特权容器。

---