前端也应该了解点 docker 知识:docker 的理念与场景

dddd

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

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

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

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

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

按照惯例,先来列个提纲或者叫先挖个坑:

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

1. docker 的历史和发展

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

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

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

前端也应该了解点 docker 知识:docker 的理念与场景

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

后来 dotCloud 一看 docker 这么火,于是把公司名也改成了 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 融资。

而在国内,也是火的一塌糊涂,各个云厂商,各种大会,都能看到 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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
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"]

上面就是一个简单的 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 的优势体现在哪里?

2.4 总结

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

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

docker 的场景不仅仅是这些,以上仅仅是结合淘宝前端的现状,YY 出来的一些可能的场景。
docker 不是银弹, 个人觉着就像我们对待 Node.js 一样,在合适的场景合理的利用。

下期预告

在下一期里面我们的小明将会出场,通过一些问答的方式来描述下 docker 的架构相关的概念和理解,如下:

下下期预告