Tag: docker

在 GHCR 里看到很多 untagged，不一定代表清理任务漏删了垃圾镜像。

如果一个 Docker 镜像是 multi-arch 构建，比如同时构建：

platforms: linux/amd64,linux/arm64

那么一个 tag 通常不是直接贴在某个具体平台镜像上，而是贴在一个“目录”上。这个目录的正式名字叫 OCI image index 或 manifest list。

可以把它理解成：

ghcr.io/org/app:sha-xxxxxxx
  -> 一个总入口 / 目录
      -> amd64 机器用的镜像
      -> arm64 机器用的镜像

用户拉镜像时还是用同一个 tag：

docker pull ghcr.io/org/app:sha-xxxxxxx

Docker 会根据本机架构自动挑正确的子镜像。amd64 机器拿 amd64，arm64 机器拿 arm64。

为什么会显示成 1 tagged + 4 untagged

以一个同时构建 linux/amd64 和 linux/arm64，并且没有关掉 buildx 默认 provenance 的镜像为例，一次构建大致会产生：

1 个 tagged image index
2 个 untagged platform image manifest
2 个 untagged provenance attestation manifest

所以 GHCR 页面上看起来就是：

1 tagged + 4 untagged

这里的 2 个 platform manifest 是真正给不同 CPU 架构运行用的镜像。它们没有自己的 tag，因为 tag 贴在上层 image index 上。

另外 2 个 provenance attestation manifest 不是运行镜像，而是构建证明。它们记录“这个镜像是从哪个 repo、哪个 commit、哪个 Dockerfile、哪次 GitHub Actions run 构建出来的，以及用了哪些基础镜像/构建依赖”。常见格式是 in-toto statement，predicate 是 SLSA provenance。

这些 untagged 可以删吗

不要只看 GHCR UI 上写着 untagged 就手动删。

如果这些 untagged 是被某个保留 tag 引用的子 manifest，删掉以后可能会破坏 multi-arch 镜像，或者丢掉 provenance 证明。正确的清理逻辑应该理解 image index 和它下面的子 manifest，而不是把所有 UI 上的 untagged 都当成孤立垃圾。

像 dataaxiom/ghcr-cleanup-action 这类专门处理 GHCR 清理的工具，会把 multi-arch image、attestation、referrer 这些关系一起考虑。删除旧 tagged image 时，它会连同下面的子 manifest 一起处理；保留新 tagged image 时，被引用的 untagged 子 manifest 也应该留下。

GitHub 能避免这种显示吗

GHCR 目前没有一个开关可以说“不要把被 image index 引用的子 manifest 显示为 untagged”。它是按 registry 里的 manifest/version 展示，所以 UI 会显得比较吵。

能减少数量，但都有代价：

• 关掉 provenance：每批少两个 attestation，代价是没有构建来源证明。
• 只构建单平台：少一个平台镜像，代价是不再同时支持 amd64/arm64。
• 单平台并关掉 provenance：最干净，但功能和供应链信息都缩水。

更实用的判断是：不要追求 GHCR 页面上完全没有 untagged，而是区分“孤立 untagged”和“被保留 tag 引用的 untagged 子 manifest”。前者可以清理，后者是镜像结构的一部分。

docker-compose.yml 中 tty: true 和 stdin_open: true 这两个配置项分别对应 docker run 的 -t 和 -i 参数。

tty: true

分配虚拟终端（Pseudo-TTY），让程序输出像在普通命令行中运行，保留颜色和交互式输出。

stdin_open: true

保持标准输入开启，即使没有 attach 到容器也能接收指令。

适用场景

Minecraft 服务器等需要交互式控制台的服务。

为什么 Minecraft 必须用它们

Minecraft 服务器有交互式控制台，可以：

• 手动输入命令：/op yourname 给自己管理员权限，或 /stop 安全关闭服务器
• 使用 docker attach 进入游戏控制台直接输入指令

如果没开这两个选项，docker attach 只能看输出，无法输入命令。

services:
  mc:
    image: itzg/minecraft-server
    tty: true
    stdin_open: true

总结：tty 负责输出，stdin_open 负责输入。

Docker Compose 默认会给卷名加上项目前缀（目录名），使用 name 属性可自定义卷名。

services:
  db:
    image: postgres
    volumes:
      - my_custom_volume:/var/lib/postgresql/data

volumes:
  my_custom_volume:
    name: "production_db_volume"

运行 docker compose up 后，docker volume ls 会显示 production_db_volume，而非 my-app_my_custom_volume。

适用场景：

• 多项目共享卷
• 固定名字便于脚本编写和迁移

Docker Compose 中的 healthcheck 配置会覆盖 Dockerfile 中的 HEALTHCHECK 指令。

# docker-compose.yml
services:
  web:
    image: myapp
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s

优先级：Dockerfile < Docker Compose。

为什么 Compose 优先？

遵循”运行时配置优于镜像构建配置”原则。Compose 覆盖 Dockerfile 的优势：

• 灵活性：不同环境（开发/测试/生产）可配置不同的检查频率或超时时间
• 依赖管理：配合 depends_on 的 condition: service_healthy 控制容器启动顺序
• 集中管理：在 Compose 文件中一目了然，无需翻阅各镜像源码

vps 内存爆炸了，上来查原因，使用 bottom 查看之后发现是 uwsgi 进程占用高内存，但我印象中我是我没有部署类似的服务的，因为我基本都是使用 docker 来部署的。

通过 cgroup 信息定位问题

Linux 通过 cgroup 来管理容器资源，每个进程都会记录自己属于哪个 cgroup。我们可以利用这一点来找到它所属的容器。

1. 找到 uwsgi 进程的 PID (Process ID)

   pidof uwsgi

   这个命令会返回一个或多个数字，就是 uwsgi 的进程 ID。我们假设返回的是 12345。

2. 查看该 PID 的 cgroup 信息

   cat /proc/12345/cgroup

   在输出中，你会看到类似下面这样的行：

   11:perf_event:/docker/a1b2c3d4e5f6...
   10:cpuset:/docker/a1b2c3d4e5f6...
   ...
   1:name=systemd:/docker/a1b2c3d4e5f6...

   注意 /docker/ 后面那串以 a1b2c3d4e5f6 开头的字符串，这就是容器的完整 ID。

3. 根据容器 ID 找到容器名

   docker inspect a1b2c3d4e5f6 | grep "Name"

   或者更简单地，列出所有容器，手动找到这个 ID：

   docker ps

   在 CONTAINER ID 列中找到对应的 ID，它旁边的 NAMES 列就是你容器的名字，例如 my-web-app。

小技巧： 你可以组合成一条命令，一步到位： cat /proc/$(pidof uwsgi)/cgroup | grep -o '[0-9a-f]\{64\}' | xargs -I {} docker inspect {} | grep "Name"

线上有个小服务，经常使用内存超标，想限制一下。我本来以为 docker compose 这些配置相关的都是跟 swarm 相关的，没想到其实是可以使用的。

在 docker compose 中添加 deploy 相关限制即可：

services:
  frontend:
    image: example/webapp
    deploy:
      resources:
        limits:
          cpus: '0.50'
          memory: 50M
          pids: 1
        reservations:
          cpus: '0.25'
          memory: 20M

参考链接：https://docs.docker.com/reference/compose-file/deploy/#resources