注意：这是 Caddy镜像 的 arm32v6 架构构建的“每架构”仓库——更多信息，请参见镜像文档中的“除amd64外的架构？”和***镜像FAQ中的“Git中镜像源已更改，该怎么办？”。

快速参考

• 维护者：
  Caddy Docker维护者

• 获取帮助：
  Caddy社区论坛

支持的标签及对应的 Dockerfile 链接

（参见FAQ中的“‘共享’标签和‘简单’标签有什么区别？”）

简单标签

• 2.10.2-alpine, 2.10-alpine, 2-alpine, alpine

• 2.10.2-builder-alpine, 2.10-builder-alpine, 2-builder-alpine, builder-alpine

共享标签

• 2.10.2, 2.10, 2, latest:

  • 2.10.2-alpine

• 2.10.2-builder, 2.10-builder, 2-builder, builder:

  • 2.10.2-builder-alpine

快速参考（续）

• 问题提交地址：
  [***]

• 支持的架构：(更多信息)
  amd64, arm32v6, arm32v7, arm64v8, ppc64le, riscv64, s390x, windows-amd64

• 已发布镜像工件详情：
  repo-info仓库的repos/caddy/目录（历史记录）
  （镜像元数据、传输大小等）

• 镜像更新：
  official-images仓库的library/caddy标签
  official-images仓库的library/caddy文件（历史记录）

• 本描述的来源：
  docs仓库的caddy/目录（历史记录）

!logo

什么是Caddy？

Caddy 2 是一款功能强大、企业级的开源Web服务器，用Go语言编写，支持自动HTTPS。

如何使用本镜像

⚠️ 关于持久化数据的注意事项

Caddy需要对两个位置具有写权限：数据目录和配置目录。虽然不必持久化配置目录中的文件（但可能方便），但持久化数据目录非常重要。

文档中说明：

数据目录不得视为缓存。其内容并非临时文件或仅为性能而存在。Caddy将TLS证书、私钥、OCSP staples和其他必要信息存储在数据目录中。未经了解相关影响，不应清除该目录。

本镜像提供两个卷挂载点：/data和/config。

以下示例中，使用命名卷caddy_data挂载到/data，以持久化数据。

注意，命名卷在容器重启和终止后仍会保留，因此升级镜像版本时，可重用相同的数据和配置目录。

基本用法

默认配置文件仅从/usr/share/caddy提供文件，因此若要从当前工作目录提供index.html：

console
$ echo "hello world" > index.html
$ docker run -d -p 80:80 \
    -v $PWD/index.html:/usr/share/caddy/index.html \
    -v caddy_data:/data \
    arm32v6/caddy
...
$ curl http://localhost/
hello world

要覆盖默认Caddyfile，可在$PWD/conf子文件夹中创建Caddyfile，并将该文件夹挂载到/etc/caddy：

console
$ docker run -d -p 80:80 \
    -v $PWD/conf:/etc/caddy \
    -v caddy_data:/data \
    arm32v6/caddy

⚠️ 不要将Caddyfile直接挂载到/etc/caddy/Caddyfile

如果使用vim或其他会更改所编辑文件inode的编辑器，只有重建容器时，更改才会在容器内生效（详见此Medium文章）。使用此类编辑器时，Caddy的优雅重载功能可能无法按预期工作（如此issue所述）。

使用Caddy镜像实现自动TLS

默认Caddyfile仅监听80端口，不设置自动TLS。但如果您的站点有域名，且其A/AAAA DNS记录已正确指向该机器的公网IP，可使用以下命令通过HTTPS提供站点服务：

console
$ docker run -d --cap-add=NET_ADMIN -p 80:80 -p 443:443 -p 443:443/udp \
    -v /site:/srv \
    -v caddy_data:/data \
    -v caddy_config:/config \
    arm32v6/caddy caddy file-server --domain example.com

关键在于Caddy需能够监听80和443端口（ACME HTTP挑战均需这两个端口）。

有关自动HTTPS支持的更多信息，请参见Caddy文档！

构建自定义Caddy镜像

大多数部署生产站点的用户不希望依赖挂载文件到容器，而是基于arm32v6/caddy构建自己的镜像：

Dockerfile
# 注意：生产环境切勿使用:latest标签
FROM arm32v6/caddy:<version>

COPY Caddyfile /etc/caddy/Caddyfile
COPY site /srv

添加自定义Caddy模块

Caddy可通过“模块”扩展。详见[***]

可使用:builder镜像快速构建新的Caddy二进制文件：

Dockerfile
FROM arm32v6/caddy:<version>-builder AS builder

RUN xcaddy build \
    --with github.com/caddyserver/nginx-adapter \
    --with github.com/hairyhenderson/caddy-teapot-module@v0.0.3-0

FROM arm32v6/caddy:<version>

COPY --from=builder /usr/bin/caddy /usr/bin/caddy

注意第二个FROM指令——通过将新构建的二进制文件覆盖到常规arm32v6/caddy镜像上，生成更小的镜像。

xcaddy工具用于构建新的Caddy入口点，包含指定模块。可仅指定模块名，或模块名+版本（用@分隔）。也可指定构建Caddy的特定版本（版本标签或提交哈希）。更多xcaddy用法。

注意，“标准”Caddy模块（github.com/caddyserver/caddy/master/modules/standard）始终包含在内。

优雅重载

更改配置时，Caddy无需完全重启。Caddy提供caddy reload命令，可零停机重载配置。

在Docker中运行Caddy时，触发配置重载的推荐方式是在运行中的容器内执行caddy reload命令。

首先，确定容器ID或名称，然后将容器ID传递给docker exec。工作目录设为/etc/caddy，以便Caddy无需额外参数即可找到Caddyfile。

console
$ caddy_container_id=$(docker ps | grep caddy | awk '{print $1;}')
$ docker exec -w /etc/caddy $caddy_container_id caddy reload

Linux capabilities

Caddy默认启用HTTP/3支持。为提高此UDP协议的性能，底层quic-go库尝试增加其套接字的缓冲区大小。NET_ADMIN capability允许其覆盖操作系统的低默认限制，无需通过sysctl修改内核参数。

赋予容器此capability是可选的，虽不太可能，但可能存在安全影响。

详见[***]

Docker Compose示例

如果倾向于使用docker compose运行服务，以下是服务定义示例（保存为compose.yaml）。配置假设您已按上文所述在$PWD/conf中放置了自定义Caddyfile。

yaml
services:
  caddy:
    image: arm32v6/caddy:<version>
    restart: unless-stopped
    cap_add:
      - NET_ADMIN
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"
    volumes:
      - $PWD/conf:/etc/caddy
      - $PWD/site:/srv
      - caddy_data:/data
      - caddy_config:/config

volumes:
  caddy_data:
  caddy_config:

优雅重载可通过docker compose exec -w /etc/caddy caddy caddy reload执行。

镜像变体

arm32v6/caddy镜像有多种版本，各适用于特定场景。

arm32v6/caddy:<version>

这是默认镜像。如不确定需求，通常应使用此版本。设计用于临时容器（挂载源代码并启动容器以运行应用），也可用作构建其他镜像的基础。

arm32v6/caddy:<version>-alpine

此镜像基于流行的Alpine Linux项目，来自alpine***镜像。Alpine Linux比大多数发行版基础镜像小得多（约5MB），因此通常生成更精简的镜像。

当最终镜像大小是首要考虑因素时，此变体很有用。需注意的是，它使用musl libc而非glibc及类似库，因此软件可能因libc需求/假设的深度而遇到问题。详见此Hacker News评论线程，了解可能出现的问题及使用Alpine-based镜像的优缺点。

为最小化镜像大小，Alpine-based镜像通常不包含额外相关工具（如git或bash）。以此镜像为基础，可在自己的Dockerfile中添加所需工具（如不熟悉，参见alpine镜像描述中的安装示例）。

许可证

查看此镜像包含的软件的许可证信息。

与所有Docker镜像一样，这些镜像可能还包含其他软件，可能采用其他许可证（如基础发行版中的Bash等，以及主要软件的任何直接或间接依赖项）。

可在repo-info仓库的caddy/目录中找到一些能够自动检测到的额外许可证信息。

对于任何预构建镜像的使用，镜像用户有责任确保对该镜像的任何使用符合其中包含的所有软件的相关许可证。