anubu

@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 等需要根据情况自行研究了。

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

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

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

- 端正认识。婆媳关系的核心就是你，没有你，她们就是两个陌生的女人，没有任何交集。因为你，才产生了婆媳关系。所以，这是你的问题，不是两个女人的问题，不要像个局外人似的。
- 母亲可以管教自己的儿子，但不能管教儿子的的家庭。不管能不能意识到，认不认可，这都是底线。
- 物理隔离可以降低游戏难度，有条件的话还是加点外挂吧。

一言难尽，感觉你在圈养你的爱人。人其实很容易被圈养的，特别是女人。你怎么想的是一回事，你实际做了又是另一回事。真要崩盘的话，很容易触发极端行为，还是趁早干预比较好。

害怕她受气，就不让她上班，真的是非常错误的认识和选择。成年人一定要认识现实生活，这样才能对世界有真正的理解，哪怕有偏差，那也是自己认知的一部分。

我们家的家务是不区分的，默契的轮换着干，也没有严格的计算，基本所有家务两个人都干过，一方面这是生活的一部分，另一方面只有真正动手干过才知道具体的问题，就不会在那里大放厥词，指手画脚，惹人生厌。

家庭要和谐，一定要有“一起”的概念，是一起生活，一起经历事情，一起度过时光的，而不是简单的只是在时间和空间上有重叠而已。