3 个不稳定版本
0.2.0 | 2023年6月12日 |
---|---|
0.1.1 | 2020年9月8日 |
0.1.0 | 2020年9月8日 |
#578 in HTTP 服务器
每月 23 次下载
30KB
405 行
Deplorable 仓库部署器
Deplorable 是一个简单且小巧的守护进程,用于部署您的代码。
这是什么?
Deplorable 是一个后台进程和 HTTP 服务器。当您将特定分支的代码推送到您喜欢的协作版本控制服务时,它接受 Webhooks,从您的仓库获取最新代码,并使用您的仓库中的 Nix 表达式(在 default.nix
中)"构建"它。
我什么时候可以使用它?
现在!
我可以在哪里使用它?
它已在 NixOS 上作为 systemd 服务运行进行了测试,但它应该在任何编译的 Rust 程序可以运行、监听 TCP 套接字并调用 Nix 软件包管理器的地方工作。这应该包括任何 Linux 发行版,以及 OS X,甚至如果愿意做一些额外的工作,可能还包括 Windows 和 BSD。
您不需要使用 systemd 来运行它。您可以使用 SysVinit 脚本、tmux/screen 会话、launchd、upstart...您想怎么做就怎么做。systemd 很好,因为 deplorable 可能会最终以相当低的 PID 号运行,这显然是出于某种原因很重要的。
我为什么要使用它?
假设您在一个大机构工作,该机构有一项政策,使得将子域名指向 Netlify 或 GitHub Pages 很困难,但很容易获取公共 IPv4 地址并在您的台式机、地下室的服务器或本地虚拟机上托管网站。Deplorable 可以帮助您在不与任何人争论是否在 GitHub 上托管网站是否违反内部政策或内部政策是否应该改变的情况下,使用这些服务的体验。
或者,假设您想要
-
在您的服务器上自动部署使用 Jekyll 或 Hugo 等静态网站生成器生成的静态网站。
-
使用您自己的框架或不受主要静态网站托管商支持的框架自动部署静态网站。
-
这就全部了吗?您可能还有其他原因需要保持代码的最新版本在某台计算机上编译。
如何使用它?
这是个好问题!
你需要五样东西
-
(可选,但现在实际上需要) 一个可用的Rust编译器和Rust包管理器Cargo。只有你想从源代码编译deplorable时才需要这个。然而,目前,你几乎肯定需要从源代码编译。如果你使用Nix来编译deplorable,这已经为你处理好了。
-
一些基本依赖项,包括libcurl和openssl。如果你使用Nix来构建deplorable(见下文),这已经为你处理好了。看看这个元是多么的优雅!
-
你想要自动部署的一个或多个GitHub仓库。
-
一台连接到互联网的计算机,可以接受web hooks(公网IP地址是最理想的,但如果你在NAT后面或者无法直接在公网上监听TCP连接,可以使用ngrok和smee等工具来帮忙)。
-
Nix包管理器(说明见这里。请注意,安装或使用Nix包管理器不需要提升权限。
构建
首先,获取源代码。你可以这样做的方式有很多,但让我们用Git吧,为什么不呢
$ git clone git://github.com/alevy/deplorable
$ cd deplorable
接下来,你有选择。你可以使用Rust的cargo
构建deplorable,或者你可以使用Nix构建deplorable(这反过来会调用Rust)。
$ cargo build --release
# outputs to $PWD/target/release/deplorable
或者
$ nix build
# outputs to $PWD/result/bin/deplorable
配置
Deplorable使用YAML(这意味着它也可以是JSON)配置文件来确定它期望从哪些仓库接收web hooks以及它应该使用哪些凭据(如果有)。配置文件有一个顶级的“repos”键,它解析为一个仓库对象的列表。每个仓库的键将对应于它的webhook路径。
每个仓库对象必须至少包含以下条目
repo
:完整的GitHub仓库名称,即{owner}/{repo}
。reference
:要监视和部署的完整引用,包括refs/heads/
前缀。通常,这可能是类似于refs/heads/master
或refs/heads/staging
的东西。out
:仓库应该编译到的相对或绝对路径。运行deplorable
的用户必须能够写入此位置。
可选地,仓库对象还可以包含
secret
:共享的GitHub webhook密钥,用于验证GitHub webhook。不需要配置共享密钥,但建议这样做以避免不必要的构建。token
:允许访问私有仓库的GitHub OAuth令牌。
以下示例显示了两个完全不存在的仓库的配置,一个公开,一个私有。
repos:
# Site 1 is in a public repo
site1:
repo: myuser/mysite1
reference: refs/heads/master
out: /var/www/site1
secret: mysecretkey1
# Site 2 is in a private repo, so it needs a token to access
site2:
repo: myuser/mysite2
reference: refs/heads/beta
out: /var/www/site2
secret: mysecretkey2
token: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
运行
运行这个该死的东西!
$ target/release/deplorable -c YOUR_CONFIG_FILE.yaml -l 0.0.0.0:1337
Listening for web hooks on 0.0.0.0:1337
如果你想在TLS上暴露deplorable或在端口80或443上,你可能需要考虑反向代理,例如通过NGINX或Apache。
设置Web Hooks
按照GitHub的指南设置你的仓库的webhook。
对于每个仓库,“有效负载URL”是
http://YOUR_IP_OR_DOMAIN_NAME:1337/REPO_KEY_FROM_CONFIGURATION
选择application/json
作为内容类型,并确保密钥与你的配置文件中的密钥匹配。最后,你只需要激活推送事件,这是默认设置。其他事件将被忽略。
常见问题解答
- 为什么叫deplorable?
它帮助你“部署”事物,我需要给仓库起个名字。请不要过度解读。
*只要您喜欢的协作版本控制系统是GitHub。
依赖项
~11-23MB
~451K SLoC