Webhook 实践 —— 自动部署

本文介绍如何使用Webhook实现博客更新后的自动部署。通过在服务器上搭建Node.js应用,监听特定HTTP请求并执行git pull命令,实现代码更新。此外,还介绍了如何确保Node.js服务器稳定运行的方法。

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

https://segmentfault.com/a/1190000003908244

Webhook,也就是人们常说的钩子,是一个很有用的工具。你可以通过定制 Webhook 来监测你在 Github.com 上的各种事件,最常见的莫过于 push 事件。如果你设置了一个监测 push 事件的 Webhook,那么每当你的这个项目有了任何提交,这个 Webhook 都会被触发,这时 Github 就会发送一个 HTTP POST 请求到你配置好的地址。

如此一来,你就可以通过这种方式去自动完成一些重复性工作;比如,你可以用 Webhook 来自动触发一些持续集成(CI)工具的运作,比如 Travis CI;又或者是通过 Webhook 去部署你的线上服务器。

Github 开发者平台的文档中对 Webhook 的所能做的事是这样描述的:

You’re only limited by your imagination.

面临的问题

我目前正好面临了这样一个问题 —— 麻烦的人肉部署。也许有人看过我之前的一篇博文《解决 Github Pages 禁止百度爬虫的方法与可行性分析》。为了解决文章中的这个问题,我最后建立了一个只服务于百度爬虫的一个备份服务器。但是随之而来的问题是,每次我的博客有些更新,都不得不 ssh 到那台服务器上把代码 pull 下来。如此做了两三次以后,我觉得我不能再这么堕落下去,于是还是决定尝试一下 Webhook。

于是我要完成的事情便是完成一个能够将我最新版本的博客,随时同步到备份服务器的 Webhook。简单分析一下我需要什么:

  1. 一台外网可以访问的主机

  2. 一个能够响应 Webhook 的服务器

  3. 配置 Webhook

1. 一台外网可访问的主机

什么叫外网可访问的主机?像阿里云的试用版就不行,它不提供外网 IP。而我使用的是 DigitalOcean 的云主机,主要的作用是架梯子,现在也顺便用来做备份服务器。当然你们也可以用类似 SAE 的服务,虽然没有 IP,但有独立的外网访问地址。

2. 响应 Webhook 的服务器

为了响应 Webhook 所发出的请求,从而做一些我们想做的事情,我们得先实现一个响应服务器。本文采用 Node 来实现一个原型,你当然也可以用 PHP,python 等,全凭个人喜好啦。代码很短,就直接陈列在下方了:

var http = require('http')
  , exec = require('exec')

const PORT = 9988
  , PATH = '../html'

var deployServer = http.createServer(function(request, response) {
  if (request.url.search(/deploy\/?$/i) > 0) {

    var commands = [
      'cd ' + PATH,
      'git pull'
    ].join(' && ')

    exec(commands, function(err, out, code) {
      if (err instanceof Error) {
        response.writeHead(500)
        response.end('Server Internal Error.')
        throw err
      }
      process.stderr.write(err)
      process.stdout.write(out)
      response.writeHead(200)
      response.end('Deploy Done.')

    })

  } else {

    response.writeHead(404)
    response.end('Not Found.')

  }
})

deployServer.listen(PORT)

如果还需要实现更多,更复杂的功能,直接在 commands 数组中添加便是。此处我的博客根目录 html 与部署服务器根目录同属一个目录,所以配置常量 PATH = '../html'。只要启动了服务器,那么 Webhook 就可以通过类似于 http://104.236.xxx.xxx:9988/deploy/ 的路径来部署我的博客备份啦。

# 在后台启动部署服务器
$ node server.js &

我以为服务器部署到这儿就完了,其实并没有,我遇到了一些麻烦。

Run Node Server Forever

我在实际使用的时候发现,我的 Node 服务器时不时会自动停掉,具体原因我暂时还没有弄清楚。不过似乎很多人都遇到了这样的困扰,要解决这个问题,forever 是个不错的选择。借助 forever 这个库,它可以保证 Node 持续运行下去,一旦服务器挂了,它都会重启服务器。

安装 forever:

[sudo] npm install -g forever

运行:

$ cd { 部署服务器的根目录 }
$ forever start server.js

我在 DigitalOcean 上的服务器安装的是 Ubuntu 系统,而 Ubuntu 中原本就有一个叫 node 的包。为了避免冲突,在 Ubuntu 上安装或使用 Node 得用 nodejs 这个名字。而 forever 默认是使用 node 作为执行脚本的程序名。所以为了处理 Ubuntu 存在的这种特殊情况,在启动 forever 时得另外添加一个参数:

forever start server.js -c nodejs

3. 配置 Webhook

如果像是本文这种最简易的应用,Webhook 的配置是十分简单的。首先进入你的 repo 主页,通过点击页面上的按钮 [settings] -> [Webhooks & service] 进入 Webhooks 配置主页面。也可以通过下面这个链接直接进入配置页面:

https://github.com/[ 用户名 ]/[ 仓库名称 ]/settings/hooks

此处只需要配置 Webhook 所发出的 POST 请求发往何处即可,于是我们就配置我们所需要的路径: http://104.236.xxx.xxx:9988/deploy/。这个地址指向的就是那个能够响应 Webhook 所发出请求的服务器。

配置好 Webhook 后,Github 会发送一个 ping 来测试这个地址。如果成功了,那么这个 Webhook 前就会加上一个绿色的勾;如果你得到的是一个红色的叉,那就好好检查一下哪儿出问题了吧!


### 如何编写 Jenkins 自动部署脚本教程最佳实践 #### 编写自动部署脚本的重要性 为了提高软件开发效率并减少人为错误,在持续集成和持续交付(CI/CD)流程中引入自动化的工具至关重要。Jenkins作为一个开源的CI服务器,支持多种插件来实现复杂的构建逻辑。 #### 安装与配置基础环境 确保已经按照指导成功安装了Jenkins服务,并且能够正常访问其Web界面[^1]。对于Java应用程序来说,通常还需要预先设置好Maven以及Docker等相关依赖项。 #### 创建自由风格项目或Pipeline Job 进入Jenkins主页后可以选择新建一个“自由风格”的job用于传统方式下的任务管理;或者是采用更现代化的方法——创建一条基于Groovy语法编写的pipeline定义文件(通常是`Jenkinsfile`)来进行声明式的流水线作业描述[^2]。 #### 配置源码仓库连接 无论是哪种类型的Job都需要指定Git或其他版本控制系统作为代码库来源。这一步骤允许Jenkins拉取最新的变更记录以便后续处理操作可以作用于最新版次的应用程序包上。 #### 构建触发器设定 为了让整个过程更加智能化,可以通过配置webhook或者其他形式的通知机制让每次提交都会触发出一次新的build尝试。当然也可以手动执行Build Now按钮发起即时测试运行。 #### Maven打包阶段 当接收到更新事件之后,Jenkins将会依据预设好的指令集依次执行各个步骤。其中一项重要工作就是利用Maven命令将工程转化为可分发的形式,比如WAR/JAR文件等。具体做法是在Execute shell部分输入如下内容: ```bash mvn clean package -DskipTests=true ``` 这条语句的作用在于清理旧数据、跳过单元测试环节快速完成编译打包动作。 #### Docker镜像制作 紧接着上述过程结束以后便进入到容器化环节。此时应该准备好一份合适的Dockerfile用来指示怎样组装最终产物成为独立运行的服务实例。下面是一个简单的例子说明如何针对Spring Boot应用定制image: ```dockerfile FROM openjdk:8-jdk-alpine VOLUME /tmp ARG JAR_FILE=target/*.jar COPY ${JAR_FILE} app.jar ENTRYPOINT ["java","-Djava.security.egd=file:/dev/./urandom","-jar","/app.jar"] ``` 这段模板指定了基础映像选用轻量级Alpine Linux发行版携带OpenJDK 8环境,并复制由前序步骤产生的`.jar`文件至目标位置最后给出启动参数列表[^3]。 #### 发布到远程主机 一旦本地构建顺利完成,则可通过SSH协议向远端机器推送新生成的artifact或者直接push docker image到私有Registry里边保存起来供其他节点下载使用。这里提供了一种通过Shell Script实现的方式: ```bash ssh user@remote_host "mkdir -p ~/apps && scp target/app.jar user@remote_host:~/apps/" ``` 以上命令序列实现了在对方路径下建立必要的目录结构并将当前项目的二进制成果传输过去等待进一步激活上线。 #### 启动服务进程 最后一步便是确保一切就绪的前提下正式开启业务功能模块。考虑到实际应用场景中的复杂度差异较大因此此处仅列举一种较为通用的做法即借助Systemctl/Daemonize等方式后台守护特定进程防止意外中断影响用户体验。 ```bash nohup java -jar ~/apps/app.jar & ``` 此行代码片段表示以非阻塞模式加载指定地址处存放着的应用主体并且将其放入后台继续运作直至遇到致命异常才会停止下来。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值