技术分享保活容器 github

uptime+webhook+action 万能自动保活

雨天狂奔2025-09-162025-10-04

uptime+webhook+action 万能自动保活

项目缘由

GitHub action 是一个强大的自动化工具，但存在几个问题：

每月 2000 分钟限额，虽然一般人用不完，但对于定时任务过多的人也有可能耗尽
定时任务不够准确，无法第一时间在服务下线时候立即启动保活
定时任务如果设置过于频繁，有可能导致官方封号

项目原理

由 uptime 监控项目 在线情况，监控间隔设为多少没有任何限制，建议 5-10 分钟
将 在线情况 通过 webhook 通知发给 CF worker 搭建的 保活脚本 或 API 跳板
方法一：由 worker 保活脚本启动保活流程，不依赖 cron 触发器
方法二：worker API 过滤 在线情况，如果服务状态为 离线，发送给指定仓库的 action（在线则不发送），action 接收信息，启动保活流程，不依赖 cron 触发器

前置条件

搭建一个 uptime 项目，如果没有 vps，可以使用免费的爪云容器
通过 CF worker 搭建一个 保活脚本 或 API 跳板，接收 uptime 发出的 webhook 通知

本文适合有一定基础并喜欢折腾的朋友，纯小白建议直接使用老王的 vps 方案或 action 方案

先部署 Uptime Kuma

项目仓库：GitHub - louislam/uptime-kuma

爪云应用商店有这个项目，可以一键搭建，内存不低于 256m

镜像地址：louislam/uptime-kuma:1
默认端口：3001
卷挂载：uptime-kuma:/app/data

部署 Worker 脚本

有两种不同的脚本，其中：方法一不依赖 GitHub action，收到 uptime 发出的 webhook 通知后立即启动保活流程；方法二则是在 uptime 发出的 webhook 通知后触发关联仓库中的 action 脚本

方法一：接收 Webhook 通知后直接启动保活流程

优势：不依赖 github action，没有 action 排队问题，保活更及时（尚在测试中，若有问题，可在评论区留言反馈）。缺点：不通用，针对不同项目需要不同的保活脚本，本文脚本仅适用于 SAP

1. 部署 Worker 保活脚本（仅适用于 SAP）

worker 代码：Keepalive/webhook-action/sap-webhook-cf.js
环境变量
- EMAIL=sap 登录邮箱，必须
- PASSWORD=sap 登录密码，必须
- APP_URLS=SAP应用的URL地址，多个地址可每行填写1个，必须
- CHAT_ID=TG 机器人或频道 ID，可选
- BOT_TOKEN=TG 机器人 Token，可选
可选绑定自定义域名

2. 获取用于 Uptime Webhook 通知的 post Url

1 2	# 注意：[URL]是占位符，需要替换为sap应用的https地址 https://部署的worker地址/webhook/restart?appUrl=[URL]

方法二：接收 Webhook 通知后传递给仓库的 Action

优势：所有依赖 action 保活的项目都可以使用这种方式，脚本是通用的。缺点： action 有时需要排队，可能不会第一时间启动（已测试，可正确运行）

1. 部署 Worker-webhook API（适用于所有 action）

worker 代码：Keepalive/webhook-action/uptime-webhook.js
环境变量
- GITHUB_TOKEN：Github 个人访问令牌，需要 repo 和 workflow 权限
- SECRET_TOKEN：项目秘钥，保护部署的 API 端点
可选绑定自定义域名

2. 获取用于 Uptime Webhook 通知的 post Url

1 2	# action在哪个仓库，就填写对应的 GitHub 用户名和仓库名 https://Worker地址?token=设置的密码&user=GitHub用户名&repo=GitHub仓库名

Uptime Kuma 通知设置

1. 新增通知设置

点开右上角的设置

点击 通知——设置通知

然后按以下设置：

显示名称：填一个易于分辨的名称，如 SAP离线
通知类型: Webhook
Post URL:
- 方法一填写：https://部署的worker地址/webhook/restart?appUrl=[URL]
- 方法二填写：https://部署的Worker地址?token=设置的密码&user=GitHub用户名&repo=GitHub仓库名
请求体: 选择 预设 - application/json (然后不要在下方出现的任何文本框中填写内容)
额外 Header: 保持 禁用 状态
保存

2. 新增监控项

回到 uptime 主页，点击左上角 新增监控项，按以下填写：

监控项类型：选择 HTTP(s) - 关键字
URL: 填写监控的网站，如 https://webapp.ap21.hana.ondemand.com
关键字: 填写一个在网站上必然出现的词，例如 Hello（注意大小写）
心跳间隔: 建议 300-600 秒，即 5-10 分钟
通知：关联刚刚设置的 SAP离线 通知（重要）
其他默认，点击保存

一定要勾选右侧通知中的 SAP离线

方法二需要额外修改仓库 Action

此处以老王的 SAP 项目为例，我 FORK 后的仓库地址：GitHub - yutian81/nodejs-argo-sap

在 自动保活SAP.yml action 代码中加入如下代码（没看懂的可以看我 fork 仓库中的代码）：

顶部触发方式这里增加以下代码

workflow_dispatch:  # 允许手动触发
  # 当 Uptime Kuma API 发送 'service-down-alert' 事件时触发此工作流。
  repository_dispatch:
    types: [service-down-alert]

step 步骤第一步增加以下代码（老王这个项目的 action 有 restart-sg-apps 和 restart-us-apps 两个 job，如果你两个区都部署了，则两处都要加）

- name: Check Trigger Event
      run: |
        echo "Workflow triggered by: ${{ github.event_name }}"
        if [[ "${{ github.event_name }}" == "repository_dispatch" ]]; then
          echo "触发事件类型 (Event Type): ${{ github.event.action }}"
          echo "收到来自 Uptime Kuma 的下线通知，开始执行自动恢复部署流程…"
        elif [[ "${{ github.event_name }}" == "workflow_dispatch" ]]; then
          echo "工作流被手动触发，开始执行部署…"
        else
          echo "工作流由计划任务触发，开始执行部署…"
        fi

到这里就全部完成了，其他依赖 action 保活的项目也是同样道理

#容器 #保活 #github