docker-compose：使用环境变量从同一个 docker-compose 文件启动服务以更改容器名称

Question

我们在一个开发团队中使用 docker。我们有所有开发人员都在从事的项目。由于我们不希望每个开发人员都有一个docker-compose.yml，因此我们使用环境变量将用户名传递给 docker-compose。在 docker-compose 里面我们有这样的东西 services: myservice: image: myimage container_name: ${user}_myservice

这对我们来说过去工作得很好，但最近停止工作了。假设有两个用户。第一个用户运行 docker-compose up myservice 启动 ${user1}_myservice。当第二个用户发出相同的命令时，第二个用户将终止运行在 ${user1}_myservice 下的容器并启动 ${user2}_myservice。

不知何故，现在 docker 服务似乎直接链接，而不仅仅是像以前那样通过 container_name 变量。

我们最近将 docker 升级到了Docker version 17.09.0-ce, build afdb6d4。我将更改归因于“新”docker 版本。我曾尝试将 docker-compose 降级到以前的版本，似乎这与 docker-compose 无关。

更新

受以下答案的启发，我们找到了以下解决方法：

我们将环境变量COMPOSE_PROJECT_NAME 设置为主机用户登录时的用户名。然后我们将 docker-compose.yml 文件中的服务名称扩展为<proj>_<service>，从而避免跨项目的相同服务名称之间的任何冲突。

Answer 1

与其在docker-compose.yml 中处理变量，不如将--project-name (-p) 选项用于docker-compose 可能更容易。

通常，docker-compose 从包含您的 docker-compose.yaml 文件的目录的名称中派生项目名称。因此，如果两个人尝试从名为 myapp 的目录启动应用程序，他们最终会发生冲突，因为两个实例都将尝试使用相同的名称。

但是，如果他们改为运行：

docker-compose --project-name ${USER}_myapp ...

然后docker-compose 为每个用户使用不同的项目名称（如alice_myapp 和bob_myapp），不会有冲突。

如果人们厌倦了使用-p 选项，他们可以像这样创建.env：

COMPOSE_PROJECT_NAME=alice_myapp

这与在命令行中指定-p alice_myapp 的效果相同。