浅谈前端项目部署
常规情况下的前端部署
npm install
npm run build ----> ./dist/
mv dist AAA
把AAA文件夹放到服务器的一个某个目录/xxx/xxx/AAA
nginx.conf server 配置listen端口，配置root目录，配置location路径，和index主页、请求转发等。
以上部署方式的弊端
- 如果工程区分环境的话，如dev环境、test环境、prod环境，需执行不同的命令才可对应到指定的环境；如：在测试环境需执行npm run build:test，在开发环境需执行npm run build:dev。
- 除去打包工程时区分环境的不便，不同环境代码书写的偏差，由于开发环境只在dev不容易注意到其他环境的，且不容易测试出来。
如： /src/main.js if (process.env.NODE_ENV === 'production') { const { mockXHR } = require('../mock') mockXHR() } 以上代码不注释的话，会导致本地环境可以正常开发通过，上线后请求无效
引出一个思考
前端项目，是否可以一次编译，到处运行？
-—-— k8s
k8s
k8s全称kubernetes，为容器服务而生的一个可移植容器的编排管理工具。
k8s的演化史：
在容器技术之前，大家开发用虚拟机比较多，比如vmware和openstack，我们可以使用虚拟机在我们的操作系统中模拟出多台子电脑（Linux），子电脑之间是相互隔离的，但是虚拟机对于开发和运维人员而言，存在启动慢，占用空间大，不易迁移的缺点。
接容器化技术应运而生，它不需要虚拟出整个操作系统，只需要虚拟一个小规模的环境即可，而且启动速度很快，除了运行其中应用以外，基本不消耗额外的系统资源。Docker是应用最为广泛的容器技术，通过打包镜像，启动容器来创建一个服务。但是随着应用越来越复杂，容器的数量也越来越多，由此衍生了管理运维容器的重大问题。
随着云计算的发展，容器在漂移。在此业务驱动下，k8s问世，提出了一套全新的基于容器技术的分布式架构领先方案，在整个容器技术领域的发展是一个重大突破与创新。
前端部署k8s的自动化构建
提交dev分支后，可以在gitlab上的CI/CD看到当前的构建状态。
必要的话也可以阻断。
如果不想自动构建，则需修改commit内容
如：commit -m "[skip ci] XXXX"
在构建成功之后，在k8s的管理平台rancher上就可以看到发布的相关服务。
前端是单独的namespace：cec-fe
点击项目名称，进入到详情页，可以将镜像tag复制给测试人员来手动更新test环境
点击项目名称下的80/http可直接跳转到项目线上地址
前端项目部署---body属性模式
npm run build:prod
生成的dist文件中，往index.html的body标签上插入属性如
<body k8s_app_base_api="http://iam-console-test.cetest.com">
前端在引用到process.env.XXX之前获取对应的body属性
以上部署方式的弊端
- 在build之前不能获取document.body，也就不能拿到上面的变量。如vue.config.js 文件中使用 process.env.xx，只能通过build:xx传入变量，也就是build之后不能改变。
- 变量命名约定需严格保持一致。
- 改动前端业务代码，容易发生错误。
引出第二个思考
上面通过修改body属性的方案之所以不算完美，
是因为在build的传参已经影响了一部分使用了环境变量的场景。
-—-—如果在build时传入对应的环境变量
前端项目部署---环境变量模式
规范package.json里的scripts，为了统一的模版，4个环境的build参数都要包括，如果有某个环境配置目前无法确认，也要先用个默认的配置。
"build:dev": "vue-cli-service build --mode dev",
"build:test": "vue-cli-service build --mode test",
"build:pre": "vue-cli-service build --mode pre",
"build:prod": "vue-cli-service build",
该模式下，运维同学会先后如下命令
- npm set registry https://registry.npm.taobao.org
- npm install
- npm run build:dev
- mv dist dev
- npm run build:test
- mv dist test
- npm run build:pre
- mv dist pre
- npm run build:prod
- mv dist prod
此方案会生成 四个dist文件并分别命名为对应的环境 如 dev环境的dist被命名为dev， prod环境的dist被命名为prod。发布到k8s中的时候镜像会读取yaml文件里定制的node_env环境变量（动态替换）来将相对应的dist文件夹内的文件同步至nginx目录下。
该模式的好处：
- 是能够准确的区分指定环境对应的包文件，随用随读，需要什么环境都可以指定到对应的dist。
- 不需要前端改动业务代码，只需要完成package.json文件夹内的build:xxx命令，减少出错。
第三个思考
如果需要调整配置base_api等参数，
需在build前更改env.prod、env.dev等文件。
这些文件是否可以自动获取并更改？
-—thinking…
常见问题FAQ
- 免费下载或者VIP会员专享资源能否直接商用？
- 本站所有资源版权均属于原作者所有，这里所提供资源均只能用于参考学习用，请勿直接商用。若由于商用引起版权纠纷，一切责任均由使用者承担。更多说明请参考 VIP介绍。
- 提示下载完但解压或打开不了？
- 找不到素材资源介绍文章里的示例图片？
- 模板不会安装或需要功能定制以及二次开发？
发表评论
还没有评论，快来抢沙发吧！