anubu

现状是正确的，归因是错误的。
OP 的结论是厂家故意把消费者骗进来杀，实际上产品厂家和安装服务是 2 个独立的利益主体，甚至有点冲突。安装服务本身就是一个非标的场景，OP 的意思应该是厂家应该提高售价，把这个非标环节包含进去，这个其实去买高端品牌应该可以缓解。走量的低端品牌，每个环节都要精打细算，不会算的都被市场淘汰了。

个人感觉还挺好用，最近 hy3 免费，基本常开了。比较适合干一些运维杂活，最近的 2 个会话：
- 在 2 个内网自建的 Nexus 实例间迁移 maven snapshots 制品，弄了十来分钟，算是一次性完成。
- 从 AzureDevOpsServer 中迁移 git 仓库到 gitea 实例，几百个仓库，半个小时迁移完成。
都是些零碎脏活，自己弄要翻 API 写脚本，怎么都要半天一天的，免费的 hy3 还没碰到排队，还要什么自行车。

@NealLason 从 gitlab runner 迁移到 Jenkins 还是挺更新我的认识的，以前总认为这是个反向操作。

感谢分享。
说一个我用此类工具的痛点，关于 DNS-01 验证的权限问题。涉及到和域名解析服务商 API 交互，几乎没有工具明确说明自己需要哪些权限，如何精细化控制权限。把整个域名解析能力交给一个第三方应用是很大的风险点，没有强背书的话，很难忽略这个风险。当然，可以自己根据服务商 API 文档自行摸索出一个最小权限，但真的很繁琐，甚至你看了半天文档，然后确认 API 权限不支持，无法缩小最小权限。如果工具本身有明确的说明，或更进一步对主流服务商有一个各自的权限配置示例，体验会好很多，可以节省很多风险评估时间。
上面只是说签发层面，全流程的话，第三方应用直接更新生产环境证书也是个风险点，各个环节都要认真评估才好。

easytier 还是更好用一些，在项目质量和信任背书层面，可能和商业公司支持的项目有些差距，但个人使用已经足够了，似乎也有很多基于这些开源项目做商业产品的。


@5261 是的，最简单的理解就是多点跨公网组成一个虚拟二层网络，这个基本就满足了大部分使用了。在这之上增加各种使用场景比如 DNS 、路由什么的。

还是有一些变通方案的，要从服务端和客户端两方面分析。
- 服务端就是缓存服务本身，比如 registry:2 ，是可以正常代理缓存非 docker.io 的上游仓库，配置环境变量即可。麻烦的是如果要缓存多个上游就要启动多个 registry ，还需要考虑前面放个反向代理和域名路由问题。也可以考虑 zot 、Harbor 类的方案。
- 客户端就比较多了，docker 的 mirror 配置仅对 docker.io 这个默认仓库生效。一个方法就是把其它仓库配置为 insecure-registries ，然后本地 hosts 劫持到上面部署的 registry 缓存代理上。如果是 nerdctl+containerd 就方便多了，自身的 mirror 配置比较丰富。可能还会涉及到 k3s 或 k8s 场景，mirror 配置上可能会多一层考虑，或直接使用底层的 containerd 。其它客户端 podman 、skopeo 、crane 等需要根据情况自行研究了。

看上去能解决问题，实际上的确是复杂了一些。这个场景目前的确没有一个共识的最佳实践，只能根据自己具体场景来摸索调整。

每个阶段有每个阶段的难处，但只要生一次病你就明白了，只要不生病，都算好带😂

根据小红书上的趋势，收货地址写市场监督管理局，是某某发明的吓唬商家的做法，不一定是真的。