前端也应该了解点 docker 知识 (系列一 )

jopen 9年前

我觉着你是看了题目点进来的。前端和 docker 这俩八竿子打不着的有毛关系？那接下来我们就扯一扯，看看能不能把它俩扯一块。

首先得达成共识，现在的前端已经不是以前的狭义的前端，如果指狭义的前端，那真是半毛钱关系都没有。但你我不可否认的是，现在是大前端的时代。什么是大前端，详细的应该大老板来给解释下，但是这里还是简单的去说一下：

前端有了 Node.js，扩展到了服务端的边界，未来有更多的可能。
前端现在也逐渐的正规化，工程化，编译，测试，发布逐渐完善。
我们是工程师，技术工种，抛开限定，多了解点技术岂不是更好。

看到这里，你可能心想，要是这么说，那确实可能是有那么一点关系。如果意识到这一点，我们已经成功拉近了 1/3 距离。

其次，这篇（系列）文章还是定位 docker 的入门文章，即使不是前端的同学来看，也能对 docker 的架构，应用场景有个一定的了解，当你听其它基友讨论 docker 的时候，也能插上一嘴。

按照惯例，先来列个提纲或者叫先挖个坑：

docker 的历史和发展（系列一）
docker 的理念与场景（系列一）
mac 上安装 docker （系列二）
docker 架构（系列二）
docker 重要命令简介（系列三）
docker 实战（系列四）
- DokerFile 及最佳实践
- docker-compose 等编排工具
- 网络
- 存储
- 集群
- 其它

1. docker 的历史和发展

回顾下历史及发展历程也算是国际惯例了，docker 的发展也充满着传奇色彩。

当时，这个公司的名称还是叫 dotCloud , 提供 Pass 服务，docker 是他们公司的一个内部项目。

2013 年 3 月 docker 正式发布开源版本。

上图是 docker 的 GitHub commit 图，看看是多么的活跃。还有那 27000+ 的星星。

后来 dotCloud 一看 docker 这么火，于是把公司名也改成了 docker 了。

一家公司玩终究玩不出大花样来，而是一堆的国际巨头型的公司的介入，大批的开发者提交代码。

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

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

2014 年 6 月，DockerCon 2014 召开，谷歌， IBM , 微软，非死book，推ter 等公司参与。于此同时 docker 1.0 正式发布。

…

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

而在国内，也是火的一塌糊涂，各个云厂商，各种大会，都能看到 docker 的身影。

2. docker 的理念

理念，往往是为解决痛点而生，就像 KISS（Keep it sample and stupid）为复杂程序而生一样，docker 的理念是 build，ship， run。

2.1 build

好吧，作为前端这个单词不陌生吧，你的项目目录下面在几天之前可能还有一个 build 目录，现在接入 ff 进行云端 build，只是把 build 换了个地方。

按照前端的理解，build 就是编译，打包的意思，和其它静态语言如 c/c++ 之流一样，在保证应用能跑起来之前所做的一些列动作。

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

如果你有打包 rpm 的经历，你可能清楚，你要区分系统的版本，cpu 的架构，从而打出特定平台和系统下的软件包。换句话讲，你 build 一次只能跑在一个特定地方。

如果做过 Java 的同学可能清楚当年为啥 Java 会火起来，编写一次，到处运行，就是因为 Java 有 JVM ，其实 docker 从某种角度看就属于 JVM 的角色。

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

回到正题，docker 的 build 做了什么工作呢？

我们来看一下 docker build 的描述文件 DockerFile ：

FROM centos:centos6  MAINTAINER yourname@example.com    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"]

</div>

上面就是一个简单的 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，都能保证你的开发，测试，部署的环境的一致。这要是搁到以前呢？卧槽，Node.js 版本不对啊，环境变量不对啊，程序放的目录不对啊，诸如此类环境不一致带来的问题将一去不复返。

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

2.2 ship

字面意思就是货船，搬运，发布的意思。看看我们目前的发布机制，基本上是原理是，本机 git push 到 GitLab, 服务器上 git pull 。

从这点上来看和 docker 的异曲同工的。

把制作好的镜像 docker push 到 dockerhub ( 致敬 GitHub ？) 或者私有 registry（你可以理解为 git 对应的 GitLab ），用户通过 docker pull 到本地，同样一会 pull 差异性的部分。这也是 docker 进行版本控制的一种方式

。

docker 拥有 dockerhub ，相较于程序员拥有 GitHub 一样，是个大宝库，这也是 docker 生态中很重要的一环。

但差异点在哪里呢？

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

docker 不仅分发镜像，也可以分发镜像的描述文件 DockerFile , 比如你想让测试在你的环境里面去测试和复现 bug，不用提供个头稍微大一些的镜像，给他一个文本文件就好了。

所以 docker 的官网上也明确的说明了受益人是需要做应用分发的开发者和运维同学。

2.3 run

很好理解，就是运行的意思。

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

那么 docker 的优势体现在哪里？

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

2.4 总结

如果这么拆开了来分析其实对 docker 是不公平的，因为人家是 build， ship， run 提供的是一整套解决方案。

我们了解了 docker 的理念，反观我们当前的开发，应用部署模式，docker 的应用场景有哪些？

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