题外话
最近对Docker和Kubernetes进行了一番学习，前两天做了一次技术分享，回去听了一遍自己演讲的录音，发现单单PPT做好还是远远不够的，没有提前准备好逻辑严谨的讲稿，在讲的时候出现了卡壳、漏掉技术点、逻辑矛盾的问题。为了解决这个问题，我打算以后在做技术分享前，都按着PPT的内容先写成博客，理顺表达逻辑。另外，我觉得每次技术分享使用的PPT都应该尽可能的做好，因为你不知道未来会不会还要拿来再讲几遍。本文以PPT+讲稿的方式编写，权当对自己这次技术分享做个记录，欢迎大家拍砖。
1. Docker出现的背景
在平常的研发和项目场景中，以下情况普遍存在：
开发/测试/现场环境
研发人员在开发环境里写好了代码做好测试后，提交给测试部门，测试人员在测试环境跑起来发现有BUG，研发人员说在开发环境没这个BUG，和测试人员多次扯皮解决BUG后发布版本，发到现场在生产环境部署后，又发现有BUG，这下轮到工程人员和测试人员扯皮。有时候为了兼容特殊的现场环境，还需要对代码进行定制化修改，拉出分支，这样导致了每次到现场升级都是一场噩梦
升级或迁移项目
在每次发版本要升级到现场时，如果现场起了多个tomcat应用，那么需要对每个tomcat都先停掉，替换war包，然后再起起来，轮流着做，不仅繁琐而且很容易出错，如果遇到升级后出现严重BUG，还要手工做回退。另外，如果项目想上云，那么在云上部署后要重新进行一轮测试，如果后面考虑还云厂商，可能相同的测试还要再进行一次（比如更换了数据存储组件），费时费力。
总结以上列举的所有场景，他们存在的一个共同的问题是：没有一种既能够屏蔽操作系统差异，又能够以不降低性能的方式来运行应用的技术，来解决环境依赖的问题。Docker应运而生。
2. Docker是什么
Docker是一种应用容器引擎。首先说一下何为容器，Linux系统提供了Namespace和CGroup技术实现环境隔离和资源控制，其中Namespace是Linux提供的一种内核级别环境隔离的方法，能使一个进程和该进程创建的子进程的运行空间都与Linux的超级父进程相隔离，注意Namespace只能实现运行空间的隔离，物理资源还是所有进程共用的，为了实现资源隔离，Linux系统提供了CGroup技术来控制一个进程组群可使用的资源（如CPU、内存、磁盘IO等），把这两种技术结合起来，就能构造一个用户空间独立且限定了资源的对象，这样的对象称为容器。Linux Container是Linux系统提供的容器化技术，简称LXC，它结合Namespace和CGroup技术为用户提供了更易用的接口来实现容器化。LXC仅为一种轻量级的容器化技术，它仅能对部分资源进行限制，无法做到诸如网络限制、磁盘空间占用限制等。dotCloud公司结合LXC和以下列出的技术实现了Docker容器引擎，相比于LXC，Docker具备更加全面的资源控制能力，是一种应用级别的容器引擎。
也正是因为Docker依赖Linux内核的这些技术，至少使用3.8或更高版本的内核才能运行Docker容器，官方建议使用3.10以上的内核版本。
3. 与传统虚拟化技术的区别
传统的虚拟化技术在虚拟机（VM）和硬件之间加了一个软件层Hypervisor，或者叫做虚拟机管理程序。Hypervisor的运行方式分为两类：
因为运行在虚拟机上的操作系统是通过Hypervisor来最终分享硬件，所以虚拟机Guest OS发出的指令都需要被Hypervisor捕获，然后翻译为物理硬件或宿主机操作系统能够识别的指令。VMWare和VirtualBox等虚拟机在性能方面远不如裸机，但基于硬件虚拟机的KVM约能发挥裸机80%的性能。这种虚拟化的优点是不同虚拟机之间实现了完全隔离，安全性很高，并且能够在一台物理机上运行多种内核的操作系统（如Linux和Window），但每个虚拟机都很笨重，占用资源多而且启动很慢。
Docker引擎运行在操作系统上，是基于内核的LXC、Chroot等技术实现容器的环境隔离和资源控制，在容器启动后，容器里的进程直接与内核交互，无需经过Docker引擎中转，因此几乎没有性能损耗，能发挥出裸机的全部性能。但由于Docker是基于Linux内核技术实现容器化的，因此使得容器内运行的应用只能运行在Linux内核的操作系统上。目前在Window上安装的docker引擎其实是利用了Window自带的Hyper-V虚拟化工具自动创建了一个Linux系统，容器内的操作实际上是间接使用这个虚拟系统实现的。
4. Docker基本概念
Docker主要有如下几个概念：
5. Docker与虚拟机、Git、JVM的类比
为了让大家对Docker有更直观的认识，下面分别进行三组类比：
上图中Docker的镜像仓库类似于传统虚拟机的镜像仓库或存放镜像的本地文件系统，Docker引擎启动容器来运行Spark集群（容器内包含基础的Linux操作系统环境），类比于虚拟机软件启动多个虚拟机，在虚拟机内分别运行Spark进程，两者区别在于Docker容器内的应用在使用物理资源时，直接与内核打交道，无需经过Docker引擎。
Docker的仓库思想与Git是相同的。
Docker的口号是“Build，Ship，and Run Any App，Anywhere”，也就是可以基于Docker构建、装载和运行应用程序，一次构建到处运行。Java的口号是“Write Once,Run Anywhere”，即一次编写到处运行。Java是基于JVM适配操作系统的特点来屏蔽系统的差异，Docker则是利用内核版本兼容性的特点来实现一次构建导出运行，只要Linux系统的内核是3.8或更高的版本，就都能把容器跑起来。
当然，正如Java中如果应用代码使用了JDK10的新特性，基于JDK8就无法运行一样，如果容器内的应用使用了4.18版本的内核特性，那么在CentOS7（内核版本为3.10）启动容器时，虽然容器能够启动，但里面应用的功能是无法正常运行的，除非把宿主机的操作系统内核升级到4.18版本。
6. Docker镜像文件系统
Docker镜像采用分层存储格式，每个镜像可依赖其他镜像进行构建，每一层的镜像可被多个镜像引用，上图的镜像依赖关系，K8S镜像其实是CentOS+GCC+GO+K8S这四个软件结合的镜像。这种分层结构能充分共享镜像层，能大大减少镜像仓库占用的空间，而对用户而言，他们所看到的容器，其实是Docker利用UnionFS（联合文件系统）把相关镜像层的目录“联合”到同一个挂载点呈现出来的一个整体，这里需要简单介绍一个UnionFS是什么：
UnionFS可以把多个物理位置独立的目录（也叫分支）内容联合挂载到同一个目录下，UnionFS允许控制这些目录的读写权限，此外对于只读的文件和目录，它具有“Copy on Write（写实复制）”的特点，即如果对一个只读的文件进行修改，在修改前会先把文件复制一份到可写层（可能是磁盘里的一个目录），所有的修改操作其实都是对这个文件副本进行修改，原来的只读文件并不会变化。其中一个使用UnionFS的例子是：Knoppix，一个用于Linux演示、光盘教学和商业产品演示的Linux发行版，它就是把一个CD/DVD和一个存在在可读写设备（例如U盘）联合挂载，这样在演示过程中任何对CD/DVD上文件的改动都会在被应用在U盘上，不改变原来的CD/DVD上的内容。
UnionFS有很多种，其中Docker中常用的是AUFS，这是UnionFS的升级版，除此之外还有DeviceMapper、Overlay2、ZFS和 VFS等。Docker镜像的每一层默认存放在/var/lib/docker/aufs/diff目录中，当用户启动一个容器时，Docker引擎首先在/var/lib/docker/aufs/diff中新建一个可读写层目录，然后使用UnionFS把该可读写层目录和指定镜像的各层目录联合挂载到/var/lib/docker/aufs/mnt里的一个目录中（其中指定镜像的各层目录都以只读方式挂载），通过LXC等技术进行环境隔离和资源控制，使容器里的应用仅依赖mnt目录中对应的挂载目录和文件运行起来。
利用UnionFS写实复制的特点，在启动一个容器时， Docker引擎实际上只是增加了一个可写层和构造了一个Linux容器，这两者都几乎不消耗系统资源，因此Docker容器能够做到秒级启动，一台服务器上能够启动上千个Docker容器，而传统虚拟机在一台服务器上启动几十个就已经非常吃力了，而且虚拟机启动很慢，这是Docker相比于传统虚拟机的两个巨大的优势。
当应用只是直接调用了内核功能来运作的情况下，应用本身就能直接作为最底层的层来构建镜像，但因为容器本身会隔绝环境，因此容器内部是无法访问宿主机里文件的（除非指定了某些目录或文件映射到容器内），这种情况下应用代码就只能使用内核的功能。但是Linux内核仅提供了进程管理、内存管理、文件系统管理等一些基础且底层的管理功能，在实际的场景中，几乎所有软件都是基于操作系统来开发的，因此往往都需要依赖操作系统的软件和运行库等，如果这些应用的下一层直接是内核，那么应用将无法运行。所以实际上应用镜像往往底层都是基于一个操作系统镜像来补足运行依赖的。
Docker中的操作系统镜像，与平常安装系统时用的ISO镜像不同。ISO镜像里包含了操作系统内核及该发行版系统包含的所有目录和软件，而Docker中的操作系统镜像，不包含系统内核，仅包含系统必备的一些目录（如/etc /proc等）和常用的软件和运行库等，可把操作系统镜像看作内核之上的一个应用，一个封装了内核功能，并为用户编写的应用提供运行环境的工具。应用基于这样的镜像构建，就能够利用上相应操作系统的各种软件的功能和运行库，此外，由于应用是基于操作系统镜像来构建的，就算换到另外的服务器，只要操作系统镜像中被应用使用到的功能能适配宿主机的内核，应用就能正常运行，这就是一次构建到处运行的原因。
下图形象的表现出了镜像和容器的关系：
上图中Apache应用基于emacs镜像构建，emacs基于Debian系统镜像构建，在启动为容器时，在Apache镜像层之上构造了一个可写层，对容器本身的修改操作都在可写层中进行。Debian是该镜像的基础镜像（Base Image），它提供了内核Kernel的更高级的封装。同时其他的镜像也是基于同一个内核来构建的（以下的BusyBox是一个精简版的操作系统镜像）：
这时候就会有一个问题，应用基于操作系统镜像来构建，那如果操作系统镜像本身就很占空间，岂不是镜像的分发不方便，而且镜像仓库占用的空间也会很大。有人已经考虑到这一点，针对不同的场景分别构造了不同的操作系统镜像，下面介绍几种最常用的系统镜像。
7. Docker基础操作系统
以上系统镜像分别适用于不同的场景：
8. Docker持久化存储
根据前面介绍的容器UnionFS写实复制的特点，可知在容器里增加、删除或修改文件，其实都是对可写层里的文件副本进行了操作。在容器关闭后，该可写层也会被删除，对容器的所有修改都会失效，因此需要解决容器内文件持久化的问题。Docker提供了两种方案来实现：
9. Docker镜像制作方法
镜像制作方法有两种：
当一个容器在运行时，在里面所有的修改都会体现在容器的可写层，Docker提供了commit命令，可以把正在运行的容器，叠加上可写层的修改内容，生成一个新镜像。如上图所示，在容器里新安装Spark组件的，如果关闭容器，Spark组件会随着可写层的消失而消失，如果在关闭容器之前使用commit命令生成新镜像，那么使用新镜像启动为容器时，容器里就会包含Spark组件。
这种方式比较简单，但无法直观的设置环境变量、监听端口等内容，适合在简单使用的场景运用。
Dockerfile是一个定义了镜像创建步骤的文件，Docker引擎通过build命令读取Dockerfile，按定义的步骤来一步步构造镜像。在研发和实施环境中，通过Dockerfile 创建容器是主流做法。下面是一个Dockerfile的例子：
FROM ubuntu/14.04 # 基础镜像
MAINTAINER guest # 制作者签名
RUN apt-get install openssh-server -y # 安装ssh服务
RUN mkdir /var/run/sshd # 创建目录
RUN useradd -s /bin/bash -m -d /home/guest guest # 创建用户
RUN echo ‘guest:123456’| chpasswd # 修改用户密码
ENV RUNNABLE_USER_DIR /home/guest # 设置环境变量
EXPOSE 22 # 容器内默认开启的端口
CMD ["/usr/sbin/sshd -D"] # 启动容器时自动启动ssh服务
Docker引擎可以根据以上Dockerfile定义的步骤，构造出一个带有ssh服务的Ubuntu镜像。
10. Docker的使用场景
Docker作为一种轻量级的虚拟化方案，应用场景十分丰富，下面收集了一些常见的场景：
持续集成和持续部署
互联网行业提倡敏捷开发，持续集成部署CI/CD便是最典型的开发模式。使用Docker容器云平台，就能实现从代码编写完成推送到Git/SVN后，自动触发后端CaaS平台将代码下载、编译并构建成测试Docker镜像，再替换测试环境容器服务，自动在Jenkins或者Hudson中运行单元/集成测试，测试通过后，马上就能自动将新版本镜像更新到线上，完成服务升级。整个过程全自动化，一气呵成，最大程度地简化了运维，而且保证线上、线下环境完全一致，而且线上服务版本与Git/SVN发布分支也实现统一。
解决微服务架构的实施难题
基于Spring Cloud这样的微服务框架，能够实现微服务的管理，但微服务本身还是需要运行在操作系统上。一个采用微服务架构开发的应用中，微服务的个数往往很多，这就导致了一台服务器上往往需要启动多个微服务来提高资源的利用率docker查看容器挂载信息，而微服务本身可能就只能兼容部分操作系统，这就导致了就算有大量的服务器资源（操作系统可能不一样），但由于微服务本身与操作系统可能相关，就不能做到让微服务在任意服务器上运行，这就带来了资源的浪费和运维的困难。利用Docker容器的环境隔离能力，让微服务运行在容器内，就能够解决以上所说的问题。
执行临时任务
有时候用户只是想执行一次性的任务，但如果用传统虚拟机的方式就要搭建环境，执行完任务后还要释放资源，比较麻烦。使用Docker容器就可以构建临时的运行环境，执行完任务后关闭容器即可，方便快捷。
多租户环境
利用Docker的环境隔离能力，可以为不同的租户提供独占的容器，实现简单而且成本较低。
11. 总结
Docker的技术并不神秘，只是整合了前人积累的各种成果实现的应用级的容器化技术，它利用各种Linux发行版中使用了版本兼容的内核容器化技术，来实现镜像一次构建到处运行的效果，并且利用了容器内的基础操作系统镜像层，屏蔽了实际运行环境的操作系统差异，使用户在开发应用程序时，只需确保在选定的操作系统和内核版本上能正确运行即可，几乎不需要关心实际的运行环境的系统差异，大大提高效率和兼容性。但随着容器运行得越来越多，容器管理将会称为另一个运维的难题，这时候就需要引入Kubernetes、Mesos或Swarm这些容器管理系统，后面有机会再介绍这些技术。
end—
K8S培训推荐
Kubernetes线下实战培训，采用3+1+1新的培训模式（3天线下实战培训，1年内可免费再次参加，每期前10名报名，可免费参加价值3600元的线上直播班；）docker查看容器挂载信息，资深一线讲师，实操环境实践，现场答疑互动，培训内容覆盖：Kubernetes集群搭建、Kubernetes设计、Pod、常用对象操作，Kuberentes调度系统、QoS、Helm、网络、存储、CI/CD、日志监控等。开班城市：北京/深圳/上海/成都。
———END———
限 时 特 惠：本站每日持续更新海量各大内部创业教程，一年会员只需128元，全站资源免费下载点击查看详情
站 长 微 信：jiumai99