将软件打包成标准单元，以便开发、运行和部署
容器是一个打包代码和所有依赖项的标准软件包，以便应用可以在另一台计算机环境快速稳定的运行起来。docker容器景象是一个轻量级、独立的、可执行的软件包，其包含程序运行起来所需要的代码、运行时间、系统工具、系统库和设置等环境。 容器镜像在运行时变为容器，当运行Docker Engine时，假使docker容器景象变为容器。
写一个计算加法的小程序，这个程序需要的输入来自于一个文件，计算完成后的结果输出到另一个文件。
由于计算机只认识0和1，所以无论需要哪种语言编写这种代码，最后都需要通过某种方式翻译成二进制文件，才能在计算机操作系统中运行起来。
而为了能够让这些代码正常运行，我们往往还要给他提供数据，比如这个加法程序所需要的输入文件。这些数据加上代码本身的二进制文件，放在磁盘上，就是我们平常所说的“程序”，也叫代码的可执行镜像。
然后，我们就可以在计算机上运行这个“程序”了。
首先，操作系统从“程序”中发现输入数据保存在一个文件中，所以这些数据就会被加载到内存中待命。同时，操作系统又读取到了计算加法的指令，这时，它就需要指示CPU完成加法操作。而CPU与内存协作进行加法计算，又会使用寄存器存放数值、内存堆栈保存执行的命令和变量。同时，计算机里还没有被打开的文件，以及各种各样I/O设备在不断地调用中修改自己的状态。
就这样，一旦程序被执行起来，它就从磁盘上的二进制文件，变成了计算机内存中的数据、寄存器里的值、堆栈中的指令、被打开的文件，以及各种设备的状态信息的一个集合。像这样一个程序运行起来的计算机执行环境的总和，就是： 进程。
所以，对于进程来说，它的静态表现就是程序，平常都安安静静的待在磁盘上；而一旦运行起来，它就变成了计算机里的数据和状态的总和，这就是它的动态表现。
而容器技术的核心功能，就是通过约束和修改进程的动态表现，从而为其创造出一个“边界”。
对于Docker等大多数Linux容器来说，Cgroups技术是同来制造约束的主要手段,而Namespace技术则是用来修改进程视图的主要方法。
假设你已经有了一个linux操作系统的Docker项目在运行，比如我的环境是Ubuntu 16.04和Docker CE 18.05。
$ docker run -it busybox /bin/sh
/ #
这个命令是Docker项目最重要的一个操作，即大名鼎鼎的docker run。
而-it参数告诉了Docker项目在启动容器后，需要给我们分配一个文本输入/输出环境，也就是TTY，跟容器的标准输入相关联，这样我们就可以和这个Docker容器进行交互了。而/bin/sh就是我们要在Docker容器里运行的程序。
即： 请帮我启动一个容器，在容器里执行/bin/sh，并且给我分配一个命令行终端跟这个容器交互。
这样，我的Ubuntu 16.04机器就变成了一个宿主机，而一个运行着/bin/sh的容器，就跑在了这个宿主机里面。
此时，如果我们在容器里执行一下ps指令，就会发现一些更有趣的事情：
/ # ps
PID USER TIME COMMAND
1 root 0:00 /bin/sh
10 root 0:00 ps
可以看到，我们在Docker里最开始执行的/bin/sh,就是这个容器内部的第一号进程（PID=1），而这个容器里一共只有两个进程在运行。这就意味着，前面执行的/bin/sh，以及我们刚刚执行的ps，已经被Docker隔离在了一个跟宿主机完全不同的世界当中。
本来，每当我们在宿主机上运行了一个/bin/sh程序，操作系统都会给它分配一个进程编号，比如PID=100。这个编号是进程的唯一标示，就像员工的工牌一样。所以PID=100，可以粗略理解为这个/bin/sh是我们公司的第100号员工。
而现在，我们要通过Docker把这个/bin/sh程序运行在一个容器当中。这时候，Docker就会在这个第100号员工入职时给它施一个“障眼法”，让他永远看不到前面的99个员工，这样会错误地以为自己就是公司的第1号员工。
这种机制，其实就是对被隔离应用的进程空间做了手脚，使得这些进程只能看到重新计算过的进程编号，比如PID=1。可实际上，他们在宿主机的操作系统里，还是原来的第100号进程。
这种技术，就是Linux里面的Namespace机制。而Namespace的使用方式也非常有意思：它其实只是Linux创建新进程的一个可选参数。我们知道，在Linux系统中创建线程的系统调用是clone(),比如：
int pit = clone(main_function, stack_sizee, SIGCHLD, NULL);
这个系统调用就会为我们创造一个新的进程，并且返回它的进程号pid。
而当我们用clone()系统调用创建一个新进程时，就可以在参数中CLONE_NEWPID参数，比如：
int pid = clone(main_function, stack_size, CLONE_NEWPID | SIGCHLD, NULL);
这时，新创建的这个进程将会“看到”一个全新的进程空间，在这个进程空间内，它的pid是1.之所以说“看到”，是因为这只是一个“障眼法”，在宿主机真实的进程空间里，这个进程的pid还是真实真实的树枝，比如100.
当然，我们还可以多次执行上面的clone()调用，这样就会创建多个PID Namespace，而每个Namespace里的应用进程，都会认为自己是当前容器里的第1号进程，他们既看不到宿主机里真正的进程空间，也看不到其他PID Namespace里的具体情况。
而除了我们刚刚用到的PID Namespace，linux操作系统还提供了Mount、UTS、IPC、Network和User这些Namespace，用来对各种不同的进程上下文进行“障眼法”操作。
比如，Mount Namespace，用于让被隔离进程只看到当前Namespace里的挂载点信息；Network Namespace，用于让被隔离进程看到当前Namespace里的网络设备和配置。
这，就是Linux容器最基本的实现原理了。
所以，Docker容器实际上是在创建容器进程时，指定了这个进程所需要启用的一组Namespace参数。这样，容器就只能“看”到当前Namespace所限定的资源、文件、设备、状态或者配置。而对于宿主机以及其他不相关的程序，它就完全看不到了。
所以说，容器，其实是一种特殊的进程而已。
在使用Docker的时候，并没有一个真正的“Docker容器”运行在宿主机里买呢。Docker项目帮助用户启动的，还是原来的应用进程，只不过在创建这些进程时，Docker为它们加上了各种各样的Namespace参数。
这时，这些进程就会觉得自己是各自PID Namespace里的第1号进程，只能看到各自Mount Namespace里挂载的目录和文件，只能访问到各自Network Namespace里的网络设备，就仿佛运行在一个个“容器”里面，与世隔绝。
