【实战原创】Docker 清理指南：以 Coze Studio 为例的资源保留与清理实践（非万能方案）

在部署 Coze Studio 开源版 的过程中，通常会使用一整套 docker-compose 服务，包括数据库、缓存、搜索、对象存储、向量数据库、消息队列以及应用本身。

随着反复部署、调试和升级，Docker 环境中往往会残留大量与当前项目无关的容器和镜像。

如果不加控制地清理，容易误删正在使用的服务；

如果长期不清理，又会造成磁盘占用、端口冲突和环境混乱。

本文以 Coze Studio 为实际案例，介绍一种 基于"项目边界"的 Docker 清理与保留方法，并说明其适用范围与延伸思路。

本文不是通用清理模板，而是一种 在明确项目归属前提下的安全实践。

一、问题背景：为什么需要"按项目"清理 Docker

在开发或测试环境中，常见问题包括：

同一台机器部署过多个 Docker 项目
历史项目已经废弃，但容器仍在
镜像不断累积，占用大量磁盘
直接使用 docker system prune -a 风险过高

核心矛盾在于：

Docker 本身并不知道"哪些资源属于哪个项目"

因此，清理前必须先人为定义 项目边界。

二、Coze Studio 项目边界的可识别性

1. 容器命名特征

在 Coze Studio 的 docker-compose.yml 中，所有服务容器统一采用 coze- 前缀：

text 复制代码

coze-mysql
coze-redis
coze-elasticsearch
coze-minio
coze-etcd
coze-milvus
coze-nsqlookupd
coze-nsqd
coze-nsqadmin
coze-server
coze-web

这意味着：

只要容器名包含 coze
就可以认为属于 Coze Studio 项目

2. 镜像命名特征

Coze Studio 核心服务镜像同样具备明显特征：

text 复制代码

cozedev/coze-studio-server
cozedev/coze-studio-web

Repository 中统一包含 coze 关键字。

三、清理策略的核心思想（比命令更重要）

1. 先定义"保留集合"，而不是"删除集合"

在 Coze Studio 场景中，保留规则是：

保留所有 名称包含 coze 的容器
保留所有 Repository 包含 coze 的镜像

其余资源，才是候选删除对象。

2. 不要过度细化过滤条件

不要使用 coze-studio 作为过滤条件：

text 复制代码

coze-mysql
coze-redis

这些基础服务并不包含 coze-studio，但它们同样是项目的一部分。

3. 所有删除操作必须可预览

任何清理命令，都应当先有一个"只查看、不删除"的版本，用于人工确认。

四、以 Coze Studio 为例的实际清理操作

1. 预览将被删除的容器

bash 复制代码

docker ps -a --format '{{.ID}} {{.Names}}' | grep -v coze

含义说明：

列出所有容器
排除名称中包含 coze 的
剩余即为"非 Coze 项目容器"

2. 删除非 Coze 容器

bash 复制代码

docker ps -a --format '{{.ID}} {{.Names}}' \
| grep -v coze \
| awk '{print $1}' \
| xargs -r docker rm -f

参数说明：

-f：强制删除，包括运行中的容器
-r：当列表为空时不执行命令，避免误操作

3. 预览将被删除的镜像

bash 复制代码

docker images --format '{{.ID}} {{.Repository}}:{{.Tag}}' | grep -v coze

4. 删除非 Coze 镜像

bash 复制代码

docker images --format '{{.ID}} {{.Repository}}' \
| grep -v coze \
| awk '{print $1}' \
| sort -u \
| xargs -r docker rmi -f

五、关于"保留"的进一步延伸

1. 数据永远不应依赖匿名 volume

Coze Studio 默认采用宿主机目录挂载：

text 复制代码

./data/mysql
./data/minio
./data/milvus

这种方式的优势是：

Docker 清理不会影响数据
数据可直接备份
环境可快速重建

2. 可选清理：无主网络与 volume

清理无用网络

bash 复制代码

docker network prune -f

清理无用 volume（谨慎）

bash 复制代码

docker volume prune -f

仅在确认：

数据未存放在 Docker volume
或已有完整备份
的情况下执行。

六、从 Coze 案例延伸到其他项目

这个方法并不专属于 Coze Studio，本质条件只有一个：

项目是否具备清晰、可识别的命名边界

将 coze 替换为你的项目关键字即可：

bash 复制代码

grep -v project_name

但前提始终不变：

命名必须稳定
能准确区分"项目内 / 项目外"资源

七、适用范围与限制说明

适用场景

本地开发环境
测试环境
单机多项目部署
项目命名规范清晰

不适用场景

生产环境
多项目共用基础镜像
不清楚数据依赖关系的系统
命名混乱的历史环境

八、总结

Coze Studio 只是一个具体示例，它所体现的价值在于：

项目资源命名清晰
项目边界明确
数据与容器解耦

基于这些前提，按项目清理 Docker 资源 才是一种安全、可控的操作。

在执行任何清理之前，都应先问自己一个问题：

我是否能够准确判断，这个资源是否属于当前项目？

只有答案明确时，清理才是工程行为，而不是冒险操作。