为什么卷中的 vendor/node_modules 映射被认为是不好的做法？

Question

Could someone explain me what is happening when you map (in a volume) your vendor or node_module files?

I had some speed problems of docker environment and red that I don't need to map vendor files there, so I excluded it in docker-compose.yml file and the speed was much faster instantly.

So I wonder what is happening under the hood if you have vendor files mapped in your volume and what's happening when you don't?

Could someone explain that? I think this information would be useful to more than only me.

Answer 1

Docker does some complicated filesystem setup when you start a container. You have your image , which contains your application code; a container filesystem , which gets lost when the container exits; and volumes , which have persistent long-term storage outside the container. Volumes break down into two main flavors, bind mounts of specific host directories and named volumes managed by the Docker daemon.

The standard design pattern is that an image is totally self-contained. Once I have an image I should be able to push it to a registry and run it on another machine unmodified.

git clone git@github.com:me/myapp
cd myapp
docker build -t me/myapp .  # requires source code
docker push me/myapp

ssh me@othersystem
docker run me/myapp         # source code is in the image
                            # I don't need GitHub credentials to get it

There's three big problems with using volumes to store your application or your node_modules directory:

1. It breaks the "code goes in the image" pattern. In an actual production environment, you wouldn't want to push your image and also separately push the code; that defeats one of the big advantages of Docker. If you're hiding every last byte of code in the image during the development cycle, you're never actually running what you're shipping out.

2. Docker considers volumes to contain vital user data that it can't safely modify. That means that, if your node_modules tree is in a volume, and you add a package to your package.json file, Docker will keep using the old node_modules directory, because it can't modify the vital user data you've told it is there.

3. On MacOS in particular, bind mounts are extremely slow , and if you mount a large application into a container it will just crawl.

I've generally found three good uses for volumes: storing actual user data across container executions; injecting configuration files at startup time; and reading out log files. Code and libraries are not good things to keep in volumes.

For front-end applications in particular there doesn't seem to be much benefit to trying to run them in Docker. Since the actual application code runs in the browser, it can't directly access any Docker-hosted resources, and there's no difference if your dev server runs in Docker or not. The typical build chains involving tools like Typescript and Webpack don't have additional host dependencies, so your Docker setup really just turns into a roundabout way to run Node against the source code that's only on your host. The production path of building your application into static files and then using a Web server like nginx to serve them is still right in Docker. I'd just run Node on the host to develop this sort of thing, and not have to think about questions like this one.