docker - docker-compose:使用env vars从同一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。我将更改归因于"new" docker 版本。我尝试将docker-compose降级到以前的版本，看来这与docker-compose没有关系。

更新

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

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

Answer 1

与其 mock 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具有相同的效果。