我们在开发人员团队中使用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。我将改变归因于＆＃34; new＆＃34;码头版。我尝试将docker-compose降级到以前的版本，看起来这与docker-compose无关。
受到以下答案的启发，我们发现了以下解决方法：
我们将env变量COMPOSE_PROJECT_NAME设置为主机上用户登录时的用户名。然后我们将docker-compose.yml文件中的服务名称扩展为<proj>_<service>，从而避免跨项目的相同服务名称之间的任何冲突。
答案 0 :(得分：2)
使用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具有相同的效果。