dockerip包不分片

docker为什么会出现

一款产品从开发到上线，一般都会有开发环境，测试环境，运行环境。

如果有一个环境中某个软件或者依赖版本不同了，可能产品就会出现一些错误，甚至无法运行。比如开发人员在windows系统，但是最终要把项目部署到linux。如果存在不支持跨平台的软件，那项目肯定也无法部署成功。

这就产生了开发和运维人员之间的矛盾。开发人员在开发环境将代码跑通，但是到了上线的时候就崩了。还要重新检查 *** 作系统，软件，依赖等版本，这大大降低了效率。造成了搭环境一两天，部署项目两分钟的事件。

docker的出现就能解决以上问题：

开发人员把环境配置好，将需要运行的程序包运行成功，然后把程序包和环境一起打包给运维人员，让运维人员部署就可以了。这大大提高了项目上线的效率。

2.docker简介

Docker是基于Go语言实现的云开源项目。

Docker的主要目标是“Build，Ship and Run Any App,Anywhere”，也就是通过对应用组件的封装、分发、部署、运行等生命周期的管理，使用户的APP（可以是一个WEB应用或数据库应用等等）及其运行环境能够做到“一次镜像，处处运行”

Linux容器技术的出现就解决了这样一个问题，而 Docker 就是在它的基础上发展过来的。将应用打成镜像，通过镜像成为运行在Docker容器上面的实例，而 Docker容器在任何 *** 作系统上都是一致的，这就实现了跨平台、跨服务器。只需要一次配置好环境，换到别的机器上就可以一键部署好，大大简化了 *** 作。

docker简介总结：

解决了运行环境和配置问题的软件容器，方便做持续集成并有助于整体发布的容器虚拟化技术。docker基于Linux内核，仅包含业务运行所需的runtime环境。

3.传统虚拟机和容器的对比

3.1虚拟机

虚拟机是可以在一种 *** 作系统里面运行另一种 *** 作系统，比如在Windows10系统里面运行Linux系统CentOS7。应用程序对此毫无感知，因为虚拟机看上去跟真实系统一模一样，而对于底层系统来说，虚拟机就是一个普通文件。这类虚拟机完美的运行了另一套系统，能够使应用程序， *** 作系统和硬件三者之间的逻辑不变。

虚拟机的缺点：

启动慢

资源占用多

冗余步骤多

3.2容器虚拟化技术

由于前面虚拟机存在某些缺点，Linux发展出了另一种虚拟化技术：

Linux容器(Linux Containers，缩写为 LXC)

Linux容器是与系统其他部分隔离开的一系列进程，从另一个镜像运行，并由该镜像提供支持进程所需的全部文件。容器提供的镜像包含了应用的所有依赖项，因而在从开发到测试再到生产的整个过程中，它都具有可移植性和一致性。

Linux 容器不是模拟一个完整的 *** 作系统而是对进程进行隔离。有了容器，就可以将软件运行所需的所有资源打包到一个隔离的容器中。容器与虚拟机不同，不需要捆绑一整套 *** 作系统，只需要软件工作所需的库资源和设置。系统因此而变得高效轻量并保证部署在任何环境中的软件都能始终如一地运行。

=

3.3两者对比

传统虚拟机技术是虚拟出一套硬件后，在其上运行一个完整 *** 作系统，在该系统上再运行所需应用进程；

容器内的应用进程直接运行于宿主的内核，容器内没有自己的内核且也没有进行硬件虚拟。因此容器要比传统虚拟机更为轻便。

每个容器之间互相隔离，每个容器有自己的文件系统 ，容器之间进程不会相互影响，能区分计算资源。

4.docker的作用

一：更快速的应用交付和部署

传统的应用开发完成后，需要提供一堆安装程序和配置说明文档，安装部署后需根据配置文档进行繁杂的配置才能正常运行。Docker化之后只需要交付少量容器镜像文件，在正式生产环境加载镜像并运行即可，应用安装配置在镜像里已经内置好，大大节省部署配置和测试验证时间。

二：更便捷的升级和扩缩容

随着微服务架构和Docker的发展，大量的应用会通过微服务方式架构，应用的开发构建将变成搭乐高积木一样，每个Docker容器将变成一块“积木”，应用的升级将变得非常容易。当现有的容器不足以支撑业务处理时，可通过镜像运行新的容器进行快速扩容，使应用系统的扩容从原先的天级变成分钟级甚至秒级。

三：更简单的系统运维

应用容器化运行后，生产环境运行的应用可与开发、测试环境的应用高度一致，容器会将应用程序相关的环境和状态完全封装起来，不会因为底层基础架构和 *** 作系统的不一致性给应用带来影响，产生新的BUG。当出现程序异常时，也可以通过测试环境的相同容器进行快速定位和修复。

四：更高效的计算资源利用

Docker是内核级虚拟化，其不像传统的虚拟化技术一样需要额外的Hypervisor支持，所以在一台物理机上可以运行很多个容器实例，可大大提升物理服务器的CPU和内存的利用率。

6.docker的应用场景

docker借鉴了标准集装箱的概念。标准集装箱是将货物运往世界各地，docker将这个模型运用到自己的设计当中，唯一不同的是：集装箱运送货物，而docker运输软件。

7.docker三要素

一：镜像（Image）

Docker 镜像（Image）就是一个只读的模板。镜像可以用来创建 Docker 容器，一个镜像可以创建很多容器。

二：容器（Container）

Docker 利用容器（Container）独立运行的一个或一组应用。容器是用镜像创建的运行实例。

它可以被启动、开始、停止、删除。每个容器都是相互隔离的、保证安全的平台。

可以把容器看做是一个简易版的 Linux 环境（包括root用户权限、进程空间、用户空间和网络空间等）和运行在其中的应用程序。

容器的定义和镜像几乎一模一样，也是一堆层的统一视角，唯一区别在于容器的最上面那一层是可读可写的。

三：仓库（Repository）

仓库（Repository）是集中存放镜像文件的场所。仓库(Repository)和仓库注册服务器（Registry）是有区别的。仓库注册服务器上往往存放着多个仓库，每个仓库中又包含了多个镜像，每个镜像有不同的标签（tag）。

仓库分为公开仓库（Public）和私有仓库（Private）两种形式。最大的公开仓库是 Docker Hub(https://hub.docker.com/)，存放了数量庞大的镜像供用户下载。国内的公开仓库包括阿里云 、网易云 等

8.docker工作原理

Docker是一个Client-Server结构的系统，Docker守护进程运行在主机上， 然后通过Socket连接从客户端访问，守护进程从客户端接受命令并管理运行在主机上的容器。 容器，是一个运行时环境，就是我们前面说到的集装箱。

9.docker平台架构图解

Docker 是一个 C/S 模式的架构，后端是一个松耦合架构，众多模块各司其职。

Docker运行的基本流程为:

用户是使用Docker Client与Docker Daemon建立通信，并发送请求给后者。

Docker Daemon作为Docker架构中的主体部分，首先提供Docker Server的功能使其可以接受Docker Client的请求。

Docker Engine执行Docker内部的一系列工作，每一项工作都是以一个Job的形式的存在。

Job的运行过程中，当需要容器镜像时，则从Docker Registry中下载镜像，并通过镜像管理驱动Graph driver将下载镜像以Graph的形式存储。

当需要为Docker创建网络环境时，通过网络管理驱动Network driver创建并配置Docker容器网络环境。

当需要限制Docker容器运行资源或执行用户指令等 *** 作时，则通过Exec driver来完成。

Libcontainer是一项独立的容器管理包，Network driver以及Exec driver都是通过Libcontainer来实现具体对容器进行的 *** 作。

10.docker的安装

Docker官网

Docker并非是一个通用的容器工具,它依赖于已存在并运行的Linux内核环境。

Docker实质上是在已经运行的Linux下制造了一个隔离的文件环境，因此它执行的效率几乎等同于所部署的Linux主机。

因此，Docker必须部署在Linux内核的系统上。如果其他系统想部署Docker就必须安装一个虚拟 Linux环境。

要求系统为64位、Linux系统内核版本为 3.8以上

查看自己虚拟机的内核：

开始安装：

一：搭建gcc环境（gcc是编程语言译器）

yum -y install gcc

yum -y install gcc-c++

二：安装需要的软件包

yum install -y yum-utils

于是突然脑洞一开，如果把整个 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 似乎就在眼前啊。

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

LXC是Linux Containers的缩写，是linux内核自带的容器化工具，用于进程隔离，namespace隔离，文件系统隔离。提供一种轻量的虚拟化解决方案。

本文的 *** 作基于的Ubuntu系统。

Ubuntu下直接安装

安装完成后查看配置情况

启动LXC container

配置桥接网络

TODO

查看一下当前可用的模板

利用可用的模板创建一个centos的容器

命令中

创建完成后，利用工具lxc-ls可以查看当前建立的container

新建立的container的文件系统保存在目录 /var/lib/lxc/<container>/rootfs 下面，同时还有一个配置文件config

从一个已经创建好的container克隆出一个新的来

查看克隆好的新的lxc container

修改config文件，通过添加一行配置修改cpu分配，例如分配了CPU 0给container

首先在container内部创建一个文件夹，比如说 /mnt/share

然后主机上也创建一个文件夹，比如说'/tmp/share'

这个时候主机上保存container文件系统的目录下面也会产生 /mnt/share 这个目录，找到这个目录的绝对路径

修改container的配置文件config， 添加一行

---