CODEWITHSUNDEEP
dockerdocker-compose
Zachary Sells
Zachary Sells

Reputation: 41

Docker-compose recommended way to use data containers

In my application I have an nginx container that I want to use to serve static webapp files. These webapp files exist in a separate container called "webapp".

What's the recommended way of mounting the webapp container into the nginx container? My current approach looks like this: 

version: '2'
services:
  nginx:
    volumes_from:
      - webapp


  webapp:
      image: someimageurl

And in the Dockerfile for webapp, I expose a volume at the same path that the nginx container is serving.

This works great, but the problem is that in docker-compose v3, "volumes_from" is being removed and replaced with named volumes. So my new config would look like:

version: '3'

volumes: 
   static-webapp:

services:
  nginx:
    volumes:
      - static-webapp:/opt/webapp


  webapp:
      image: someimageurl
      volumes:
        - static-webapp:/opt/webapp

The problem with this is that the data from the webapp container will only be copied into the 'static-webapp' volume once. After changing the content and re-running docker-compose up, the content in the volume is unchanged. I understand that this is by design, as to not overwrite persistent data.

My question is: How should I be doing this with v3 of docker-compose? I essentially want an unnamed volume that I can mount into multiple containers.

The solutions I've thought of are:

1.) Bundle the static content in the nginx container. I don't like this because then I can't keep the requirements separate.

2.) I could manually remove the 'static-webapp' volume after each docker-compose run. This also seems non-ideal.

Upvotes: 4

Views: 1414

Answers (1)

BMitch
BMitch

Reputation: 264306

The recommended way is to remove dependencies between containers since these dependencies don't logically apply to swarm where containers may be running on different hosts where they can't share files (this is why volumes-from was removed from the version 3 format). Data containers had already been deprecated after the introduction of of named volumes, despite some out of date documentation suggesting otherwise.

The options that I can think of off the top of my head include:

  1. Using a version 2 compose file and not using swarm mode. There's no need to upgrade to the version 3 format if you aren't using this with swarm mode.

  2. Directly add your data to each container.

  3. Rearchitecture your app to split apart components differently. I'm not clear on the use case of application code in both nginx and another container, seems like it should only be one or the other.

  4. Create a data sync utility container that has all of the app data, runs globally across the swarm, and pushes out changes to volumes on each of the swarm nodes on startup. This could also poll something like a git repo and constantly update the local volume on any changes. Your other containers then point to this local named volume.

  5. Point the containers to a remote volume, like NFS, so you only need to update the data once from any host and eliminate any hosts being out of sync, but also adding extra latency in any reads.

Upvotes: 6

Related Questions