caddyserver 生产运行一种玩法实践
实际上就是一个尝试，毕竟如果生产使用了caddyserver 做为一些核心业务只是需要做不少考虑的
参考图
备注：以上图是基于自建acme 服务处理的（比较适合内部服务），因为caddyserver 同时存储tls 配置以及基于api 的配置，所有对于单机部署模式有一些调整，后边介绍
集成说明
- acme 是自建的服务，基于了step-ca 对于step-ca 为了实现ha 部署，使用了db 进行配置存储，具体可以参考官方文档，或者我写的一些简单实践
- 因为caddyserver 会自己进行tls的配置（利用了acme），我们为了灵活的支持多种域名证书集成了step-ca，同时因为存在多实例节点将tls存储在s3中
- 基于api 的配置，需要复用（服务重启之后）所以开启了--resume，因为配置需要在多个节点进行复用，使用了juicefs，存储哪些autosave.json（复用了db 以及s3 组件）
- 配置还加载之后还需要进行reload，可以使用caddy 的reload 能力（可以通过ansbile 或者支持ssh 能力的cli 工具）
- 实际运行节点，需要通过守护进程玩法（linux 可以基于systemd）
备注：实际上以上关于tls部署，可以不用使用s3，但是使用了s3 方便存储复用以及管理，对于autosave.json 也是可以不用juicefs，nfs 也是可以的，或者就不使用共享存储了，一个节点配置，然后通过分发也行，当然还有一种方法就是使用agent 模式，进行拉取同步（每次调整一个配置文件），而且对于业务规模较大的玩法可以使用多集群部署
说明
以上是一个简单玩法的尝试，实际上这个东西比较灵活可以随意组合，实现灵活的系统管理，同时基于acme 对于系统进行tls 的支持，目前caddyserver 功能是越来越强大了
参考资料
https://caddyserver.com/docs/json/
https://github.com/caddyserver/dist/blob/master/init/caddy-api.service
https://github.com/caddyserver/dist/blob/master/init/caddy.service
