我想把头围在Docker上，但是很难弄清楚。我试图在我的小项目（MERN堆栈）中实现它，并且我在思考如何区分开发（可能是登台）和生产环境。
我看到了一个示例，其中他们使用了2个Docker文件和2个docker-compose文件（每个对都包含一个env，因此Dockerfile + docker-compose.yml用于prod，Dockerfile-dev + docker-compose-dev.yml用于dev） 。
但这对我来说似乎有点过头了。我希望仅在两个文件中使用它。
另外一个问题是，例如，对于开发，我想在全球范围内安装nodemon，而不是为了安装。
在完美的解决方案中，我想运行这样的东西
docker-compose -e ENV=dev build docker-compose -e ENV=dev up
请记住，我仍然没有完全使用docker，因此，如果您发现了我对docker的一些误解，则可以指出它们。
你可以采取一些线索，从“ 在生产中使用撰写 ”
您几乎肯定会想要对应用程序配置进行更改，使其更适合实时环境。这些更改可能包括： 删除应用程序代码的所有卷绑定，以使代码保留在容器内，并且不能从外部更改 绑定到主机上的不同端口 设置不同的环境变量（例如，减少日志记录的冗长性或启用电子邮件发送） 指定重启策略（例如，重启：始终）以避免停机 添加额外的服务（例如，日志聚合器）
您几乎肯定会想要对应用程序配置进行更改，使其更适合实时环境。这些更改可能包括：
然后，该建议与您提到的示例不太相似：
因此，您可能需要定义一个额外的Compose文件，例如production.yml，以指定适合生产的配置。该配置文件只需要包含您想要对原始Compose文件进行的更改。 docker-compose -f docker-compose.yml -f production.yml up -d
因此，您可能需要定义一个额外的Compose文件，例如production.yml，以指定适合生产的配置。该配置文件只需要包含您想要对原始Compose文件进行的更改。
production.yml
docker-compose -f docker-compose.yml -f production.yml up -d
这种 覆盖机制 比尝试在一个撰写文件中混合使用dev和prod逻辑更好，并且使用环境变量尝试选择一个更好。
注意：如果您命名第二个dockerfile docker-compose.override.yml，则简单的docker-compose up将自动读取覆盖。 但是根据您的情况，基于环境的名称会更清晰。
docker-compose.override.yml
docker-compose up
