让运维也学学前端，那天下就太平了
目标：定义 Docker 与前端的关系，介绍前端部署的几种方式，阐述 Docker 化的前端的优点所在
今天我们来讲讲前端与 Docker 之间的关系
Docker 是运维工具而不是开发工具。
很多前端工程师把 Docker 想象成开发工具，来回推敲自己的开发过程，却找不到任何一个地方需要用到 Docker，所以对于 Docker 他们常常认为这是一个负担。
说实话，Docker 跟前端开发并没有什么关系。反而 Docker 的引入对前端开发有了更多的要求，让前端开发者需要做开发流程之外的事情。
那为什么我们还是要使用 Docker ？
我就来说说我为什么要使用 Docker。
前端部署的各个阶段
前端部署之 FTP
以前，我们的项目是用 Angular ＋ grunt 的前端应用。我们将环境分为 develop、test、production 三个环境，对应不同的 API Url及配置。为了方面我们的部署，针对不同的环境我们做了不同的构建任务 例如：grunt build:develop 、grunt build:test 和 grunt build:production 。每次前端构建之后，将会生成一系列经过静态文件，将这些静态文件放到 Web 服务器服目录就可以被访问了。
每次需要上线前端项目，我都需要直连到服务器，把构建好的静态文件丢上去。简单粗暴，但是久而久之问题就来了：
- 直连服务器，安全肯定得不到保证。
- 不论哪个环境项目上线都需要我参与。也许让运维也学学前端，那么天下就太平了。
- 上线项目的方式不够灵活，有较大的局限。
前端部署之 Jenkins
后来，我司运维引进 Jenkins，据说能实现自动化部署，听着这个自动化就感觉高端大气上档次。不过我司运维话锋一转说配置较为复杂。我想复杂就复杂吧，通过 Jenkins 能实现自动化，解决之前的几个问题，能把我从无尽的运维中拯救出来，让我安安静静地做一个前端就好了。
我司运维经过了 git 访问权限配置、定时检测更新配置、更新脚本编写（也就十来行，不过我司运维与我共同写的），发现 Jenkins 就配置的差不多的，但是一运行就报错。他找不到问题，让我来看看。无奈发现当前主机没有前端构建需要的 node 和 grunt。也许让运维也学学前端，那么天下就太平了。怎么办，装呗。终于经历千辛万苦，我们的自动化流程跑起来了，每次我一上传代码，Jenkins 就能帮我把代码发布到环境上。感觉真好，简直是配置过一次就不想再配置第二次。但是奈何，我们当时的前端项目有 4 个，继续配置之。
配置好之后的 Jenkins 简直是可爱，帮我从无尽的运维之中解出来，我可以安静的做一个前端了。
但是好日子没过多久，随着项目的复杂度增加，相同项目在不同的分支上对第三方依赖的版本也略有些许区别，导致环境上前端展示的效果和开发展示的效果不同，一狠心，针对 develop 和 release（git 分支采用 gitflow）分支单独进行配置。但是前端项目有四个，还是都配置吧。这样子 4 * 2 ＝ 8（master 生产环境分支是单独配置的），简直了。自己挖的坑，哭着也要填完。
（番外：一个月后，服务器坏了，所有的配置的都需要重来一遍，也许让运维也学学前端，那么天下就太平了。）
说说好处：
- 通过 Jenkins 作为中转避免了直连服务器。
- Jenkins 实现了代码的自动化部署，只需提交代码便可上线环境。
- Jenkins 提供手动执行任务的功能和权限管理的能力。上线方式相当的灵活。
说说问题：
- Jenkins 配置繁琐，特别是多个项目多个分支都得配置的时候简直不能更丧心病狂。
- Jenkins 执行的命令都是依赖于本机环境，如果出现项目 A 依赖的 Node 版本是 0.10.10，项目 B 依赖的 Node 版本是 0.12.2，这个配置就更加复杂了。（我们后来对项目 A 的 Node 版本进行了升级。）
前端部署之 Docker
机缘巧合，我遇到了 Docker ，其实 Docker 和 Jenkins 可以搭配着使用解决上述 Jenkins 的一些问题，但是 Jenkins 给我的印象是在是太深刻，我直接放弃了，再加上市面上也有很多基于 Docker 的 CI/CD 工具使用起来都特别的方便，例如 Daocloud 和 Gitlab CI（相关链接中有两篇讲解如何搭建持续集成环境文章）。
Docker 是容器管理引擎，他的核心理念就是构建一次，可以运行在任何一个可以运行容器的地方。
当然引入 Docker 到我们的项目开发部署流程之中，我们在开发中也会做一些调整，根据项目来编写该项目的 Dockerfile。如果在本地能正常运行，再也不用担心在服务器上会有各种各样由环境不同引发的奇葩问题。由于 Docker Image 是标准的交付件，所以基于 Docker 自动化部署和自动化发布会变得非常方便，结合市面上的 Docker CI/CD 厂商，我们能非常方便地实现开发>测试>部署自动化。
引入 Docker 也许对前端开发没有帮助，甚至对前端开发来说是需要多掌握一门技能的负担，但是放眼前端开发及部署的整体流程，它将前端项目环境搭建的工作交给了前端，而不是运维。让最熟悉的人做最熟悉的事情，效率成倍提高。这也是我推崇用 Docker 部署前端的原因。
最后再用本文的核心来作为文章的总结：也许让运维也学学前端，那么天下就太平了。我们前端就不用这么折腾了。
相关链接