基于WebHook实现Gitee自动化部署

本文介绍了如何利用WebHook和自定义Shell脚本实现Gitee项目的自动化部署。首先,通过webhook工具创建HTTP端点接收Gitee的WebHook请求,并配置执行部署命令。接着,自定义简化版的deploy脚本,用于自动获取代码更新并重启服务。文章详细阐述了配置WebHook服务和deploy脚本的过程,包括鉴权方式、自动化部署脚本的编写以及使用Supervisor管理服务。最后,提供了完整的配置示例,帮助读者实现自己的自动化部署流程。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

基于WebHook实现Gitee自动化部署

大纲

1.起因和思路

2.WebHooks服务

3.自动化部署脚本

4.配置和完成

1.起因和思路

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

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

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

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

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

  1. Gitee收到git提交事件, 发送WebHook请求到WebHook服务
  2. 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.自动化部署脚本

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

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

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

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

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

使用方式如下:

  1. 创建配置文件 deploy.conf , 根据文档进行配置
  2. 执行 deploy env-name setup 初始化目录及clone项目
  3. 执行 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:

### Gitee实现自动化部署的 CI/CD 配置 要在 Gitee实现自动化部署,通常会借助一些常见的 CI/CD 工具来完成整个流程。以下是关于如何利用 Jenkins 和 Docker 来设置 Gitee 的 CI/CD 流程。 #### 使用 Jenkins 和 Docker 实现 Gitee 自动化部署 1. **代码托管平台的选择** 开发人员需要将代码提交至 Gitee 平台作为版本控制管理工具[^3]。这一步骤是后续自动化的基础。 2. **Webhook 设置** 在 Gitee 中配置 Webhook 地址,指向 Jenkins 服务端口。当有新的代码推送时,Gitee 将向 Jenkins 发送通知以触发构建任务。 3. **Jenkins 构建过程** - Jenkins 接收到 Webhook 请求后,从 Gitee 拉取最新的项目源码。 - 利用脚本执行项目的打包操作(如 npm run build 对于前端项目),并生成可运行的应用程序文件或者容器镜像[^1]。 4. **Docker 容器化** 如果目标环境支持 Docker,则可以通过创建自定义的 Dockerfile 文件,在其中指定应用程序所需的依赖项以及启动方式;随后由 Jenkins 负责构建该镜像,并推送到私有的或公共的 Docker Registry。 5. **远程服务器上的部署** Jenkins 可通过 SSH 协议连接到生产环境中的一台或多台主机上,传输已打包好的静态资源或者是完整的容器镜像地址。接着执行一系列命令完成最终的服务更新工作。 6. **反馈机制** 整个 CICD 过程结束后,可以选择性地把成功与否的信息返回给开发者查看,甚至还可以集成即时通讯软件比如钉钉来进行实时消息提醒。 以上描述了一个典型的基于 Gitee、Jenkins 和 Docker 技术栈所构成的连续交付流水线方案概述[^2]。当然具体实施细节可能会因应不同场景下的特殊需求而有所调整变化。 ```bash # 示例:简单的 Jenkins Pipeline Script (Groovy) pipeline { agent any stages { stage('Checkout') { steps { git 'https://gitee.com/<your-repo>.git' } } stage('Build') { steps { sh ''' docker build -t my-app . docker push my-app:latest ''' } } stage('Deploy'){ steps{ sshPublisher( publishers: [ sshPublisherDesc( configName: 'production-server', transfers: [sshTransfer(cleanRemote: true, sourceFiles: '**')], usePromotionTimestamp: false, verbose: true ) ] ) } } } } ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值