基于WebHook实现Gitee自动化部署

大纲

1.起因和思路

2.WebHooks服务

3.自动化部署脚本

4.配置和完成

1.起因和思路

前段时间在写一个小的Web项目, 部署到了租的云服务器上, 后续也进行了一些开发和优化, 每次开发完都要进行手动登录服务器部署, 感觉整个过程有点麻烦, 就想实现一个简化的自动化部署流程.

目前自动化部署主要有两种方式

通过项目下的增加CI配置的方式触发, 使用Runner服务执行 (类似GitLab CI的方式, 在项目里增加 .gitlab-ci.yml 文件)
通过WebHook事件请求, 发送到专门的CI/CD服务进行处理 (像Jenkins)

看了Gitee目前支持的方式, 第一种一般需要付费, 或者是用三方服务, 登录私有服务器执行命令; 第二种方式应该更合适我, 不过我不需要太复杂的功能.

目前来说, 简单流程就是:

Gitee收到git提交事件, 发送WebHook请求到WebHook服务
WebHook服务进行校验并执行相应的部署命令

需要一个接收WebHook请求的服务, 解析并处理相应的事件, 在GitHub上找了下, 发现了一个合适的项目https://github.com/adnanh/webhook

2.WebHooks服务

该WebHook项目简介:

webhook是一个用Go编写的轻量级可配置工具，它允许您在服务器上轻松创建HTTP端点（hook），您可以使用它执行配置的命令。您还可以将HTTP请求中的数据（例如头、负载或查询变量）传递给您的命令。webhook还允许您指定触发钩子必须满足的规则。

项目基本能满足需求, 通过配置文件的方式, 设定触发条件的规则, 以及执行的命令

使用也很简单, 下载Release文件, 解压后执行:

/path/to/webhook -hooks hooks.json -verbose

访问地址:

http://yourserver:9000/hooks/conf-id-name

详细的使用方式请查看原项目说明

3.自动化部署脚本

在上述事件触发后, 需要执行自动化部署命令, 我希望达到的效果如下:

自动获取最新提交, 并重启服务
在更新失败或者在服务重启失败后, 可以自动回滚到上一个版本

在GitHub上找了下, 发现了Shell项目https://github.com/visionmedia/deploy

但是该项目不是直接在远程服务器运行的, 是在本地电脑配置远程服务器连接, 在本地配置及调用. 跟我的需求不太一致, 我需要该命令直接在服务器执行

基于上述项目, 我进行fork修改了一个版本, gitee地址https://gitee.com/geeknonerd/deploy, 去掉了ssh登录相关内容, 直接在服务器上运行命令

使用方式如下:

创建配置文件 deploy.conf , 根据文档进行配置
执行 deploy env-name setup 初始化目录及clone项目
执行 deploy env-name list 查看之前的部署记录

4.配置和完成

Gitee的WebHook鉴权方式有两种, 可通过 WebHook 密码进行鉴权，或通过签名密钥生成请求签名进行鉴权.

密码的方式会在请求头里附带上密码; 签名密钥则是在请求头里附带生成的签名.

上面提到的WebHook服务项目, 是支持密码的方式, 不支持Gitee的签名密钥方式, 可以通过deploy 脚本来实现校验

附上配置示例:

WebHooks服务 hooks.yaml (其中[]括起来的需要改成自己的配置)

- id: [YOUR-PROJ]
execute-command: [/path/to/deploy]
command-working-directory: [YOUR-PROJ-PATH]
pass-environment-to-command:
- source: header
  envname: GTIMESTAMP
  name: X-Gitee-Timestamp
- source: string
  envname: GSECRET
  name: [YOUR-TOKEN-SECRET]
- source: header
  envname: GTOKEN
  name: X-Gitee-Token
response-message: Receive request!
trigger-rule:
and:
  - match:
      type: value
      value: refs/heads/master
      parameter:
        source: payload
        name: ref
  - match:
      type: value
      value: git-oschina-hook
      parameter:
        source: header
        name: User-Agent
  - match:
      type: value
      value: [YOUR-GITEE-EMAIL]
      parameter:
        source: payload
        name: pusher.email

该配置使用的密钥签名方式, 并将签名传递到deploy脚本的环境变量中

Deploy脚本 deploy.conf (其中[]括起来的需要改成自己的配置)

[prod]
repo git@gitee.com:[YOUR-GIT-REPOSITORY]
path [YOUR-PROJ-PATH]
ref origin/master
pre-deploy [/path/to/cmp_str $(/path/to/cal_sign "$GTIMESTAMP" "$GSECRET") "$GTOKEN"]
post-deploy sudo supervisorctl restart [YOUR-PROJ]
test /path/to/cmp_str $(sudo supervisorctl status [YOUR-PROJ] | awk '{print $2}') 'RUNNING'

我是使用Supervisor进行进程服务管理, 所以用到了相应的命令, 具体配置根据自己需求来.

上述配置还用到了两个简单的Shell脚本, cmp_str用于比较两个字符串是否相等, cal_sign用于计算Gitee签名, 脚本内容如下:

cmp_str

#!/usr/bin/env bash

usage() {
  cat <<-EOF

  Usage: ./cmp_str str1 str2
    Compare two strings to check if they are equal or not.
    If str1 == str2 return 0, else 1.

EOF
}

if [ $# -lt 2 ]; then
    usage
    exit 2
fi

if [ "$1" == "$2" ]; then
    exit 0
else
    exit 1
fi

cal_sign

#!/usr/bin/env sh

usage() {
  cat <<-EOF

  Usage: ./cal_sign timestamp secret
    Calculate HMAC SHA256 signatures with timestamp and secret, then convert to base64.

EOF
}

if [ $# -lt 2 ]; then
    usage
    exit 2
fi

echo -n "$1\n$2" | openssl dgst -sha256 -hmac "$2" -binary | base64

到此, 完成了一个简版的自动化部署服务.

References: