容器更新工具里 watchtower 名气最大，但它的思路是轮询：每隔一段时间去问镜像仓库「有没有新镜像」。轮询间隔摆在那里，更新不够即时，还得给它开仓库的读权限。
\nautodok 走的是另一条路：不轮询，只等通知。它暴露一个 HTTP API，CI 流水线构建完新镜像后 POST 一下，它就把镜像拉下来、用原配置重启容器。主动权在流水线手里，更新时机精确到「这次构建」。
\n\n项目非常精简，只暴露两个端点：
\n| 端点 | 鉴权 | 作用 |
|---|---|---|
GET /health | 不需要 | 健康检查，Docker daemon 可达时返回 200 |
POST /update | 需要 API Key | 拉取指定镜像并用原配置重启指定容器 |
推荐的工作流：
\nPOST /update，带上容器名和新镜像 tag用 docker compose 起一个容器就行，官方仓库自带 compose.yml：
services:
autodok:
image: cars10/autodok
container_name: autodok
restart: always
#ports:
# - 3000:3000
volumes:
- /var/run/docker.sock:/var/run/docker.sock
- ./data:/data
#- /home/user/.docker/config.json:/config.json
三个关键点：
\ndocker.sock：autodok 靠它操作本机容器，这是它能「重启别的容器」的前提./data 目录：API Key 持久化在这里，启动后从日志（docker compose logs -f autodok）或 ./data/api_key 文件里都能拿到autodok.example.com），比直接暴露端口好管理，也方便流水线跨机访问如果从私有镜像仓库拉镜像，把最后一行 volume 的注释去掉，挂上你 docker login 过的 config.json，autodok 会复用里面的凭据。
最朴素的用法，排查问题或临时更新时很实用：
\n# 健康检查（不需要鉴权）
curl -X GET \"http://autodok.example.com/health\"
# 触发更新：把容器 myapp 更新到 myapp:1.2.0
curl -X POST \"http://autodok.example.com/update\" \\
-H \"Authorization: $API_KEY\" \\
-H \"content-type: application/json\" \\
-d '{\"container\": \"myapp\", \"image\": \"registry.example.com/myapp:1.2.0\"}'
# 成功响应
# {\"message\":\"Container 'myapp' restarted with new image 'registry.example.com/myapp:1.2.0'\"}
container 必须是正在运行中的容器名；image 必须是仓库里已存在的镜像和 tag。
在 .gitlab-ci.yml 里，构建推送镜像之后加一个 deploy 阶段：
stages:
- build
- deploy
build-image:
stage: build
script:
- docker build -t registry.example.com/myapp:$CI_COMMIT_SHORT_SHA .
- docker push registry.example.com/myapp:$CI_COMMIT_SHORT_SHA
deploy:
stage: deploy
image: curlimages/curl:latest
script:
- |
curl -X POST \"$AUTODOK_URL/update\" \\
-H \"Authorization: $AUTODOK_API_KEY\" \\
-H \"content-type: application/json\" \\
--max-time 300 \\
-d \"{\\\"container\\\": \\\"myapp\\\", \\\"image\\\": \\\"registry.example.com/myapp:$CI_COMMIT_SHORT_SHA\\\"}\"
rules:
- if: $CI_COMMIT_BRANCH == \"main\"
两个变量在 GitLab 项目 Settings → CI/CD → Variables 里配置：AUTODOK_URL（autodok 的访问地址）和 AUTODOK_API_KEY（记得勾选 Masked）。deploy 阶段的 runner 用 curlimages/curl 镜像即可，不需要 docker。
Jenkinsfile 里同样在推送镜像后加一步：
\nstage('Deploy') {
steps {
sh '''
curl -X POST \"$AUTODOK_URL/update\" \\
-H \"Authorization: $AUTODOK_API_KEY\" \\
-H \"content-type: application/json\" \\
--max-time 300 \\
-d '{\"container\": \"myapp\", \"image\": \"registry.example.com/myapp:'\"$GIT_COMMIT_SHORT\"'\"}'
'''
}
}
AUTODOK_URL 和 AUTODOK_API_KEY 放在 Jenkins 凭据里（Credentials Binding 注入为环境变量），GIT_COMMIT_SHORT 可以在前面 stage 里用 git rev-parse --short HEAD 提取。
如果装了 HTTP Request 插件，也可以不用 curl，写成声明式：
\nstage('Deploy') {
steps {
httpRequest url: \"${env.AUTODOK_URL}/update\",
httpMode: 'POST',
contentType: 'APPLICATION_JSON',
customHeaders: [[name: 'Authorization', value: env.AUTODOK_API_KEY]],
requestBody: '{\"container\": \"myapp\", \"image\": \"registry.example.com/myapp:latest\"}',
timeout: 300
}
}
POST /update 的耗时 = 拉镜像 + 重启容器。大镜像可能要几分钟，除了 curl 的 --max-time，前面反代（nginx 的 proxy_read_timeout）和 CI 客户端的超时也要同步放大，否则镜像还没拉完请求先断了——注意请求断了不影响 autodok 继续执行，只是你拿不到结果autodok 的功能边界很清晰：不做镜像扫描、不做编排、不轮询，就老老实实提供「给我一个容器名和新镜像，我帮你原地更新」的 API。对「代码 push 后希望测试环境立刻更新」这类场景，比 watchtower 的轮询更精准，也比在流水线里直接 ssh 上去敲命令干净得多。项目很小，源码读完不用一顿饭的时间，值得上手一试。
", "url": "https://cooree.co/blog/autodok-cicd-container-update", "title": "autodok：让 CI 流水线按需更新容器的轻量工具", "summary": "autodok 提供一个 API，按需拉取新镜像并用原配置重启容器。记录它的部署方式，以及和 GitLab CI、Jenkins、curl 手动触发的几种用法。", "date_modified": "2026-10-24T00:00:00.000Z", "author": { "name": "容器运维工程师" }, "tags": [ "Docker", "CI/CD", "自动化运维", "autodok" ] }, { "id": "https://cooree.co/blog/minio-mc-commands", "content_html": "MinIO 本身部署很简单，但日常运维——传文件、同步目录、清旧数据、查容量——都要靠它的官方客户端 mc。mc 兼容 S3 协议，MinIO、AWS S3、阿里云 OSS 都能管。这篇是我的实战笔记，参考了这份 mc 使用指南补充完善，按使用频率从高到低组织。
mc 是单二进制，下下来就能跑：
\n# Linux
curl -o /usr/local/bin/mc https://dl.min.io/client/mc/release/linux-amd64/mc && chmod +x /usr/local/bin/mc
# macOS
brew install minio/stable/mc
# 或者容器里临时用一次（不落地配置）
docker run --rm -it --entrypoint=/bin/sh minio/mc
mc --version # 验证
第一步永远是注册集群别名（alias），后面的命令都用别名指代集群：
\nmc alias set local http://127.0.0.1:9000 minioadmin minioadmin
# ^别名 ^服务地址 ^AccessKey ^SecretKey
mc alias ls # 看已配置的别名
mc alias remove local # 删除别名
mc admin info local # 验证连通性，顺便看集群概况
连接非 MinIO 的 S3 服务或个别老环境时，可能需要显式指定签名版本：mc alias set ... --api S3v4（S3v4 是常见默认）。
别把 AccessKey / SecretKey 写进公开仓库。生产环境走环境变量或 CI 密钥注入，并按需收缩账号权限。
| 操作 | 命令 |
|---|---|
| 建桶 / 删空桶 | mc mb local/photos / mc rb local/photos |
| 看桶列表 / 递归列对象 | mc ls local / mc ls --recursive local/photos |
| 上传 / 下载 | mc cp app.tar.gz local/backup/ / mc cp local/backup/app.tar.gz ./ |
| 递归上传目录 | mc cp --recursive ./dist local/static/ |
| 远端桶间复制 | mc cp local/backup/app.log local/archive/app.log |
| 查看对象元数据 | mc stat local/backup/app.log |
| 直接看内容 / 看开头 | mc cat local/config/app.yaml / mc head local/backup/big.log |
| 比对两端差异 | mc diff ./data local/backup/data/ |
| 删除对象 | mc rm local/photos/old.png |
| 递归删整个前缀 | mc rm --recursive --force local/photos/2023/ |
| 看占用 | mc du local / mc du --depth 2 local |
| 按名字查找 | mc find local/photos --name \"*.png\" |
几乎所有子命令都支持 --json 输出，配 jq 做脚本解析很方便：
mc stat --json local/backup/app.log | jq '.size'
# 幂等创建：桶已存在也不报错，写进部署脚本里很合适
mc mb local/backup --ignore-existing
# 创建时指定区域
mc mb local/backup --region us-east-1
删桶有个高危操作单独强调：
\n# 强制删除桶及桶内全部内容，不可恢复，生产慎用
mc rb --force --dangerous local/backup
mc cp / mc mv 有几个容易忽略但很实用的参数：
--attr key=value：上传时附加自定义元数据（如缓存策略、内容类型）--continue：大文件传断了后续传，不用从头再来--newer-than 7d / --older-than 30d：按修改时间过滤，只传某时间窗的对象备份迁移的核心命令组合：
\n# 增量同步本地目录进桶（默认只增不删）
mc mirror --overwrite ./备份目录 local/backup/
# 同步前先看两端差异，心里有数再动手
mc diff ./备份目录 local/backup/
# 排除临时文件
mc mirror --overwrite --exclude \"*.tmp\" ./data local/backup/data/
# 加 --watch 持续监听，文件一变就同步（准实时热备）
mc mirror --watch ./logs local/log-backup/
# 严格镜像：目标端多出来的文件也删掉（慎用）
mc mirror --overwrite --remove ./data local/backup/data/
我的经验是：mirror 之前先 diff。diff 只读不写，把「将会发生什么」先看清楚，尤其是打算加 --remove 的时候。
按时间过滤删除是定期清理任务的标配：
\n# 清理 30 天前的临时文件
mc rm --recursive --force --older-than 30d local/backup/tmp/
# 开了版本控制的桶，要删干净得加 --versions
mc rm --recursive --force --versions local/photos/2023/
不给人开账号，发文件/收文件都靠预签名 URL：
\n# 临时下载链接，24 小时有效
mc share download --expire 24h local/backup/report.pdf
# 临时上传链接，让对方往指定位置传文件
mc share upload --expire 7d local/incoming/
注意 --expire 最长 7 天，写更长会被截断。
按桶/前缀控制，四档策略：
\n| 策略 | 说明 |
|---|---|
download | 匿名可读可下载（静态资源桶常用） |
upload | 匿名可上传（一般不推荐） |
public | 匿名可读可写（极度危险，仅测试） |
none | 禁止匿名访问（默认，最安全） |
mc anonymous set download local/public-assets # 公开只读
mc anonymous set none local/private # 关闭匿名
mc anonymous list local # 查看各桶现状
mc find 不只是按名字找，还能按时间、大小过滤，甚至对结果执行命令：
mc find local/backup --name \"*.log\" --older-than 7d # 7 天前的日志
mc find local/backup --larger 100MB # 排查异常大文件
mc find local/logs --name \"*.gz\" --exec \"mc rm {}\" # 找到即处理
mc admin 是集群管理入口（需要管理员凭据的 alias）：
mc admin info local # 集群状态、容量、在线节点
mc admin user add local reader pass123456 # 加用户
mc admin policy attach local readwrite --user reader # 授权
mc admin service restart local # 滚动重启
mc admin heal --recursive local # 触发修复（换盘之后）
s3://bucket/... 报错：mc 用的是 ALIAS/BUCKET/OBJECT 形式，不是 AWS CLI 的 s3:// 写法mc cp --continue 续传，或改 mirror 增量同步；先 mc du 确认磁盘和桶配额充足--remove；加了 --remove 就有破坏性，先拿测试桶练手mc rm --recursive --force 没有回收站：删了就是删了，删之前先 mc ls --recursive 确认范围，或先 mirror 一份备份--force 与 --dangerous 成对出现的地方都要当心：比如删非空桶，二次确认被跳过mc 的设计很「Unix」：ls、cp、rm、cat、du、find 一套照搬，学习成本约等于零。日常运维记住 alias set 起手、diff 先行、mirror 做同步、share 发链接、admin info 看集群，就覆盖了九成场景。剩下的翻翻 mc <命令> --help，自带的帮助写得相当清楚。
生产容器基本都是精简镜像，里面没有 ss、tcpdump，甚至没 sh。想抓个包、看个端口，总不能往运行中的容器里装东西。nsenter 是这类场景的救星：从宿主机直接进入容器的命名空间执行命令，容器里缺工具也没关系——用的是宿主机的。
容器隔离的本质是 Linux namespace。nsenter 是对 setns 系统调用的封装：指定一个目标进程的 PID，把当前命令「塞进」它的某个命名空间里执行。容器里 1 号进程的所有命名空间就是这个容器的隔离边界，进去就等于站在容器内部。
nsenter -t <PID> [命名空间选项] <要执行的命令>
常用命名空间选项：
\n| 选项 | 进入的空间 | 典型用途 |
|---|---|---|
-n | network | 抓包、看端口、看路由（用得最多） |
-m | mount | 看容器视角的文件系统挂载 |
-p | pid | 看容器内的进程列表 |
-i | ipc | 共享内存、消息队列 |
-u | uts | 主机名 |
-a | 全部 | 完全进入容器环境 |
也可以不通过 PID、直接指定命名空间文件，比如 Kubernetes 注册的：nsenter --net=/var/run/netns/cni-xxx ...
# Docker
PID=$(docker inspect -f '{{.State.Pid}}' <容器名>)
# Kubernetes 节点上（找 Pod 沙箱的 PID）
crictl pods --name <pod名> # 拿到 pod 沙箱 ID
crictl inspect <沙箱ID> | grep pid # 里面的 info.pid
K8s 里一个 Pod 的所有容器共享网络命名空间，所以进 pause 沙箱的网络空间就等于进了整个 Pod 的网络。
\n抓容器网卡的包（最经典，配合 tcpdump 笔记一起看）：
\nnsenter -t $PID -n tcpdump -i eth0 -nn port 80
看容器里实际监听的端口（镜像里没 ss 时）：
nsenter -t $PID -n ss -lnt
看容器视角的挂载和磁盘：
\nnsenter -t $PID -m -- df -h
nsenter -t $PID -m -- mount | grep nfs
验证容器内 DNS 解析：
\nnsenter -t $PID -n -- nslookup kubernetes.default
完全进入容器环境执行一系列命令（近似 docker exec，但不要求容器里有 shell）：
nsenter -t $PID -a /bin/bash
CAP_SYS_ADMIN，普通用户直接跑会 permission deniedsetns: cannot set namespace——重新取一次 PID 即可-m 里别乱动：在挂载命名空间里 umount 或挂东西影响的是容器本体，只读看看就好eth0 是容器的网卡，和宿主机的 eth0 不是一回事，别抓错方向nsenter 把「容器里没工具」这个借口彻底消灭了：宿主机的 tcpdump、ss、ip、nslookup 全都是容器的排查工具。记住核心三板斧——docker inspect 拿 PID、nsenter -t $PID -n 进网络空间、完事退出不留痕。它比进容器装调试镜像优雅得多，也不会污染运行环境。
前端项目的 Node 版本要求五花八门：老项目锁 Node 16，新项目要 Node 20+，CI 镜像又是另一个版本。系统包管理器装的 Node 只有一个版本，来回卸载重装不现实。nvm 就是干这个的：把多个 Node 版本装进用户目录，一条命令切换。
\n\n官方安装脚本（版本号以 nvm releases 页为准，写这篇时最新是 v0.40.8）：
\ncurl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.8/install.sh | bash
脚本做的事很简单：把 nvm 克隆到 ~/.nvm，然后往你的 ~/.bashrc / ~/.zshrc 里追加几行初始化代码。装完重开终端或手动生效：
source ~/.bashrc # zsh 用户用 ~/.zshrc
nvm --version # 能打印出版本号就成了
安装脚本要访问 raw.githubusercontent.com，国内大概率超时。三个替代办法，任选其一：
# 1. 走代理（有的话）
https_proxy=http://127.0.0.1:7890 curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.8/install.sh | bash
# 2. 直接下 tarball 解压到 ~/.nvm
mkdir -p ~/.nvm && curl -L https://github.com/nvm-sh/nvm/archive/refs/tags/v0.40.8.tar.gz | tar -xz -C ~/.nvm --strip-components=1
# 然后手动把初始化代码写进 shell rc（见官方 README）
# 3. 用 Gitee 上的同步镜像仓（搜 nvm 镜像，注意甄别同步是否及时）
nvm 装好了，装 Node 还要从 nodejs.org 下载，同样慢。把下载源换成 npmmirror：
\n# 写入 shell rc，永久生效
export NVM_NODEJS_ORG_MIRROR=https://npmmirror.com/mirrors/node
之后再装版本就丝滑了：
\nnvm install --lts # 装最新 LTS
nvm install 20 # 装指定大版本的最新
nvm ls-remote --lts # 看看有哪些 LTS
nvm ls # 本机已装版本
nvm use 20 # 当前 shell 切到 Node 20
nvm alias default 20 # 设默认版本（新终端自动用它）
nvm current # 当前在用哪个
nvm uninstall 16 # 卸载某个版本
项目里放一个 .nvmrc 文件（内容就一行版本号，如 20），进目录后 nvm use 不带参数会自动读它，团队协作时每人手上的版本就统一了。
echo $SHELL 确认自己跑的是什么 shellsudo 下 nvm 不存在：nvm 装在用户目录，root 的环境里没有它。需要全局场景就换思路，别 sudonpm i -g 装过的工具要重装。装完新版本可以用 nvm install 20 --reinstall-packages-from=16 一次性搬过去nvm 本身没什么技术含量，但它是前端环境的第一块地基：装对一次，后面所有项目的版本切换都是一句话的事。国内使用记住两个加速点——安装脚本走代理或镜像，装 Node 前把 NVM_NODEJS_ORG_MIRROR 指到 npmmirror。
网络问题排查到最后，十有八九要落到「抓个包看看」。tcpdump 是Linux 上抓包的第一工具，参数和表达式看着多，常用的就那一小撮。这篇是我的随手笔记，按「参数 → 表达式 → 菜谱」组织，用的时候直接抄。
\n\n大多数发行版自带，没有就 apt install tcpdump / yum install tcpdump。抓包需要 root 或 CAP_NET_RAW 能力。
| 参数 | 作用 |
|---|---|
-i eth0 / -i any | 指定网卡，any 抓所有（含 lo） |
-n | 不做 DNS 反解（快很多，基本必加） |
-nn | 连端口也不反解成服务名（显示 80 而不是 http） |
-c 100 | 抓够 100 个包就停，防止刷屏/打满磁盘 |
-w file.pcap | 写进文件，给 Wireshark 分析 |
-r file.pcap | 从文件读包（可再叠加过滤表达式） |
-A | 以 ASCII 打印包内容（看 HTTP 明文请求很直观） |
-X | 同时打印十六进制和 ASCII |
-s 0 | 抓完整包（默认有截断长度，看内容必加） |
-q | 精简输出，一行一个包 |
-G 60 -W 10 | 每 60 秒滚动写一个文件，最多保留 10 个（长期抓包用） |
组合规则：and、or、not，加括号分组。
host 10.0.0.5 # 和这台机器有关的流量
src host 10.0.0.5 # 只看它发出的
port 80 # 端口
src port 53 and udp # 它发出的 DNS 查询
net 10.244.0.0/16 # 整个网段
portrange 8000-9000 # 端口范围
icmp # 只看 ICMP（ping）
tcp[tcpflags] & tcp-syn != 0 # 只看 SYN（新建连接）
tcp[tcpflags] & tcp-rst != 0 # 只看 RST（被拒/异常断开）
less 1500 and greater 1400 # 按包长过滤（排查 MTU 问题）
「服务通不通」先看握手——只有 SYN 没有 ACK，多半是对面没监听或中间被丢：
\ntcpdump -i any -nn 'tcp[tcpflags] & (tcp-syn|tcp-ack) != 0 and port 8080'
抓 HTTP 请求明文看内容：
\ntcpdump -i any -nn -A -s 0 port 80
看 DNS 解析走向（K8s 里排查 CoreDNS 特别好用）：
\ntcpdump -i any -nn port 53
「小包通、大包卡死」——MTU 黑洞排查：症状很典型——能 ping 通、能建连、小响应正常，一传大文件就卡死，跨隧道（WireGuard / IPsec / VXLAN）链路最常见。隧道把 MTU 吃小了，而路径上的 ICMP「需要分片」通知又被防火墙吞了，大包发出去就石沉大海。
\n先在发大文件的一侧看大包是不是在反复重传：
\ntcpdump -i eth0 -nn 'tcp and greater 1400' host <对端IP>
# 同样的序列号一遍遍出现 = 大包根本没被对面收到
再到隧道接口上看有没有人提醒我们降包长：
\ntcpdump -i tun0 -nn icmp
# 能看到 \"ICMP unreachable - need to frag\" = 通知在路上，只是被中间吞了
# 完全看不到 = 黑洞实锤
确认后给 TCP 连接钳制 MSS，让包长不越线即可解决：
\niptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
写文件回去用 Wireshark 细读：
\ntcpdump -i any -nn -s 0 -w /tmp/api.pcap host 10.0.0.5 and port 443 -c 1000
抓容器网卡的包：容器里没 tcpdump，从宿主机借——先 docker inspect 拿 PID 再 nsenter 进网络空间：
PID=$(docker inspect -f '{{.State.Pid}}' myapp)
nsenter -t $PID -n tcpdump -i eth0 -nn port 80
长期值守抓偶发问题（滚动文件 + 限量）：
\ntcpdump -i eth0 -nn -s 0 -G 300 -W 20 -w /tmp/capture-%Y%m%d%H%M%S.pcap port 6379
dropped by kernel 数量，不为 0 说明抓的速率赶不上流量，加过滤表达式收窄或换 -s 减小快照长度cni0、veth 对、物理网卡上抓到的视角都不一样；跨节点流量在物理网卡上是封装后的包（flannel 是 UDP 4789），想看成色要选对位置-A 对 TLS 没用：443 上的内容全是密文，别浪费时间，最多看看 ClientHello 里的 SNItcpdump -i any 等于自杀，永远先加过滤条件和 -c 限量tcpdump 的心法就两条：一是用表达式把范围缩到最小，问题流量的特征越具体越好；二是拿不准就 -w 落盘，丢给 Wireshark 慢慢看比盯着滚屏强。再配合 nsenter 进容器网络空间，容器网络问题也基本通吃。
上篇写的 autodok 是「按需触发」派：CI 构建完镜像后 POST 一下，它才去更新容器。这篇写它的对立面——轮询派的代表 watchtower：自己定时去问镜像仓库「有没有新镜像」，有就拉下来原地重启容器，全程不需要 CI 参与。
\n两种方式没有优劣，只有适不适合，文末给出选型对比。
\n\n工作原理一句话：watchtower 挂载 docker.sock，按设定的周期拿着运行中容器的镜像去仓库比对 digest，发现新镜像就拉取，然后用原来的启动配置（卷、端口、环境变量）重建容器。
最简一行跑起来：
\ndocker run -d \\
--name watchtower \\
-v /var/run/docker.sock:/var/run/docker.sock \\
containrrr/watchtower
实际使用推荐 compose，把常用参数写清楚：
\nservices:
watchtower:
image: containrrr/watchtower
container_name: watchtower
restart: always
volumes:
- /var/run/docker.sock:/var/run/docker.sock
command: --interval 3600 --cleanup --rolling-restart
--cleanup 让更新后顺手删掉旧镜像，避免磁盘被旧镜像悄悄吃满；--interval 3600 把默认 24 小时的轮询周期改成 1 小时。
| 参数 | 作用 |
|---|---|
--interval 3600 | 轮询周期（秒），默认 86400（24 小时） |
--schedule \"0 0 4 * * *\" | 用 cron 表达式定时（六段式，含秒），与 interval 二选一 |
--cleanup | 更新后删除旧镜像 |
--rolling-restart | 多副本时逐个重启，避免同时断 |
--monitor-only | 只检测不更新，有更新时发通知（生产建议先用这个观察一阵） |
--include-stopped / --include-restarting | 把停止/重启中的容器也纳入管理 |
--remove-anonymous-volumes | 更新时连带删除匿名卷（注意数据安全） |
--run-once | 只跑一轮就退出，适合手动执行或定时任务 |
--label-enable | 只管理带 com.centurylinklabs.watchtower.enable=true 标签的容器 |
默认管理所有容器，生产上一般要收窄范围。两种姿势：
\n命令行点名：直接在命令末尾写容器名，只管理列出的：
\ndocker run -d --name watchtower \\
-v /var/run/docker.sock:/var/run/docker.sock \\
containrrr/watchtower myapp nginx --interval 3600
标签过滤（推荐，配合 --label-enable）：只动显式打标的容器，新增容器默认不受管，最安全：
services:
myapp:
image: registry.example.com/myapp:latest
labels:
- com.centurylinklabs.watchtower.enable=true
反过来，给容器打 com.centurylinklabs.watchtower.enable=false 可以明确排除。
更新动作发生在凌晨四点而你毫不知情，出了问题就是事故。watchtower 内置 shoutrrr 通知，配置一个 URL 即可，支持 Slack、Discord、Gotify、邮件 SMTP、Microsoft Teams、Telegram、ntfy 等几十种渠道，多个地址空格分隔：
\nenvironment:
- WATCHTOWER_NOTIFICATION_URL=slack://watchtower@token-a/token-b/token-c gotify://gotify.example.com/token
配合 --notification-title-tag 加标题前缀，多台机器跑多个 watchtower 时能分清通知来自哪台。
很多人不知道 watchtower 也有按需触发的一面。开启 HTTP API 模式后，它暴露 POST /v1/update 端点，外部（比如 CI 流水线）可以主动触发更新：
services:
watchtower:
image: containrrr/watchtower
volumes:
- /var/run/docker.sock:/var/run/docker.sock
command: --http-api-update
environment:
- WATCHTOWER_HTTP_API_TOKEN=mytoken
ports:
- 8080:8080
# 触发所有受管容器的更新
curl -H \"Authorization: Bearer mytoken\" localhost:8080/v1/update
# 只更新指定镜像
curl -H \"Authorization: Bearer mytoken\" \"localhost:8080/v1/update?image=foo/bar,foo/baz\"
注意：开了 API 模式后默认关闭周期轮询，想两者并存要加 --http-api-periodic-polls。这个设计思路和 autodok 一致——把触发权交还给流水线。
拉私有仓库的镜像需要凭据，两种方式：
\n# 方式一：环境变量
-e REPO_USER=username -e REPO_PASS=password
# 方式二：挂载 docker login 后的 config.json（推荐）
-v $HOME/.docker/config.json:/config.json
方式二有个坑：bind mount 绑定的是 inode，docker login 或编辑器保存文件时是「新建再替换」，inode 变了，容器里的凭据就停留在旧版本。解决办法是挂软链接——先 ln -s ~/.docker/config.json ~/docker-config.json，再挂载软链接，inode 就稳定了。
enable=false 排除掉--monitor-only + 通知跑一两周，确认更新频率和对象符合预期再开自动更新docker image prunepre-update/post-update 命令| 维度 | watchtower（轮询） | autodok（按需） |
|---|---|---|
| 触发方式 | 自己定期查仓库 | 等 CI POST /update |
| 更新时机 | 有延迟（取决于轮询周期） | 精确到「这次构建」 |
| CI 依赖 | 无，仓库里有新镜像就动 | 需要流水线里加一步 |
| 通知能力 | 内置 shoutrrr 多渠道 | 无（看 CI 自己的通知） |
| 适用场景 | 个人服务、第三方镜像跟进、无 CI 的小项目 | 有完整 CI/CD、要求更新时机精确的环境 |
两者不互斥：我自己的用法是生产用 autodok 跟着流水线走，个人小服务用 watchtower 开着 label 过滤自动跟进。
\nwatchtower 的价值在于「零接入成本」：挂个 socket、起个容器，存量服务立刻获得自动更新能力。代价是更新时机的控制权不在你手里。用 label 过滤收窄管理范围、配上通知渠道、重要服务坚决排除，它就是一个省心的守夜人。
", "url": "https://cooree.co/blog/watchtower-auto-update", "title": "watchtower：让容器自动跟上镜像更新", "summary": "watchtower 通过轮询镜像仓库自动更新运行中的容器。记录它的部署方式、常用配置、通知渠道和 HTTP API 触发模式，并与 autodok 做选型对比。", "date_modified": "2026-10-24T00:00:00.000Z", "author": { "name": "容器运维工程师" }, "tags": [ "Docker", "自动化运维", "watchtower", "CI/CD" ] }, { "id": "https://cooree.co/blog/blog-writing-example", "content_html": "这是一篇可复制的博客写作示例。博客适合记录运维实践、故障复盘和学习心得；系统化的技术手册可以放在 docs 目录中。
\n\n文章放在项目根目录的 blog/ 下，也可以按主题建立子目录，例如 blog/containers/docker-inspection.md。使用 .md 或 .mdx 文件，开头写 YAML 元信息，后面写 Markdown 正文。
目录用于整理源文件，不会自动成为 Navbar 分类。本文设置了 slug: blog-writing-example，对应地址是 /blog/blog-writing-example。复制本文件后，请修改标题、日期、摘要和 slug，避免地址重复。
---
slug: docker-inspection
title: Docker 日常巡检记录
date: 2026-10-21
authors: ops
tags: [Docker, 运维]
keywords: [Docker, 容器, 巡检]
description: 记录 Docker 容器状态、资源占用和日志的日常检查方法。
---
| 字段 | 本站写作建议 |
|---|---|
title | 明确填写文章标题，正文从二级标题开始即可。 |
date | 明确填写发布日期，使用 YYYY-MM-DD，便于排序和归档。 |
slug | 建议填写唯一的英文短路径，文件改名后也能保持文章地址。 |
authors | 使用 blog/authors.yml 中的作者键；当前示例为 ops。 |
tags | 用数组填写分类标签，供标签页聚合文章。 |
keywords | 可选，填写与文章相关的关键词。 |
description | 建议填写简短描述，用于页面元信息。 |
image | 可选，填写已存在的封面图片路径或有效 URL。 |
sticky | 本模板扩展字段，可选数字；数值越大排序越靠前，省略时按 0 处理。 |
draft | 可选，设为 true 时用于草稿，生产构建不发布。 |
这些字段不要求全部填写。本站建议显式填写上面示例中的字段，避免依赖文件名推断标题或日期。YAML 使用空格缩进；包含特殊字符的标题或描述可用引号包裹。
\nauthors.yml 目前使用“容器运维工程师”作为显示名称，可以自行改成昵称，并按需添加个人主页或头像。
博客插件沿用 Docusaurus 的文章处理，在此基础上按 sticky 值降序排列，并将前 10 篇文章提供给首页。需要置顶时，可在元信息中添加 sticky: 1；日常文章可以省略。date 用于发布时间和默认时间排序。
在开头写一至两段摘要，再插入以下标记。标记前的内容用于博客列表摘要，完整正文仍会显示：
\n{/* truncate */}
description 与列表摘要不是同一个用途，建议同时填写描述和截断标记。
记录操作原因、预期结果、适用版本和环境。示例目标是查看 Docker 容器的运行状态，不代表已经对实际环境执行操作。
\n# 查看容器及其状态
docker ps -a
# 查看一次资源占用快照
docker stats --no-stream
在命令后记录预期输出、实际结果和异常判断依据。日志中如有密码、令牌或内部地址，发布前先处理敏感信息。
\n采用 Docusaurus 标准语法，类型后可用方括号设置标题，正文与冒号标记之间保留空行：
\n:::tip[操作建议]
先在测试环境验证，再执行生产变更。
:::
先在测试环境验证，再执行生产变更。
执行重启、清理或升级前，确认业务影响、备份和回滚方案。
常用类型包括 note、tip、info、warning、danger。
本地图片放在 static/ 下，引用时省略 static。下面是语法示例，需要先放入实际图片再使用：
[Docker 官方文档](https://docs.docker.com/)
Markdown 可以直接写链接、表格、列表和代码块；如需使用 React 组件，再考虑 MDX 和对应的组件导入。
\nslug、title、date、description 和标签。authors 能在作者配置中找到。pnpm dev 查看文章与博客列表。pnpm build，检查构建结果。