为什么个人项目我更推荐使用Caddy?[通俗易懂]

为什么个人项目我更推荐使用Caddy?[通俗易懂]最近我把自己一些项目里面的nginx换成了caddy,运转相当良好,比较开心,所以写了这篇文章,也推荐给大家使用

Image

为什么个人项目我更推荐使用Caddy?

前言

最近我把自己一些项目里面的 nginx 换成了 caddy,运转相当良好,比较开心,所以写了这篇文章,也推荐给大家使用。

什么是Caddy?

Caddynginx 一样,也是一个非常棒的跨平台 web server,它是用 go 写的,而 nginx 则是 c。核心功能上比较类似。

谁更牛逼?很明显是 nginxnginx功能多,性能强,而且还有 OpenResty 这种神级项目(国人章亦春大佬写的),这个第一,绝对是当之无愧的。

那么nginx这么强,为啥要换成Caddy呢?

Caddy是够用且省心的

对我们个人项目而言,很多时候往往只需要用到 web server 中的一小部分功能,比如重要的反向代理,https,或者设置额外的 Header,又或者前端那种 history 路由,设置的 try_files 策略等等…

这些功能,往往都已经内置在各个成熟的 web server 内部功能中,我们只需要添加对应的配置,就能够开启并进行使用。

另外相比 nginx,虽然 Caddy 性能差一点(对应有benchmark),但是够用。更重要的是,Caddy 使用起来足够的省心。这个特点主要体现在,足够简单的配置文件和校验和自动化的 https.

简单的配置

是的,Caddy 的配置文件: Caddyfile 非常的简单且语义化, 它由一个一个可嵌套的块 (block) 组成:

Image

Caddy 内部也提供了格式化和校验配置文件合法性的cli命令。而且它还内置了一套 adminrestful 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 中间有个 [<matcher>] 
    # 这里不写代表 all,和 glob 里的 * 同理
    # 你也可以显式配置成自己想要的,比如 /api/*
    reverse_proxy localhost:port
}

为什么没有设置 HostX-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 给配置好了,同时连 80443 的策略也弄好了(可关闭此策略)。省去了调试配置的时间,是为省心。

值得注意的是,对于本地的 hostnameip地址Caddy 的自动 https 策略,是直接生成自签名 ssl 证书,它会向你要求一定的权限,需要你进行授权。

而对于可被DNS解析的域名,它就会去请求免费证书了,如下图所示:

Image

它会去 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

今天的文章为什么个人项目我更推荐使用Caddy?[通俗易懂]分享到此就结束了,感谢您的阅读。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
如需转载请保留出处:https://bianchenghao.cn/86315.html

(0)
编程小号编程小号

相关推荐

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注