CODEWITHSUNDEEP
dockerdocker-compose
Martin Paucot
Martin Paucot

Reputation: 1251

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

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 ?

Thanks in advance.

EDIT

The angular container is only here to serve the files. We could rsync the built application to the server on the host machine then mouting the volume to the container (host -> guest) but it would go against our CI process : build app->build image->push to registry->watchtower pull new image

Upvotes: 2

Views: 1457

Answers (2)

BMitch
BMitch

Reputation: 263617

From your comment:

There is no program running for the client, the CI compile the app and build the custom Image which COPY the application files in /var/www/client. Then watchtower pull this new image and restart the container. The container only run in daemon with (tail -f /dev/null & wait).

Looking at this from a high level, I don't see any need to have two containers or volumes at all. Simply build your application with a multi-stage build that generates an nginx image with the needed content:

FROM your_angular_base AS build
COPY src /src
RUN  steps to compile your code

FROM nginx_base as release
...
COPY --from=build /var/www/client/ /var/www/client/
...

Then your compose file is stripped down to just:

...
  ### NGINX Server #########################################
  nginx:
    image: registry.gitlab.com/***/***/***:staging
    networks:
      - frontend
      - backend

networks:
  backend:
  frontend:

If you do find yourself in a situation where a volume is needed to be shared between two running containers, and the volume needs to be updated with each deploy of one of the images, then the best place for that is an entrypoint script that copies files from one location into the volume. I have an example of this in my docker-base with the save-volume and load-volume scripts.

Upvotes: 1

David Maze
David Maze

Reputation: 158848

Docker volumes are not intended to share code, and I'd suggest reconsidering this workflow.

The first time you launch a container with an empty volume, and only the first time and only if the volume is already empty, Docker will populate it with contents from the container. Since volumes are intended to hold data, and the application is likely to change the data that will be persisted, Docker doesn't overwrite the application data if the container is restarted; whatever was in the volume directory remains unchanged.

In your setup that means this happens:

  1. You start the angular container the first time, and since the client named volume is empty, Docker copies content into it.
  2. You start the nginx container.
  3. You delete and restart the angular container; but since the client named volume is empty, Docker leaves the old content there.
  4. The nginx container still sees the old content.

For a typical browser application, you don't actually need a "program" running: once you've run through a Typescript/Webpack/... sequence, the output is a collection of totally static files. In the case of Angular, there is an Ahead-of-Time compiler that produces these static files. The sequence I'd recommend here is:

  1. Check out your application source tree locally.
  2. Develop your browser application in isolation, using developer-oriented tools like ng serve or npm start. Since this is all running locally, you don't need to fight with anything Docker-specific (filesystem mappings, permissions, port mappings, ...); it is a totally normal Javascript development sequence. The system components you need for this are just Node; it is strictly easier than installing and configuring Docker.
  3. Compile your application to static files with the Angular AOT compiler or Webpack or npm build.
  4. Publish those static files to a CDN; or bind-mount them into an nginx container; or maybe build them into a custom image.

In the last case you wouldn't use a named Docker volume. Instead you'd mount the local filesystem into the container. A complete docker-compose.yml file for this case could look like:

version: '3'
services:
  nginx:
    image: registry.gitlab.com/***/***/***:staging
    volumes:
      - ./client:/var/www/client
    ports:
      - '8000:80'

Upvotes: 1

Related Questions