usual2970

Certimate 越来越受欢迎，需求也越来越多，这就要求我们根据需求完善、扩展 Certimate 的功能。在扩展Certimate的过程中，我们发现传统表单的表达能力实在有限，有些需求很难基于现有的表单来扩展。所以在v0.3 版本中，我们主要引入了工作流的概念。使用工作流：

• 我们可以把各种功能抽象成一个个节点，实现新功能时添加新的节点类型就可以了。
• 按需把用到的节点组装成一个工作流，来灵活实现证书管理的目标。

把各种功能抽象成一个个节点​

在传统的表单中，如果我们要扩展一个新的功能，手段可能就是添加字段。如果要添加的字段过多，表单就会很冗长，导致用户无所适从。

这个时候我们还可以将冗长的表单拆分成多个步骤，如：第1步：填基础信息。第2步填：高级信息。不过，这依然没有从根本上解决问题，有了第2步后面就有可能有第3、4步甚至更多步。而且有可能部分用户只需要其中的部分步骤，现在也被迫填完所有步骤。

Certimate v0.3引入了节点的概念，1个节点代表着一类功能。比如目前实现的节点有开始节点、申请节点、部署节点、分支节点、通知节点。申请节点只需要填写申请证书相关的信息，部署节点也只需要填写部署相关的信息。

有了这个基础，未来我们可以添加更多的节点，比如代码节点，用户可以在上面配置一段代码，执行自定义的逻辑。

按需组织节点，灵活实现证书管理的目标​

传统表单还有个问题，就是一旦设计好，对所有的用户都一视同仁。但这种一视同仁，对有些用户来说，提供的能力过多了，对另外一些用户来说，又过少了。而灵活组织节点，可以解决这些用户的问题。

功能过多了​

从项目中的Issues中可以看到，有些用户只想使用Certimate申请证书，并不想部署证书。而又些用户只想使用Certimate的部署证书的能力部署自己的购买的证书。

当他们面对表单时，即要填写申请相关的信息，又要填写部署相关的信息，这对他们来说可能是不必要的。

在v0.3中，我们可能自定义工作流中的节点，添加需要的节点，删除不必要的节点，以达成自己的目标。

功能过少了​

对于另一部分用户来说，他可能想要达到更多的目标，比如：一个流程可以申请任意多个域名的证书，同时每个证书可以部署到任意多个服务。这个时候就可以使用现有的分支节点，分支节点可以理解为子工作流，理论上工作流可以无限嵌套，但是并不推荐这样做。

同时未来我们会实现更多的节点类型，用户可以基于自己的需求，组装自己的工作流。

总结​

Certimate v0.3 中我们引入工作流的概念，帮助用户灵活的实现证书管理的目标，同时有利于后续Certimate 能力的扩展。

鸣谢​

特别感谢 @Fudiwei 大佬对本项目的鼎力支持！

由于工作原因，我本人仅在 v0.3 初期完成了工作流的基本流程搭建。后续的诸多关键工作，包括将 UI 从 shadcn 替换为 antd、支持更多的 provider、代码优化等，几乎全部由 @Fudiwei 独力完成。 这是一项完全无收益的开源项目，但他仍然倾注了大量的时间与精力，非常令人敬佩。再次向 Fudiwei 表示由衷的感谢！

Certimate 作为作者工作中提升工作效率的工具，很好的符合了我个人的工作场景。但是在开源后，遇到了五花八门的需求，这些需求对应的场景有些是我不曾考虑到的。 这就导致在满足各种需求的同时，很难做到完全向后兼容，所以就出现了第一个不向后兼容的版本：v0.2.0.

v0.2.0 的主要特性如下：

• 域名编辑分为申请配置和部署配置 2 个阶段，申请配置支持更多选项。
• 一个域名配置可以添加 0 或多个部署。
• 授权和部署阶段需要的字段拆分，授权只维护授权信息。

域名编辑分为申请配置和部署配置 2 个阶段​

老版本域名编辑分为基础设置和高级设置，其实让人觉得很奇怪，到底什么是基础设置，什么是高级设置？ v0.2.0 根据阶段的不同，将域名编辑分为了 2 个阶段，分别是申请配置和部署配置。 申请配置只配置和申请相关的信息，如域名、邮箱、申请授权等。

部署配置主要是配置和部署相关的信息，如证书路径、部署命令、部署授权等。

一个域名配置可以添加 0 或多个部署​

有的用户只是想把 certimate 作为申请证书的工具并不想部署证书，有的用户又想把一个证书部署到多个服务上，比如泛域名。

之前一个域名配置只能添加 1 个部署，且必须有 1 个部署，所以老版本并不能满足上述场景。

v0.2.0 支持一个域名配置添加 0 或多个部署，这样就可以满足上述场景了，而且老版本的授权组也不需要了。

授权和部署阶段需要的字段拆分，授权只维护授权信息​

老版本中有点部署阶段需要的字段是和授权信息混杂在一起的，比如 ssh授权，老版本中除了需要填写host、port、username、password等信息外，还需要填写部署命令、证书路径等信息。 这种设计本身是不合理的，首先理论上来说部署命令和证书路径等信息就不属于授权信息，另外也导致授权信息不能复用，即使 2 张证书要部署到同一个服务器，也需要填写2次授权信息。

v0.2.0 将授权和部署阶段需要的字段拆分，授权只维护授权信息，部署阶段需要的字段在域名配置的部署配置中填写，这样老版本中域名变量也不需要了。

总结​

综上所述，v0.2.0 是一个不向后兼容的版本，但是它的主要特性是为了满足更多的用户需求以及方便后续扩展。 老版本的用户可以继续使用老版本，也可以选择升级到 v0.2.0，但是要重新配置一遍。

我在平时的工作过程中要管理多个站点，这些站点基本都部署在各种 CDN 上，在国内，所有厂商的服务都不会自动给你的域名添加证书，这就需要我定期的去操作，非常麻烦的同时也容易忘掉，这就是我为什么要写 Certimate 的原因。

支持了我的常用场景后，我便将 Certimate 开源了，越来越多的用户开始反馈，他们也需要将证书部署到自己的主机上，最初的版本只支持一个证书部署到到一个主机上，这就和实际的用户需求有了冲突。

用户的实际需求是：

• 1 个证书可以部署到多个主机上，如泛域名、或者负载均衡等场景。
• 多个证书可以部署到 1 个主机上，如1 个主机上有多个服务的场景。

因此，Certimate 支持了域名变量和部署授权组的概念，以便满足用户的需求。

域名变量​

域名变量是指和域名相关的变量，在申请证书成功后，部署时会将域名变量替换到部署命令中，从而实现多个证书部署到1个主机上的场景。

使用方法​

• 在添加/编辑域名页面中，点击高级设置，在变量输入框中输入变量，变量的格式为 key=val，如有多个变量用;号分隔。示例：

key1=val1;
key2=val2;

• 在部署授权中，证书的路径、以及命令中可以使用变量，使用方法为 ${key1}，示例：

部署授予权组​

部署授权组是指将多个 SSH主机的授权合并到同一个组中，在填写域名信息时，可以选择某个授权组，在部署时就会将证书部署到该授权组中的所有主机上。

使用方法​

• 点击 部署授权组菜单，点击新增授权组，填写授权组名称，点击保存。
• 在添加/编辑授权时，选择你之前添加的授权组。目前只支持 SSH 授权。
• 在添加/编辑域名时，点击 高级设置选择你之前添加的授权组。

总结​

以上便是 Certimate 的域名变量和部署授权组的功能，希望能帮助到更多的用户。

Certimate 开源后，我收到了很多用户的反馈。其中有一些诸如：为什么不用 Caddy呢？除了有 UI外它和 acme.sh有什么区别呢？这里写一篇文章来解释一下。

有这种疑问，我觉得主要是工作场景单一限制了想象力。理由如下：

1. 服务或者网站只部署在主机上，没有考虑到还有部署到 CDN 和其它服务上的情况。
2. 只考虑到自己的技术能力，没有考虑其它同事可能登录服务器都困难的情况。
3. 更易用不是更好吗？

服务不只部署在主机上​

在当前的前后端分离的技术背景下，同时为了节省服务器资源，前端服务或者网站可能会选择部署在 CDN、对象存储等服务上。后端API也可能会在前面接一个负载均衡服务。

虽然用过国外服务的用户都知道，国外的服务基本上都会自动给你的域名添加证书，但是国内的服务就是要手动添加证书的。

另外，在公司内部，工具选择上有的时候我们也身不由己，你真的觉得你一定会被允许使用 Caddy 吗？

这些场景下，Caddy、acme.sh 等工具就无法满足需求了。

考虑一下小白的感受​

Caddy 配置好以后就可以自动获取证书了，这里不做讨论。

acme.sh 对于有一定技术能力的人来说还是能轻松上手的，但是对于登录服务器都困难的人来说，还是需要一定的时间去学习。这个时候有个易用的 UI就可以让技术能力没那么强的人也能轻松上手。 只需要根据 UI 提示填写信息，然后点击部署即可。

更易用不是更好吗？​

即便你技术能力很强，让生活变得理简单不是更好吗？

如果你管理的站点有多个，你哼哧哼哧的一个个服务器的去登录，安装、配置 acme.sh，突然有一天又要下线某几个站点，你又要一个个去登录，卸载 acme.sh，是不是觉得很麻烦？

这时个如果有1 个可以统一调度的、易用的 UI 工具，是不是就可以让你更轻松的管理你的站点了？🐶

总结​

综上所述，不同的场景可以选择不同的工具。

如果你只有一个服务/站点需要管理，且你的技术能力很强，那就用 Caddy、acme.sh 吧。如果你有多个服务/站点需要管理，甚至站点都不是部署在主机上，或者你就是想简单一点，Certimate 将是你更好的选择。

Hellow world!​