本站与您分享了使用docker部署前端应用程序的案例。希望你看完这篇文章有所收获。大家一起讨论一下。
码头工人越来越受欢迎。它可以隔离环境，扩大容量，方便运维管理。开发人员开发、测试和部署也更加方便。
最重要的是，当你面对一个奇怪的项目时，你可以通过遵循Dockerfile使它在本地快速运行，甚至不用看文档(文档不一定完整或正确)。
现在我非常强调devops的想法。我把五个字devops放在电脑桌面上，一天就学会了一切。突然，devops的意思是写一个Dockerfile来运行应用(开玩笑。
下面是如何使用Docker部署前端应用程序。千里之行，始于足下，即能先跑。
先让它跑起来
首先，简单介绍一个典型的前端应用部署流程
Npm安装，安装相关性
Npm运行构建、编译、打包和生成静态资源
服务静态资源
在介绍了部署过程之后，只需编写一个Dockerfile
FROMnode:alpine
#代表生产环境
ENVPROJECT_ENVproduction
工作目录/代码
添加。/code
runpminstallnpmrunbuildnpminstall-ghttp-服务器
曝光80
CMDhttp-服务器。/public-p80现在这个前端服务正在运行。然后，您可以完成部署的其他阶段。一般来说，以下是运维工作，但拓展你的知识边界总是对的。
使用nginx或traefik作为反向代理
使活动：慈云数据爆款香港服务器，CTG+CN2高速带宽、快速稳定、平均延迟10+ms 速度快，免备案，每月仅需19元！！ 点击查看用kubernetes或compose进行编辑。
使用gitlab ci或无人机ci作为配置项/光盘
此时镜像存在两个问题，导致部署时间过长，不利于产品的快速交付
建筑镜子的时间太长了
构建图像太大，1G
从 dependencies 和 devDependencies 下手
陆小凤说，如果一个前端程序员一天工作八个小时，至少浪费两个小时。一个小时用于npm安装，另一个小时用于npm运行构建。
对于每个部署，如果能减少无用包的下载，可以节省大量的映像构建时间。诸如eslint、mocha和chai这样的代码风格测试模块可以放入devDependencies中。在生产环境中使用npm安装-生产包装。
关于两者之间的区别，请参阅文件https://docs.npmjs.com/files/package.json.html#dependencies
FROMnode:alpine
ENVPROJECT_ENVproduction
工作目录/代码
添加。/code
runnminstall-productionnpmrunbuildnpminstal-ghttp-server
曝光80
CMDhttp-服务器。/public-p80好像快了一点。
我们注意到package.json相对于项目的源文件是比较稳定的。如果没有新的安装包可以下载，那么在重新构建映像时就不需要重新打包了。您可以节省一半的时间在npm安装。
利用镜像缓存
对于ADD，如果要添加的内容没有改变，可以使用缓存。将package.json从源文件中分离出来并写入映像是一个很好的选择。目前，如果没有新的安装包更新，可以节省一半的时间
FROMnode:alpine
ENVPROJECT_ENVproduction
# http-服务器可以在不改变的情况下利用缓存
runnminstall-ghttp-服务器
工作目录/代码
ADDpackage.json/code
运行安装-生产
添加。/code
RUNnpmrunbuild
曝光80
CMDhttp-服务器。/public-p80关于利润
用缓存有更多细节，需要特别注意一下，如 RUN git clone 的缓存此类
参考官方文档 https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#leverage-build-cache
多阶段构建
得益于缓存，现在镜像构建时间已经快了不少。但是，镜像的体积依旧过于庞大，也会增加每次的部署时间考虑下每次 CI 部署的流程
在构建服务器构建镜像
把镜像推至镜像仓库服务器，
在生产服务器拉取镜像，启动容器
显而易见，镜像体积过大造成传输效率低下，增加每次部署的延时。
即使，构建服务器与生产服务器在同一节点下，没有延时的问题。减少镜像体积也能够节省磁盘空间
关于镜像体积的过大，很大一部分是因为node_modules 臭名昭著的体积
但最后我们只需要 public 文件夹下的内容，对于源文件以及node_modules下文件，占用体积过大且不必要，造成浪费。此时可以利用 Docker 的多阶段构建，仅来提取编译后文件
参考官方文档 https://docs.docker.com/develop/develop-images/multistage-build/
FROMnode:alpineasbuilderENVPROJECT_ENVproduction#http-server不变动也可以利用缓存WORKDIR/codeADDpackage.json/codeRUNnpminstall--productionADD./codeRUNnpmrunbuild#选择更小体积的基础镜像FROMnginx:alpineCOPY--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，并加上永久缓存，不需要打入镜像
FROMnode:alpineasbuilderENVPROJECT_ENVproduction#http-server不变动也可以利用缓存WORKDIR/codeADDpackage.json/codeRUNnpminstall--productionADD./code#npmrunuploadCdn是把静态资源上传至cdn上的脚本文件RUNnpmrunbuild&&npmrunuploadCdn#选择更小体积的基础镜像FROMnginx:alpineCOPY--from=buildercode/public/index.htmlcode/public/favicon.ico/usr/share/nginx/html/COPY--from=buildercode/public/static/usr/share/nginx/html/static
看完了这篇文章，相信你对“使用docker部署前端应用的案例”有了一定的了解，如果想了解更多相关知识，欢迎关注亿速云行业资讯频道，感谢各位的阅读！
《使用docker部署前端应用的案例》来自互联网同行内容，若有侵权，请联系我们删除！
还没有评论，来说两句吧...