Docker on 寻 Mi 处

机器越来越多之后，我给每一台都挂上了探针

Sun, 02 Aug 2026 23:55:00 +0800

我一直没有正经的监控。

出问题的时候，是我自己发现网站打不开，然后上去看。或者更糟，是朋友告诉我"你博客挂了"。

有几次是证书过期，有一次是数据库满了导致写不进去，还有一次是 nginx 的 worker 全挂了。每一次都是被动发现，中间可能已经挂了好几个小时。

后来在 NodeSeek 上看到有人推荐 Uptime Kuma，说是自托管的监控面板，界面好看，配置简单。我花了一个晚上装起来，之后就没再被"你博客挂了"这种消息尴尬过。

装

Docker Compose，目录 /srv/uptime-kuma：

services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    container_name: uptime-kuma
    restart: unless-stopped
    volumes:
      - ./data:/app/data
    ports:
      - "127.0.0.1:3001:3001"
    environment:
      TZ: Asia/Shanghai
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

`1`	`docker compose up -d`

端口只绑 127.0.0.1，外面通过 nginx 反代进来。

nginx 反代

Uptime Kuma 用 WebSocket 做实时更新，反代的时候要配 upgrade：

server {
    listen 443 ssl;
    http2 on;
    server_name status.mibase.top;

    ssl_certificate     /etc/letsencrypt/live/status.mibase.top/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/status.mibase.top/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:3001;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
    }
}

proxy_read_timeout 设长一点。WebSocket 是长连接，如果超时太短，连接会被反复断开重连，页面上的状态会一闪一闪。

进去之后

打开 https://status.mibase.top，会让你创建管理员账号。

建完就进到主界面。左边是监控列表，右边是状态页。

上手先加一个监控。点左上角的"添加新监控"。

监控类型有十几种，HTTP、TCP、Ping、DNS、关键词、推送、证书过期，等等。

HTTP 监控

最常用的是这个。

监控类型：HTTP(s)
友好名称：博客
URL：https://blog.mibase.top
心跳间隔：60 秒
重试次数：2
请求超时：30 秒

心跳间隔 是多久检查一次。六十秒是个平衡点，太频繁会增加负担，太慢会延迟发现。

重试次数 是连续失败多少次才判定为故障。设成 2 意味着单次失败不算，连着两次失败才告警。这个能过滤掉偶尔的网络抖动。

还有一个"接受的状态码"，默认是 200-299。如果你的站会返回 304，得把它加进去。

进阶一点，可以用关键词监控。比如检查页面里有没有某个特定的字符串：

1
2

监控类型：HTTP(s) - 关键词
关键词：明月小站

这样不只是检查服务器返回了 200，还检查内容是对的。有时候 nginx 返回了 200 但页面是空的，这种也能发现。

证书过期监控

这个是我觉得最实用的一个。

1
2

监控类型：HTTP(s) - 关键词
URL：https://blog.mibase.top

其实不用单独配，Uptime Kuma 会自动检测 HTTPS 站点的证书剩余天数，显示在监控详情里。

但它默认不会因为证书快过期而告警。要单独加一个"证书过期"类型的监控：

1
2
3

监控类型：证书过期
域名：blog.mibase.top
过期前通知天数：14

设成十四天，留够续期和排查的时间。

我配了这个之后，再也没遇到过证书过期。

TCP 端口监控

有些服务没有 HTTP 接口，比如数据库、Redis、SSH。

1
2
3

监控类型：TCP 端口
主机名：db.mibase.top
端口：3306

这个只检查端口能不能连上。连不上就告警。

我用它监控了 MariaDB 的 3306 和 SSH 的 2222。

Ping 监控

检查机器本身活不活。

1
2

监控类型：Ping
主机名：blog.mibase.top

这个用的是 ICMP。有些云厂商会禁 ICMP，那就用 TCP 端口替代。

Docker 容器监控

Uptime Kuma 有个 Docker 类型的监控，可以检查容器是否在运行。

但有个前提，Uptime Kuma 这个容器要能访问宿主机的 Docker socket：

1
2
3

    volumes:
      - ./data:/app/data
      - /var/run/docker.sock:/var/run/docker.sock:ro

:ro 是只读挂载。这个很重要，因为 docker.sock 相当于宿主机的 root 权限，只读能减少风险。

不过即便如此，能访问 docker.sock 的容器仍然是很危险的。我的做法是只在监控服务器上开这个，业务服务器上不装 Uptime Kuma。

推送监控

这个类型有点特别，方向是反的。

其他监控是 Uptime Kuma 主动去检查目标。推送监控是目标主动向 Uptime Kuma 报告"我还活着"。

新建一个推送监控，它会给你一个 URL：

`1`	`https://status.mibase.top/api/push/xxxxxxxx`

然后你在目标机器上加一个定时任务：

`1`	`curl -fsS -m 10 --retry 5 -o /dev/null https://status.mibase.top/api/push/xxxxxxxx`

如果 Uptime Kuma 在一段时间内没收到这个请求，就判定为故障。

这个特别适合备份任务。比如你的备份脚本每天跑一次，跑完就推一下。如果哪天没推，说明脚本没跑或者跑失败了。

我的备份脚本里就加了这个：

1
2

curl -fsS -m 10 --retry 5 -o /dev/null \
  "https://status.mibase.top/api/push/xxxxxxxx?status=up&msg=OK&ping="

通知

监控没有通知等于没监控。

Uptime Kuma 支持几十种通知方式，Telegram、邮件、Webhook、企业微信、钉钉，等等。

我用的是 Telegram，配置最简单。

先在 Telegram 里找 @BotFather，发 /newbot，按提示建一个 bot，拿到 token。

然后找 @userinfobot，发一条消息，它会告诉你你的 chat id。

在 Uptime Kuma 的设置里，通知，新建：

1
2
3

通知类型：Telegram
Bot Token：123456:ABC-DEF...
Chat ID：123456789

点"测试"，如果 Telegram 里收到消息就说明配好了。

告警的降噪

通知配好之后，最先冒出来的问题是太吵。

网络抖一下，收到一条。服务重启，收到一条。半夜三点被吵醒，一看是误报。

Uptime Kuma 提供了几个手段。

重试次数 是最基础的。连续失败 N 次才告警。

还有一个"心跳间隔"的倍数，叫"重试间隔"。默认是心跳间隔的倍数，可以让重试之间隔得久一点。

另外可以在通知里设"仅在状态变化时通知"。这样故障恢复的时候会发一条，不会一直重复。

我的配置是，心跳间隔六十秒，重试两次，重试间隔六十秒。也就是说，从故障发生到告警，大概需要三分钟。这个延迟可以接受，换来的是极少的误报。

状态页

Uptime Kuma 可以生成一个公开的状态页，给用户看。

在设置里新建状态页，选要显示的监控，设一个路径，比如 /status。

然后访问 https://status.mibase.top/status 就能看到。

这个页面挺好看的，绿色是正常，红色是故障，还能显示最近一次的心跳延迟。

我给自己的几个站做了个公开状态页，虽然没什么人看，但自己看着舒服。

数据备份

Uptime Kuma 的所有配置都存在 SQLite 里，位置是 /app/data/kuma.db。

备份就是拷这个文件：

1
2

docker exec uptime-kuma sqlite3 /app/data/kuma.db ".backup '/app/data/backup.db'"
docker cp uptime-kuma:/app/data/backup.db ./kuma-backup-$(date +%F).db

注意要先 .backup 再拷，不能直接拷正在使用的 db 文件。

恢复就是把文件放回去，然后重启容器。

几个小问题

Uptime Kuma 的资源占用不大，一个监控大概占几兆内存。我有二十多个监控，整个容器占了一百多兆。

它的数据库会一直增长，因为每次心跳都记一条。跑久了文件会变大。可以在设置里开启"保留心跳数据的天数"，默认是无限。

有一次我发现监控页面加载很慢，查下来是数据库太大了。开了保留九十天之后，文件从两百多兆降到了三十多兆。

还有一个，如果你的监控目标也在同一台机器上，那机器挂了的时候，监控也跟着挂了，什么都监控不到。

所以我后来把 Uptime Kuma 放在了一台独立的机器上，监控其他所有机器。这样至少能保证监控本身是活的。

现在的状态

我现在的监控列表里有二十多项。

几个站点的 HTTP 可用性，几台 VPS 的 Ping，数据库和 SSH 的端口，几张证书的过期时间，还有备份任务的推送。

每天早上起来看一眼，全是绿的，心里就踏实。

这个工具最大的价值不是它能做什么高级的分析，而是它让我从"被动发现问题"变成了"主动知道状态"。这个转变看起来小，但对心态的影响很大。

受够了密码管理器的订阅费，我自己搭了一个

Wed, 11 Feb 2026 11:20:00 +0800

我用了三年某密码管理器的付费版。

涨价那次我忍了，从每年三十多美元涨到四十多。去年又涨，我看着账单发了会儿呆，然后打开了它的定价页。

家庭版六个人，一年六十美元。我家里真正会用密码管理器的只有我和我老婆两个人。

那天晚上我就在看有没有自建的方案。Vaultwarden 是第一个跳出来的，因为它的定位很明确，就是 Bitwarden 服务端的轻量实现，用 Rust 写的，官方服务端要好几 G 内存，它几十兆就能跑。

它和 Bitwarden 是什么关系

先说清楚，Vaultwarden 不是 Bitwarden 的官方项目，它是一个兼容实现。

它实现了 Bitwarden 的服务端 API，所以官方的所有客户端都能连，浏览器插件、桌面端、手机 App、命令行工具，全都行。你只要在登录界面把服务器地址改成自己的域名。

它的好处是轻。官方服务端是一整套微服务，跑起来要 SQL Server 加一堆容器，没有 4G 内存根本带不动。Vaultwarden 一个二进制文件加 SQLite 就能跑，1G 的机器绰绰有余。

代价是它不是官方维护的，某些新功能会滞后。比如 Bitwarden 前阵子推的 passkey 支持，Vaultwarden 过了一段时间才跟上。不过核心的密码管理功能一直很稳。

部署

我用的是 Docker Compose，目录放在 /srv/vaultwarden。

services:
  vaultwarden:
    image: vaultwarden/server:1.32.7
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: "https://vault.mibase.top"
      SIGNUPS_ALLOWED: "false"
      INVITATIONS_ALLOWED: "true"
      ADMIN_TOKEN: "${ADMIN_TOKEN}"
      DATABASE_URL: "/data/db.sqlite3"
      ROCKET_PORT: "80"
      TZ: "Asia/Shanghai"
    volumes:
      - ./data:/data
    ports:
      - "127.0.0.1:8088:80"

几个关键点。

DOMAIN 必须写对，而且必须是 https。它是用来生成邮件里的链接、WebAuthn 的 origin 这些东西的。写错了，注册邀请链接会指向错误的地址。

SIGNUPS_ALLOWED: "false" 是关掉公开注册。不关的话，任何人只要知道你的域名就能注册账号，虽然数据是隔离的，但白占你的资源，还有被滥用的风险。

关掉之后，加人要用邀请。INVITATIONS_ALLOWED: "true" 是开着邀请功能，你可以在管理后台生成邀请链接。

ADMIN_TOKEN 是管理后台的密码。这个值不要写死在 compose 文件里，用环境变量从 .env 文件读。生成方法：

`1`	`openssl rand -base64 48`

ports 只绑 127.0.0.1，不对外暴露。外面通过 nginx 反代进来，这样容器端口不会被直接扫到。

nginx 反代

server {
    listen 443 ssl;
    http2 on;
    server_name vault.mibase.top;

    ssl_certificate     /etc/letsencrypt/live/vault.mibase.top/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/vault.mibase.top/privkey.pem;

    client_max_body_size 128M;

    location / {
        proxy_pass http://127.0.0.1:8088;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

client_max_body_size 128M 是给附件上传用的。Bitwarden 支持存文件附件，默认的上传限制是一兆，不改的话传大一点的附件会失败。

Upgrade 和 Connection 那两个头是给 WebSocket 用的。Bitwarden 的客户端会用 WebSocket 做实时同步，不配这个，同步会有延迟。

证书

`1`	`sudo certbot --nginx -d vault.mibase.top`

certbot 会自动改 nginx 配置，加上证书路径和 http 到 https 的跳转。

续期是自动的，systemd timer 会每天检查。可以手动测一下：

`1`	`sudo certbot renew --dry-run`

这个一定要测。我见过有人配完就没管，一年后证书过期，所有客户端都连不上。

首次使用

浏览器打开 https://vault.mibase.top，会看到 Bitwarden 的登录页。点"创建账户"，注册第一个账号。

注册完之后，立刻去管理后台把注册关掉。虽然前面已经在环境变量里关了，但保险起见再看一眼：

`1`	`https://vault.mibase.top/admin`

输入 ADMIN_TOKEN 进去，找到 SIGNUPS_ALLOWED，确认是 false。

管理后台里还能看到用户列表、邀请、诊断信息。有个"发送测试邮件"的按钮，配了 SMTP 之后可以用来验证。

邮件

不配 SMTP 也能用，但有些功能会受限。比如忘记主密码的重置邮件、新设备登录的验证邮件、邀请链接的邮件发送。

我的配置：

      SMTP_HOST: "smtp.example.com"
      SMTP_FROM: "vault@mibase.top"
      SMTP_FROM_NAME: "Vaultwarden"
      SMTP_PORT: "587"
      SMTP_SECURITY: "starttls"
      SMTP_USERNAME: "vault@mibase.top"
      SMTP_PASSWORD: "${SMTP_PASSWORD}"

我用的是某个邮件服务商的免费额度，一个月五百封，够用了。

有个细节，SMTP_SECURITY 的值是 starttls 或者 force_tls，不是 tls。写错了它不会报错，只是发不出去，日志里也看不太出来。

客户端怎么连

浏览器插件和手机 App 的登录界面，都有一个设置服务器的入口。

浏览器插件里，在登录框下面有个齿轮图标，点进去能填"自托管环境"的服务器 URL。

手机 App 上，登录页左上角有个齿轮，点进去填。

填 https://vault.mibase.top，不要带 /admin 或者别的路径。

填完之后回登录页，用刚才注册的账号登录。如果之前用过官方服务，本地已经有数据，会提示你选择"登录到另一个服务器"还是"迁移"。选迁移的话，本地数据会同步到新服务器。

数据在哪儿

/srv/vaultwarden/data/
├── db.sqlite3
├── db.sqlite3-wal
├── db.sqlite3-shm
├── attachments/
├── sends/
├── rsa_key.pem
├── rsa_key.pub.pem
└── icon_cache/

db.sqlite3 是主数据库，所有的密码条目、用户信息都在里面。

rsa_key.pem 是服务端的私钥，用来签名 JWT。这个文件丢了，所有用户都得重新登录。所以备份的时候一定要带上。

attachments 是附件，sends 是临时分享的文件。

备份

因为用的是 SQLite，直接拷贝文件是不安全的，可能有正在写的事务。

正确的做法是用 SQLite 的备份命令：

`1`	`docker exec vaultwarden sqlite3 /data/db.sqlite3 ".backup '/data/backup.sqlite3'"`

这个命令会在数据库层面做一次一致性备份，不会因为并发写入出错。

然后打包：

tar -czf /backup/vaultwarden-$(date +%F).tar.gz \
  -C /srv/vaultwarden/data \
  --exclude='icon_cache' \
  db.sqlite3 backup.sqlite3 attachments sends rsa_key.pem

icon_cache 是网站图标缓存，没必要备份，重新访问的时候会自动下载。

我写了个脚本，每天凌晨跑一次，保留三十天，同步到对象存储。具体写法在另一篇备份的文章里。

恢复

这个流程一定要演练过。

docker compose down
rm -rf data/*
tar -xzf /backup/vaultwarden-2026-02-10.tar.gz -C data/
mv data/backup.sqlite3 data/db.sqlite3
docker compose up -d

注意要先 down 再恢复文件，不然容器还在跑，恢复的文件会被覆盖。

我第一次演练的时候就是忘了停容器，恢复完发现数据还是旧的，还以为是备份有问题。

安全上要注意的

这个服务存的是你最敏感的东西，安全得多花点心思。

ADMIN_TOKEN 要够长，至少四十八个字符的随机串。这个 token 泄露了，别人能改你的配置。

不要开公开注册。即使开了，也要配验证码和邮件验证，否则会被当成免费的密码库来用。

HTTPS 是必须的，不是可选项。客户端的很多功能（WebAuthn、剪贴板 API）在 http 下根本不能用。

考虑加一层 Cloudflare Access，只允许自己的邮箱访问。不过这会影响到手机 App 的连接，因为 App 不方便走浏览器登录。我自己没加，因为 Vaultwarden 本身有登录验证，风险可控。

用下来的感受

到现在用了四个月，手机、电脑、浏览器插件都连着，同步很稳。

速度比官方服务快，因为服务器就在国内，延迟只有几十毫秒。官方服务在国内访问有时候要绕很久。

有一个小遗憾，它没有官方的"紧急访问"功能（就是你挂了之后让别人拿到你的密码库）。社区有替代方案，但要额外配。

还有一个，自托管意味着你得自己保证它一直活着。如果服务器挂了，你又刚好需要查一个密码，那就尴尬了。所以我把重要的几个密码（邮箱、银行、主密码）另外抄了一份在纸上，放在家里。

值不值

一年省六十美元，折合人民币四百多。花的时间大概是一个周末。

如果只看钱，不太值。但这四个月里，我对自己的密码到底存在哪儿、怎么加密的、备份在什么地方，有了完全的掌控。这种确定感是订阅服务给不了的。

当然也有代价。服务器挂了是我的责任，数据丢了我的责任，被人攻破了也是我的责任。用别人的服务，这些责任是别人担的。

这个取舍每个人不一样。我的选择是，愿意为掌控感承担这份责任。

两个容器明明在同一个宿主机上，就是互相连不上

Mon, 29 Jul 2024 02:54:00 +0800

有段时间我在搭一个小的内部工具，前端是一个 PHP 的容器，后端是一个 Redis 容器。两个都在同一台机器上，端口也都正常开着。

但 PHP 那边一连 Redis 就报错，Connection refused，或者更奇怪一点，php_network_getaddresses: getaddrinfo failed。

我当时的第一反应是，两个容器不是都在 172.17.0.x 这个网段吗，怎么可能连不上。

这个想法本身就是错的。花了小半个晚上才想明白问题出在哪，记一下。

先看清楚默认的 bridge 网络

我当时的启动命令大概是这样的：

1
2

docker run -d --name redis redis:7
docker run -d --name web -p 8080:80 php:8.2-apache

两条命令都没指定 --network，所以它们都跑在默认的 bridge 网络上。

docker network inspect bridge 看一眼：

`1`	`docker network inspect bridge --format '{{json .Containers}}' \| jq`

两个容器确实都在里面，IP 分别是 172.17.0.2 和 172.17.0.3。

那我先进 web 容器里试一下：

1
2

docker exec -it web bash
ping 172.17.0.3

通。说明二层是通的，两个容器确实能互相访问。

`1`	`ping redis`

ping: bad address 'redis'

到这里问题就很清楚了。IP 能通，名字解析不了。

默认 bridge 没有内置 DNS

这是 Docker 里一个非常容易踩的点。

在默认的 bridge 网络上，Docker 是不提供自动服务发现的。容器之间只能通过 IP 通信，不能通过容器名。你想让 redis 这个名字能解析，得自己用 --link，而这个参数早就被标记成废弃了，官方文档里明确说不建议用。

那为什么我印象里"容器名可以互相访问"呢。

因为自定义网络可以。

只要你自己建一个 bridge 网络，Docker 就会给它启用一个内置的 DNS 服务器，所有接入这个网络的容器都会自动注册自己的名字。之后容器之间直接 ping 服务名 就能通。

这就是关键区别。默认 bridge 是个历史包袱，为了兼容早期的行为，它没开这个功能。

改成自定义网络

1
2
3

docker network create appnet
docker run -d --name redis --network appnet redis:7
docker run -d --name web --network appnet -p 8080:80 php:8.2-apache

再进 web 容器：

`1`	`docker exec -it web bash -c "getent hosts redis"`

这次输出 172.18.0.2 redis，解析成功了。

不过这里还有个细节。ping 在 php:8.2-apache 这个镜像里可能没装，getent hosts 更通用一些。curl、nc 这些也未必有，排查的时候先确认工具在不在。

内置 DNS 是怎么回事

Docker 在每个自定义网络的容器里塞了一个 127.0.0.11 的 DNS 服务器。你可以看一下容器里的 /etc/resolv.conf：

`1`	`docker exec web cat /etc/resolv.conf`

输出大概是：

1
2

nameserver 127.0.0.11
options ndots:0

这个 127.0.0.11 是 Docker 的 embedded DNS。它拦截容器内的所有 DNS 查询，先查自己维护的一张表，也就是同一网络里其他容器的名字。查不到再转发给宿主机的 DNS 或者你在 daemon.json 里配的上游。

ndots:0 这个选项也有讲究。它决定了域名里有多少个点才被当成绝对域名。设成 0 意味着任何带点的名字都先当绝对域名查，不做 search domain 的拼接。这个值能减少很多无谓的查询延迟。

那我当初为什么连 IP 也失败过

前面说 IP 能 ping 通，但那是后来验证的。我最初遇到的报错是 Connection refused，这个和 DNS 没关系，是另一个问题。

Redis 的镜像默认只监听 127.0.0.1。这是从 Redis 3.2 开始的默认行为，官方镜像也继承了这个配置。也就是说，就算你从外面连得上这个容器的 IP，Redis 本身也只接受本机回环的连接。

解决办法是启动的时候覆盖掉：

`1`	`docker run -d --name redis --network appnet redis:7 redis-server --bind 0.0.0.0`

或者用配置文件：

1
2
3

docker run -d --name redis --network appnet \
  -v ./redis.conf:/usr/local/etc/redis/redis.conf \
  redis:7 redis-server /usr/local/etc/redis/redis.conf

配置文件里写 bind 0.0.0.0，再配一个 requirepass，因为一旦绑到 0.0.0.0，同网络里任何容器都能连，得有个密码。

这里顺便说一句，bind 0.0.0.0 不等于把 Redis 暴露到公网。只要你没做端口映射，外面还是进不来，只有同一 Docker 网络里的容器能访问。这个边界很容易搞混。

名字里的下划线和连字符

还有一次，我在 Compose 里把服务名写成了 my_redis，然后在应用配置里写 my_redis，死活解析不了。

查了半天，是 Docker 的 DNS 对下划线的处理有点特殊。容器名里带下划线的时候，有些客户端库在做解析的时候会失败，因为下划线在主机名规范里本来就不是合法字符。

把服务名改成 my-redis，问题立刻消失。

所以我的建议是，容器名和服务名只用小写字母、数字和连字符。别用下划线，也别用大写。这个约定能省掉很多莫名其妙的解析失败。

Compose 里的网络行为

Compose 比裸 docker run 好一些，它会自动为每个项目建一个网络，项目内的服务默认都接进去，名字自动能解析。

但有几个地方还是会踩。

一个是跨项目。项目 A 的容器想连项目 B 的容器，默认是连不上的，因为它们在两个不同的网络里。得建一个外部网络，两边都声明 external: true 接进去。

另一个是 container_name 和 services 键的区别。如果你设了 container_name: redis，那这个容器在网络里的别名就是 redis。如果你没设，Compose 生成的容器名是 项目名-redis-1，但它在网络里的别名同时包含 redis 和 项目名-redis-1。所以在同一个 Compose 项目里，写服务名总是能通的。

这个行为在扩容的时候会变。docker compose up --scale web=3 之后，三个 web 容器会共享 web 这个别名，DNS 返回的是一组 IP，客户端连到哪个不确定。这时候做负载均衡是它自带的，不需要额外配置。

一个特别隐蔽的坑：网络别名冲突

我有一次把两个不同的项目都接到了同一个外部网络里，然后两边都有一个叫 db 的服务。

结果就是 DNS 返回两个 IP，客户端随机连，有时候连到 A 的数据库，有时候连到 B 的。数据错乱了一整天才发现。

解决办法是给服务加显式的网络别名：

services:
  db:
    networks:
      shared:
        aliases:
          - projectA-db

然后应用里就写 projectA-db。这样不会撞。

或者干脆别共用网络，用不同的网络隔离。这个我后来更倾向，隔离得越清楚，出问题的概率越小。

排查顺序

踩过这几次之后，我形成了一个固定的检查顺序。

先看容器在不在同一个网络：

1
2

docker inspect web --format '{{range $k, $v := .NetworkSettings.Networks}}{{$k}} {{end}}'
docker inspect redis --format '{{range $k, $v := .NetworkSettings.Networks}}{{$k}} {{end}}'

两个输出里得有至少一个共同的网络名。

再看容器里的 DNS 配置：

`1`	`docker exec web cat /etc/resolv.conf`

得看到 127.0.0.11。

再试解析：

`1`	`docker exec web getent hosts redis`

能解析出 IP 说明名字这块没问题了。

最后测连通性：

`1`	`docker exec web nc -zv redis 6379`

到这一步还不行，那就是服务本身没监听对地址，或者有防火墙规则。

这套顺序跑一遍，基本五分钟内能定位。

现在的习惯

我现在新起一个服务，一律先建自定义网络，绝不往默认 bridge 里塞东西。

Compose 的话，我习惯显式写一个 networks 段，哪怕只是默认的那个。写出来心里有数，不用去猜它自动生成了什么名字。

还有个小习惯，我在容器里排查的时候，如果发现 ping、curl、nc 都没有，会临时起一个 nicolaka/netshoot 容器接到同一个网络上：

`1`	`docker run -it --rm --network appnet nicolaka/netshoot`

这个镜像里工具很全，dig、tcpdump、curl、nc 什么都有。比自己往业务镜像里装工具干净得多。

这类网络问题，说穿了就是"默认配置不是你以为的那个"。默认 bridge 没有 DNS，Redis 默认只听回环，容器名别带下划线，这三件事记住了，能省掉一大半的排查时间。

20G 的硬盘被 Docker 吃干净了，我把清理这件事理顺了

Wed, 22 May 2024 10:46:00 +0800

那天早上是被监控机器人的 Telegram 消息震醒的。

[WARN] rootfs usage 92%，我那台 20G 硬盘的小机器。前一天晚上看还是 78%，一夜之间涨了十几个点。

登上去 df -h 一看，/ 确实快满了。但奇怪的是，du -sh /var/lib/docker 只有 9 个多 G，和我印象里的数字差不多。真正占地方的东西藏在哪儿了。

这次排查让我把 Docker 的磁盘占用彻底搞清楚了一遍，记下来。

先搞清楚它到底占了多少

`1`	`docker system df -v`

这个命令比 docker system df 详细得多，它会把镜像、容器、本地卷、构建缓存四类分开列，每一类还列出具体的条目和大小。

我第一次跑出来的结果是这样的：

TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          42        9         18.6GB    13.2GB (71%)
Containers      11        8         210MB     180MB (85%)
Local Volumes   17        6         3.1GB     1.4GB (45%)
Build Cache     88        0         2.4GB     2.4GB

十八个 G 的镜像，只有九个是活跃的。这就是问题所在。

我这两年在同一台机器上试过太多东西，什么 GitLab、Drone、MinIO、各种数据库版本，装完觉得不好用就 docker compose down 了，容器没了，镜像还躺在那儿。每个都几百兆，攒起来就是十几个 G。

镜像怎么清

最直接的是清掉那些没有标签的悬空镜像：

`1`	`docker image prune`

它只会删掉 <none>:<none> 那种，也就是构建过程中产生的中间层，或者被新版本顶掉标签的旧镜像。这个操作是安全的，因为没有任何容器在用它们。

如果想连"有标签但没有容器使用"的一起删：

`1`	`docker image prune -a`

这个就要小心了。它会问你确认，确认之后把所有没被容器引用的镜像全删掉。我当时脑子一热跑了这个，结果把我准备好的 mariadb:10.11 也删了。虽然能重新拉，但那台机器的网络拉大镜像很慢，花了十几分钟。

后来我的做法是先看清单再决定：

`1`	`docker image ls --filter "dangling=false" --format "table {{.Repository}}\t{{.Tag}}\t{{.Size}}\t{{.CreatedSince}}"`

按创建时间排序，心里有个数，再挑着删。

单个删：

`1`	`docker image rm <IMAGE_ID>`

如果提示被容器引用，先看是哪个容器：

`1`	`docker ps -a --filter ancestor=<IMAGE_ID>`

容器和它的可写层

docker ps -a 里那些 Exited 状态的容器，很多人以为删了容器就干净了，其实容器本身的可写层也占空间。

`1`	`docker container prune`

这个只删已停止的容器。有几点要提醒。

容器删了，它的可写层就没了。如果你在容器里手动改过什么文件、装过什么包，没写进镜像也没挂载出来，那部分就彻底丢了。我之前有个容器，为了图省事直接在里面 apt install 了个工具，后来 prune 一跑，第二天发现功能没了，又得重来一遍。

所以正确做法是，要么写进 Dockerfile，要么挂载出来，别指望容器的可写层能长期保存东西。

数据卷是最需要小心的一类

`1`	`docker volume prune`

这个命令删的是"没有被任何容器引用"的卷。听起来很安全，实际上有个陷阱。

我那次跑完之后，发现一个早就停掉的测试容器的数据卷被删了。虽然那个容器本来也没用了，但里面存着我早期的一些实验数据。删掉之后想找回来是不可能了。

所以我的建议是，跑之前先列出来看看：

`1`	`docker volume ls --filter "dangling=true"`

确认这些名字你都不认识、也不想要，再执行 prune。

更稳的做法是一个一个删：

`1`	`docker volume rm <VOLUME_NAME>`

麻烦，但至少你知道自己删了什么。

还有一种情况要注意。如果卷的名字是 Compose 自动生成的（形如 项目名_卷名），你 docker compose down 的时候不加 -v，卷是会保留的。加了 -v 就会连卷一起删。这个 -v 我在文档里看到过好几次，但真正记住是在一次误操作之后。

构建缓存：最容易被忽略的大头

这个是我这次排查才发现的大户。

`1`	`docker builder prune`

它会删掉 BuildKit 的缓存。现在的 Docker 默认用 BuildKit，每次 docker build 都会把中间层缓存下来，下次构建能复用。这个机制很好，但缓存不会自己过期，越攒越多。

我那次看到 2.4G，基本上都是几个月前折腾某个项目留下的。

想连所有缓存一起清：

`1`	`docker builder prune -a`

-a 是 all，包括那些还在被引用的缓存。清完之后下次构建会慢一些，但空间能立刻回来。

还有个带时间过滤的用法，我觉得挺实用：

`1`	`docker builder prune --filter "until=168h"`

只删七天以前的。这样常用的缓存还能留着，老的自然淘汰。

一键清理，以及为什么我不推荐

网上到处都写着这条：

`1`	`docker system prune -a --volumes`

它会把停止的容器、没用的网络、所有没被引用的镜像、所有没被引用的卷、所有构建缓存，一次性全清掉。

确实爽，我那次跑完从 92% 降到了 51%。

但我不推荐把它当成日常操作。原因有三个。

它不问你就删卷。数据卷里可能有你还没意识到重要的东西。

它把镜像全清了。下次起服务要重新拉，如果网络不好，等于给自己挖坑。

它不区分环境。你在开发机上跑和在跑着线上服务的机器上跑，风险完全不一样。我有一次在生产机上顺手跑了，把一个还没启动但准备切换的旧版本镜像删了，回滚的时候抓瞎。

我现在的固定动作

经过这次，我给自己定了一套流程，每个月做一次。

先看占用：

`1`	`docker system df -v`

然后按风险从低到高依次清：

1
2
3

docker container prune -f
docker image prune -f
docker builder prune -f --filter "until=336h"

这三条都是只删"明确没用"的东西，相对安全。卷我单独处理，先 docker volume ls --filter dangling=true 看清单，确认了再手动删。

再加上一条，给日志设上限。这个比清理更治本。Docker 默认的 json-file 驱动不限制大小，一个话多的服务能写到几个 G。我在每个 compose 文件里都加了：

logging:
  driver: json-file
  options:
    max-size: "10m"
    max-file: "3"

这样单个容器最多占 30M 日志，怎么跑都撑不爆。

顺手发现的一个问题

清理的时候我注意到 /var/log 下面也有几个 G。是 journald 的日志，默认能占到磁盘的 10%。

`1`	`journalctl --disk-usage`

看到是 1.8G。我改了 /etc/systemd/journald.conf：

`1`	`SystemMaxUse=200M`

然后 systemctl restart systemd-journald，空间立刻回来了。

这个问题和 Docker 没关系，但它们是同一类问题，都是"某个东西默认不限制自己，跑久了就把盘吃满"。清理只是补救，设上限才是根治。

现在的状态

清完之后稳定在 55% 左右，跑了两个月没再告警。

我也顺手在监控里加了一条，磁盘超过 80% 就推消息。这次是被 92% 才叫醒的，有点晚。早点知道，处理起来从容得多。

回头看，这件事本身没什么技术含量，真正花时间的是搞清楚哪些能删、哪些不能。Docker 把很多东西藏起来了，system df -v 这个命令就是那把钥匙。知道东西在哪儿，才谈得上管理。

用了两年 Docker Compose，我把这些套路固定下来了

Tue, 26 Mar 2024 06:32:00 +0800

刚开始用 Docker 那阵子，我特别喜欢在命令行里敲 docker run。参数一行能拉出去两百多个字符，-v、-p、-e 混在一起，看着挺有成就感。

直到有一次我为了调一个环境变量，把容器删了重建，结果忘了当初挂载的路径是哪个。数据卷还在，但容器起不来了，日志里全是找不到配置文件的报错。我在 docker inspect 的输出里翻了十几分钟，才从一个早已忘记的临时目录里把东西找回来。

那次之后我就老老实实用 Compose 了。现在服务器上所有的服务，都是一个个 compose.yaml 管着。

为什么是 Compose 而不是别的

有人会说，你都上 Docker 了，干嘛不上 Kubernetes。

我的答案很朴素，我就一台 2 核 4G 的机器，跑着七八个容器。K8s 的控制面自己就要吃掉一两个 G，剩下的空间还不够我塞服务。而且我一个人维护，出问题的时候需要的是能快速看懂的东西，不是一整套抽象。

Compose 的好处是，所有配置都在一个文件里，看得见摸得着。改完 docker compose up -d，它自己算差异，只重建变化的部分。要回滚就把文件换回去再 up 一次。

还有个被低估的点，就是文件本身就是文档。半年后我忘了某个服务是怎么配的，打开文件一看全明白了。

目录怎么摆

我现在的习惯是，所有服务放在 /srv 下面，一个服务一个目录：

/srv
├── blog
│   ├── compose.yaml
│   └── data
├── db
│   ├── compose.yaml
│   ├── conf
│   └── data
├── proxy
│   ├── compose.yaml
│   ├── conf.d
│   └── certs
└── monitor
    ├── compose.yaml
    └── data

数据统一放在服务目录下的 data 子目录，然后挂载进去。这样备份的时候，把 /srv 整个打包就够了，不用去 /var/lib/docker 里翻那些名字是哈希的目录。

这一点很关键。Docker 的具名卷虽然方便，但它在文件系统里藏在 /var/lib/docker/volumes/ 下面，备份脚本写起来很难看。用 bind mount 直接映射到自己的目录，什么都清楚。

一个完整的例子

拿博客举例。我的博客是 Hugo 生成的静态文件，用一个 nginx 容器托管：

services:
  blog:
    image: nginx:1.25-alpine
    container_name: blog
    restart: unless-stopped
    ports:
      - "127.0.0.1:8080:80"
    volumes:
      - ./public:/usr/share/nginx/html:ro
      - ./conf.d:/etc/nginx/conf.d:ro
    healthcheck:
      test: ["CMD", "wget", "-q", "--spider", "http://127.0.0.1/"]
      interval: 30s
      timeout: 5s
      retries: 3
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

几个地方值得说。

ports 我只绑了 127.0.0.1，不写 0.0.0.0。意思是这个端口只能从本机访问，外面进不来。真正对外的入口交给 nginx 反向代理，这样容器端口就不会直接暴露在公网上。这一点在我被扫过几次之后变得特别重要。

restart: unless-stopped 而不是 always。区别在于，我手动 docker compose stop 之后，unless-stopped 的容器重启机器也不会自己起来，always 会。调试的时候这个区别能省不少事。

logging 那段一定要加。Docker 默认的 json-file 日志没有大小限制，一个话多的服务跑上几个月，能把磁盘写满。我第一次被磁盘告警吵醒就是因为这个，日志文件堆到了 20 多个 G。

healthcheck 是给后面的 depends_on 用的，下面会讲。

数据库和依赖顺序

数据库的 compose 我一般这么写：

services:
  mariadb:
    image: mariadb:11.2
    container_name: mariadb
    restart: unless-stopped
    environment:
      MARIADB_ROOT_PASSWORD_FILE: /run/secrets/db_root
      MARIADB_DATABASE: app
      MARIADB_USER: app
      MARIADB_PASSWORD_FILE: /run/secrets/db_app
      TZ: Asia/Shanghai
    volumes:
      - ./data:/var/lib/mysql
      - ./conf/my.cnf:/etc/mysql/conf.d/my.cnf:ro
    ports:
      - "127.0.0.1:3306:3306"
    healthcheck:
      test: ["CMD", "healthcheck.sh", "--connect", "--innodb_initialized"]
      interval: 10s
      timeout: 5s
      retries: 10
      start_period: 30s

secrets:
  db_root:
    file: ./secrets/db_root.txt
  db_app:
    file: ./secrets/db_app.txt

密码用 secrets 而不是直接写 environment。这样 docker inspect 出来的环境变量里看不到明文，compose.yaml 也可以放心提交到私有仓库。文件权限设成 600 就行。

start_period 这个参数新手容易忽略。它是给容器一个"还在启动中，别急着判定失败"的宽限期。MariaDB 第一次初始化数据目录要花几十秒，不设这个，健康检查会一直失败，把容器标记成 unhealthy。

healthcheck.sh 是 MariaDB 官方镜像自带的脚本，比自己拼 mysqladmin ping 可靠，因为它会真的等到 InnoDB 初始化完。

应用那边要等数据库好了再起，就这么写：

  app:
    image: myapp:latest
    depends_on:
      mariadb:
        condition: service_healthy

注意是 service_healthy，不是默认的 service_started。默认那个只保证容器进程起来了，不保证里面服务能连。我第一次用默认值的时候，应用每次重启都要重试好几次才连上数据库，日志里一堆 connection refused。

网络怎么连

Compose 默认会给项目建一个 bridge 网络，同一个文件里的服务互相用服务名就能访问。这个挺好用，但跨文件就不行了。

我有两个选择。要么把相关服务塞进同一个 compose 文件，要么建一个外部网络让它们共享。

我选了后者，因为数据库和博客的更新节奏不一样，混在一个文件里，改博客的配置会把数据库也带着重建一次，太危险。

建网络：

`1`	`docker network create --driver bridge shared`

然后每个文件里都声明：

1
2
3

networks:
  shared:
    external: true

服务上再加一句：

1
2

    networks:
      - shared

这样博客容器里直接 ping mariadb 就能通。

不过这里有个坑，container_name 和自定义网络里的服务名是两套东西。用 container_name 的时候，容器在网络里的别名是那个名字，不是 services 下的键。我一开始没注意，配置里写服务名连不上，改成 container_name 才对上。

我的建议是干脆别用 container_name，让 Compose 自己按 项目名-服务名-序号 生成。虽然名字长一点，但不会和别的项目冲突，扩容的时候也不会撞名。

反代那一层

nginx 做反向代理的容器，配置文件单独放：

server {
    listen 80;
    server_name blog.mibase.top;

    location / {
        proxy_pass http://blog:80;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

proxy_pass 里写的是容器名，因为它在同一个 shared 网络里，Docker 的内置 DNS 会解析。

X-Forwarded-For 这几行别省。省了之后，nginx 的访问日志里全是反代容器的内网 IP，你想看真实访客来源就看不到了。Cloudflare 那边传过来的真实 IP 也会在这一层层里丢掉。

更新镜像的流程

我不用 watchtower 那种自动更新的东西。自动更新很爽，但它会在你睡觉的时候把一个能跑的服务换成一个跑不起来的版本。

我的流程是手动但固定：

cd /srv/db
docker compose pull
docker compose up -d
docker compose ps
docker compose logs --tail=50

拉完先看 ps，确认状态是 running 并且 healthy，再看日志有没有报错。有问题就 docker compose down 然后换回上一个 tag。

所以镜像 tag 我尽量不用 latest，写具体版本号。mariadb:11.2 比 mariadb:latest 可控太多了。

备份怎么配合

因为数据都在 /srv/*/data 下面，备份脚本写起来很直接：

#!/bin/bash
set -euo pipefail
ts=$(date +%F)
tar -czf /backup/srv-$ts.tar.gz -C / srv --exclude='*/cache/*'

不过数据库不能这么直接打包，热备份出来的文件可能是不一致的。数据库我单独用 mariadb-dump 导出：

`1`	`docker compose exec -T mariadb mariadb-dump --all-databases --single-transaction > /backup/db-$ts.sql`

--single-transaction 保证导出的是一个一致的时间点，不会因为导出过程中有人写入而错乱。

写在最后

Compose 这个工具本身不复杂，难的是把使用习惯固定下来。

我现在新加一个服务，基本就是复制一个已有的目录，改改镜像名和端口，十分钟能跑起来。出问题的时候也知道去哪儿看，日志在哪、数据在哪、配置在哪，都是固定的位置。

这套东西没什么高深的技术，但它让我在面对一台跑了两年、装着七八个服务的机器时，心里是有底的。这大概就是运维这件事最实际的价值。