我已经检查了SO，但找不到详尽的答案。
我的docker-composer.yml定义了包括卷在内的几件事
app:
volumes:
- "./:/app"
...
如果我使用docker run实例化映像，那么我需要再次指定docker-compose.yml中指定的相同卷。
docker run -v "./:/app"
对于某些用例来说，这可能是可取的，但一般来说，在 2 个不同的地方指定相同的定义并不是真正可维护的(或者对于未来的开发人员来说很明显(。我想避免在不同的位置定义相同的配置(一个用于docker-compose，一个作为docker run的参数(。
是否可以说，如果在docker-compose.yml内部配置卷(或其他参数(，那么为了拥有它们，映像应该通过docker-compose up而不是docker run -v redundant:volume:specification运行？
注意：我问的是最佳实践，而不是个人意见。
您应该认为docker-compose.yml与为您运行docker run的非常专业的 shell 脚本没有什么不同。 尝试最小化所需装载和选项的数量(例如，不要在映像中的代码上绑定挂载代码(并不是一个坏主意，但说"这只能通过此docker-compose.yml文件运行"也不是特别的最佳做法。
还要考虑还有其他方法可以使用不同的语法运行容器。 Kubernetes 和 Hashicorp 的 Nomad 都有非常不同的语法，并且不能重用docker-compose.yml。 如果在不同的上下文中运行映像，则基本上必须重写此配置。
在有限的范围内 - "对于这个开发项目，在这个环境中，在这个特定的存储库中" - 说"使用标准选项运行它的标准方法是通过docker-compose up"是合理的，但如果需要，仍然可以以不同的方式运行映像。
一般来说，一旦开始使用它，就应该依靠docker-compose，因为仅仅依靠docker <cmd>可能会错过一些配置并给出意想不到的结果(特别是如果刚登陆项目并且对它没有信心(。
使用docker run执行映像将导致以下缺点：
- 必须记住在每次运行时添加最终参数，这些参数隐式地包含在
docker-compose - 即使记住或让 bash 脚本使用正确的参数调用
docker run，这些参数的未来更改也需要反映在两个不同的地方。这不是很易于维护且容易出错。 - 最终其他相关的图像将无法运行，必须记住手动运行它们;或者将它们添加到脚本中，在两个不同的地方再次定义。
但是，要考虑其他跑步者(k8s(的更广泛观点，请查看David Maze的答案。