前端开发者的 Docker 之旅

[daocloud]

「 Docker 开发大礼包」已经到了第三季。

「JavaScript ：世界上最被误解的语言」这句话源于 JSON 的创建者 Douglas Crockford 的博客文章 「 JavaScript:
The World's Most Misunderstood Programming Language 」。 JavaScript 的前缀很容易使人联想到 Java ，并认为它是 Java 的子集或简化版的 Java 。看起来最初给它选这个名字是别有用心的，是故意混淆概念，故意制造「误解」的。

前端其实是一个非常古老的话题，它的故事几乎伴随着 Web 技术发展的各个阶段，也同样经历了跌宕起伏、涅槃重生的激荡三十年。毫不夸张的说，前端的演化历史和成功，是工程师不断突破桎梏、迈向本我的探索旅程。

前端出现在什么时候？

在 Web 技术出现的那一刻，前端一直伴随着 Web 技术的发展演化。可以说是 Web 技术的鼻祖。

前端是由什么语言组成的？

前端开发技术，从狭义的定义来看，是指围绕 HTML 、 JavaScript 、 CSS 这样一套体系的开发技术，它的运行宿主是浏览器。

前端最具代表性的技术革新在什么时候？

历史滚滚往前， 2004 年 Gmail 像风一样的女子来到人间，很快 2005 年 Ajax 正式提出，加上 CDN 开始大量用于静态资源存储，于是出现了 JavaScript 王者归来的 SPA （ Single Page Application 单页面应用）时代。

下一个 JavaScript 版本？

ECMAScript 2015 （亦称 ECMAScript Harmony ，简称 ES2015 ）

谁在主导前端的方向？

Facebook 、 Google

Angular 又是什么？

最好用的前端开发框架（仅代表 DaoCloud 意见）

前端的包依赖怎么做？

NPM

前端技术发展的下一阶段

Node 带来的全栈时代

常见的前端技术栈和应用场景？

2015 年某宝双十一访问到的所有 www 域页面（包括首页、频道、会场等）全部是一个全栈 node 应用支撑的（出处）。

前端运维部署

自动化构建，甚至利用 Nginx 层解决前端一些硬伤，发布 /回滚速度（包含编译）只需要 100s 发布到全部生产环境机器，供快速响应、迭代。

前端的烦恼

然而，前端代码的交付并不是 copy 和 paste 这么简单，代码发布之前的前端构建、跟测试和生产环境不同 API 的对接、 JS 代码混淆、不同发布分支的管理等等，这些体力劳动，每次发布时，都是挑起前端和运维团队大战的导火线。前端技术已经越发复杂，前端工程师并不希望把有限的生命花费在分发复杂应用的交付流程性的事物上！

那怎么破的，能教教吗？

上 Docker!

欢迎进入由 DaoCloud 推出的「 Docker 开发大礼包」第三季「前端应用 Docker 开发大礼包」，七篇由浅入深、精心设计的系列文章，将带领前端开发者领略 Docker 化应用开发和发布的全新体验。

• 运维也学学前端，那天下就太平了
• Hello Docker
• Docker 和 Node Express 应用
• 用 Docker 搭建 Angular 前端应用
• Angular 应用根据环境变量切换不同的后端 API
• Angular 应用根据环境变量切换不同的 CDN
• Angular 应用 Docker 启动加速

[bdbai]

V2 不缺资深前端，内容跨度这么大 几个意思？

[mzer0]

你们怎么解决 docker 的 systemctl 问题的?......

[allensun]

@mzer0 哈哈，行家啊

[djyde]

angular ，哈哈哈哈哈哈

[qgy18]

下一个 JavaScript 版本？

ECMAScript 2015 （亦称 ECMAScript Harmony ，简称 ES2015 ）
--------
ES2015 ，也就是 ES6 ，是当前版本。下一个版本是 ES7 了。

[mzer0]

@allensun 看来大家都被坑在 systemctl

[NemoAlex]

楼主发的这都是什么破玩意
有同感的吗

[Juggernaut]

还送 DOCKER 书籍吗

[jonnyhsy]

React 不服！

[hkongm]

楼主发的这都是什么破玩意
有同感的吗
@NemoAlex

[daocloud]

@NemoAlex 这是前端与 Docker 结合的系列文章。您可以在文末看到全部系列内容。

[daocloud]

@hkongm 这是前端与 Docker 结合的系列文章。您可以在文末看到全部系列内容。

[daocloud]

@Juggernaut 请时刻关注我们的官网微信和微博，有最新活动第一时间会推送。

[holyghost]

我就是想知道 docker 的 systemctl 现在有啥进展没有。

[hcymk2]

为什么要用 systemctl 在 docker 里面？

[phoneli]

@allensun
@mzer0
systemctl 有啥问题？

[jsq2627]

自家产品前端已经在用 angular+docker+daocloud 构架了

总体还不错，部署、迁移很方便，遇到的比较坑的问题有这些：

- 构建 Docker 镜像的时候没法设定环境变量。测试服和正式服需要不同的构建参数（ gulp 需要执行不一样的任务），在自动构建的时候没法区分。目前解决办法是默认按照正式服构建，在容器启动的时候如果检测到是测试服，那重新执行构建。

- DaoCloud 每次更新容器的镜像的时候，会有一小会（几秒到几十秒）的服务中断。即使对单个应用设置了容器个数>1 ，在重启的时候还是会全部同时重启的。如果可以容器分两批依次重启，中断时间也许会短一点。现在解决办法是用自有集群部署，似乎情况会好些（没有仔细观测，因为也不是非常在乎这几秒的中断）。

- 部署到 DaoCloud 云平台的时候，单个容器的配置比较低，有些应用可能根本跑不起来。产品用了 angularjs ，需要针对爬虫做预渲染，把 prerender.io 预渲染服务器封装到了 Docker 镜像中，如果部署到 DaoCloud 云平台，一个容器可能只能渲染三四个网页就提示 out of memory 崩溃了。现在解决办法是用接入自有集群。

- DaoCloud 的镜像构建服务器可选国内或海外，我们遇到了这样的问题：产品代码仓库使用的是 coding.net ，如果用海外服务器，发现从 coding.net 拉代码特别特别慢，如果用国内服务器， npm/bower 又不是很好使。解决办法是后来把代码仓库迁移到 GitHub 去了。

- 应用容器的镜像自动发布也不是非常好使。比如我们产品正式服想要在每一个新 tag 自动发布新镜像，测试服想要在 develop 分支每个新 commit 自动发布，现在是没法实现的。暂时只好设置仓库在每一个 commit 都重新构建，测试服自动发布最新构建，正式服手动发布。

[Reficul]

搭车同问，为什么 systemctl 坑？

用 systemctl 启动 docker 没问题啊， docker 里装 systemctl 感觉好像没必要啊。