autodok 走的是另一条路：不轮询，只等通知。它暴露一个 HTTP API，CI 流水线构建完新镜像后 POST 一下，它就把镜像拉下来、用原配置重启容器。主动权在流水线手里，更新时机精确到「这次构建」。

项目地址​

• GitHub：cars10/autodok（Rust 编写，MIT 协议）
• Docker Hub：cars10/autodok

项目非常精简，只暴露两个端点：

推荐的工作流：

1. 推送代码触发 CI
2. CI 构建并推送新镜像
3. CI 向 autodok 发 POST /update，带上容器名和新镜像 tag
4. autodok 拉镜像、按原配置（卷、环境变量等）重启容器

部署方式​

用 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

三个关键点：

• 挂载 docker.sock：autodok 靠它操作本机容器，这是它能「重启别的容器」的前提
• ./data 目录：API Key 持久化在这里，启动后从日志（docker compose logs -f autodok）或 ./data/api_key 文件里都能拿到
• 端口默认注释掉了：推荐用 nginx / traefik 反代一个域名出来（比如 autodok.example.com），比直接暴露端口好管理，也方便流水线跨机访问

如果从私有镜像仓库拉镜像，把最后一行 volume 的注释去掉，挂上你 docker login 过的 config.json，autodok 会复用里面的凭据。

curl 手动触发​

最朴素的用法，排查问题或临时更新时很实用：

# 健康检查（不需要鉴权）
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 结合​

在 .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。

与 Jenkins 结合​

Jenkinsfile 里同样在推送镜像后加一步：

stage('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，写成声明式：

stage('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 继续执行，只是你拿不到结果
• 一次只能更新一个容器：要更新多个容器就发多个请求，串行执行
• API Key 保管：它等于这台机器容器层的操作权限，别写死在仓库里，一律走 CI 变量/凭据注入

小结​

autodok 的功能边界很清晰：不做镜像扫描、不做编排、不轮询，就老老实实提供「给我一个容器名和新镜像，我帮你原地更新」的 API。对「代码 push 后希望测试环境立刻更新」这类场景，比 watchtower 的轮询更精准，也比在流水线里直接 ssh 上去敲命令干净得多。项目很小，源码读完不用一顿饭的时间，值得上手一试。

安装与配置​

mc 是单二进制，下下来就能跑：

# 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），后面的命令都用别名指代集群：

mc 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 是常见默认）。

日常操作速查​

几乎所有子命令都支持 --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

删桶有个高危操作单独强调：

# 强制删除桶及桶内全部内容，不可恢复，生产慎用
mc rb --force --dangerous local/backup

传输的细节参数​

mc cp / mc mv 有几个容易忽略但很实用的参数：

• --attr key=value：上传时附加自定义元数据（如缓存策略、内容类型）
• --continue：大文件传断了后续传，不用从头再来
• --newer-than 7d / --older-than 30d：按修改时间过滤，只传某时间窗的对象

同步（mirror）与比对（diff）​

备份迁移的核心命令组合：

# 增量同步本地目录进桶（默认只增不删）
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 的时候。

清理旧数据​

按时间过滤删除是定期清理任务的标配：

# 清理 30 天前的临时文件
mc rm --recursive --force --older-than 30d local/backup/tmp/

# 开了版本控制的桶，要删干净得加 --versions
mc rm --recursive --force --versions local/photos/2023/

预签名分享链接​

不给人开账号，发文件/收文件都靠预签名 URL：

# 临时下载链接，24 小时有效
mc share download --expire 24h local/backup/report.pdf

# 临时上传链接，让对方往指定位置传文件
mc share upload --expire 7d local/incoming/

注意 --expire 最长 7 天，写更长会被截断。

匿名访问权限​

按桶/前缀控制，四档策略：

mc anonymous set download local/public-assets   # 公开只读
mc anonymous set none local/private             # 关闭匿名
mc anonymous list local                         # 查看各桶现状

find 进阶与 mc admin​

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            # 触发修复（换盘之后）

常见问题​

• Access Denied：先查 AccessKey/SecretKey，再查该账号对目标桶的 IAM/Policy 权限；还有一个隐蔽原因——服务器时间偏差太大会导致签名失败，确认 NTP 正常
• 路径写成 s3://bucket/... 报错：mc 用的是 ALIAS/BUCKET/OBJECT 形式，不是 AWS CLI 的 s3:// 写法
• HTTPS 自签名证书报错：测试环境可临时跳过校验，生产正确做法是把 CA 证书装进系统信任链
• 大文件上传中断：用 mc cp --continue 续传，或改 mirror 增量同步；先 mc du 确认磁盘和桶配额充足

几个坑​

• mirror 默认不删多余文件：源端删了的目标端还在，想完全一致必须显式加 --remove；加了 --remove 就有破坏性，先拿测试桶练手
• mc 和服务端版本要般配：太老的 mc 连新服务端会在 admin 子命令上报怪错，升级 mc 就好
• 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，自带的帮助写得相当清楚。

原理一句话​

容器隔离的本质是 Linux namespace。nsenter 是对 setns 系统调用的封装：指定一个目标进程的 PID，把当前命令「塞进」它的某个命名空间里执行。容器里 1 号进程的所有命名空间就是这个容器的隔离边界，进去就等于站在容器内部。

基本用法​

nsenter -t <PID> [命名空间选项] <要执行的命令>

常用命名空间选项：

也可以不通过 PID、直接指定命名空间文件，比如 Kubernetes 注册的：nsenter --net=/var/run/netns/cni-xxx ...

先拿到容器的 PID​

# 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 的网络。

实战场景​

抓容器网卡的包（最经典，配合 tcpdump 笔记一起看）：

nsenter -t $PID -n tcpdump -i eth0 -nn port 80

看容器里实际监听的端口（镜像里没 ss 时）：

nsenter -t $PID -n ss -lnt

看容器视角的挂载和磁盘：

nsenter -t $PID -m -- df -h
nsenter -t $PID -m -- mount | grep nfs

验证容器内 DNS 解析：

nsenter -t $PID -n -- nslookup kubernetes.default

完全进入容器环境执行一系列命令（近似 docker exec，但不要求容器里有 shell）：

nsenter -t $PID -a /bin/bash

几个坑​

• 需要 root 或 CAP_SYS_ADMIN，普通用户直接跑会 permission denied
• 目标进程退出，命名空间就没了：拿着 PID 正准备进，容器恰好重启，PID 失效，报 setns: cannot set namespace——重新取一次 PID 即可
• -m 里别乱动：在挂载命名空间里 umount 或挂东西影响的是容器本体，只读看看就好
• 进网络命名空间后看到的 eth0 是容器的网卡，和宿主机的 eth0 不是一回事，别抓错方向

小结​

nsenter 把「容器里没工具」这个借口彻底消灭了：宿主机的 tcpdump、ss、ip、nslookup 全都是容器的排查工具。记住核心三板斧——docker inspect 拿 PID、nsenter -t $PID -n 进网络空间、完事退出不留痕。它比进容器装调试镜像优雅得多，也不会污染运行环境。

安装​

官方安装脚本（版本号以 nvm releases 页为准，写这篇时最新是 v0.40.8）：

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.8/install.sh | bash

脚本做的事很简单：把 nvm 克隆到 ~/.nvm，然后往你的 ~/.bashrc / ~/.zshrc 里追加几行初始化代码。装完重开终端或手动生效：

source ~/.bashrc   # zsh 用户用 ~/.zshrc
nvm --version      # 能打印出版本号就成了

# 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 镜像，注意甄别同步是否及时）

装 Node 走国内镜像​

nvm 装好了，装 Node 还要从 nodejs.org 下载，同样慢。把下载源换成 npmmirror：

# 写入 shell rc，永久生效
export NVM_NODEJS_ORG_MIRROR=https://npmmirror.com/mirrors/node

之后再装版本就丝滑了：

nvm 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 不带参数会自动读它，团队协作时每人手上的版本就统一了。

几个坑​

• 新开终端 nvm 失效：初始化代码没写进你实际用的 shell 的 rc 文件（bash 和 zsh 是两份）。用 echo $SHELL 确认自己跑的是什么 shell
• sudo 下 nvm 不存在：nvm 装在用户目录，root 的环境里没有它。需要全局场景就换思路，别 sudo
• 全局 npm 包不共享：每个 Node 版本有自己独立的全局包目录，切版本后 npm i -g 装过的工具要重装。装完新版本可以用 nvm install 20 --reinstall-packages-from=16 一次性搬过去
• 别用 brew 装 nvm：官方明确不支持，brew 版和初始化脚本经常闹别扭，老老实实走官方脚本

小结​

nvm 本身没什么技术含量，但它是前端环境的第一块地基：装对一次，后面所有项目的版本切换都是一句话的事。国内使用记住两个加速点——安装脚本走代理或镜像，装 Node 前把 NVM_NODEJS_ORG_MIRROR 指到 npmmirror。

前置​

大多数发行版自带，没有就 apt install tcpdump / yum install tcpdump。抓包需要 root 或 CAP_NET_RAW 能力。

常用参数速查​

过滤表达式​

组合规则：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，多半是对面没监听或中间被丢：

tcpdump -i any -nn 'tcp[tcpflags] & (tcp-syn|tcp-ack) != 0 and port 8080'

抓 HTTP 请求明文看内容：

tcpdump -i any -nn -A -s 0 port 80

看 DNS 解析走向（K8s 里排查 CoreDNS 特别好用）：

tcpdump -i any -nn port 53

「小包通、大包卡死」——MTU 黑洞排查：症状很典型——能 ping 通、能建连、小响应正常，一传大文件就卡死，跨隧道（WireGuard / IPsec / VXLAN）链路最常见。隧道把 MTU 吃小了，而路径上的 ICMP「需要分片」通知又被防火墙吞了，大包发出去就石沉大海。

先在发大文件的一侧看大包是不是在反复重传：

tcpdump -i eth0 -nn 'tcp and greater 1400' host <对端IP>
# 同样的序列号一遍遍出现 = 大包根本没被对面收到

再到隧道接口上看有没有人提醒我们降包长：

tcpdump -i tun0 -nn icmp
# 能看到 "ICMP unreachable - need to frag" = 通知在路上，只是被中间吞了
# 完全看不到 = 黑洞实锤

确认后给 TCP 连接钳制 MSS，让包长不越线即可解决：

iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

写文件回去用 Wireshark 细读：

tcpdump -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

长期值守抓偶发问题（滚动文件 + 限量）：

tcpdump -i eth0 -nn -s 0 -G 300 -W 20 -w /tmp/capture-%Y%m%d%H%M%S.pcap port 6379

几个坑​

• 先看 dropped 计数：结束时 tcpdump 会打印 dropped by kernel 数量，不为 0 说明抓的速率赶不上流量，加过滤表达式收窄或换 -s 减小快照长度
• 抓的位置决定看到什么：容器场景在宿主机 cni0、veth 对、物理网卡上抓到的视角都不一样；跨节点流量在物理网卡上是封装后的包（flannel 是 UDP 4789），想看成色要选对位置
• -A 对 TLS 没用：443 上的内容全是密文，别浪费时间，最多看看 ClientHello 里的 SNI
• 生产环境先估量：高流量网卡上裸跑 tcpdump -i any 等于自杀，永远先加过滤条件和 -c 限量

小结​

tcpdump 的心法就两条：一是用表达式把范围缩到最小，问题流量的特征越具体越好；二是拿不准就 -w 落盘，丢给 Wireshark 慢慢看比盯着滚屏强。再配合 nsenter 进容器网络空间，容器网络问题也基本通吃。

两种方式没有优劣，只有适不适合，文末给出选型对比。

项目地址​

• GitHub：containrrr/watchtower（Go 编写，Apache-2.0 协议）
• 官方文档：containrrr.dev/watchtower
• Docker Hub：containrrr/watchtower

工作原理一句话：watchtower 挂载 docker.sock，按设定的周期拿着运行中容器的镜像去仓库比对 digest，发现新镜像就拉取，然后用原来的启动配置（卷、端口、环境变量）重建容器。

部署方式​

最简一行跑起来：

docker run -d \
  --name watchtower \
  -v /var/run/docker.sock:/var/run/docker.sock \
  containrrr/watchtower

实际使用推荐 compose，把常用参数写清楚：

services:
  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 小时。

常用配置速查​

只更新指定容器​

默认管理所有容器，生产上一般要收窄范围。两种姿势：

命令行点名：直接在命令末尾写容器名，只管理列出的：

docker 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 等几十种渠道，多个地址空格分隔：

environment:
  - WATCHTOWER_NOTIFICATION_URL=slack://watchtower@token-a/token-b/token-c gotify://gotify.example.com/token

配合 --notification-title-tag 加标题前缀，多台机器跑多个 watchtower 时能分清通知来自哪台。

HTTP API 模式：也能被 CI 触发​

很多人不知道 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 一致——把触发权交还给流水线。

私有镜像仓库​

拉私有仓库的镜像需要凭据，两种方式：

# 方式一：环境变量
-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 就稳定了。

实践中的几个坑​

• 生产慎用全自动：数据库、有状态服务不要交给 watchtower 自动更新，镜像一换数据面就重建，滚动更新和备份策略都不是它的职责。这类服务打 enable=false 排除掉
• 先 monitor-only 观察：上线初用 --monitor-only + 通知跑一两周，确认更新频率和对象符合预期再开自动更新
• cleanup 是把双刃剑：删旧镜像省磁盘，但出问题时少了「秒回滚旧镜像」这条路。重要服务可以不开 cleanup，改靠定期 docker image prune
• 生命周期钩子：需要在更新前执行备份/排空流量等操作，可以看官方文档的 lifecycle hooks，给容器配 pre-update/post-update 命令

watchtower vs autodok 选型​

两者不互斥：我自己的用法是生产用 autodok 跟着流水线走，个人小服务用 watchtower 开着 label 过滤自动跟进。

小结​

watchtower 的价值在于「零接入成本」：挂个 socket、起个容器，存量服务立刻获得自动更新能力。代价是更新时机的控制权不在你手里。用 label 过滤收窄管理范围、配上通知渠道、重要服务坚决排除，它就是一个省心的守夜人。

文件应该放在哪里​

文章放在项目根目录的 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 容器状态、资源占用和日志的日常检查方法。
---

这些字段不要求全部填写。本站建议显式填写上面示例中的字段，避免依赖文件名推断标题或日期。YAML 使用空格缩进；包含特殊字符的标题或描述可用引号包裹。

authors.yml 目前使用“容器运维工程师”作为显示名称，可以自行改成昵称，并按需添加个人主页或头像。

首页与置顶​

博客插件沿用 Docusaurus 的文章处理，在此基础上按 sticky 值降序排列，并将前 10 篇文章提供给首页。需要置顶时，可在元信息中添加 sticky: 1；日常文章可以省略。date 用于发布时间和默认时间排序。

列表摘要​

在开头写一至两段摘要，再插入以下标记。标记前的内容用于博客列表摘要，完整正文仍会显示：

{/* truncate */}

description 与列表摘要不是同一个用途，建议同时填写描述和截断标记。

运维文章正文示例​

背景与目标​

记录操作原因、预期结果、适用版本和环境。示例目标是查看 Docker 容器的运行状态，不代表已经对实际环境执行操作。

环境与前置条件​

• 环境：填写测试或生产环境。
• 版本：填写 Docker 和操作系统版本。
• 权限：确认具备访问目标 Docker 服务的权限。
• 变更窗口：涉及变更时填写时间和影响范围。

检查步骤​

# 查看容器及其状态
docker ps -a

# 查看一次资源占用快照
docker stats --no-stream

在命令后记录预期输出、实际结果和异常判断依据。日志中如有密码、令牌或内部地址，发布前先处理敏感信息。

验证与回滚​

• 验证：记录服务状态、监控指标和业务检查结果。
• 回滚：若涉及配置变更，写明恢复步骤和验证方法。
• 本例仅展示查询命令，无需回滚；实际操作请按影响填写。

Admonitions 提示框​

采用 Docusaurus 标准语法，类型后可用方括号设置标题，正文与冒号标记之间保留空行：

:::tip[操作建议]

先在测试环境验证，再执行生产变更。

:::

常用类型包括 note、tip、info、warning、danger。

图片与链接​

本地图片放在 static/ 下，引用时省略 static。下面是语法示例，需要先放入实际图片再使用：

![容器巡检截图](/img/blog/docker-inspection.png)

[Docker 官方文档](https://docs.docker.com/)

Markdown 可以直接写链接、表格、列表和代码块；如需使用 React 组件，再考虑 MDX 和对应的组件导入。

发布前检查​

• 修改 slug、title、date、description 和标签。
• 确认 authors 能在作者配置中找到。
• 保留一处摘要截断标记，检查正文和图片链接。
• 删除示例说明、占位内容和敏感信息。
• 运行 pnpm dev 查看文章与博客列表。
• 结束开发服务后运行 pnpm build，检查构建结果。