避免docker-compose.yml配置之间的端口冲突？

我正在使用Docker for Mac，在单独的存储库中有3个不同的“微服务”，它们有自己的

Docker compose.yml

文件。这些服务本身不在docker中运行，但有一个

docker compose.yml

文件，用于显示每个服务使用的数据库（例如postgresql、minio和redis）。这使我能够轻松地独立处理服务

但是，由于端口冲突，很难同时提供两个服务

cd service1和&docker compose up-d和&cd service2和&docker compose up-d

。例如，如果service1调出PostgreSQL并将其公开到端口5432，而service2也希望这样做，那么第二个

docker compose up

命令将失败

这两个服务共享同一个PosgtreSQL容器是可以接受的，但我不确定是否可以告诉docker compose“使用service1中的数据库（如果可用），或者创建一个新容器”

另一个解决方案是确保每个服务都有一个唯一的端口，但随着使用越来越多的docker compose堆栈，这可能很难跟踪

任何关于管理此类工作流的建议都将不胜感激

如果有帮助，下面是我的docker-compose.yml文件之一的外观：

minio:
  image: minio/minio
  ports:
    - "9000:9000"
  volumes:
    - ./test/.minio/data:/export
    - ./test/.minio/config:/root/.minio
  environment:
    - "MINIO_ACCESS_KEY=AKIAIOSFODNN7EXAMPLE"
    - "MINIO_SECRET_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
    - "MINIO_ENABLE_FSMETA=true"

createbucket:
  image: garland/aws-cli-docker
  links:
    - minio
  command: >
    /bin/sh -c "
      while ! wget -q -s http://minio:9000/minio/login; do sleep 1; done;
      aws configure set default.s3.signature_version s3v4;
      aws configure set default.region us-east-1;
      aws s3api create-bucket \
        --bucket service1-test \
        --endpoint-url=http://minio:9000;
      exit 0;
    "
  environment:
    - "AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE"
    - "AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"

db:
  image: postgres:9.5
  ports:
    - "5432:5432"

createdb:
  image: postgres:9.5
  links:
    - db
  command: >
    /bin/bash -c "
      while ! psql --host=db --username=postgres; do sleep 1; done;
      psql --host=db --username=postgres -c 'CREATE DATABASE \"service1-test\";';
    "

services:
  image: alpine:3.2
  links:
    - db
    - minio
  command: /bin/true

---

我用这个命令来实现它：

docker compose up createdb&&docker compose up createbucket&&docker compose up-d服务

这似乎是您要使用的东西。这意味着要创建第四个

docker compose.yml

文件，将您的服务绑定在一起，在其中您还可以重新定义共享服务。

问题是您将主机上的服务与容器集成在一起，因此您没有太多选择。您可以发布显式端口，也可以为容器使用显式IP地址，但这两者都很难管理。如果你也以容器的形式运行你的服务，那就不一样了——它将在与其依赖项相同的Docker网络中运行，并且你不需要发布端口。是的，的确如此。作为临时解决方案，我创建了一个共享docker-compose.yml，并通过外部链接引用其服务。当我使用Node.js时，我制作了一个npm脚本，可以自动启动共享服务（），但它显然不是一个100%docker compose唯一的解决方案。我只使用docker-compose.yml作为数据库的原因是，我上次尝试时docker中的

npm安装

太慢了（而且我经常添加/删除依赖项）nodemon工作不正常，但如果情况有所改善，我可能应该再试一次。您可以尝试拆分Dockerfile-只需在一个命令中执行

复制package.json

，然后在复制整个应用程序源代码之前，按照单独的说明运行npm install。然后带有依赖项的层将被缓存，以后的构建应该很快，但是如果您更改

package.json

，构建将看到更改并再次运行

npm install

。看起来对

扩展的支持已经取消