基于码头和基层的工作流自动化

Question

我正在寻找一个基于码头的项目设置，它支持：

1. 最接近生产的开发环境
2. 为所有开发人员提供最好的工作流自动化工具
3. 高度可移植/快速设置开发环境，支持Linux、OSX和Windows.目前我们使用的是Vagrant，这似乎仍然是最明显的选择。

满足#1：

• 相同的应用程序容器(node.js + Apache)用于开发、测试、分期和生产
• 不要仅仅为了开发而向容器添加任何自定义工作流工具

满足#3：

• 不要要求开发人员为各自的环境/操作系统安装他们自己的开发工具(例如，让他们在主机内安装node.js、npm、grunt等)

因此，为了满足#2，我的想法是：

• 有第二个"dev“容器，它与节点/apache容器共享文件，并运行所有工作流自动化。
• 运行所有的咕噜表/重建/重新加载/浏览器同步等。
• 如果使用Vagrant，则文件共享实质上是主机->dev容器->app容器。

上述模型是否有任何缺陷，或者更好的想法？

一个潜在的缺失点是是否--如果是的话--避免每次在生产中执行完整的容器构建。在不冒生产与其他容器不匹配的风险的情况下，我想“打包”容器，这样当新代码被推入生产时，应用服务器只需要重新启动，而不是npm安装等等。特别是，一旦我们推动生产，它就不再需要从第三方服务器中提取任何东西才能运行。

Answer 1

这是一个有点宽泛的问题，在这个问题上，答案将是固执己见的，而不是客观的论据，但这里我要改变的是：

1. Node.js很好，但是我会选择nginx而不是Apache。Node.js和Nginx都是基于事件的，允许更多的吞吐量，这是Node.js的优势之一。但这可能会有所不同，比如，如果您需要某些Apache专用模块，但Nginx似乎更自然地将其放在Node前面。
2. 你为什么想要一个单独的容器？为了使生产容器最小化，它不需要开发工具？

我真的认为，比方说，生产容器中的grunt.js不太重，但是，您似乎试图将影响降到最低。无论如何，您也可以在一个容器中同时拥有代码和grunt watch等，并像这样部署。优点是，您简化了设置，缺点是您的产品构建可能会安装一些额外的库。例如，您可以通过在部署生产容器时将NODE_ENV设置为生产，这样在启动时脚本将知道不加载某些开发工具。