Docker - Mount a volume from a container to an other (equivalent volumes_from) in docker-compose 3

Question

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?

Answer 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 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 2

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.