2

Along with a few others, I am having issues using a micro services architecture of applications and employing docker-compose the way I want to.

Summary: I have X micro service projects (lets call these project A, project B and project C. Each micro service depends on the same containers (lets call these dependency D and dependency E.

The Problem: Ideally, project A, B and C would ALL have both dependencies (D & E) in their docker-compose.yml files; however, this becomes an issue as docker compose sees these as duplicate containers when in reality, I would like to reuse them. Here is an error message that is commonly seen:

ERROR: for A Cannot create container for service A: b'Conflict. The container name "/A" is already in use by container "sha". You have to remove (or rename) that container to be able to reuse that name.'

From what I have seen, people are recommending that you define the container in one project and reference it using networks and external links. Although this works, it introduces a dependency on a different docker-compose yml file (the file that defines the dependency!).

Another approach that I've read argues for isolation of containers in their docker compose files and then referencing multiple files when you want to build. Again, although this works, its certainly not as stunningly convenient as docker typically is to work with. If I am unable to work out a solution, I will go with this approach.

Have other people in the non-mono repo world (specifically with micro services) had any success with a different approach?

I've been ask to clarify with some examples:

Here is what 2 different compose yml files look like for project A and project B:

Project A:

version: '2'
services:
  dependencyD:
    image: dependencyD:latest
    container_name: dependencyD

  dependencyE:
    image: dependencyE:latest
    container_name: dependencyE

  projectA:
    image: projectA:latest
    container_name: projectA
    depends_on:
      - dependencyD
      - dependencyE

Project B:

version: '2'
services:
  dependencyD:
    image: dependencyD:latest
    container_name: dependencyD

  dependencyE:
    image: dependencyE:latest
    container_name: dependencyE

  projectB:
    image: projectB:latest
    container_name: projectB
    depends_on:
      - dependencyD
      - dependencyE
Chad Van De Hey
  • 2,716
  • 3
  • 29
  • 46
  • Can you post a sample docker-compose file? – Rico Sep 18 '18 at 03:58
  • I don't understand what the problem is – Constantin Galbenu Sep 18 '18 at 08:24
  • First, you cannot have two containers with the same name in one host (specified by container_name in your docker run or in compose file). You can use multiple compose files, but docker won't start the containers. Besides, you are confusing by using same name for your project and dependencies. Is project A and dependency A are same thing or different? As reco suggested, can you post some the compose file you are using? – techtabu Sep 18 '18 at 14:48
  • I've added some examples. My apologies for the potentially confusing description – Chad Van De Hey Sep 18 '18 at 16:11

1 Answers1

3

There is a feature called external links. From the docs:

Link to containers started outside this docker-compose.yml or even outside of Compose, especially for containers that provide shared or common services.

Having multiple docker-compose.yml files is also common to organize containers into meaningful groups. Maybe your scenario can use multiple YAML files and the external links.

cringe
  • 13,401
  • 15
  • 69
  • 102
  • This is what I've essentially gathered and mentioned in both of my potential approaches. – Chad Van De Hey Sep 18 '18 at 16:05
  • 1
    Other than exposing ports and juggling external IP addresses around, I don't see a way to conveniently connect the containers. I think this is the limit of docker-compose and the reason why people then switch to something more powerful like Kubernetes. – cringe Sep 20 '18 at 06:12