Docker的标准模型是将应用程序代码构建到不可变的映像中。通常情况下，您不需要将代码与图像中内置的代码分开分发或注入。在您上面显示的示例中，我通常希望在Dockerfile中看到构建器
使用MacOS，我有一个docker compose，它以以下方式使用三个服务
services:
service_1:
volumes:
- ./apps:/usr/src/app/apps
- ./packages:/usr/src/app/packages
build:
dockerfile: Dockerfile
service_2:
volumes:
- ./apps:/usr/src/app/apps
- ./packages:/usr/src/app/packages
build:
dockerfile: Dockerfile
service_3:
volumes:
- ./apps:/usr/src/app/apps
- ./packages:/usr/src/app/packages
build:
dockerfile: Dockerfile
当前Dockerfile:
FROM node as builder
COPY . /app
RUN yarn install
FROM node
ARG app_name
COPY --from=builder /app /app
WORKDIR /app/$app_name
RUN yarn start
在dockerfile中使用构建器或者使用诱变剂或NFS装载之类的东西会更高性能吗？我读过关于Yarn/NPM在MacOS容器中的安装时间要长得多的文章，这让我对是否可以通过将卷更改为nfs/mutagen synchronized来增加我的用例感到困惑。
RUN，而不是您显示的单独的volumes:装载。
就性能而言，非Linux平台上的绑定装载存在已知问题。使用NFS服务而不是Docker Desktop的本机文件系统处理程序的一些解决方案会快一点，但不如使用本地文件系统快。使用内置在映像中的代码可以完全避免这些性能问题。
services:
service_1:
build:
context: .
args:
app_name: app1
# but no volumes: