企业官网建设流程全解析

在部署Coze Studio 开源版的过程中，通常会使用一整套docker-compose服务，包括数据库、缓存、搜索、对象存储、向量数据库、消息队列以及应用本身。
随着反复部署、调试和升级，Docker 环境中往往会残留大量与当前项目无关的容器和镜像。

如果不加控制地清理，容易误删正在使用的服务；
如果长期不清理，又会造成磁盘占用、端口冲突和环境混乱。

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

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

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

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

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

核心矛盾在于：

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

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

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

1. 容器命名特征

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

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 核心服务镜像同样具备明显特征：

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

Repository 中统一包含coze关键字。

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

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

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

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

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

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

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

coze-mysql coze-redis

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

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

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

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

1. 预览将被删除的容器

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

含义说明：

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

2. 删除非 Coze 容器

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

参数说明：

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

3. 预览将被删除的镜像

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

4. 删除非 Coze 镜像

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

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

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

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

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

这种方式的优势是：

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

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

清理无用网络

docker network prune -f

清理无用 volume（谨慎）

docker volume prune -f

仅在确认：

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

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

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

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

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

grep-v project_name

但前提始终不变：

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

七、适用范围与限制说明

适用场景

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

不适用场景

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

八、总结

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

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

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

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

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

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