关于linux:一个比-Nginx-功能更强大的-Web-服务器

9次阅读

共计 9410 个字符，预计需要花费 24 分钟才能阅读完成。

Caddy 是一个 Go 编写的 Web 服务器，相似于 Nginx，Caddy 提供了更加弱小的性能，随着 v2 版本公布 Caddy 曾经能够作为中小型站点 Web 服务器的另一个抉择；相较于 Nginx 来说应用 Caddy 的劣势如下:

主动的 HTTPS 证书申请(ACME HTTP/DNS 挑战)
主动证书续期以及 OCSP stapling 等
更高的安全性包含但不限于 TLS 配置以及内存平安等
敌对且弱小的配置文件反对
反对 API 动静调整配置(有木有人能够搞个 Dashboard)
反对 HTTP3(QUIC)
反对动静后端，例如连贯 Consul、作为 k8s ingress 等
后端多种负载策略以及衰弱检测等
自身 Go 编写，高度模块化的零碎不便扩大(CoreDNS 基于 Caddy1 开发)
……

就目前来说，Caddy 对于我集体印象惟一的毛病就是性能没有 Nginx 高，然而这是个仁者见仁智者见智的问题；相较于提供的这些便利性，在性能可承受的状况下齐全有理由切换到 Caddy。

留神: 在 Caddy1 时代，Caddy 官网公布的预编译二进制文件是不容许进行商业应用的，Caddy2 当前曾经全副切换到 Apache 2.0 License。

在默认状况下 Caddy2 官网提供了预编译的二进制文件，以及自定义 build 下载页面，不过对于须要集成一些第三方插件时，咱们仍需采纳官网提供的 xcaddy 来进行自行编译；以下为具体的编译过程:

本局部编译环境默认为 Ubuntu 20.04 零碎，同时应用 root 用户，其余环境请自行调整相干目录以及配置；编译时自行处理好迷信上网相干配置，也能够间接用国外 VPS 服务器编译。

首先下载 go 语言的 SDK 压缩包，其余平台能够从 https://golang.org/dl/ 下载对应的压缩包:

wget https://golang.org/dl/go1.15.6.linux-amd64.tar.gz

下载实现后解压并配置相干变量:

# 解压
tar -zxvf go1.15.6.linux-amd64.tar.gz
# 挪动到任意目录
mkdir -p /opt/devtools
mv go /opt/devtools/go
# 创立 go 相干目录
mkdir -p ${HOME}/gopath/{src,bin,pkg}
# 调整变量配置，将以下变量退出到 shell 初始化配置中
# bash 用户请编辑 ~/.bashrc
# zsh 用户请编辑 ~/.zshrc
export GOROOT='/opt/devtools/go'
export GOPATH="${HOME}/gopath"
export GOPROXY='https://goproxy.cn' # 如果曾经解决了迷信上网问题，GOPROXY 变量能够删除，否则可能会起副作用
export PATH="${GOROOT}/bin:${GOPATH}/bin:${PATH}"
# 让配置失效
# bash 用户替换成 ~/.basrc
# 从新退出登录也能够
source ~/.zshrc

配置实现后，应该在命令行执行 go version 并有以下胜利返回:

bleem ➜ ~ go version
go version go1.15.6 linux/amd64

依照官网文档间接命令行执行 go get -u github.com/caddyserver/xcaddy/cmd/xcaddy 装置即可:

bleem ➜ ~ go get -u github.com/caddyserver/xcaddy/cmd/xcaddy
go: downloading github.com/caddyserver/xcaddy v0.1.7
go: found github.com/caddyserver/xcaddy/cmd/xcaddy in github.com/caddyserver/xcaddy v0.1.7
go: downloading github.com/Masterminds/semver/v3 v3.1.0
go: github.com/Masterminds/semver/v3 upgrade => v3.1.1
go: downloading github.com/Masterminds/semver/v3 v3.1.1
.....

装置实现后该当在命令行能够间接执行 xcaddy 命令:

# xcaddy 并没有提供欠缺的命令行反对，所以 `--help` 报错很失常
bleem ➜  ~ xcaddy --help
go: cannot match "all": working directory is not part of a module
2021/01/07 12:15:56 [ERROR] exec [go list -m -f={{if .Replace}}{{.Path}} => {{.Replace}}{{end}} all]: exit status 1:

编译之前零碎须要装置 jq、curl、git 命令，没有的请应用

apt install -y curl git jq

命令装置；

自行编译的目标是减少第三方插件方便使用，其中官网列出的插件能够从 Download 页面获取到:

其余插件能够从 GitHub 上寻找或者自行编写，整顿好这些插件列表当前只须要应用 xcaddy 编译即可:

# 获取最新版本号，其实间接去 GitHub realse 页复制一下就行
# 这里转化为脚本是为了不便自动化
export version=$(curl -s "https://api.github.com/repos/caddyserver/caddy/releases/latest" | jq -r .tag_name)
# 应用 xcaddy 编译
xcaddy build ${version} --output ./caddy_${version} 
        --with github.com/abiosoft/caddy-exec 
        --with github.com/caddy-dns/cloudflare 
        --with github.com/caddy-dns/dnspod 
        --with github.com/caddy-dns/duckdns 
        --with github.com/caddy-dns/gandi 
        --with github.com/caddy-dns/route53 
        --with github.com/greenpau/caddy-auth-jwt 
        --with github.com/greenpau/caddy-auth-portal 
        --with github.com/greenpau/caddy-trace 
        --with github.com/hairyhenderson/caddy-teapot-module 
        --with github.com/kirsch33/realip 
        --with github.com/porech/caddy-maxmind-geolocation 
        --with github.com/caddyserver/format-encoder 
        --with github.com/mholt/caddy-webdav

编译过程日志如下所示，稍等片刻后将会生成编译好的二进制文件:

编译胜利后能够通过 list-modules 子命令查看被增加的插件是否胜利编译到了 caddy 中:

bleem ➜  ~ ./caddy_v2.3.0 list-modules
admin.api.load
admin.api.metrics
caddy.adapters.caddyfile
caddy.listeners.tls
caddy.logging.encoders.console
caddy.logging.encoders.filter
caddy.logging.encoders.filter.delete
caddy.logging.encoders.filter.ip_mask
caddy.logging.encoders.formatted
caddy.logging.encoders.json
caddy.logging.encoders.logfmt
caddy.logging.encoders.single_field
caddy.logging.writers.discard
caddy.logging.writers.file
caddy.logging.writers.net
caddy.logging.writers.stderr
caddy.logging.writers.stdout
caddy.storage.file_system
dns.providers.cloudflare
dns.providers.dnspod
dns.providers.duckdns
dns.providers.gandi
dns.providers.route53
exec
http
http.authentication.hashes.bcrypt
http.authentication.hashes.scrypt
http.authentication.providers.http_basic
http.authentication.providers.jwt
......

宿主机装置 Caddy2 须要应用 systemd 进行守护，侥幸的是 Caddy2 官网提供了各种平台的安装包以及 systemd 配置文件仓库；目前举荐的形式是间接采纳包管理器装置规范版本的 Caddy2，而后替换自编译的可执行文件:

# 装置规范版本 Caddy2
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/cfg/gpg/gpg.155B6D79CA56EA34.key' | sudo apt-key add -
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/cfg/setup/config.deb.txt?distro=debian&version=any-version' | sudo tee -a /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy
# 替换二进制文件
systemctl stop caddy
rm -f /usr/bin/caddy
mv ./caddy_v2.3.0 /usr/bin/caddy

Docker 用户能够通过 Dockerfile 自行编译 image，目前我编写了一个基于 xcaddy 的 Dockerfile，如果有其余插件须要集成自行批改从新编译即可；以后 Dockerfile 预编译的镜像曾经推送到了 Docker Hub 中，镜像名称为 mritd/caddy。

Caddy2 的配置文件外围采纳 json，然而 json 可读性不强，所以官网保护了一个转换器，形象出称之为 Caddyfile 的新配置格局；对于 Caddyfile 的残缺语法请查看官网文档 https://caddyserver.com/docs/…，本文仅做一些根本应用的样例。

Caddyfile 反对相似代码中 function 一样的配置片段，这些配置片段能够在任意地位被 import，同时能够承受参数，以下为配置片断示例:

# 括号内为片段名称，能够自行定义
(TLS) {
    protocols tls1.2 tls1.3
    ciphers TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
}
# 在任意地位能够援用此片段从而达到配置复用
import TLS

import 指令除了反对援用配置片段以外，还反对援用内部文件，同时反对通配符，有了这个命令当前咱们就能够不便的将配置文件进行模块化解决:

# 援用内部的 /etc/caddy/*.caddy
import /etc/caddy/*.caddy

针对于站点域名配置，Caddyfile 比拟自由化，其格局如下:

地址 {站点配置}

对于这个“地址”承受多种格局，以下都为非法的地址格局:

localhost
example.com
:443
http://example.com
localhost:8080
127.0.0.1
[::1]:2015
example.com/foo/*
*.example.com
http://

Caddyfile 反对间接援用零碎环境变量，通过此性能能够将一些敏感信息从配置文件中剔除:

# 援用环境变量 GANDI_API_TOKEN
dns gandi {$GANDI_API_TOKEN}

针对于配置片段，Caddyfile 还反对相似于函数代码的参数反对，通过参数反对能够让内部援用时动静批改配置信息:

(LOG) {
    log {
        format json  {time_format "iso8601"}
        # "{args.0}" 援用传入的第一个参数，此处用于动静传入日志文件名称
        output file "{args.0}" {
            roll_size 100mb
            roll_keep 3
            roll_keep_for 7d
        }
    }
}
# 援用片段
import LOG "/data/logs/mritd.com.log"

在启动 Caddy2 之前，如果指标域名 (例如: www.example.com) 曾经解析到了本机，那么 Caddy2 启动后会尝试主动通过 ACME HTTP 挑战申请证书；如果冀望应用 DNS 的形式申请证书则须要其余 DNS 插件反对，比方下面编译的 –with github.com/caddy-dns/gandi 为 gandi 服务商的 DNS 插件；对于应用 DNS 挑战的配置编写形式须要具体去看其插件文档，目前 gandi 的配置如下:

tls {dns gandi {env.GANDI_API_TOKEN}
}

配置实现后 Caddy2 会通过 ACME DNS 挑战申请证书，值得注意的是即便通过 DNS 申请证书默认也不会申请泛域名证书，如果想要调整这种细节配置请应用 json 配置或治理 API。

理解了以上根底配置信息，咱们就能够理论编写一个站点配置了；以下为本站的 Caddy 配置样例:

目录构造:

caddy
├── Caddyfile
├── mritd.com.caddy
└── mritd.me.caddy

Caddyfile

Caddyfile 次要蕴含一些通用的配置，并将其抽到配置片段中，相似于 nginx 的 nginx.conf 主配置；在最初局部通过 import 关键字引入其余具体站点配置，相似 nginx 的 vhost 配置。

(LOG) {
    log {
        # 日志格局参考 https://github.com/caddyserver/format-encoder 插件文档
        format formatted "[{ts}] {request>remote_addr} {request>proto} {request>method} <- {status} -> {request>host} {request>uri} {request>headers>User-Agent>[0]}"  {time_format "iso8601"}
        output file "{args.0}" {
            roll_size 100mb
            roll_keep 3
            roll_keep_for 7d
        }
    }
}
(TLS) {
    # TLS 配置采纳 https://mozilla.github.io/server-side-tls/ssl-config-generator/ 生成，SSL Labs 评分 A+
    protocols tls1.2 tls1.3
    ciphers TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
}
(HSTS) {# HSTS (63072000 seconds)
    header / Strict-Transport-Security "max-age=63072000"
}
(ACME_GANDI) {
    # 从环境变量获取 GANDI_API_TOKEN
    dns gandi {$GANDI_API_TOKEN}
}
# 聚合下面的配置片段为新的片段
(COMMON_CONFIG) {
    # 压缩反对
    encode zstd gzip
    # TLS 配置
    tls {
        import TLS
        import ACME_GANDI
    }
    # HSTS
    import HSTS
}
# 开启 HTTP3 实验性反对
{
    servers :443 {
        protocol {experimental_http3}
    }
}
# 引入其余具体的站点配置
import /etc/caddy/*.caddy

mritd.com.caddy

mritd.com.caddy 为主站点配置，主站点配置内次要编写一些路由规定，TLS 等都从配置片段引入，这样能够放弃对立。

www.mritd.com {# 重定向到 mritd.com(默认 302)
    redir https://mritd.com{uri}
    # 日志
    import LOG "/data/logs/mritd.com.log"
    # TLS、HSTS、ACME 等通用配置
    import COMMON_CONFIG
}
mritd.com {
    # 路由
    route /* {reverse_proxy mritd_com:80}
    # 日志
    import LOG "/data/logs/mritd.com.log"
    # TLS、HSTS、ACME 等通用配置
    import COMMON_CONFIG
}

mritd.me.caddy

mritd.me.caddy 为老站点配置，目前次要将其 301 到新站点即可。

www.mritd.me {
    # 重定向到 mritd.com
    # 最初的 "code" 反对三种参数
    # temporary => 302
    # permanent => 301
    # html => HTML document redirect
    redir https://mritd.com{uri} permanent
    # 日志
    import LOG "/data/logs/mritd.com.log"
    # TLS、HSTS、ACME 等通用配置
    import COMMON_CONFIG
}
mritd.me {
    # 重定向
    redir https://mritd.com{uri} permanent
    # 日志
    import LOG "/data/logs/mritd.com.log"
    # TLS、HSTS、ACME 等通用配置
    import COMMON_CONFIG
}

启动与重载

配置文件编写实现后，通过 systemctl start caddy 可启动 caddy 服务器；每次配置批改后能够通过 systemctl reload caddy 进行配置重载，重载期间 caddy 不会重启(实际上调用 caddy reload 命令)，当配置文件书写谬误时，重载只会失败，不会影响正在运行的 caddy 服务器。

本文只是列举了一些简略的 Caddy 应用样例，在弱小的插件配合下，Caddy 能够实现各种“神奇”的性能，这些性能依赖于简单的 Caddy 配置，Caddy 配置须要仔细阅读官网文档，对于 Caddyfile 的每个配置段在文档中都有具体的形容。

值得一提的是 Caddy 自身内置了丰盛的插件，例如内置“file_server”、内置各种负载平衡策略等，这些插件组合在一起能够实现一些简单的性能；Caddy 是采纳 go 编写的，官网也给出了具体的开发文档，相较于 Nginx 来说通过 Lua 或者 C 来开发编写插件来说，Caddy 的插件开发上手要容易得多；Caddy 自身针对数据存储、动静后端、配置文件转换等都内置了扩大接口，这为有特定需要的扩大开发打下了良好基础。

最终总结，综合来看目前 Caddy2 的性能损失可承受的状况下，相较于 Nginx 相对是个绝佳抉择，各种新性能都可能满足现代化 Web 站点的需要，真香正告。

原文：https://mritd.com/2021/01/07/…

正文完

linux

发表至： linux

2021-02-02

0

关于SegmentFault:Linux系统中删除目录中的文件夹和文件的方法有哪些呢

关于linux:程序人生-Linux-Daemon-程序设计示例

关于linux:查看当前-linux-主机支持什么类型的硬件解码

Linux软件安装

关于javascript:可能是东半球最好看的vue3日历组件vuebaiducalendar

关于linux:一个比-Nginx-功能更强大的-Web-服务器

Caddy 简介

编译 Caddy2

Golang 环境装置

装置 xcaddy

编译 Caddy2

装置 Caddy2

宿主机装置

Docker 装置

配置 Caddy2

配置片段

配置模块化

站点配置

环境变量

配置片段参数反对

主动证书申请

残缺模块化配置样例

总结

站内搜索