【问题标题】：Why docker container name has an random number at the end?为什么docker容器名称末尾有一个随机数？
【发布时间】：2018-11-15 19:46:33
【问题描述】：

我有一个 docker-compose.yml 文件如下（其中的一部分）：

version: '3.5'
services:
    framework:
    image: ${DOCKER_REGISTRY}/gme/fmk:${COMPOSE_PROJECT_NAME}
    build: ./fmk
    ports:
      - "2020:2020"
      - "2025:2025"
      - "4999:4999"
    volumes:
      - ${FOLDER_ENV}/workspace/logs/framework:/var/log/gcti
      - ${FOLDER_ENV}/..:/usr/local/genesys/gsg_qaart

我得到的是：

vagrant@docker:/repos/gsg_qaart/docker$ docker-compose ps
]              Name                             Command               State                                             
Ports
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------
callback_framework_1_df361f67842c   /bootstrap.sh                    Up      0.0.0.0:2020->2020/tcp, 0.0.0.0:2025->2025/tcp, 0.0.0.0:4999->4999/tcp, 5432/tcp

你看名字很奇怪，应该是“callback_framwork_1”，为什么后面有一个随机数？

顺便说一句，我正在使用：

vagrant@docker:/repos/gsg_qaart/docker$ docker -v
Docker version 18.09.0, build 4d60db4
vagrant@docker:/repos/gsg_qaart/docker$ docker-compose -v
docker-compose version 1.23.1, build b02f1306

谢谢。

【问题讨论】：

docker ps 的输出是什么？
e743b462e56c gme/fmk:callback "/bootstrap.sh" 2 分钟前上升 2 分钟 0.0.0.0:2020->2020/tcp, 0.0.0.0:2025->2025/tcp, 0.0. 0.0:4999->4999/tcp, 5432/tcp callback_framework_1_2d34e5dc1703
我刚刚更新到最新的 docker 版本后也得到了这个。它破坏了我的脚本，因为我不能再指望容器名称保持不变
我猜这破坏了 LOADS 脚本（当然包括我团队的脚本）。难怪他们在不到一个月的时间内就回滚了。

标签： docker docker-compose containers

【解决方案1】：

编辑。

此更改在 v1.23.2 中恢复

所以compose v1.23有一个重要的变化，https://github.com/docker/compose/releases/tag/1.23.0

Compose 在此创建的容器的默认命名方案版本已从 project_service_index 更改为 project_service_index_slug，其中 slug 是随机生成的十六进制字符串。请确保更新在升级之前相应地依赖旧命名方案的脚本。

因此，如果您想要一个确定的容器名称，请使用

services:
    framework:
        container_name: framework

【讨论】：

【解决方案2】：

我无法对容器名称进行硬编码，我希望能够从任何目录运行。所以我最终选择了部分名称：

docker exec -it $(docker ps --format='{{.Names}}' | grep server) bash

【讨论】：

【解决方案3】：

请注意，其他答案/故障排除是有效/正确的，但我想为使用 docker-compose 提供一些思考，尽管 docker-compose 如何恢复 slug 更改。在使用 docker-compose 服务时可以强调一个很好的做法。

我个人的想法是 docker-compose 试图改变他们工具的使用方式。我在 github 上阅读了一些暗示这一点的内容，但这是我在阅读了他们的一些开发人员反馈后的看法，特别是来自以下 github issue on the slugs。

利用docker-compose的内部服务机制

我试图概括一下，因为以下示例可能并不完全适用于您的设置，但它们应该会有所帮助。由于您已经在使用 docker-compose，因此使用通过 docker 网络和 docker-compose 提供的服务发现优于通过容器名称进行硬编码访问。

使用 docker-compose 时，会创建由 1..* 个容器组成的服务。在您的示例中，服务 framework 是使用 1 个容器 callback_framework_1_df361f67842c 创建的。

从另一个 docker 容器/docker 容器中的代码访问服务

服务可用于 DNS/网络而不是容器名称，即 <protocol>://<host>:<port>/<endpoint> 无处不在，其中 container name 被用作 <host>，service name 也可以用作 <host> (例如在 docker 网络上的另一个容器内执行 ping）：

ping <service>
ping framework

对

ping <container-name>
ping callback_framework_1_df361f67842c

以上两个 ping 都有效。 Docker 负责与相应容器的网络连接，当有多个容器组成一个服务时，它负责对容器的负载均衡请求。

从主机通过服务访问你的容器，即从脚本运行 docker 命令

如果您有从主机执行的脚本，您也可以使用 docker-compose 代替 docker 命令：

docker-compose exec <service> sh
docker-compose exec framework sh

对

docker exec -it <container-name> sh
docker exec -it callback_framework_1_df361f67842c sh

docker-exec 默认使用第一个容器，但是当有多个容器组成一个 docker 服务时，可以使用--index=<index> 标志来寻址目标容器。详情请见docker-compose exec documentation。

【讨论】：