袋鼠云前端项目发布工具dtux-kangaroo

摘要：每家公司在前端项目发布体系可能不尽相同，本篇文章仅仅介绍袋鼠云的前端发布体系，希望能对大家能有所启发。目前袋鼠云采用的是前后端分离的方式，但是开发中还是比较依赖后端的，接口数据还不是很完善。

在目前的大趋势下，前端和后端解耦已经是一个业界的趋势。前端和后端一旦解耦之后，前端的项目和后端的项目便可以自己发布，互不影响。这样极大地提高工作效率，免去了很多互相等待的时间。每家公司在前端项目发布体系可能不尽相同，本篇文章仅仅介绍袋鼠云的前端发布体系，希望能对大家能有所启发。

项目地址： https://github.com/ruichengpi...

首先说一下整个前端这边的运行流程，一般浏览器请求我们大致分为两条线资源请求和接口请求。下面我们以这两个线说一下整个流程：

1. 资源请求： 这边我们Nginx服务器跟我们前端打包出来资源都是放在同一台机器上。Nginx设置一下我们静态资源的目录，浏览器的资源请求都会从这个静态资源目录中获取，我们本地往远程机器推送前端资源也是在这个目录下。

2. 接口请求： 浏览器的所有接口请求都会被我们远程机器上的Nginx拦截,然后路径规则匹配代理相应的接口服务上。

这边以Centos为例为例：

yum install nginx

这里有个需要注意的是，我们要尽量保证nginx全局命令是可用，有不少公司nginx命令不是全局的，如何在对应的roo.config.js中做一下设置，后面我们会讲到。

这里我们需要设定一下三个目录：

前端资源存放目录 例如：/root/app

前端项目nginx配置存放目录 例如：/root/nginx

前端资源备份目录 例如：/root/backup

设置一下nginx配置文件，一般来说是/etc/nginx/nginx.conf。当然根据每个公司不同情况找到对应的配置文件

...
http{
    include /root/nginx/*.conf;  
}
...

include /root/nginx/*.conf;

这句话表示/root/nginx下所有以.conf结尾的文件都会被加载进来，而/root/nginx是我们所设定的nginx配置文件存放目录。

nginx -c /etc/nginx/nginx.conf  //启动nginx，并确定前面配置是否正确

上面命令仅作参考，具体根据情况来定。

我们访问资源的时候有些人会遇到nginx抛出403 Forbidden的情况，这是是因为我们nginx配置文件最上面的user设置的用户权限不够，可以改成user root来解决。

以下四个功能均支持-c或者--config指定配置文件.如果未指定配置文件，则默认在项目根目录下去roo.config.js作为配置文件。

该命令用于备份我们的前端资源包，这样有利于我们做版本的管理。当线上出现重大问题的时候，可以及时拿过来做版本回滚。

执行roo backup命令，如果设置了NODE_ENV=production则会在远程机器上的backupDirectory里生成一个“production_YYYYMMDD”的前端资源包，若未设置则生成一个
“test_YYYYMMDD”的前端资源包，其中YYYYMMDD为当天的年月日，当天上传多次也只会生成一个包，后续上传的将会覆盖之前上传的前端资源。

以下为必须配置项：

roo.config.js

module.exports={
  local:{
    resourceDirectory:"<本地前端资源所在目录，该目录下的内容将会全部上传>"
  },
  origin:{
    host:"<远程机器IP>",
    username: "<远程机器用户名>",
    password: "<远程机器密码>",
    backupDirectory:"<远程机器备份前端资源的目录>"
  }
}

该命令用于生成项目对应的nginx配置文件，并更新线上的nginx配置文件。执行roo nginx文件之后，会在roo.config.js中指定的local.nginxConfigFilePath生成对应的nginx配置文件，并更新远程机器上的roo.config.js中指定的origin.nginxConfigFilePath的nginx配置文件，然后执行nginx的reload操作。

以下为必须配置项：

roo.config.js

module.exports={
  local:{
     nginxConfigTemplate:""
     nginxConfigFilePath:""
  },
  origin:{
    host:"<远程机器IP>",
    username: "<远程机器用户名>",
    password: "<远程机器密码>",
    nginxConfigFilePath:"<远程机器上该项目的nginx配置文件的路径，此文件将会被nginx主文件include>"    
  },
//nginxConfig里的参数将用于生成本项目的nginx配置文件
  nginxConfig:{
    port:"<开放端口>",
    serverName："<服务名称>",
    publicPath:"<静态资源目录>"，
    //locations将对于nginx里面的location
    locations:[
        {
            path:"<匹配路径>",
            //对应location中的配置项
            configs:[
                {
                    key:"proxy_redirect",
                    value:"off"
                },
                {
                    key:"proxy_set_header",
                    value:"Host $host"
                },
                {
                    key:"proxy_pass",
                    value:"代理路径"
                },
            ]
        }
    ]
  }
}

默认nginx配置文件模板

server {
  listen       {{port}};
  server_name  {{serverName}};
  location / {
    root        {{publicPath}};
    try_files $uri /index.html;
    location ~ .*.(ico|js|css|gif|jpg|jpeg|png|bmp|swf)$ {}
  }
  {{#each locations}}
  location {{this.path}} {
    {{#each this.configs}}
    {{this.key}} {{this.value}};
    {{/each}}
  }
  {{/each}}
}

该命令用于检查远程机器的端口占用情况。

-p 或者 --port | 会检测该端口是否占用，若占用会显示相关使用情况

roo port  // 会拉取远程机器上所有已占用的端口情况

roo port -p 8000  //检测8000端口是否占用，若占用显示被使用情况

以下为必须配置项：

roo.config.js

module.exports={
    origin:{
        host:"<远程机器IP>",
        username: "<远程机器用户名>",
        password: "<远程机器密码>"
    }
}

该命令将roo.config.js文件中local.resourceDirectory指定的前端资源目录内的资源上传到origin.resourceDirectory目录下。origin.resourceDirectory指定的目录也会跟nginxConfig.publicPath指定的目录相对应。

以下为必须配置项：

roo.config.js

module.exports={
    local:{
        resourceDirectory:"<本地前端资源所在目录，该目录下的内容将会全部上传>"
    }    
    origin:{
        host:"<远程机器IP>",
        username: "<远程机器用户名>",
        password: "<远程机器密码>",
        resourceDirectory:"<远程机器存在前端资源的目录，上传的前端资源将会存在这里>",
        nginxConfigFilePath:"<远程机器上该项目的nginx配置文件的路径，此文件将会被nginx主文件include>"  
    }
}

module.exports={
  local:{
    resourceDirectory:"<本地前端资源所在目录，该目录下的内容将会全部上传>",
    nginxConfigFilePath:""
  },
  origin:{
    host:"<远程机器IP>",
    username: "<远程机器用户名>",
    password: "<远程机器密码>",
    resourceDirectory:"<远程机器存在前端资源的目录，上传的前端资源将会存在这里>",
    backupDirectory:"<远程机器备份前端资源的目录>"
    nginxConfigFilePath:"<远程机器上该项目的nginx配置文件的路径，此文件将会被nginx主文件include>"    
  },
 //nginxConfig里的参数将用于生成本项目的nginx配置文件
  nginxConfig:{
    port:"<开放端口>",
    serverName："<服务名称>",
    publicPath:"<静态资源目录>"，
    //locations将对于nginx里面的location
    locations:[
        {
            path:"<匹配路径>",
            //对应location中的配置项
            configs:[
                {
                    key:"proxy_redirect",
                    value:"off"
                },
                {
                    key:"proxy_set_header",
                    value:"Host $host"
                },
                {
                    key:"proxy_pass",
                    value:"代理路径"
                },
            ]
        }
    ]
  }
}

目前袋鼠云这边的项目构建工具采用的是Yeoman的构建体系，可以满足袋鼠云这边对项目构建的需求。但是有点小小不足的地方，就是每次项目模板更新之后都要重新发布Yeoman的脚手架，灵活性相对较差。后面打算把项目的生成的工作交给dtux-kangaroo，并且所有项目模板均放在github上，每次生成项目都会从github重新拉，模板贡献者只需要关注自己的github仓库即可，只要将更新合并到master分支上，后续项目生成均会提到更新。当然在现有的Yeoman的脚手架改造也可以实现同样的功能，但是本着工具精简的原则，会将现有的Yeoman的脚手架迁到dtux-kangaroo并进行改造。

目前袋鼠云采用的是前后端分离的方式，但是开发中还是比较依赖后端的，接口数据mock还不是很完善。后面计划加入roo mock来解决数据mock问题，初步想法是借助后端的swagger来实现接口数据mock。

dtux-kangaroo已经验证了这套发布体系的可行性，也解决了如何与远程机器的交互的问题。为前端资源发布平台的搭建打下很好的基础。后面计划搭建这个前端资源发布平台，提高前端资源发布的效率，减少对运维的依赖。