简年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 似乎就在眼前啊。

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

docker在centOS下默认会安装在/var/lib/docker/目录下， 这个目录的容量不大，创建的容器或镜像多了就无法使用了。

目录迁移记录如下（更改到/home/docker下）：

1、停止docker服务。

2、创建新的docker目录，执行命令df -h,找一个大的磁盘。我的是放在/home目录下面，我的/home目录大小有900G。 我在 /home目录下面建了 /home/docker/lib目录，执行的命令是：

3、迁移/var/lib/docker目录下面的文件到 /home/docker/lib下面

注意：如果文件内容很多的话，为了确保成功最好是一个文件一个文件的拷贝。如果在拷贝过程中报“设备上没有空间”的错误，就使用mv剪切。

4、修改docker配置（/etc/systemd/system/docker.service.d/devicemapper.conf）,在文件末添加 --graph=/home/docker/lib

devicemapper.conf文件的内容如下：

注意：如果/etc/systemd/system/docker.service.d/devicemapper.conf，这个路径找不到的话，就新建，新建之后加入内容，没有私服地址的话就可以去掉”--insecure-registry=私服地址”。

5、重载配置，重启docker

6、启动成功后，确定容器没问题后删除/var/lib/docker/目录中的文件，然后就OK了。

---