您好,登录后才能下订单哦!
这篇文章主要介绍“怎么使用Docker高效部署前端应用”,在日常操作中,相信很多人在怎么使用Docker高效部署前端应用问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答”怎么使用Docker高效部署前端应用”的疑惑有所帮助!接下来,请跟着小编一起来学习吧!
先让它跑起来
首先,简单介绍一下一个典型的前端应用部署流程
npm install, 安装依赖
npm run build,编译,打包,生成静态资源
服务化静态资源,如 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 EXPOSE80 CMD http-server ./public -p 80
现在这个前端服务已经跑起来了,接下来你可以完成部署的其它阶段了。
一般情况下,以下就成了运维的工作了,不过,拓展自己的知识边界总是没错的。其它阶段介绍如下
使用 nginx 或者 traefik 做反向代理。在我内部集群中使用了 traefik,详见 traefik 简易入门
使用 kubernetes 或者 docker compose 做容器编排。在我内部集群中使用了 compose,详见 docker compose 简易入门
使用 gitlab ci,drone ci 或者 github actions 等做 CI/CD 自动部署。
这时镜像存在两个问题,导致每次部署时间过长,不利于产品的快速交付,没有快速交付,也就没有敏捷开发 (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 EXPOSE80 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 EXPOSE80 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 部署的流程
在构建服务器 (Runer) 构建镜像
把镜像推至镜像仓库服务器
在生产服务器拉取镜像,启动容器
显而易见,镜像体积过大会在前两步上传及下载时造成传输效率低下,增加每次部署的延时。
即使,构建服务器与生产服务器在同一节点下,没有延时的问题 (基本没可能)。减少镜像体积也能够节省磁盘空间。
关于镜像体积的过大,完全是因为node_modules 臭名昭著的体积:
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
到此,关于“怎么使用Docker高效部署前端应用”的学习就结束了,希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习,快去试试吧!若想继续学习更多相关知识,请继续关注亿速云网站,小编会继续努力为大家带来更多实用的文章!
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。