Docker资源名称命名规则 - Docker

由于没有找到Docker官方文档、权威参考，本文内容取自AI、网络和使用经验，如果有不正确之处请指出。

什么是有效 Docker 资源名？

在 Docker 里常说的“有效资源名”，指的是容器 / 服务 / 网络 / volume / secret / config / stack 等资源的名称必须满足的格式规则。不同资源略有差异，但核心规则是一致的。

1）通用核心规则（最常见、最安全）

一个“安全且通用”的 Docker 资源名应满足：

✅ 推荐（最稳）：

my-service
web
redis-cache
app_v2

❌ 不推荐 / 可能报错：

-my-service
my_service_
my.service
app:1

很多 Docker 资源名的校验大致等价于（不完全逐字引用，但意思对了）：

实际上：全小写 + - 分隔 是社区事实标准，几乎不会踩坑。

如果你不确定某个名字是否“有效/稳妥”：

只用小写字母 + 数字 + -，不以 - 开头结尾，别加点/冒号/空格。

Docker Swarm 的 stack 名称在命名上有一些硬性限制和推荐习惯，下面按“必须 / 建议”给出总结。

Stack 名称最终会作为前缀参与生成资源名：

<stack>_<service>
<stack>_<network>
<stack>_<secret>
<stack>_<config>

因此 stack 名称必须是一个有效的 Docker 资源名称，通常要求：

示例合法名：

prod
staging
demo-web
app_v2

改 stack 名 ≈ 重新创建所有资源 因为资源名是 <stack>_<service>，改名后旧 service/network 不会自动复用。
不要依赖 stack 名做“环境区分”过度复杂化 比如 prod-eu-web-01 这种偏长，往往不如用 label/environment=prod 清晰。
某些老版本/某些场景对 _ 处理不一致，- 更安全。

Stack 名应是小写字母/数字，用 - 分隔，不以 -/_ 开头结尾的短名字；它会直接成为服务/网络等资源的前缀，所以命名要稳定、可读、可预测。

在 Docker Swarm 的 stack 文件（deploy） 里，services 下的 key（服务名） 一般遵循下面这些约定/规则：

这其实和 Docker 的 container name / service name / network name 的命名限制是一致的。

当你用 docker stack deploy -c xxx.yml mystack 部署时，最终资源名会变成：

<stack>_<service>

例如 mystack_web，mystack_redis。

因此：服务名本身不要带 stack 前缀，除非你有意为之。