入门指南
欢迎使用 Caddy!本教程将探索 Caddy 的基础用法,帮助您从高层次了解它。
目标:
- 🔲 运行守护进程
- 🔲 尝试 API
- 🔲 给 Caddy 一个配置
- 🔲 测试配置
- 🔲 创建 Caddyfile
- 🔲 使用配置适配器
- 🔲 使用初始配置启动
- 🔲 比较 JSON 和 Caddyfile
- 🔲 比较 API 和配置文件
- 🔲 在后台运行
- 🔲 零停机配置重载
前提条件:
- 基本的终端/命令行技能
- 基本的文本编辑器技能
- 在 PATH 中有
caddy
和curl
如果您通过包管理器安装了 Caddy,Caddy 可能已经作为服务运行。如果是这样,请在进行本教程之前停止该服务。
让我们开始运行它:
caddy
哎呀;没有子命令时,caddy
命令只显示帮助文本。您可以在任何时候忘记该怎么做时使用它。
要启动 Caddy 作为守护进程,使用 run
子命令:
caddy run
这会永久阻塞,但它到底在做什么?目前...什么都没做。默认情况下,Caddy 的配置("config")是空白的。我们可以在另一个终端中使用管理 API 来验证这一点:
curl localhost:2019/config/
我们可以通过给 Caddy 一个配置来使其变得有用。这可以通过多种方式完成,但我们将在下一节中使用 curl
向 /load 端点发送 POST 请求。
您的第一个配置
为了准备我们的请求,我们需要创建一个配置。Caddy 的配置本质上就是一个 JSON 文档。
将此保存为 JSON 文件(例如 caddy.json
):
{
"apps": {
"http": {
"servers": {
"example": {
"listen": [":2015"],
"routes": [
{
"handle": [{
"handler": "static_response",
"body": "Hello, world!"
}]
}
]
}
}
}
}
}
然后上传它:
curl localhost:2019/load \
-H "Content-Type: application/json" \
-d @caddy.json
我们可以通过另一个 GET 请求验证 Caddy 是否应用了我们的新配置:
curl localhost:2019/config/
通过在浏览器中访问 localhost:2015 或使用 curl
来测试它是否工作:
curl localhost:2015
Hello, world!
如果您看到 Hello, world!,那么恭喜 -- 它工作了!确保您的配置按预期工作总是一个好主意,特别是在部署到生产环境之前。
您的第一个 Caddyfile
对于 Hello World 来说,刚才的操作有点复杂。
配置 Caddy 的另一种方式是使用 Caddyfile。我们上面用 JSON 写的相同配置可以简单地表示为:
:2015
respond "Hello, world!"
将其保存为当前目录中名为 Caddyfile
的文件(无扩展名)。
如果 Caddy 已经在运行,请停止它(Ctrl+C),然后运行:
caddy adapt
或者如果您将 Caddyfile 存储在其他地方或使用了其他名称:
caddy adapt --config /path/to/Caddyfile
您将看到 JSON 输出!这里发生了什么?
我们刚刚使用了一个配置适配器将我们的 Caddyfile 转换为 Caddy 的原生 JSON 结构。
虽然我们可以获取该输出并发出另一个 API 请求,但我们可以跳过所有这些步骤,因为 caddy
命令可以为我们完成。如果当前目录中有一个名为 Caddyfile 的文件且没有指定其他配置,Caddy 将加载 Caddyfile,为我们适配它,并立即运行它。
现在当前文件夹中有了 Caddyfile,让我们再次执行 caddy run
:
caddy run
或者如果您的 Caddyfile 在其他地方:
caddy run --config /path/to/Caddyfile
(如果它的名称不是以 "Caddyfile" 开头,您需要指定 --adapter caddyfile
。)
您现在可以再次尝试加载您的站点,您将看到它正在工作!
如您所见,您可以通过几种方式使用初始配置启动 Caddy:
- 当前目录中名为 Caddyfile 的文件
--config
标志(可选使用--adapter
标志)--resume
标志(如果之前加载了配置)
JSON 与 Caddyfile
现在您知道 Caddyfile 只是为您转换为 JSON。
Caddyfile 似乎比 JSON 更容易,但您是否应该始终使用它?每种方法都有优缺点。答案取决于您的需求和使用场景。
JSON | Caddyfile |
---|---|
易于生成 | 易于手动编写 |
易于编程 | 难以自动化 |
极具表现力 | 中等表现力 |
完整的 Caddy 功能 | 大部分 Caddy 功能 |
允许配置遍历 | 不能在 Caddyfile 内遍历 |
允许部分配置更改 | 只能整体更改配置 |
可以导出 | 不能导出 |
兼容所有 API 端点 | 兼容部分 API 端点 |
文档自动生成 | 文档是手动编写的 |
普遍使用 | 特定用途 |
更高效 | 计算量更大 |
有点无聊 | 有点有趣 |
了解更多:JSON 结构 | 了解更多:Caddyfile 文档 |
您需要决定哪种方式最适合您的使用场景。
重要的是要注意,JSON 和 Caddyfile(以及任何其他支持的配置适配器)都可以与 Caddy 的 API 一起使用。但是,如果您使用 JSON,您将获得 Caddy 的全部功能和 API 特性。如果使用配置适配器,使用 API 加载或更改配置的唯一方式是通过 /load 端点。
API 与配置文件
您还需要决定您的工作流程是基于 API 还是基于 CLI。(您可以在同一服务器上同时使用 API 和配置文件,但我们不推荐这样做:最好有一个真实的来源。)
API | 配置文件 |
---|---|
通过 HTTP 请求更改配置 | 通过 shell 命令更改配置 |
易于扩展 | 难以扩展 |
难以手动管理 | 易于手动管理 |
非常有趣 | 也很有趣 |
了解更多:API 教程 | 了解更多:Caddyfile 教程 |
选择 API 或配置文件工作流程与使用配置适配器是正交的:您可以使用 JSON 但将其存储在文件中并使用命令行界面;相反,您也可以将 Caddyfile 与 API 一起使用。
但大多数人会使用 JSON+API 或 Caddyfile+CLI 的组合。
如您所见,Caddy 非常适合各种使用场景和部署!
启动、停止、运行
由于 Caddy 是一个服务器,它会无限期运行。这意味着在执行 caddy run
后,您的终端将保持阻塞状态,直到进程终止(通常使用 Ctrl+C)。
虽然 caddy run
是最常用的,通常也是推荐的(特别是在制作系统服务时!),但您也可以使用 caddy start
来启动 Caddy 并让它在后台运行:
caddy start
这将让您再次使用终端,这在某些交互式无头环境中很方便。
然后您需要自己停止进程,因为 Ctrl+C 不会为您停止它:
caddy stop
或使用 API 的 /stop 端点。
重载配置
您的服务器可以执行零停机配置重载/更改。
所有加载或更改配置的 API 端点 都是优雅的,可以实现零停机。
但是,当使用命令行时,您可能会想使用 Ctrl+C 来停止服务器,然后重新启动它以获取新配置。不要这样做:停止和启动服务器与配置更改是正交的,会导致停机时间。
相反,使用 caddy reload
命令进行优雅的配置更改:
caddy reload
这实际上只是在底层使用 API。它将加载您的配置文件,并在必要时将其适配为 JSON,然后优雅地替换活动配置,而不会造成停机。
如果加载新配置时出现任何错误,Caddy 将回滚到最后一个正常工作的配置。