WUD 部署教程：跟踪 Docker 镜像更新与维护记录

开始前

服务器上的容器越来越多以后，最难记住的往往是镜像版本。有的服务固定一个版本，有的长期跟着 `latest`；上次什么时候更新、这次提示意味着什么，靠逐个打开仓库很容易漏。WUD，也就是 What's Up Docker，可以观察容器使用的镜像并检测更新，把维护线索集中到一个页面。

这篇只做更新观察，不配置自动重建触发器。更新提醒出现后，仍然需要读发行说明、保存数据和安排验收。一个新镜像标签并不能说明它适合立即替换正在运行的数据库或应用。

部署前先确认 VPS 的磁盘、内存和公网访问条件，也可以查看雨云云服务器；注册时填写优惠码 `KuZhuJi`。

镜像标签与更新提示

镜像标签可以改变指向。`latest` 这个名字没变，仓库里的镜像内容也可能已经更新；固定版本标签也不是任何仓库都保证不可覆盖。摘要用于标识具体镜像内容，运行容器则使用创建时选定的镜像，不会因为仓库发布了新内容就自动变化。

官方界面示例用于查看容器及更新线索，图中的版本号是演示内容。列表里的提醒需要结合标签规则、镜像来源和版本说明解释，不应直接视为已经完成升级或已经修复漏洞。

先整理自己的 Compose 文件，为重要服务记录当前标签、数据目录和恢复方式。WUD 的用途是帮助发现需要处理的版本变化，而不是代替这些维护记录。

配置账号与 Docker 访问

下面使用项目当前官方镜像。应用会访问 Docker Socket，因此要把它当作具有重要权限的服务管理。后台仅监听回环地址，使用独立管理员密码，暂时不添加更新触发器或外部脚本。

mkdir -p ~/services/wud/store
cd ~/services/wud
umask 077
printf 'WUD_AUTH_ADMIN_USER=admin\n' > .env
printf 'WUD_AUTH_ADMIN_PASSWORD=%s\n' "$(openssl rand -hex 24)" >> .env
chmod 600 .env

保存 `compose.yaml`：

services:
  wud:
    image: getwud/wud:latest
    env_file:
      - .env
    ports:
      - "127.0.0.1:3007:3000"
    volumes:
      - ./store:/store
      - /var/run/docker.sock:/var/run/docker.sock:ro
    restart: unless-stopped

`/store` 是当前项目的默认持久存储路径，保存应用状态；不同主版本的数据格式和认证方式可能不同。本文的管理员环境变量来自当前 README，老版本部署不能只复制这些字段就认为兼容。初次验证后固定实际版本或摘要，再按对应发行说明更新。

docker compose config --quiet
docker compose up -d
docker compose logs --tail=100 wud

本地 Docker Socket 路径取决于安装方式。Rootless Docker 不一定使用 `/var/run/docker.sock`，不要为了接入而给所有用户开放 Socket 权限。先确认自己的 Docker 运行模式和实际路径。

只读挂载不等于 Docker API 只读

`:ro` 限制挂载文件的写入，并不会把通过 Socket 调用的 Docker API 自动变成只读。能连接这个接口的进程具有重要操作能力，是否配置触发器和是否开放管理界面都需要控制。

如果以后改用 Socket 代理或远程 Docker，按当前官方文档明确可访问的 API 与网络路径。一个随手加入的第三方代理容器不一定自动提供合适的权限边界，不能因为名字里有“proxy”便认为风险已经处理。

观察结果先进入维护清单，正式升级通过原有部署配置进行。这样能留下版本、备份和验收记录，避免提醒、重建和数据迁移同时发生却没人知道顺序。

准备独立实例时，可在雨云选择适合的云服务器配置，优惠码 `KuZhuJi`。配置按实际任务选择，数据库和附件另做备份。

首次登录先核对容器清单

ssh -L 13007:127.0.0.1:3007 user@your-server

本机访问 `http://127.0.0.1:13007`，使用 `.env` 中的账号登录。对照 `docker ps` 与页面中的容器，确认名称和镜像来源。无法读取时看日志，区分 Socket 权限、Docker 连接及仓库认证问题。

不要只检查页面能打开。找一个普通应用容器，核对当前镜像标签和是否给出了检查结果，再观察下一次检查时间。网络错误和“没有新版本”是不同状态；仓库不可访问时，不能把空结果当作全部服务已经最新。

公共仓库与私有仓库的凭据需求不同。需要认证时，为相应仓库安排所需范围的凭据，避免把个人全权限令牌直接塞给监控工具。记录凭据的用途，轮换或停用后确认检查结果恢复正常。

每种标签规则都有维护含义

语义版本标签可以帮助区分主版本、次版本和修订版本，但项目并不都采用相同发布规则。日期标签、发行渠道、架构后缀和特殊构建名，需要按该镜像的实际命名理解。不要把包含更多字符的标签一律当作更高版本。

固定主版本可以减少跨代变化，仍然可能收到这个主版本内的更新。固定完整版本时，工具可能提示存在其他版本，但不代表原标签被修改。摘要固定则需要明确自己准备迁移到什么目标。整理维护清单时把当前标识、候选标识和更新时间分开记。

仓库对请求有速率限制，网络和权限错误应先解决，再调整检查频率。没有必要为了几台服务器每分钟轮询所有镜像。先使用默认机制观察，确认真实需要后才修改对应配置，避免额外请求没有带来可处理的信息。

需要增加服务器时，可以打开雨云选购页面，填写优惠码 `KuZhuJi`；迁移前保留数据与原有部署配置。

一次更新只处理一个需要验收的服务

出现提醒后，先打开官方发行说明，查是否包含数据库迁移、配置改名、目录规则或最低版本要求。保存 Compose、环境配置、旧镜像标识和一致的数据副本，再更新目标服务。

docker compose images
docker compose ps

上述命令在目标服务自己的目录执行，用来记录现状。实际拉取与重建使用该服务的维护流程，不在 WUD 目录里随便执行另一套更新命令。更新后检查功能、后台任务和数据，而不是只看容器显示 running。

回退同样需要注意数据迁移。旧镜像还在，不等于新数据库能被它读取；需要旧数据时从升级前备份恢复。对于缓存或无状态服务，回退边界可能更简单，但也要核对调用它的其他应用。

保留观察器配置，也保留真正的业务备份

WUD 的 `store`、`.env` 和 Compose 用于恢复观察器，它们不包含所有被观察应用的数据。不要因为这个工具列出了全站容器，就认为打包它的目录能恢复整台服务器。

mkdir -p backups
docker compose stop wud
tar -czf "backups/wud-$(date +%F-%H%M%S).tar.gz" store .env compose.yaml
docker compose start wud

副本转移到其他存储，权限与其中的凭据相称。恢复测试使用独立目录，确认管理员能登录、容器能被识别、仓库检查正常。若以后启用自动触发器，测试副本先停用它们，避免两套观察器同时处理正式容器。

维护记录里最后应留下实际完成的升级，而不只是“发现新版本”。记录新旧镜像、备份位置和验收结果，下次提醒出现时就能判断这是新的变化，还是上次尚未处理完的任务。