免责声明: 本文属于纯思路探讨，使用demo代码所造成的影响与作者无关。

前言

近日，百川云平台发布了新的产品：牧云主机管理助手。可以帮助用户简单、轻量级的进行主机管理。

很快啊，在体验了一波基本功能后，发现主机助手真的很便捷：

• 一键安装，秒级同步
• 家里的虚拟机再也不用通过端口转发这种粗暴的方式来提供远程使用
• 各云厂商的主机再也不用记IP登陆
• 换一台全新的电脑也能够立马投入工作，优雅的远程连接到了自己的服务器（elegant~)
• 三台主机内还是免费使用

一番把玩后，作为一个白嫖怪，还是发现了一个盲点：

牧云主机管理助手的定位是：主机管理工具。
那么对于白嫖怪来说，我连主机都没有，该怎么办呢？

打开格局

早期在关注主机白嫖这个方向时，除了各种云厂商的学生党羊毛，还曾注意到一个思路，那就是现在众多的CI平台。

随着云原生环境的不断发展，越来越多的厂商开始接受DevOps的思路，持续集成(CI)也成为了必不可缺的一个环节。通过持续集成，开发者可以快速、自动、可重复的将代码进行测试、编译、打包等步骤，从源代码生成发布版本。

而持续集成的整个环节，都会提供一个环境供流程进行自动构建。这个执行构建的主机自然就成了我们白嫖怪的目标。

在最初的思路中，我们能够获取主机操作权限的方式，第一反应通常都是ssh,因此，现有的白嫖版本都是通过各种ssh模拟服务来连接到action VM环境中。

参考链接
https://p3terx.com/archives/ssh-to-the-github-actions-virtual-server-environment.html

但是在实际使用中，由于ssh交互的问题，很容易导致断开连接后，整个环境丢失。使用的体验上并没有那么舒适。

结合最近出现的牧云主机管理助手，突发奇想：能否通过牧云主机助手的方式，来获取到action VM的权限呢？

实际测试

如此，我们要做的事情就很明确了：

• 让CI执行牧云主机助手部署的脚本
• 因为部署脚本是daemon模式，所以我们需要sleep来维持CI存活的状态。

仅需两步，我们就可以获取到了一个免费的 E5 2vCPU/​7G RAM/​90G SSD主机。

为了方便使用，我将上述思路打包成了Github Action，详细代码可以查看 Github仓库, 方便开发者快速进行接入。

使用场景

在执行Github Action时，无法登陆到实际执行的VM环境中来进行debug，检查构建失败的真正原因。

此时可以使用上述GitHub action, 通过牧云主机管理助手登陆到debug action的环境中，手动check构建失败的问题，从而避免了修改workflows来进行debug的麻烦方式。

该场景仅作为抛砖引玉，除此之外，我相信实际能够应对的场景仍有很多，而且牧云主机管理助手仍在以腹泻式进行迭代更新，欢迎大家探索和分享出更多的玩法～