分类: 容器与部署

  • 用 Docker Compose 管理一组长期运行的服务

    整理说明:本文属于“2025-2026 技术笔记整理”系列,于 2026 年 8 月集中整理并公开发布。

    用 Docker Compose 管理 WordPress 服务栈

    当站点同时依赖 WordPress、数据库和反向代理时,逐个启动容器容易遗漏网络、存储或参数。Docker Compose 把这些约束写进 compose.yaml,让部署和维护使用同一套声明。

    先读懂编排文件

    services 定义组件;同一 Compose 网络中的容器可用服务名通信,例如 WordPress 通过 database:3306 访问数据库。volumes 保存持久数据,secrets 以文件形式挂载敏感值,profiles 可放置仅在维护时启动的工具。

    • restart: unless-stopped 可在异常退出或主机重启后恢复服务,但不能替代监控。
    • depends_on 只表达依赖关系;需要等待数据库真正可用时,应配合健康检查和 service_healthy 条件。
    • 数据库可只加入内部网络,减少不必要的端口暴露。
    services:
      wordpress:
        depends_on:
          database:
            condition: service_healthy
        volumes:
          - wordpress_data:/var/www/html
    

    启动前检查,启动后观察

    修改 YAML 后先运行配置渲染命令,它会合并环境变量和覆盖文件,并及早发现缩进、字段或变量问题。确认结果无误后再后台启动:

    docker compose config
    docker compose up -d
    docker compose ps
    docker compose logs -f --tail=100
    

    ps 检查运行和健康状态,logs 用于追踪故障。在运行中的容器执行诊断可用 docker compose exec wordpress php -v;带 profile 的工具服务可用 docker compose --profile tools run --rm wpcli ... 临时启动。

    更新、暂停与清理

    更新时先运行 docker compose pull,再执行 docker compose up -d。Compose 会重建需要变化的容器,命名卷不会因此消失。操作前仍应备份,完成后检查日志和站点;镜像标签应按维护策略固定。

    • stop 停止服务但保留容器,start 可原样恢复。
    • restart 只重启现有容器,不会把新 YAML 配置应用进去。
    • down 删除容器和项目网络,默认保留命名卷。
    • down -v 会删除命名卷,可能清空站点与数据库,不能作为普通重启命令。

    应把 config、备份、启动、健康检查和日志复核固化为操作顺序。Compose 让环境可重复,数据保护和上线验证仍需明确流程。

  • WordPress 容器化部署中的数据持久化与备份

    整理说明:本文属于“2025-2026 技术笔记整理”系列,于 2026 年 8 月集中整理并公开发布。

    WordPress 容器的数据持久化与可恢复备份

    容器可以重建,但数据不能随可写层消失。WordPress 状态包括数据库中的文章、用户和配置,以及文件系统中的上传、主题、插件与运行配置。只备份一类无法恢复完整站点。

    把数据放到容器之外

    WordPress 站点目录通常是 /var/www/html,MariaDB 数据目录是 /var/lib/mysql。为它们挂载命名卷,容器替换后仍可挂载原数据:

    services:
      database:
        volumes:
          - database_data:/var/lib/mysql
      wordpress:
        volumes:
          - wordpress_data:/var/www/html
    
    volumes:
      database_data:
      wordpress_data:
    

    命名卷由 Docker 管理。docker compose down 默认保留它们,docker compose down -v 则会删除项目命名卷。卷并非备份:磁盘损坏、误删和错误写入仍会影响数据。

    分别导出数据库和站点文件

    数据库应使用自身的逻辑导出工具备份,不能在运行中直接复制 /var/lib/mysql。以下命令从挂载的密码文件读取凭据,并把 SQL 输出到主机;备份目录应提前创建并限制权限:

    docker compose exec -T database sh -c \
      'mariadb-dump --single-transaction --quick \
      -u"$MARIADB_USER" -p"$(cat "$MARIADB_PASSWORD_FILE")" \
      "$MARIADB_DATABASE"' > backup/wordpress.sql
    
    docker compose exec -T wordpress \
      tar -C /var/www/html -czf - . \
      > backup/wordpress-files.tar.gz
    

    -T 关闭伪终端,避免混入控制内容。--single-transaction 为事务表提供一致性快照;存在非事务表或结构变更时应安排维护窗口。文件与数据库应同期备份,减少附件不匹配。

    备份完成不等于可以恢复

    • 为文件名加入时间标识,记录对应的 Compose 配置、镜像标签和恢复说明。
    • 将备份复制到另一台主机或对象存储,不要只放在原服务器磁盘。
    • 对归档和 SQL 计算校验值,备份任务失败时应产生告警。
    • 密码和密钥应单独加密保管,避免明文秘密混进普通归档。

    恢复时先阻止写入,在干净卷还原文件并导入数据库,再核对域名、媒体、登录和插件。演练应在隔离环境执行;只有完成关键操作,才能证明备份有效。生产站点还应明确恢复时间和可接受的数据丢失范围。

  • 使用 Caddy 为容器网站配置反向代理与 HTTPS

    整理说明:本文属于“2025-2026 技术笔记整理”系列,于 2026 年 8 月集中整理并公开发布。

    用 Caddy 为 WordPress 配置反向代理与域名 HTTPS

    WordPress 可只监听内部网络,由 Caddy 接收公网请求、终止 TLS,再转发给应用。这样只有代理发布端口,数据库和应用不直接暴露,也便于管理证书。

    域名和网络是自动 HTTPS 的前提

    把 A 记录指向服务器公网 IPv4;若发布 AAAA 记录,也要确保 IPv6 可达。防火墙需允许 TCP 80、443。Caddy 使用域名作为站点地址时会申请、续期证书,并把 HTTP 重定向到 HTTPS。解析错误或公网无法回源会导致签发失败。

    代理与 WordPress 应加入同一 Compose 网络。内部 DNS 会解析服务名,因此上游可写 wordpress:80;对 Caddy 容器而言,localhost 指向它自己。

    example.com {
      encode zstd gzip
      reverse_proxy wordpress:80
    
      header {
        -Server
        X-Content-Type-Options "nosniff"
        Referrer-Policy "strict-origin-when-cross-origin"
      }
    }
    

    example.com 换成真实域名即可触发 HTTPS;仅写 :80 不会申请域名证书。裸域名与 www 同时使用时,应明确主域名并重定向。

    保存证书状态,正确传递协议

    Caddy 的 /data 包含证书、私钥和自动 HTTPS 状态,必须挂载持久卷;/config 也宜持久化。丢失这些数据可能导致重复申请证书。私钥卷及其备份应限制权限。

    reverse_proxy 会设置常用的 X-Forwarded-* 头。WordPress 必须识别 X-Forwarded-Proto: https,并使用 https:// 站点地址,否则可能出现循环跳转或混合内容。只应信任受控代理的转发头。

    验证配置再切换流量

    docker compose exec proxy \
      caddy validate --config /etc/caddy/Caddyfile
    docker compose restart proxy
    docker compose logs -f --tail=100 proxy
    

    校验通过后重启代理,并从外部访问域名,检查证书主机名、HTTPS 跳转、后台登录和媒体资源。保留管理 API 时可优雅重载;显式关闭管理 API 时应重启容器。

    • 证书错误先查 A、AAAA 记录,再查 80、443 端口。
    • 出现 502 时,检查共享网络、服务名、容器状态和上游日志。
    • 循环跳转时,核对 WordPress 的 HTTPS 识别逻辑和站点地址。

    上线后应观察证书续期和错误日志。域名可达、存储持久化和正确处理代理头,都是稳定运行的必要条件。