前端高级进阶：使用 docker 高效部署你的前端应用

这是山月关于高级前端进阶暨前端工程系列文章的第 M 篇文章 (M 随便打的，毕竟也不知道能写多少篇)，关于前 M-1 篇文章，能够从个人 github repo shfshanyue/blog 中找到，若是点进去的话能够捎带~点个赞~，若是没有点进去的话，那就给这篇文章点个赞。

本篇文章地址在 前端工程化系列，欢迎订阅。

1. 前端高级进阶：javascript 代码是如何被压缩
2. 前端高级进阶：如何更好地优化打包资源
3. 前端高级进阶：网站的缓存控制策略最佳实践及注意事项
4. 前端高级进阶：在生产环境中使你的 npm i 速度提高 50%
5. 前端高级进阶：使用 docker 高效部署你的前端应用

---

我在 github 上新建了一个仓库 每日一题，天天一道面试题，欢迎交流。

• 前端面试题小记
• 前端大厂面经大全集
• 计算机基础面试题小计

---

Docker 变得愈来愈流行，它能够轻便灵活地隔离环境，进行扩容，运维管理。对于业务开发者而言，随着持续集成的发展，对代码质量及快速迭代的要求也愈来愈高。

对于前端而言，在 CI 环境中使用也更容易集成开发，测试与部署。好比能够为流水线(Pipeline)设置 Lint/Test/Security/Audit/Deploy/Artifact 等任务，更好地把控项目质量。

如今不管是前端，后端仍是运维，都很强调 devops 的理念，接下来我将会写一系列关于 devops 在前端中应用的文章。你能够在个人博客 https://github.com/shfshanyue... 中或者个人公众号 【全栈成长之路】中订阅更多文章。

这里将介绍如何使用 Docker 部署前端应用，千里之行，始于足下。始于足下的意思就是，先让它可以跑起来。

先让它跑起来

首先，简单介绍一下一个典型的前端应用部署流程

1. npm install, 安装依赖
2. npm run build，编译，打包，生成静态资源
3. 服务化静态资源，如 nginx

介绍完部署流程后，简单写一个 Dockerfile

FROM node:10-alpine

# 表明生产环境
ENV PROJECT_ENV production

# 许多 package 会根据此环境变量，作出不一样的行为
# 另外，在 webpack 中打包也会根据此环境变量作出优化，可是 create-react-app 在打包时会写死该环境变量
ENV NODE_ENV production

WORKDIR /code
ADD . /code
RUN npm install && npm run build && npm install -g http-server
EXPOSE 80

CMD http-server ./public -p 80

如今这个前端服务已经跑起来了，接下来你能够完成部署的其它阶段了。

通常状况下，如下就成了运维的工做了，不过，拓展本身的知识边界老是没错的。其它阶段介绍以下

• 使用 nginx 或者 traefik 作反向代理。在我内部集群中使用了 traefik，详见 traefik 简易入门
• 使用 kubernetes 或者 docker compose 作容器编排。在我内部集群中使用了 compose，详见 docker compose 简易入门
• 使用 gitlab ci，drone ci 或者 github actions 等作 CI/CD 自动部署。在我内部集群中使用了 github actions，详见 github actions 简易入门

这时镜像存在两个问题，致使每次部署时间过长，不利于产品的快速交付，没有快速交付，也就没有敏捷开发 (Agile)

• 构建镜像时间过长
• 构建镜像大小过大，多时甚至 1G+

利用镜像缓存

咱们注意到，相对于项目的源文件来说，package.json 是相对稳定的。若是没有新的安装包须要下载，则再次构建镜像时，无需从新构建依赖。则能够在 npm install 上节省一半的时间。

对于 ADD 来说，若是须要添加的文件内容的 checksum 没有发生变化，则能够利用缓存。把 package.json/package-lock.json 与源文件分隔开写入镜像是一个很好的选择。目前，若是没有新的安装包更新的话，能够节省一半时间

FROM node:10-alpine

ENV PROJECT_ENV production
ENV NODE_ENV production

# http-server 不变更也能够利用缓存
RUN npm install -g http-server

WORKDIR /code

# 首次添加此两个文件，充分利用缓存
ADD package.json package-lock.json /code
RUN npm install --production

ADD . /code
RUN npm run build
EXPOSE 80

CMD http-server ./public -p 80

关于利用缓存有更多细节，须要特别注意一下。如 RUN git clone <repo>，若是命令字符串没有更新，则将使用缓存，当命令是非幂等性时，这将有可能致使问题。

关于缓存及可能致使的问题，能够参考个人文章 Dockerfile 最佳实践

CI 环境下的优化

FROM node:10-alpine

ENV PROJECT_ENV production
ENV NODE_ENV production

# http-server 不变更也能够利用缓存
RUN npm install -g http-server

WORKDIR /code

# 首次添加此两个文件，充分利用缓存
ADD package.json package-lock.json /code
RUN npm ci

ADD . /code
RUN npm run build
EXPOSE 80

CMD http-server ./public -p 80

在 CI 环境下主要作了一点改动：使用 npm ci 代替 npm i，经实验，npm ci 能够减小将近一半的的依赖安装时间。

$ npm install
added 1154 packages in 60s

$ npm ci
added 1154 packages in 35s

另外，当 package.json 与 package-lock.json 版本不匹配时，npm ci 将会报出异常，提早检测出不安全信息，及早发现问题，及早解决问题。

多阶段构建

得益于缓存，如今镜像构建时间已经快了很多。可是，此时镜像的体积依旧过于庞大，这也将会致使部署时间的加长。缘由以下

考虑下每次 CI/CD 部署的流程

1. 在构建服务器 (Runer) 构建镜像
2. 把镜像推至镜像仓库服务器
3. 在生产服务器拉取镜像，启动容器

显而易见，镜像体积过大会在前两步上传及下载时形成传输效率低下，增长每次部署的延时。

即便，构建服务器与生产服务器在同一节点下，没有延时的问题 (基本没可能)。减小镜像体积也可以节省磁盘空间。

关于镜像体积的过大，彻底是由于node_modules 臭名昭著的体积:

但最后咱们只须要构建生成的静态资源，对于源文件以及 node_modules 下文件，占用体积过大且没必要要，形成浪费。

此时能够利用 Docker 的多阶段构建，仅来提取编译后文件，即打包生成的静态资源，对 Dockerfile 作一改进

FROM node:10-alpine as builder

ENV PROJECT_ENV production
ENV NODE_ENV production

# http-server 不变更也能够利用缓存
WORKDIR /code

ADD package.json package-lock.json /code
RUN npm ci

ADD . /code
RUN npm run build

# 选择更小体积的基础镜像
FROM nginx:10-alpine
COPY --from=builder /code/public /usr/share/nginx/html

此时，镜像体积从 1G+ 变成了 50M+。若此时的部署仅仅是在测试环境或者多分支环境下为了方便测试，那就大功告成，完美解决问题了。

使用对象存储服务 (OSS)

分析一下 50M+ 的镜像体积，nginx:10-alpine 的镜像是16M，剩下的40M是静态资源。生产环境的静态资源每每会在独立域名上维护，并使用 CDN 进行加速。

若是把静态资源给上传到文件存储服务，即OSS，并使用 CDN 对 OSS 进行加速，则没有必要打入镜像了。而在生产环境下也有对静态资源上 CDN 的强烈需求。

此时镜像大小会控制在 20M 如下。虽然极大地减少了镜像体积，可是它会增长复杂度与增长镜像构建时间(如上传到OSS)，对于测试环境或者分支环境不必使用 OSS。

关于静态资源，能够分类成两部分：

• /build，此类文件在项目中使用 require/import 引用，会被 webpack 打包并加 hash 值，并经过 publicPath 修改资源地址。能够把此类文件上传至 oss，并加上永久缓存，不须要打入镜像
• /static，此类文件在项目中直接引用根路径，直接打入镜像，若是上传至 OSS 可能增长复杂度 (批量修改 publicPath)

此时经过一个脚本命令 npm run uploadOss，来把静态资源上传至 OSS。更新后的 Dockerfile 以下

FROM node:10-alpine as builder

ENV PROJECT_ENV production
ENV NODE_ENV production

# http-server 不变更也能够利用缓存
WORKDIR /code

ADD package.json package-lock.json /code
RUN npm ci

ADD . /code

# npm run uploadOss 是把静态资源上传至 oss 上的脚本文件
RUN npm run build && npm run uploadOss

# 选择更小体积的基础镜像
FROM nginx:10-alpine
COPY --from=builder code/public/index.html code/public/favicon.ico /usr/share/nginx/html/
COPY --from=builder code/public/static /usr/share/nginx/html/static

小结

通过本篇文章总结，在前端中构建镜像须要注意如下几点

1. 镜像中使用基于 alpine 的镜像，减少镜像体积。
2. 镜像中须要锁定 node 的版本号，尽量也锁定 alpine 的版本号，如 node:10.19-alpine3.11。(我示例代码中未如此详细地指出)
3. 选择合适的环境变量 NODE_ENV 及 PROJECT_ENV，如在测试环境下进行构建
4. npm ci 替代 npm i，避免版本问题及提升依赖安装速度
5. package.json 单独添加，充分利用镜像缓存
6. 使用多阶段构建，减少镜像体积
7. 若有必要，静态资源请上 CDN

与我交流

扫码添加个人机器人微信，将会自动（自动拉人程序正在研发中）把你拉入前端高级进阶学习群

推荐一个关于大厂招聘的公众号【互联网大厂招聘】，做者将在公众号里持续推送各个大厂的招聘职位及要求，并与大厂面试官以及招聘负责人直通，感兴趣的能够直接与负责人交流。

另外，做者也将持续推送优质的大厂面试经验，各类大厂独家面试题以及优秀文章分享，不限于前端，后端，运维和系统设计。

我在 github 上新建了一个仓库 每日一题，天天一道面试题，欢迎交流。

• 前端面试题小记
• 计算机基础面试题小计