docker-compose：使用env vars从相同的docker-compose文件启动服务来更改容器名称
我们在一个开发团队中使用docker。 我们有项目的所有开发者的工作。 由于我们不希望每个开发人员都有一个docker-compose.yml ，所以我们使用环境variables将用户名传递给docker-compose。 在docker-compose里面我们有这样的services: myservice: image: myimage container_name: ${user}_myservice
这对我们来说工作得很好，但最近停止了工作。 假设有两个用户。 第一个用户运行docker-compose up myservice启动$ {user1} _myservice。 当第二个用户发出相同的命令时，第二个用户将杀死在$ {user1} _myservice下运行的容器并启动$ {user2} _myservice。
不知何故，似乎docker服务现在直接链接，不仅像以前一样通过container_namevariables链接。
我们最近升级了Docker version 17.09.0-ce, build afdb6d4到Docker version 17.09.0-ce, build afdb6d4 。 我将变更归因于“新”泊坞窗版本。 我已经尝试将docker-compose降级到以前的版本，看起来这与docker-compose没有关系。
UPDATE
受到以下答案的启发，我们发现了以下解决方法：
我们将envvariablesCOMPOSE_PROJECT_NAME设置为主机上用户login的用户名。 然后，我们将docker-compose.yml文件中的服务名称扩展为<proj>_<service> ，从而避免跨项目的相同服务名称之间的任何冲突。
而不是在docker-compose.ymlvariables， docker-compose.yml的--project-name （ -p ）选项可能更容易一些。
通常， docker-compose从包含docker-compose.yaml文件的目录名称中派生项目名称。 所以如果两个人试图从一个名为myapp的目录启动一个应用程序，他们将最终发生冲突，因为这两个实例将试图使用相同的名称。
但是，如果他们运行，而不是：
docker-compose --project-name ${USER}_myapp ...
然后docker-compose为每个用户使用不同的项目名称（如alice_myapp和bob_myapp ），这样就不会有冲突。
如果人们厌倦了使用-p选项，他们可以创build一个.env像这样：
COMPOSE_PROJECT_NAME=alice_myapp
这与在命令行中指定-p alice_myapp具有相同的效果。