Docker 入门（一）

Docker 入门（一）

---

一、初识 Docker

Docker 是一个开源的引擎，可以轻松的为任何应用创建一个轻量级的、可移植的、自给自足的容器。

开发者在笔记本上编译测试通过的容器可以批量的在生产环境中部署，包括 VMs（虚拟机）、bare metal、OpenStack 集群和其他的基础应用平台。

Docker 通常用于如下场景：

• web 应用的自动化打包和发布
• 自动化测试和持续集成、发布
• 在服务型环境中部署和调整数据库或其他的后台应用
• 从头编译或者扩展现有的 OpenShift 或 Cloud Foundry 平台来搭建自己的 PaaS 环境

1、Docker 的历史和发展

最开始，docker 是 dotClound 公司的一个内部项目（该公司提供 PaaS 服务）。

2013年3月，docker 正式发布开源版本。火了之后，dotClound 公司改名 docker。

接着，一堆的国际巨头型公司介入，大批开发者提交代码。

2013年11月 RHEL 6.5 发布，集成了对 docker 的支持，拉开了各大厂商竞相支持 docker 的大幕。

2014年4月开始，亚马逊、谷歌、微软在他们的云产品中开始支持 docker。

2014年6月，DockerCon 2014 召开，谷歌、IBM、微软、Facebook、Twitter 等公司参与。与此同时，docker 1.0 正式发布。

…

2015年4月，docker 完成了 D 轮 $9500w 的融资。

2、Docker 的理念

docker 的理念是 build、ship、run。

（1）build

按照前端的理解，build 就是编译、打包的意思，在保证应用能跑起来之前所做的一系列动作。

常规的打包有什么问题呢？它不能打包环境。

前端能不能做到 build 一次，各端运行呢？这就需要出现一个运行时的东西，屏蔽各端差异，从这个角度看，react 可能勉强算一个。

那么，docker 的 build 做了什么工作呢？

下面看一下 docker build 的描述文件 DockerFile：

FROM centos:centos6
MAINTAINER [email protected]

RUN yum -y update; yum clean all
RUN yum -y install epel-release; yum clean all
RUN yum -y install nodejs npm; yum clean all

# copy 程序代码到容器的 /src 下
ADD . /src

RUN cd /src; npm install

EXPOSE 8080

CMD ["node", "/src/index.js"]

上面是一个简单的 Node.js 应用的 build 描述文件，docker 根据这个描述文件来 build 出一个镜像，一个可以到处运行的镜像。

第一个关键字 FROM，它的意思是要从哪里作为基础镜像来制作你现有的镜像。

假设有一个 Midway 的 docker 镜像，这里面已经做好了运行 Midway 应用的所有环境准备，那么，我们在开发、测试、线上，都可以使用同一个 Midway 的镜像。如果要基于 Midway 的 4.0 版本，那就 FROM Midway: 4.0，如果想用 5.0 就 FROM Midway： 5.0 。

从上面 Midway 的例子来看，Midway 的镜像是包含了 Midway 的环境，不管是 windows、mac、linux，只要能用 docker，就能保证开发、测试、部署的环境一致。

如果没有 docker，就会有一堆的问题，比如 Node.js 版本不对啊，环境变量不对啊，程序放的目录不对啊 大专栏  Docker 入门（一），诸如此类的一些环境问题。

总结来说，docker 具有的这种能够打包环境的能力，是它能够导出运行的关键。

（2）ship

这个单词的字面意思是货船、搬运、发布的意思。

我们目前的发布机制，基本原理是：本机 git push 到 GitHub/GitLab（都是使用 git 的代码管理平台），服务器上 git pull。

docker 和我们目前的发布机制是异曲同工的。把制作好的镜像 docker push 到 dockerhub（可以理解为 GitHub）或者私有 registry（可以理解为 GitLab），用户通过 docker pull 到本地。这也是 docker 进行版本控制的一种方式。

那传统发布和 docker 的差异在哪里呢？

传统的发布只是把代码或者程序发布到线上。如果不涉及类似 Node.js 版本升级，npm 模块升级，环境变量迭代等，其实是凸显不出 docker 的优势的。

docker 不仅分发镜像，也可以分发镜像的描述文件 DockerFile

。比如想让测试在你的环境里去测试和复现 bug，不用提供镜像，给他图个文本文件就好了。所以，docker 的受益人是需要做应用分发的开发者和运维同学。

（3）run

run 就是运行的意思。

对于传统前端来讲，把静态文件放到 web 服务器的对应目录就可以了，不涉及其它动作。对于 Node.js 类应用来讲会复杂一些，不仅仅是把应用代码发布上去就能生效，还要考虑涉及到应用关停等影响服务可用性的动作。

那么 docker 的优势是什么呢？

• run anywhere，也就是可以运行在任何可以运行 docker 的容器的机器上。如果你的应用就是固定的两台设备，这体现不出 docker 的优势，但是如果应用分布在不同的地方，甚至在不同的云服务上，都可以保证正常的秒级启动。这也给我们在突发流量的时候可以迅速实现扩容。
• 非常轻量，和传统的进程没有太大差别，这也是相对于传统 vm 非常大的一个优势。
• 资源隔离，保证各个应用之间不相互影响，同时充分利用机器资源。

（4）总结

反观我们目前的开发、应用部署模式，docker 的应用场景有哪些？

• 需要重复配置统一的环境
  • 一个团队开发同一个程序，需要一直的开发环境。以前每个成员都要在自己电脑上配置一遍，但使用 docker 基本是配置一遍，其他同学共享就可以了。
  • 减少持续集成和测试的难度（集成和测试的一大难点是环境一致性问题）。
  • 减少开发、测试、线上环境因为环境不一致出现的问题。
  • 有很多知名成熟的镜像，我们可以直接拿来用。
• 快速、高效利用当前资源
  • 有时候一个容器就能完成的事情，我们去申请一台 vm，资源有些浪费。
  • 生成一台 vm 是分钟级别的，而生成一台容器是秒级的。这种优势在大规模迅速扩容才会凸显出来。
• 需要资源隔离的场景
  • 比如一些多租户的环境里，一个用户的失控（比如程序把内存吃光，把宽带打满），docker 在这方面可以很好的做控制。
• 需要快速动态的伸缩容量的场景
  • 比如说大促，开始之前迅速扩容，结束之后迅速销毁
• 微服务
• 更多…