docker学习1：docker前世今生

Docker简介

Docker是2013发起的一个项目，早在2013年，Docker自诞生起，就是整个技术界的明星项目，当时我还在上海实习，就在各种技术媒体上看到了Docker的介绍文章，很多技术媒体宣称docker是一项技术突破，并且是一次技术革命，可惜当时由于本身是一个Android Framework开发者，眼界很低，对于这种OS虚拟化技术有点不屑一顾，而今转后台后才发现这项技术的重要性

Docker的特征

Docker是一个云开源项目，托管在github，任何人都可以通过 git clone 或者fork参与进来，本身是基于linux的容器技术，采用当时如日中天google新推出的Go语言实现。采用apache 2.0协议开源。

docker镜像地址

Go语言与Docker

相比Go语言与其它语言的对比，国内外很多技术媒体都有列举，在Docker领域，Go语言相比其它语言的优势在于

相对于C/C 开发难度低，支持向前兼容，运维维护成本小
相对于python，生成的是静态文件，有效的避免的低级错误，并且性能高一个等级
并发性好，内存占用低
部署简单，毕竟生成的静态文件，有glibc的地方就能运行

一门语言当然也有自己的缺点，比如，内存回收延迟久，图片处理库有bug，对包版本要求严格等一些问题，但是瑕不掩瑜，一个开发成本极其简单，性能优良，部署简单的语言与Docker简直就是天作之合

至于Go语言的优势，在Go的社区中都有非常详尽的讨论，这里不多讲

Docker的目标

Docker的是一个轻量级的操作系统虚拟化解决方案。主要目标，用官网的概括来说就是“Build，Ship and Run Any App,Anywhere”：编译，装载任何App,在任何地方都可以运行，我们大概理解就是一个容器，实现了对应用的封装，部署，运行等生命周期管理，只要在glibc的环境下，到处都可以运行。

这点在企业的云服务部署是有非常广泛的应用前景。后面我们将详细讨论。

Docker的引擎

Docker的是基于Linux自带的（Linux。 Containers,LXC）技术，在LXC上，Docker进行了近一步封装。正因为如此，Docker只能在Linux环境下运行，当然，前段时间docker终于支持OSX和Windows了，虽然还是体验尝鲜版，但更加方便开发者去开发了！

Docker的原理

其实前面讲了这么多，Docker的原理已经不言而喻，这里用IBM的解释就是

容器有效的将单个操作系统管理的资源划分到孤立的组中，以便更好的在孤立的组之间平衡有冲突的资源使用需求。与虚拟化相比，这样既不需要指令级模拟，也不需要即时编译。容器可以在核心CPU本地运行指令，而不需要任何专门的解释机制。此外，也避免了准虚拟化（paravirtualization）和系统调用替换中的复杂性。
简而言之就是，Docker是一个盒子，一个盒子装一个玩具，无论你丢在哪里，你给他通电(glibc)，他就能运行。你的玩具大就用大盒子，小玩具就用小盒子。

两个应用之间的环境是环境是完全隔离的，建立通信机制来互相调用。容器的创建和停止都十分快速（秒级），容器自身对资源的需求十分有限，远比虚拟机本身占用的资源少。

Docker VS VM

Docker与虚拟机(虚拟机)的区别可以看：

左图是虚拟机的工作原理图，对资源进行抽象，着重体现在硬件层面的虚拟化上，这种方式增加了两场调用链，对性能的损耗比较大，而且还会占用大量的内存资源

有图是Docker的工作原理图，属于OS级别的虚拟化，kernel通过创建多个镜像来隔离不同的app进程，由于kernel是是共享，而且本身linux image也不大，性能损耗几乎可以不计，而且内存占用也不大，大大节约了设备成本。

Docker架构总览

最核心的是 Docker Daemon我们称之为Docker守护进程，也就是Server端，Server端可以部署在远程，也可以部署在本地，因为Server端与客户端(Docker Client)是通过Rest API进行通信。

docker CLI 实现容器和镜像的管理，为用户提供统一的操作界面,这个客户端提供一个只读的镜像，然后通过镜像可以创建一个或者多个容器(container)，这些容器可以只是一个RFS(Root File System),也可以是一个包含了用户应用的RFS。容器在docker Client中只是一个进程，两个进程是互不可见的。

用户不能与server直接交互，但可以通过与容器这个桥梁来交互，由于是操作系统级别的虚拟技术，中间的损耗几乎可以不计

注：

CLI：command line interface。命令行接口.
RFS：Root File System 根文件系统.

Image & Container

在docker中，我们重点关注的就是镜像和容器了。因为在实际应用中，我们封装好镜像，然后通过镜像来创建容器，在容器运行我们的应用就好了。而server端掌控网络和磁盘，我们不用去关心，启动docker sever 和 docker client都是一条命令的事情。后面会详细讲docker的启动过程。

Image: 一个只读的镜像模板。可以自己创建一个镜像也可以从网站上下载镜像供自己使用。镜像包含了一个RFS.一个镜像可以创建很多容器。

Container:由docker client通过镜像创建的实例，用户在容器中运行应用，一旦创建后就可以看做是一个简单的RFS，每个应用运行在隔离的容器中，享用独自的权限，用户，网络。确保安全与互相干扰

两者在创建后，都是一堆layer的统一视角，唯一的却别是镜像最上面那一层是只读的，不可以修改，但是容器最上面一层是rw的，提供给用户操作

repository:仓库，这个东西没有单独介绍不是因为它不重要，而是因为之前做个比较多的Android源码编译，所以这里就没有仔细往下看，大概就是一个镜像库，最大的是docker hub，类似于google 的aosp，当然也可以本地搭，比如mig事业群就有自己的repo。

Docker的应用

最后，这里讲一下docker的应用作为本文的终结。

A:为什么会想起来学习docker技术

2016年年中的时候，我转做后台，经历了一段时间的时候痛苦转型后，中学摸到了门槛，年底赶上事业群的服务器docker化，那段时间非常痛苦，因为相对实体机或者虚拟机，各种问题频出，因为虚拟机或者实体机是不会迁移的，我们部署一套服务后会有一些依赖库需要安装，但是那段时间docker经常迁移，之前也没有接触过docker，导致问题频出。

到2017年4月的时候，docker基本稳定下来，我们也开始享受docker带来的种种便利，比如：

发布服务再也不用care服务器的运行环境了，所有的服务器都是自动分配docker，自动部署，自动安装，自动运行
再也不用担心其他服务引起的磁盘问题，cpu问题，系统问题了。之前我们固定在一台idc上发布我们所有的服务，导致后面这台idc上挂了200多个服务，日志文件经常导致磁盘爆满，一旦磁盘爆满，200多个服务就要挂掉一半服务。
更好的资源利用，因为今年还没有数据出来，但个人预计是会给公司节省一半的服务器资源，既避免了资源浪费的同时，又保证了服务的稳定运行
自动迁移，学历了docker后，我们可以自己制作镜像，后面服务迁移的时候，只要使用我们自己的镜像，无论怎么迁移都不会出现任何问题
对于运维来说，管理更加方便了。

目前MIG事业群已经全面接入了docker，也证明了docker容器技术的成功性。

PS：

edhat 已经集中支持 Docker
Google 在PaaS 产品中广泛应用。