浅谈前端项目部署

常规情况下的前端部署

  npm install
  npm run build ----> ./dist/
  mv dist AAA
  把AAA文件夹放到服务器的一个某个目录/xxx/xxx/AAA
  nginx.conf server 配置listen端口，配置root目录，配置location路径，和index主页、请求转发等。复制代码

以上部署方式的弊端

  1. 如果工程区分环境的话，如dev环境、test环境、prod环境，需执行不同的命令才可对应到指定的环境；如：在测试环境需执行npm run build:test，在开发环境需执行npm run build:dev。
  2. 除去打包工程时区分环境的不便，不同环境代码书写的偏差，由于开发环境只在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属性复制代码

以上部署方式的弊端

  1. 在build之前不能获取document.body，也就不能拿到上面的变量。如vue.config.js 文件中使用 process.env.xx，只能通过build:xx传入变量，也就是build之后不能改变。
  2. 变量命名约定需严格保持一致。
  3. 改动前端业务代码，容易发生错误。

引出第二个思考

  上面通过修改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目录下。

该模式的好处：

  1. 是能够准确的区分指定环境对应的包文件，随用随读，需要什么环境都可以指定到对应的dist。
  2. 不需要前端改动业务代码，只需要完成package.json文件夹内的build:xxx命令，减少出错。

第三个思考

如果需要调整配置base_api等参数，
需在build前更改env.prod、env.dev等文件。
这些文件是否可以自动获取并更改？

            -—thinking…复制代码