JavaSa
JavaSa

Reputation: 6241

Docker swarm having some shared volume

I will try to describe my desired functionality:
I'm running docker swarm over docker-compose In the docker-compose, I've services,for simplicity lets call it A ,B ,C.

Assume C service that include shared code modules need to be accessible for services A and B.

My questions are:
1. Should each service that need access to the shared volume must mount the C service to its own local folder,(using the volumes section as below) or can it be accessible without mounting/coping to a path in local container.

  1. In docker swarm, it can be that 2 instances of Services A and B will reside in computer X, while Service C will reside on computer Y. Is it true that because the services are all maintained under the same docker swarm stack, they will communicate without problem with service C.

If not which definitions should it have to acheive it? My structure is something like that:

version: "3.4"

services:
  A:        
    build: .
    volumes:
      - C:/usr/src/C
    depends_on:
      - C


  B:
    build: .
    volumes:
      - C:/usr/src/C

    depends_on:
      - C

  C:
    image: repository.com/C:1.0.0
    volumes:
      - C:/shared_code

volumes:
     C:

Upvotes: 0

Views: 729

Answers (2)

Bret Fisher
Bret Fisher

Reputation: 8596

Sharing code is an anti-pattern in a distributed model like Swarm. Like David says, you'll need that code in the image builds, even if there's duplicate data. There are lots of ways to have images built on top of others to limit the duplicate data.

If you still need to share data between containers in swarm on a file system, you'll need to look at some shared storage like AWS EFS (multi-node read/write) plus REX-Ray to get your data to the right containers.

Also, depends_on doesn't work in swarm. Your apps in a distributed system need to handle the lack of connection to other services in a predicable way. Maybe they just exit (and swarm will re-create them) or go into a retry loop in code, etc. depends_on is mean for local docker-compose cli in development where you want to spin up a app and its dependencies by doing something like docker-compose up api.

Upvotes: 1

David Maze
David Maze

Reputation: 158848

If what you’re sharing is code, you should build it into the actual Docker images, and not try to use a volume for this.

You’re going to encounter two big problems. One is getting a volume correctly shared in a multi-host installation. The second is a longer-term issue: what are you going to do if the shared code changes? You can’t just redeploy the C module with the shared code, because the volume that holds the code already exists; you need to separately update the code in the volume, restart the dependent services, and hope they both work. Actually baking the code into the images makes it possible to test the complete setup before you try to deploy it.

Upvotes: 1

Related Questions