使用 Shipit 来自动化部署 Node 应用

之前一直想为 node 的发布整理出一个流程，但一直没有太多实践，后来就忙给忘却了，不过最近做了几个小东西，每次发布都要登陆服务器，终于下决心自动化这个流程。

项目结构

Node 的项目结构是这样子的，可参考 github: Koa2-Boilerplate

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
├── app
│   ├── apis
│   ├── models
│   └── services
├── bin
├── config
│   ├── application.yml
│   └── database.yml
├── lib
│   └── middleware
├── Dockerfile
├── docker-compose.yml
├── process.yml
├── shipitfile.js
└── package.json

## 整理现在的发布流程

目前仍有 ES Module 不是 Node 支持，所以发布时需要 build 生成发布代码，然后将发布用的代码放到服务器，通过 pm2 启动，或构建 Docker 镜像。

为此，我们构建了两个 repo：

  1. 项目的源码，编译后，生成 dist 为发布用的代码
  2. 编译后的代码，包含各种配置文件，dockerfile, docker-compose 文件。

流程：

  • 源码项目更新，然后 build 出 dist 目录
  • 将 dist 复制到 发布项目，然后迁入 git
  • 服务器拉取发布 git
  • Docker build
  • Docker run

小的项目中，如果不需要对 docker 进行版本说明，以上流程将是一个很简单的事。

如果想要自动化的话，就需要考虑以下两个构建步骤：

  • 代码构建服务器：因为是小的项目，可以不需要中间的构建服务器，直接由本机的另一个路径，或者是服务器的一个路径来承担，建议放在本机，这样服务器就不需要 node 相关的软件了。
  • Docker 构建服务器：docker image 一定要在远程服务器本机处理的，不然传输成本就太高了，这就要求构建服务器，

## 什么是 Shipit？

Shipit 是一个用 Node 写的自动化引擎，也是一个发布工具。

说白点就是 Universal automation and deployment tool，通用自动化部署工具而已。

和 Capistrano 对比

作为 Capistrano 的 Node 版，有什么区别：

Capistrano

  • Ruby 语言（这个对我来说没问题）
  • 在服务器端拉代码，然后进行 build 的。
  • 插件多，社区完善。

Shipit

  • Pure JavaScript，在 Node 上体验会更好。
  • 本地拉取 git repo，本地打包（好处是服务器上不需要配置 node.js 了），然后 rsync 指定目录到 Server
  • 3个月未更新。
  • 支持的插件少，但可以自己写，很简单。

对比完这些，觉得还是 Shipit 更适合一些。


## Shipit Configuration

接下来，就在本机尝试安装和配置 Shipit。

安装

1
2
$ npm install --global shipit-cli
$ npm install --save-dev shipit-cli shipit-deploy shipit-shared

Create a shipitfile.js

Shipit 的运行依赖于配置文件，在项目的根目录，创建 shipitfile.js 就可以开始了。

一个简单的示例（为 staging 环境配置一台远程服务器，并新建一个叫 pwd 的 task）：

1
2
3
4
5
6
7
8
9
10
11
module.exports = function (shipit) {
  shipit.initConfig({
    staging: {
      servers: 'root@project.com'
    }
  });

  shipit.task('pwd', function () {
    return shipit.remote('pwd');
  });
};

这时，就可以通过以下命令 shipit+服务器+task 来运行了。

1
$ shipit staging pwd

## 发布实战：

基于 shipit-deploy 的发布流程

当然一个完整的发布流程，会有多个 task 进行顺序执行，而 shipit 自身也只是定位于一个编排引擎，它提供了 task 的组合能力（基于: Orchestrator）同时，还提供了钩子的能力，能在一些 task 前后加入自己的task(event)，这称为 Emit，接下来会用到这些功能。

我们完全有能力基于这些编排组合能力和钩子实现发布的所有流程，但重复从来都是应当被吐槽的。社区也早有一些最佳实践，shipit-deploy 就是 shipit 自己做的一个发布实践。

利用它可以很快速的完成自己的发布流程，同时，它也提供了大量的 Emitter，供我们进行扩展。

更多的可以查看官方文档：

实际项目 deploy 的扩展

对比下 shipit-deploy 的 task flow，我们需要的是在 fetch 完代码后加入以下流程：

  • npm install
  • npm run build

通过 emit 就可以实现，代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
shipit.blTask('npm-install', function () {
  shipit.log('yarn install.');
  return shipit.local('yarn install', { cwd: '/tmp/app-koa2boilerplate' })
});

shipit.blTask('npm-build', function () {
  shipit.log('npm build start.');
  return shipit.local('npm run build', { cwd: '/tmp/app-koa2boilerplate' })
});

shipit.on('fetched', function () {
  console.log('itis npm build');
  shipit.start(['npm-install', 'npm-build']);
});

运行以下命令，就能完成代码获取，构建，发布代码到 Server 上的流程。

1
$ shipit staging deploy

真实的启动流程

经过上面的步骤，可用于线上发布的代码已被放置在服务器上了。那项目中的一些被 gitignore 的配置文件呢。

请看下面两篇：


REF:: ---