How to serve/update content from one Docker container in another - node.js

Question

I'm trying to run NodeJS served by nginx. I want to proxy to the NodeJS server, and serve static content like images, css, js.
Here's my docker-compose file:
version: "3.7"
services:
web:
build: .
image: 127.0.0.1:5000/test
volumes:
- public:/app/public
deploy:
replicas: 2
nginx:
image: nginx:stable-alpine
ports:
- 80:80
volumes:
- ./nginx/nginx.conf:/etc/nginx/conf.d/default.conf:ro
# share files from web
- public:/static:ro
volumes:
public:
My Dockerfile runs npx webpack -p to build all static files (/app/public), and then runs the NodeJS server with node /app/src/server.min.js. The NodeJS serves server-side React with ajax endpoints for minimal page updates. As I mentioned above the nginx container serves the static content (css, js, images, etc).
The problem is that I can't update the static files. Once the volume is created and populated, those files aren't able to be altered, i.e. I can't update CSS or JS.
You can see this behavior with docker-compose up or docker stack deploy.
Is there some way that I could recreate the volume, or serve the files in some other way between the containers?

Answer 1

There's three basic approaches you can take here.
The first is, at build time, copy those static assets somewhere outside of Docker space where Nginx or something else can host them. If you're running in AWS anyways, you can serve them directly out of S3; if you're in a local environment, use a host path instead of a named volume. This mostly just avoids the "only on first use" volume behavior, but it requires some work outside of Docker.
You can build the same content into two images, and not try to share it using a volume. You'd have to add a second Dockerfile for the nginx image, and if there's some sort of build pipeline (Webpack?) to build the static content you'd have to ensure that's run up front. A Dockerfile line like
COPY --from=127.0.0.1:5000/test /app/public /static
might work.
You can also have the web image copy its own data manually at startup, instead of relying on Docker to do this for you. You can have an entrypoint script like
#!/bin/sh
if [ -d /static ]; then
cp -r /app/public/* /static
fi
exec "$#"
Add that to your image, and mount the shared volume on /static in both containers.
All of these cases avoid the behavior of Docker automatically populating volumes. I try to avoid that in general because of exactly this issue: it only happens the first time you run a container, but in reality you're frequently making updates, redeploying, etc. but that volume already exists so Docker won't update it. (This behavior also doesn't work at all in Kubernetes, in spite of it otherwise being able to run standard Docker images without modification.)