你们要的反向 Server 酱来了

[Muninn]

前一段时间看到有人问有没有反向 Server 酱，我发现我也挺需要的，最近两个月就动手写了一个。

它能通过微信公众号控制你的服务器，但不是直接控制的，为了安全，是在云端存储了消息，等着服务器上的 Agent 去拉取。这样同时也有了内网穿透的能力。

这样，就可以在服务号里通过简单的消息让服务器执行重启服务之类的动作。
我甚至把它集成到了我的某些服务里当成了一个业务控制台，体验也不错。

当然它也有正向 Server 酱的通知功能。

项目文档在: https://letserver.run

Github: https://github.com/hack-fan/skadi

当作控制台的公众号:

只写好了主要的功能和文档，其他的会根据大家的建议慢慢更新吧。

看 V 站看了很多年，每次有什么都先发这里，附带一个暗号吧，对着公众号说 v2ex 就可以增加两个 Agent 数量配额～

[styang]

看起来还可以

[Sunyanzi]

玩了半天 ... 很有趣 ... 比 ServerChan 更简单实用 ... 希望能坚持下去 ...

另外一些问题 ... 一是我同一个 job id 可以 fail 或 succeed 无数次 ... 这是有意设计为之的还是个 bug ..?

我感觉可以加个 proceed 作为中间态 ... 一旦到 fail 或 succeed 感觉 job 就能删了 ... 不然留着有啥用 ..?

另外 ... 两个消息通知接口 /agent/info 和 /agent/warning ... 显示的消息好像没区别 ... 那为啥分开咧 ..?

[tcfenix]

老哥...你的.idea 冒出来了.,...处理一下

[oldcai]

挺有意思，给我了一些启发。

[Muninn]

@tcfenix 现在.idea 就是需要同步的呀，里边是项目级别的配置，不需要同步的个别文件有忽略列表的。

[enotx]

看上去很棒，马克一下回家试试

[Muninn]

@Sunyanzi 可以 fail 多次是个 bug，谢谢。

历史 job 本来想提供 log 功能供回顾一下最近的。不过可以考虑默认删了，用户需要打开 log 再保留。

info 和 warning 的模版不一样，默认颜色也不一样～ 一个是蓝色的一个是红色的

[Sunyanzi]

@Muninn 其实微信的聊天窗口就是个简陋的 log ... 如果要做详细 ... 可以考虑比如只保留最近三个月 ...

但保留归保留 ... 「已完成」的状态还是不能更改的 ... 如果对已完成的任务执行 fail / succeed 可返 405 ...

同时强烈建议引入 proceed 态用于耗时操作的反馈 ... 否则现在只能调 /message/info 感觉不太对 ...

至于 info 和 warning 是我的问题了 ... 我是老版本微信 ... 包括 message 在内三种模板显示都没区别 ...

另发现的公号 bug ... plan 里面已有 agent 和最大 agent 数量显示颠倒了 ...

以及「每分钟最多发起一次查询」这句话感觉也有哪里不太对 ... 一来实测并没有这个限制 ...

二来这不是「最多」而是「必须」 ... 如果我不每分钟发起一次查询的话会离线的 ...

说到这个 ... 离线则不吃任务这事儿也怪怪的 ... 如果是我我会设计成离线状态吃且仅吃一个任务 ...

离线状态无未拉取任务正常提示等待拉取 ... 如果有未拉取任务则提示队列非空之类的 ... 不过这都是后话了 ...

[guog]

@Muninn 里面有 IDE 的配置，一般都有个人习惯

[eason1874]

不错。我也用企业微信+云函数+API 网关做了些简单的应用，可以在微信上查询和修改一些服务器配置。

挺好用的，缓解流量焦虑症尤其有效。

[Muninn]

@Sunyanzi 谢谢反馈这么多。已完成的肯定不能更改的，这个会很快修复的。

proceed 的状态在服务端看来就是取走的状态。耗时我来统计一下吧，会显示在成功失败的反馈中。

plan 的文本确实错了～

查询的 rate limit 因为是有 api 的怕有人自己写 Agent 的时候疯狂调用。 准备给普通版一分钟高级版做到三秒之类的。 但是我发现我会的 rate limit 是用 redis 实现的，而取 job 也只是一个 redis 操作，这时候 rate limit 消耗的资源不不 limit 还大…… 但是放在 web server 那一层又会误伤，所以还没想好。

离线是否接受任务我再想想，这个只是设定问题。 有的任务也许发起的人就想现在执行，过一阵等在线了取走执行也许会出事。感觉还是不接受比较好。

[AkaGhost]

有可能和其他人共享某些 agent 的控制权限吗，看了下文档貌似没有提及相关功能

[ashuai]

/plan
你可以创建 0 个 Agent，已经创建 3 个
/status
您的所有 Agent: 无

-。-

[Muninn]

@wyf001912hp 这个暂时不准备，后面会出一个用 企业微信 /dingding/飞书 /slack/team 任选的，那时候才支持共享之类的。 这个只准备给个人用～

[ashuai]

@wyf001912hp 这个想法不错。但貌似会有商业化的 bug
我邀来 10 个同事，每人 3 个，共 30 个，我们共享着玩 lol

[Sunyanzi]

@Muninn 因为实际上同样的东西我好几年前就琢磨着要做来着 ... 但因为舍不得三百块一直就没做 ...

所以这些设计其实一直在我脑子里 ... 我甚至考虑了有用户量之后疯狂推广告养自己的可能性一类的 ...

跑题了 ... 关于 proceed 我想要实现的功能是针对一个任务可以推送多条文字消息 ... 和被取走还不太一样 ...

现在如果我取了不做或压根不取会产生自动超时 ... 而 proceed 状态实际上就是 cancel 掉这个超时 ...

说到底我想要实现的效果是可以不受模板消息六十分钟五条的限制给自己推送多条文本消息 ...

和现在 bug 中的 fail / succeed 行为类似 ... 即如果我有一个已被拉取处理状态标记为 proceed 的任务 ...

那么我在后续比较长一段时间里 ... 可以一直用同一个 job id 给自己发消息 ... 直到该任务标记完成为止 ...

rate limit 这事情 ... 实际上是个「要不要为了可能存在的恶意用户增大所有人消耗」的问题 ...

我觉得可以先不做 ... 如果真的有人不以测试为目的高并发压机器的话再说 ... 感觉上应该不会 ...

至于离线任务 ... 现在的在线状态其实只能保证一分钟内 Agent 活过 ... 之后会不会取其实是不可控的 ...

而且如果对任务的时效性没有要求 ... 我大可以把一分钟拉一次改成三分钟拉一次 ... 避免超时还降低机器压力 ...

细想了想这种场景是存在的 ... 但如果要改的话涉及还挺多的 ... 对我而言不是刚需 ... 还是看你的计划啦 ...

[xushanli]

Server 酱转型了吗

[Muninn]

@ashuai 哈哈 低级失误

[Muninn]

@Sunyanzi 持续发消息这个我理解你的意思了。

微信限制收到一句话最多回复 5 条。现在及时反馈 /取走 /结果 用了三条。 其实只剩两条额度了。 我可以考虑怎么节约一下，然后再允许发两条中间状态。

[Sunyanzi]

@Muninn 事实上不用节约的 ... 在我的测试里 ... 最多回复五条指的是「五条内容不一样的消息」 ...

连续且内容相同的消息可以疯狂回复 ... 不受这个限制 ...

再者说所有消息都有五条额度 ... 我可以随便发个不在命令列表里的消息 ... 接下来坐等收消息就好 ...

其实不需要为了这个功能改动太多 ... 只需要一个可以产生消息且不将任务标记完成的动作就好 ...

或者一个更简单的办法 ... 保留现在 bug 中的 fail / succeed 但改个消息内容改个名字 ... 就齐了 ...