让运维也学学前端,那天下就太平了

让运维也学学前端,那天下就太平了

目标:定义 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 服务器服目录就可以被访问了。

每次需要上线前端项目,我都需要直连到服务器,把构建好的静态文件丢上去。简单粗暴,但是久而久之问题就来了:

  1. 直连服务器,安全肯定得不到保证。
  2. 不论哪个环境项目上线都需要我参与。也许让运维也学学前端,那么天下就太平了。
  3. 上线项目的方式不够灵活,有较大的局限。

前端部署之 Jenkins

后来,我司运维引进 Jenkins,据说能实现自动化部署,听着这个自动化就感觉高端大气上档次。不过我司运维话锋一转说配置较为复杂。我想复杂就复杂吧,通过 Jenkins 能实现自动化,解决之前的几个问题,能把我从无尽的运维中拯救出来,让我安安静静地做一个前端就好了。

我司运维经过了 git 访问权限配置、定时检测更新配置、更新脚本编写(也就十来行,不过我司运维与我共同写的),发现 Jenkins 就配置的差不多的,但是一运行就报错。他找不到问题,让我来看看。无奈发现当前主机没有前端构建需要的 node 和 grunt。也许让运维也学学前端,那么天下就太平了。怎么办,装呗。终于经历千辛万苦,我们的自动化流程跑起来了,每次我一上传代码,Jenkins 就能帮我把代码发布到环境上。感觉真好,简直是配置过一次就不想再配置第二次。但是奈何,我们当时的前端项目有 4 个,继续配置之。

配置好之后的 Jenkins 简直是可爱,帮我从无尽的运维之中解出来,我可以安静的做一个前端了。

但是好日子没过多久,随着项目的复杂度增加,相同项目在不同的分支上对第三方依赖的版本也略有些许区别,导致环境上前端展示的效果和开发展示的效果不同,一狠心,针对 develop 和 release(git 分支采用 gitflow)分支单独进行配置。但是前端项目有四个,还是都配置吧。这样子 4 * 2 = 8(master 生产环境分支是单独配置的),简直了。自己挖的坑,哭着也要填完。

(番外:一个月后,服务器坏了,所有的配置的都需要重来一遍,也许让运维也学学前端,那么天下就太平了。)

说说好处:

  1. 通过 Jenkins 作为中转避免了直连服务器。
  2. Jenkins 实现了代码的自动化部署,只需提交代码便可上线环境。
  3. Jenkins 提供手动执行任务的功能和权限管理的能力。上线方式相当的灵活。

说说问题:

  1. Jenkins 配置繁琐,特别是多个项目多个分支都得配置的时候简直不能更丧心病狂。
  2. 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 部署前端的原因。

最后再用本文的核心来作为文章的总结:也许让运维也学学前端,那么天下就太平了。我们前端就不用这么折腾了。

相关链接