<p><strong>The Problem</strong>: Named volumes are initialized on container creation when the volume is empty, and from the first container that starts up using that volume. That initialization includes all files, directories, and file metadata like owners and permissions. If there is content in the named volume, docker will not initialize it again since that would defeat the purpose of persistence.</p>

<p><strong>Option A</strong>: When you have multiple containers sharing a volume to share updated build time content like you have, my first suggestion is to modify the build to place the relevant data in each image. Depending on what is being shared and between what images, you may be able to use shared image layers to avoid ever needing to copy the data.</p>

<p><strong>Option B</strong>: When placing the data in each image and avoiding the shared volume is infeasible, then you likely want a process to copy data from the image into the volume as part of your container entrypoint. This has two advantages. First it works when the containers startup in either order, so you can eliminate dependencies between container startup order (though you may find it necessary to include some wait step in the other container entrypoints if they fail when run before the data is copied). And second, your copy can update the volume when existing data is already there.</p>

<p>I've implemented a <code>load-volume</code> and <code>save-volume</code> pair of scripts in my <a href="https://github.com/sudo-bmitch/docker-base#volume-caching" rel="nofollow noreferrer">docker base image</a> that you can reuse in your own images to implement this second option. I typically ran into this issue when using tmpfs volumes to support read-only containers, but the scripts have been made generic enough to support your use case. Note that your scenario likely involves deleting existing data from the volume, and I've implemented that using <code>rsync</code> for performance, so that needs to be installed in your image to work.</p>

CC BY-SA 4.0
2019-12-24T21:14:54.407Z
2019-12-24T21:14:54.407Z
BMitch
<p>You could use <code>named volumes</code>, see <a href="https://docs.docker.com/compose/compose-file/" rel="nofollow noreferrer">https://docs.docker.com/compose/compose-file/</a> instead of <code>bind mounts</code> like you are doing in the example. The difference is that the <code>named volume</code> is a docker volume that could be found by issuing <code>docker volumes ls</code> and remove by issuing <code>docker-compose down -v</code>. The bind volume starts with a dot, e.g. <code>./some/mount</code> and is a directory on the file system. </p>

<p>The named volume could be used to share information between two containers.</p>

CC BY-SA 4.0
2019-12-24T20:39:05.550Z
2019-12-24T20:39:05.550Z
030
<p>I've two containers : <strong>nginx</strong> &amp; <strong>angular</strong>. The <strong>angular</strong> container contains the code and is automatically pulled from the registry when there is a new version (with watchtower).</p>

<p>I set up a Shared Volume between <strong>angular</strong> &amp; <strong>nginx</strong> to share the code from <strong>angular</strong> to <strong>nginx</strong>.</p>

<pre><code>  ### Angular #########################################
  angular:
    image: registry.gitlab.com/***/***:staging
    networks:
      - frontend
      - backend
    volumes:
      - client:/var/www/client

  ### NGINX Server #########################################
  nginx:
    image: registry.gitlab.com/***/***/***:staging
    volumes:
      - client:/var/www/client
    depends_on:
      - angular
    networks:
      - frontend
      - backend

volumes:
  client:
networks:
  backend:
  frontend:
</code></pre>

<p>When I build &amp; run for the first time the environment, everything works.
The problem is when there is a new version of the <strong>client</strong>, the image is pulled, the container is re-built and the new code version is inside the <strong>angular</strong> container, but in the <strong>nginx</strong> container it still the old code version of the <strong>client</strong>.</p>

<p>The shared volumes does not let me do what i want because we can not specify who is the host, is it possible to mount a volumes from a container to an other?</p>

CC BY-SA 4.0
2019-04-13T14:52:25.307Z
Can you make a 3rd party provider export the shared volume and mount it (as clients) on both the client and the server containers? This way both would mount the same volume regardless which one is re-built (or in which order if both are).
Dan Cornilescu
CC BY-SA 4.0
2019-12-24T20:31:36.387Z
Could you reply to the comment?
030
<docker><docker-compose><volume>
Docker - Mount a volume from a container to an other (equivalent volumes_from) in docker-compose 3
Martin Paucot
# Docker - Mount a volume from a container to an other (equivalent volumes_from) in docker-compose 3

(Asked by: username_0 on 2019-04-12)

I've two containers : nginx & angular. The angular container contains the code and is automatically pulled from the registry when there is a new version (with watchtower).
I set up a Shared Volume between angular & nginx to share the code from angular to nginx.
  ### Angular #########################################
  angular:
    image: registry.gitlab.com/***/***:staging
    networks:
      - frontend
      - backend
    volumes:
      - client:/var/www/client

  ### NGINX Server #########################################
  nginx:
    image: registry.gitlab.com/***/***/***:staging
    volumes:
      - client:/var/www/client
    depends_on:
      - angular
    networks:
      - frontend
      - backend

volumes:
  client:
networks:
  backend:
  frontend:

When I build & run for the first time the environment, everything works.
The problem is when there is a new version of the client, the image is pulled, the container is re-built and the new code version is inside the angular container, but in the nginx container it still the old code version of the client.
The shared volumes does not let me do what i want because we can not specify who is the host, is it possible to mount a volumes from a container to an other?

**Tags:** docker, docker-compose, volume

> **Comments:**
> **username_1**: Can you make a 3rd party provider export the shared volume and mount it (as clients) on both the client and the server containers? This way both would mount the same volume regardless which one is re-built (or in which order if both are).  
> **username_2**: Could you reply to the comment?  

---

## 2 answers

### Answer by username_3 on 2019-12-24. Score: 1

**The Problem**: Named volumes are initialized on container creation when the volume is empty, and from the first container that starts up using that volume. That initialization includes all files, directories, and file metadata like owners and permissions. If there is content in the named volume, docker will not initialize it again since that would defeat the purpose of persistence.

**Option A**: When you have multiple containers sharing a volume to share updated build time content like you have, my first suggestion is to modify the build to place the relevant data in each image. Depending on what is being shared and between what images, you may be able to use shared image layers to avoid ever needing to copy the data.

**Option B**: When placing the data in each image and avoiding the shared volume is infeasible, then you likely want a process to copy data from the image into the volume as part of your container entrypoint. This has two advantages. First it works when the containers startup in either order, so you can eliminate dependencies between container startup order (though you may find it necessary to include some wait step in the other container entrypoints if they fail when run before the data is copied). And second, your copy can update the volume when existing data is already there.

I've implemented a `load-volume` and `save-volume` pair of scripts in my [docker base image](https://github.com/sudo-bmitch/docker-base#volume-caching) that you can reuse in your own images to implement this second option. I typically ran into this issue when using tmpfs volumes to support read-only containers, but the scripts have been made generic enough to support your use case. Note that your scenario likely involves deleting existing data from the volume, and I've implemented that using `rsync` for performance, so that needs to be installed in your image to work.


---

### Answer by username_2 on 2019-12-24. Score: 0

You could use `named volumes`, see <https://docs.docker.com/compose/compose-file/> instead of `bind mounts` like you are doing in the example. The difference is that the `named volume` is a docker volume that could be found by issuing `docker volumes ls` and remove by issuing `docker-compose down -v`. The bind volume starts with a dot, e.g. `./some/mount` and is a directory on the file system.

The named volume could be used to share information between two containers.


---

