Compose: Cross-mount volume between two containers

[ScreamingDev]

Hello.

I have service A containing "/path/to/file.socket".
This file shall now be in service B in the path "/different/path/to/socket.io" (could also be the same path, tho).

It would be very useful to have such an option in the docker-compose.yml file:

version: '2'
services:
    MYSQL_SERVICE:
        image: mysql:latest
        environment:
            MYSQL_ROOT_PASSWORD: ''
            MYSQL_ALLOW_EMPTY_PASSWORD: 1
    PHP_SERVICE:
        image: php:latest
        volumes_from:
            - MYSQL_SERVICE:/var/run/mysqld/mysqld.sock:/var/run/mysqld/mysqld.sock

Currently you might need to create an empty file, mount it in service A and then mount the same file in service B. Such a detour. Especially if you need to do it with directories - then it will end up in a big mess.

Hope to hear from you soon.

Cheers!

[dnephin]

The current options for sharing volumes between services is:

• a host volume that is listed as a volume in both services
• a named volume that is used by both services
• volumes_from another service

The Docker API doesn't support volumes_from with paths, so this isn't something we can support in Compose. However there are already a lot of existing options for sharing paths.

[ScreamingDev]

a host volume that is listed as a volume in both services

As far as I understand then something like this shall do:

services:
  foo:
    volumes:
      - ./common_folder:/var/run/app_folder
  bar:
    volumes:
      - ./common_folder:/var/run/app_folder

This is a thing I tried. The socket generated by container "foo" are not visible in the host (maybe I do something wrong here). So container "bar" has no chance getting the sockets

a named volume that is used by both services

This seems like datavolume:/var/lib/mysql can be reused by another service which actually is the solution. I created this:

services:
  mysql:
    volumes:
      - datavolume:/var/run/mysqld
  app:
    volumes:
      - datavolume:/var/run/mysqld
volumes:
  datavolume: {}

Am I right that service "mysql" and "app" share the same socket (folder/volume) now?

I tested it already but can't believe that it took a whole day of hacking and nagging in the IRC for that simple solution. ;D

[mijamo]

I encounter kind of the same problem and the thing is that the datavolume is not a solution for me as the files do not get overridden by a new version.

If I follow the previous example, let's say you have a file /var/run/mysqld/somefile coming from the mysql container. Then when you run docker-compose up you can indeed access /var/run/mysqld/somefile fromapp`.

However, if for any reason /var/run/mysqld/somefile gets updated during the next docker compose build, * the container will keep the older version* and you will have the old somefilein both the mysql and app containers.

Is there any way to solve this? My use case is that my "app" container builds some files that I would like to access in my "nginx" container. Those files could be flushed everytime I run docker compose build.

[pkyeck]

@mijamo did you find a solution for this problem?

[mijamo]

@pkyeck I cannot say I have found a really nice solution so far.

I had to just use a volume that holds the information, and an "updater" container is responsible for getting the new data and updating the container's data through rsync. My use case made it necessary to have a separate container for that because the data needs compilation, I guess in other cases it could be integrated in the RUN instruction for the container.

[MANTHAN-D]

I am trying to use solution of named volume to share sockets between two services. But I am unable to connect using nc command. Command fails saying Connection refused. Does this mean the socket files are not available across two containers ?

[james-nesbitt]

I don't agree with the initial attempt for this issue. In particular, Mysql already provides the options for a tcp socket instead of a unix socket, and this approach already works fantastically. If you are worried about opening the db socket to the network, then use a docker network to isolate the open port between the two networks.
Using the established method of sharing a tcp socket works much better with provisioning services which may distribute the stack across servers, but will handle the network access automatically. This is true for swarm/docker-cloud, rancher, kubernetes etc.

However, I am also looking for a way to get shared file data between two containers, where the initial files come from one of the images, and are needed by multiple other containers:

###
# Source
#

  source:
    image: quay.io/wunder/fuzzy-alpine-base
    command:
      - /bin/true
    volumes:
      - "/app/web"
      - "/app/vendor"
      - "/app/config"

####
# Servers
#

  db:
    image: quay.io/wunder/fuzzy-alpine-mariadb

  memcache:
    image: quay.io/wunder/fuzzy-alpine-memcached

  fpm:
    image: quay.io/wunder/fuzzy-alpine-php-dev
    volumes-from:
      - source

  www:
    image: quay.io/wunder/fuzzy-alpine-nginx-pagespeed-drupal
    volumes-from:
      - source

This kind of approach is common in the web-source world, were we reuse the simplest service images in scaled sets, but keep a project specific source code separate.
In our case we just build php, nginx and similar services that have aligned requirements (source code in the same place, similar users and permissions etc,) and then we can easily connect the services.

• we don't want to have to build project specific php-fpm and nginx images, that would be ridiculous
• we would use global volumes, if we could populate them from the project image
• we like project images because we can use the docker image system to distribute and manage projects

[markshust]

I'm surprised no one mentioned YAML anchors. Docker doesn't officially support this because it's already provided by YAML format.

See here for details -- https://github.com/markoshust/docker-magento/blob/master/compose/magento-2/docker-compose.yml#L14

Pretty sure this issue can be closed out :)

[mauro-midolo]

+1

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically closed because it had not recent activity during the stale period.