从零搭建 Node Faas（三）编译部署

编译部署主要包含了将编写的 Function 编译为可执行代码，以及函数发布上线的过程。

一、整体流程

这是第一篇文章中出现过的图，其中分为两条线路。一条是通过 Faas 平台进行发布，因为 Live 的发布过程需要管控，所以这部分编译部署需要收拢到我们自己控制。这是第一条路径。

另一条是通过 CLI 进行发布，因为 Test 环境发布相对宽松，用户自己在本地编译好之后直接通过 CLI 发布可以更快的验证，这是第二条路径。

这篇文章也会从这两条编译路径去进行梳理。

二、Live 环境编译部署

1. Jenkins

这里把 Live 环境的编译放到了 Jenkins 中，这样就能自己管控编译过程。

1.1. Jenkins CLI

为了方便 Jenkins 调用，开发一套 Jenkins-CLI，用于 Jenkins 调用编译、部署等命令。

Jenkins-CLI 需要设计实现的命令：

clone：用于拉代码
build：用于编译
deploy：用于部署发布
status：用于设置部署状态

以上四个命令即可满足 Jenkins 的编译、部署需求。除此以外，配置一个 Sentry 服务，用于收集错误日志以及报警。Sentry 的配置我将放到下一篇文章 Faas 的服务治理中，里面会解释一下 Sentry 这一部分的配置。

1.2 Jenkins Pipeline

Live 环境编译部署过程最重要的就是 Jenkins 这个流程，首先需要在 Jenkins 中配置一个 pipeline，用于编译、部署、发布。

如下所示结构：

pipeline {
  agent {
    docker {
      image <镜像地址>
      args '-u 0 -v pnpm-cache:/root/.local/share/pnpm/store -v yarn-cache:/usr/local/share/.cache/yarn -v npm-cache:/root/.npm/_cacache'
      reuseNode true
      // ...
    }
  }
  stages {
    stage('Setup') {
      steps {
        // faas clone xxx
      }
    }

    stage('Build') {
      steps {
        // pnpm install
        // faas build
      }
    }

    stage('Deploy') {
      steps {
        // faas deploy
        // faas status success
      }
    }
  }

  post {
    success {
      // ...
    }
    failure {
      // ...
    }
    aborted {
      // ...
    }
    // Clean after build
    cleanup {
      cleanWs cleanWhenNotBuilt: false, deleteDirs: true, notFailBuild: true
    }
  }
}

这个 Jenkins Pipeline 有几个需要注意的优化点：

docker 镜像中挂载 volume 缓存，加速编译过程。你可以看到这里挂载了 pnpm、yarn、npm 的缓存目录。
reuseNode true，复用 Jenkins 节点，加速编译过程。
pnpm install 可以放到 Dockerfile 中，加速编译过程。
post 阶段，根据编译结果执行不同的操作，记录编译过程的错误。
cleanup 阶段配置，清理编译过程中产生的文件。

同时，为了方便 Pipeline Script 的更新，还可以把 Jenkins 配置为 Pipeline script from SCM，这样就可以把 Pipeline Script 放到代码仓库中，方便更新。

2. USS 上传

因为需要把编译产物在 server 上下载，并且把 function 存储到数据库中，所以需要将产物上传到 USS（对象存储）中。这里面有一个值得一提的就是分片上传。

如上图所示，以 5M 为一个分片，将文件分片并行上传到 USS 中，这样可以加速上传过程。

三、本地编译部署

本地编译部署过程相对宽松，因为不需要管控，所以可以直接通过 CLI 进行 Test 环境的发布。部署的逻辑同样使用 USS 上传，和 Live 环境无差别，此处不再赘述。重点讲一下 CLI 的编译过程。

1. 支持命令

login：登录
user：查看用户信息
app list：查看应用列表
build [function-name]：编译
deploy [function-name]：增量部署 / 全量部署
watch：监听文件变化，这里主要是用于本地调试，会在后面的 Faas 本地调试展开

以上几个命令就足以支持用户本地的编译部署需求。

2. 依赖编译

这里面有一个值得注意的点就是分析依赖关系。如下图所示：

函数（Function）可能引入 common 自己写的逻辑
函数（Function）可能第三方依赖
Common 可能引入第三方依赖
Common 可能引入 Common

预期：只保留 Common，不保留第三方依赖。

因为提供了指定依赖的 runtime，所以没有必要将第三方依赖打包进最终产物中。但是同时，需要保留 Common，因为 Common 是被 Funtion 引用的公共依赖。

2.1. 方案选型

有以下三个常见打包方案：

方案一：webpack + webpack-node-externals 插件✅

方案二：Tsc，没办法将产物编译到一个输出文件❌

方案三：Rollup，插件支持少，没办法区分打包❌

2.2. webpack 配置

webpack 配置如下所示：

return {
  mode: "production",
  target: "async-node18",
  entry,
  output: {
    clean: true,
    library: {
      type: "commonjs",
    },
    iife: false,
    filename: "[name]/index.js",
    path: options.dist,
  },
  module: {
    rules: [
      {
        test: /\.ts$/,
        use: {
          loader: require.resolve("ts-loader"),
        },
        exclude: /node_modules/,
      },
    ],
  },
  resolve: {
    extensions: [".ts", ".js"],
  },
  devtool: 'source-map',
  // All dependencies will not be packaged in
  externals: [nodeExternals()],
  externalsType: "commonjs",
  plugins,
}