实际上就是一个尝试,毕竟如果生产使用了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.servicehttps://github.com/caddyserver/dist/blob/master/init/caddy.service
标签:tls,存储,acme,s3,配置,玩法,实践,caddyserver From: https://blog.51cto.com/rongfengliang/6026183