软件授权用 Keygen.sh - 自部署服务

Keygen 是一款由开发者为开发者构建的一套开源/企业级的软件授权和分发系统，系统服务提供了比较完善的 API，我们可以自托管或试用 Keygen Cloud。

前言

对于我个人而言，当前产品授权验证的整体思路如下，仅供参考。

授权验证使用思路

电子商务平台：接入的电子商务平台都与 keygen.sh 服务直接或间接的进行数据交互；
产品：软件产品通过调用 keygen.sh 服务实现密钥验证/激活/注销激活，为了保证授权验证完整性，产品中也需有一定密钥验证处理逻辑；
灵活统一性：为了保证数据的统一性和操作便捷，我决定使用 paddle 作为管理产品的唯一入口，通过 Webhook 服务自动向 Keygen.sh 服务中管理产品/定价策略；电子商务平台形成订单后都可以自动新增消费用户和生成许可。

工作进展

已经走通了于数码荔枝的对接以及产品内的密钥验证/激活的所有流程。

下一步

目前在设计 Webhook 服务，后续为了简化流程保证接口的安全性，会将当前直接对接 keygen 接口的电子商务平台（如数码荔枝）都接入 webhook 服务接口。

webhook 服务只开放少量接口，降低数据风险；
提供单一接口，方便类似于数码荔枝这样的平台接入；

如果不想花精力自维护 Keygen，可以选择试用一下 Keygen Cloud，收费方案如下：

Keygen Cloud 定价

早期我选择的是自己部署开源的社区版（CE 版本），CE 版本属于单管理账户的版本，也可以联系 Keygen.sh 获取 EE 版本授权码，解锁管理账户数量限制。

自部署的原因如下：

开源版本接口是全功能的，社区版（CE）只有 1 个管理账户数的限制；
目前看维护成本不高，相对于 Cloud 版本成本低很多；
看后期发展及 keygen.sh 的实际使用效果，会选择性为 keygen.sh 的价值买单支持。

自部署

下面就开始讲解一下我自部署 CE 版本的过程，官方文档写的也很详细，每个人的情况多少有些不同，有问题再去细查文档——self-hosting。

准备工作

一台有固定 IP 的服务器部署服务，我使用的是自己租的云服务器；
一个域名（配置域名解析），用于服务绑定，就可以用域名访问服务 API 了；
服务器安装 docker，要保证能正常拉取镜像。

✨可以网上搜索加速方式方法，我这里使用的是网络魔法的方式，有修改镜像源的方式。

为了保证各服务网络互通，我们最好是将要启动的容器都在同一个网络组中启动，先创建一个专门的网络组。

配置数据库

指定网络创建数据库容器。

启动 Postgres 容器

💡如果因为操作失误希望删除容器和数据重新启动新的数据库，记得也要删除 postgres Volume。

启动 Redis 容器

构建环境变量

启动 keygen 服务之前需要创建必要的环境变量。

💡KEYGEN_HOST 记得修改为你自己需要使用的域名，比如我的形如：xxx.5km.tech，后面反向代理和域名解析要与这个域名保持一致。

设置账户信息

提前准备好 UUID 作为单用户的用户名 ID，macOS 下终端中执行命令 uuidgen 即可生成，记下来作为 KEYGEN_ACCOUNT_ID，配置服务时会用到。

然后执行下面的命令配置服务

运行起来后会提示你输入账户 ID，你输入上面的 KEYGEN_ACCOUNT_ID 即可，📮邮箱和🔑密码填写自己要用做管理账户的就好，一定要记住邮箱和密码，后面需要配置获取管理员 Token 用来调用 API 验证。

执行完成后会有提示让在终端执行一些 export 命令，主要包含上面👆定义的一些环境变量和 setup 过程生成的环境变量，其中就包含 KEYGEN_ACCOUNT_ID。

执行后最好是将这些 export 指令放到 shell 配置中，比如我使用 zsh，所以放到 ~/.zshrc 文件最后。

运行 Web 服务

启动 web 服务容器时不要忘记添加 KEYGEN_ACCOUNT_ID 环境变量。

运行 Worker 服务

启动 Worker 服务时不要忘记添加 KEYGEN_ACCOUNT_ID 环境变量。

反向代理

这样做是为了保证 keygen 能接受你正确域名过来的请求并启用 https，因为我们启动服务的时候指定了 HOST，这里就是为了能够将域名请求自动转发到3000 端口的本地服务。

通过 caddy 可以轻松实现：反向代理 + https。

安装 caddy

我的服务器是 Ubuntu 系统，所以执行命令安装 caddy：

参考官方文章：🔗 Install

修改配置文件

根据需要自行修改为自己要使用的域名，安装完 caddy 后，可能会默认生成一个 /etc/caddy/CaddyFile 的配置文件，我们直接删掉原有内容，改为自己的配置即可，如下：

💡上面两处 [KEYGEN_HOST] 替换为你的域名，比如我的形如：xxx.5km.tech

保存之后，可以通过命令验证配置：

如果没问题，需要重新启动 caddy 服务：

域名解析

登录你购买域名解析后台，添加使用域名的解析即可，因为我是添加的一个二级域名并指定到服务器的 ip，所以需要添加 A 记录：

主机记录：填写你自己的二级域名，比如我这里是 xxx
记录类型：A 记录
记录值：填写服务器的 IP 地址

添加成功后等待几分钟，应该就能生效了。

至此，你的 keygen.sh 服务部署工作完成了🎉！

测试

服务部署成功后，执行命令测试服务。

💡 [KEYGEN_HOST] 替换为你的域名，比如我的形如：xxx.5km.tech

结果形似下面的结果就说明成功啦！

管理服务

官方暂时不提供 GUI 的管理工具，据说在做着，后面会开源！

当前可以通过服务的 API 和容器中的 console 工具管理服务中的数据，以下命令可以启动 console：

启动后我们可以查 public_key，过程如下，使用的命令是 Account.sole.public_key

在使用 API 之前，还需要通过配置的邮箱和密码获取 admin-token。

💡API 调用提醒
请求 API 需要使用账户的唯一 ID，或在注册时选择的 slug 。每个 API 请求将在 URL 路径中使用账户 ID 或 slug，即 /v1/accounts/<id> 或 /v1/accounts/<slug> 。您的账户 ID 和 slug 可以互换用作 URL 参数。
CE 版本 是单账户系统，所以其中 /accounts/<slug> 或者 /accounts/<id> 可以省略，比如 tokens 接口的 endpoint 可以写为 /v1/tokens。

[KEYGEN_HOST]：替换为你的域名
[邮箱]：替换为上面启动服务配置时填写的邮箱📮
[密码]：替换为上面启动服务配置时填写的密码🔑

执行命令后会得到一个 Token 对象的 json 数据，其中 data.attributes.token 就是我们需要的 admin-token。

这样我们后面测试 API 就可以用这个 token 作为验证访问啦，比如获取所有 token：

请求头中加入 Authorization 字段信息，<admin-token> 为获取任何时候上述方法获取的 token；
[KEYGEN_HOST]：替换为你的域名

自荐工具

KeygenGo Preview

简单测试一下 API 用 curl 或者 API 工具（我一般用 RapidAPI，原来叫 Paw）还可以，但是后面真的管理数据确实不太方便，所以花了几天时间撸了一个比较初级的 GUI 客户端工具 - KeygenGo，现在可以加入 TestFlight 试用。

这个工具是一款面向 keygen cloud 或者自建服务的 GUI 工具，目前从获取 token 到产品、策略、许可、密钥、用户管理功能已基本具备，后面也会根据自己功能需求和大家的反馈慢慢完善，一起开心地用 Keygen 🚀。

PS：开发这个工具算不算为 keygen 生态构建做了一丝.....丝贡献🙃!

总结

感谢你耐心的读到这里，以上就是本篇文章全部内容，后面会继续分享 keygen 相关的内容，包括个人产品上的使用经验/注意事项（坑🫠）以及围绕 keygen 做的 webhook 服务的相关内容，非常欢迎关注我（@okooo5km）、订阅博客和转发文章，下篇文章再见👋！

动态更新