使用 docker 高效部署前端应用

docker 变得愈来愈流行，它能够轻便灵活地隔离环境，进行扩容，方便运维管理。对开发者也更方便开发，测试与部署。

最重要的是，当你面对一个陌生的项目，你能够照着 Dockerfile，甚至不看文档(文档也不必定全，全也不必定对)就能够很快让它在本地跑起来。

如今很强调 devops 的理念，我把 devops 五个大字放在电脑桌面上，格物致知了一天。豁然开朗，devops 的意思就是写一个 Dockerfile 去跑应用(开玩笑。

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

• 原文地址: 如何使用 docker 高效部署前端
• 系列文章: 当我有一台云服务器时我作了什么

若是对你可以有所帮助，能够帮我在 shfshanyue/op-note 上点个 star。

先让它跑起来

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

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

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

FROM node: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 作反向代理
• 使用 kubernetes 或者 compose 等作编排。
• 使用 gitlab ci 或者 drone ci 等作 CI/CD

这时镜像存在有两个问题，致使每次部署时间过长，不利于产品的快速交付

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

从 dependencies 和 devDependencies 下手

陆小凤说过，一个前端程序员如果天天工做八个小时，至少有两个小时是白白浪费了的。一个小时用来 npm install，另外一个小时用来 npm run build。

对于每次部署，若是可以减小无用包的下载，便可以节省不少镜像构建时间。eslint，mocha，chai 等代码风格测试模块能够放到 devDependencies 中。在生产环境中使用 npm install --production 装包。

关于二者的区别能够参考文档: https://docs.npmjs.com/files/...

FROM node:alpine

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

CMD http-server ./public -p 80

好像是快了那么一点点。

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

利用镜像缓存

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

FROM node:alpine

ENV PROJECT_ENV production
ENV NODE_ENV production

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

WORKDIR /code

ADD package.json /code
RUN npm install --production

ADD . /code
RUN npm run build
EXPOSE 80

CMD http-server ./public -p 80

关于利用缓存有更多细节，须要特别注意一下，如 RUN git clone <repo> 的缓存此类

参考官方文档 https://docs.docker.com/devel...

多阶段构建

得益于缓存，如今镜像构建时间已经快了很多。可是，镜像的体积依旧过于庞大，也会增长每次的部署时间

考虑下每次 CI 部署的流程

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

显而易见，镜像体积过大形成传输效率低下，增长每次部署的延时。

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

关于镜像体积的过大，很大一部分是由于node_modules 臭名昭著的体积

但最后咱们只须要 public 文件夹下的内容，对于源文件以及node_modules下文件，占用体积过大且没必要要，形成浪费。

此时能够利用 Docker 的多阶段构建，仅来提取编译后文件

参考官方文档 https://docs.docker.com/devel...

FROM node:alpine as builder

ENV PROJECT_ENV production
ENV NODE_ENV production

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

ADD package.json /code
RUN npm install --production

ADD . /code
RUN npm run build

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

此时，镜像体积从 1G+ 变成了 50M+

使用 CDN

分析一下 50M+ 的镜像体积，nginx:alpine 的镜像是16M，剩下的40M是静态资源。

若是把静态资源给上传到 CDN，则没有必要打入镜像了，此时镜像大小会控制在 20M 如下

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

• /static，此类文件在项目中直接引用根路径，打包时复制进 /public 下，须要被打入镜像
• /build，此类文件须要 require 引用，会被 webpack 打包并加 hash 值，并经过 publicPath 修改资源地址。能够把此类文件上传至 cdn，并加上永久缓存，不须要打入镜像

FROM node:alpine as builder

ENV PROJECT_ENV production
ENV NODE_ENV production

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

ADD package.json /code
RUN npm install --production

ADD . /code

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

# 选择更小体积的基础镜像
FROM nginx: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

---

欢迎关注公众号山月行，我会按期分享一些先后端以及运维的文章，而且会有技术与生活上的每日回顾与总结，欢迎关注交流