为什么个人项目我更推荐使用Caddy?
为什么个人项目我更推荐使用Caddy?
- 为什么个人项目我更推荐使用Caddy?
- 前言
- 什么是
Caddy? Caddy是够用且省心的- 简单的配置
- 自动化
https - 结尾
- 参考链接
前言
最近我把自己一些项目里面的 nginx 换成了 caddy，运转相当良好，比较开心，所以写了这篇文章，也推荐给大家使用。
什么是Caddy?
Caddy 和 nginx 一样，也是一个非常棒的跨平台 web server，它是用 go 写的，而 nginx 则是 c。核心功能上比较类似。
谁更牛逼？很明显是 nginx，nginx功能多，性能强，而且还有 OpenResty 这种神级项目(国人章亦春大佬写的)，这个第一，绝对是当之无愧的。
那么nginx这么强，为啥要换成Caddy呢？
Caddy是够用且省心的
对我们个人项目而言，很多时候往往只需要用到 web server 中的一小部分功能，比如重要的反向代理，https，或者设置额外的 Header，又或者前端那种 history 路由，设置的 try_files 策略等等…
这些功能，往往都已经内置在各个成熟的 web server 内部功能中，我们只需要添加对应的配置，就能够开启并进行使用。
另外相比 nginx，虽然 Caddy 性能差一点(对应有benchmark)，但是够用。更重要的是，Caddy 使用起来足够的省心。这个特点主要体现在，足够简单的配置文件和校验和自动化的 https.
简单的配置
是的，Caddy 的配置文件: Caddyfile 非常的简单且语义化, 它由一个一个可嵌套的块 (block) 组成:
Caddy 内部也提供了格式化和校验配置文件合法性的cli命令。而且它还内置了一套 admin 的 restful api 用来动态的改变配置。
而且它为了适配各种配置格式，还维护了不少的配置文件适配器，比如nginx-adapter,caddy-mysql-adapter
等等。
不过笔者尝试过直接用 nginx.conf 直接起 Caddy，效果一般，还是推荐用官方最原生的 Caddyfile 以避免转化过程中出现的奇奇怪怪的问题。
比如你从 nginx 迁移过来：
location / {
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://localhost:port;
}
在 Caddyfile 里就可以这样写:
example.com {
# reverse_proxy 和 localhost:port 中间有个 []
# 这里不写代表 all，和 glob 里的 * 同理
# 你也可以显式配置成自己想要的，比如 /api/*
reverse_proxy localhost:port
}
为什么没有设置 Host，X-Forwarded-For？因为 Caddy 默认自动设置好了这些 Header。而且这个配置同时也设置好了 websocket，而 nginx 还要去配置一些协议升级到http 1.1的配置块。
自动化 https
这个可能是 Caddy 的一大特色之一了，正如官方宣传的那样：
Caddy is the first and only web server to use HTTPS automatically and by default.
然而，实际上早就有很多自动化的https项目了，比如nginx + acme.sh/ certbot 也能做到啊。
是的，都可以做到，只不过 Caddy 是直接内置了 ACME protocol server 处理方法，默认开启，而且配置也极其简单。
比如nginx+acme.sh,我们需要配置 nginx 配置的 ssl目录，然后执行 acme.sh 成功之后，还要 systemctl reload nginx.service 即:
acme.sh --install-cert -d mydomain.com \
--cert-file /etc/nginx/certs/mydomain.com/cert \
--key-file /etc/nginx/certs/mydomain.com/key \
--fullchain-file /etc/nginx/certs/mydomain.com/fullchain \
--reloadcmd "systemctl reload nginx.service"
假如 nginx 运行在一个容器里，那就需要给所在容器打上 label，然后设置许多的环境变量。假如你使用 neilpang/acme.sh 镜像，也需要很多的额外操作，容易卡壳，这对我们开发者来说，显然大大提升了错误发生的可能，开发体验不够友好。
而 Caddy 呢，直接帮你把所有站点的 https 给配置好了，同时连 80 跳 443 的策略也弄好了（可关闭此策略）。省去了调试配置的时间，是为省心。
值得注意的是，对于本地的 hostname 和 ip地址，Caddy 的自动 https 策略，是直接生成自签名 ssl 证书，它会向你要求一定的权限，需要你进行授权。
而对于可被DNS解析的域名,它就会去请求免费证书了，如下图所示：
它会去 Let's Encrypt 申请 90 天的免费证书，并自动进行续期，我们大部分时候都不需要去管它。
结尾
看到这，你应该知道使用 Caddy 的好处了，对于熟悉 nginx 的我们来说，迁移到它的成本很低。如果你和我一样是一个懒人，推荐你也来试一试。
参考链接
https://github.com/caddyserver/nginx-adapter
https://www.rmedgar.com/blog/using-acme-sh-with-nginx/
https://github.com/acmesh-official/acme.sh/wiki/deploy-to-docker-containers
https://caddyserver.com/docs/caddyfile-tutorial
https://caddyserver.com/docs/caddyfile