node.js - 在 Amazon ECS 上的 Docker 中运行 Node API 的最佳方式是什么？

Question

随着 docker 以及 Amazon ECS 等调度和编排服务的出现，我正在尝试确定部署 Node API 的最佳方式。撇开 Docker 和 ECS 不谈，我想利用 Node 集群库在发生异步错误时优雅地处理 Node 应用程序崩溃，如 documentation 中所建议的那样。 ，通过创建一个主进程和多个工作处理器。

除了优雅地处理错误之外，集群方法的一个好处是为每个可用的 CPU 创建一个工作处理器。但这在 docker 世界中有意义吗？在一个 Docker 容器中运行多个 Node 进程是否有意义，该容器将被扩展到 ECS 上的 EC2 实例集群中？

如果没有 Node 集群方法，我将失去优雅处理错误的能力，因此我认为至少应该为每个 docker 容器运行一个主进程和一个工作进程。我仍然对在 ECS 的任务定义中定义多少 CPU 感到困惑。 ECS documentation说明每个容器实例每个 CPU 有 1024 个单元；但这与 EC2 计算单元不同，是吗？话虽如此，我需要选择具有适当数量的 vCPU 的 EC2 实例类型来实现这一点？

我知道，实现最佳配置可能需要对我的特定 Node API 应用程序进行某种程度的基准测试，但如果能更好地了解从哪里开始，那就太棒了。也许我需要做一些学习/研究？任何指导我的路径或建议的指针将不胜感激!

编辑:回顾一下我的具体问题:

1. 按照 here 所述运行主/从集群是否有意义？在 docker 容器内实现优雅的崩溃？

2. 使用集群文档中描述的几乎相同的代码，通过 require('os').cpus().length 来“扩展”到可用的 CPU 是否有意义？

3. Amazon 在 ECS 任务定义的文档中是什么意思，其中提到 cpus 设置，容器实例每个 CPU 有 1024 个单元？这个设置的一个好的起点是什么？

4. 在 ECS 集群中使用实例类型以提供基于上述内容的 Node API 的良好起点是什么？可用的 vCPU 对前面的问题有何影响？

Answer 1

所有这些技术都是新的，最佳实践仍在建立中，所以这些只是我的经验中的提示。

每个容器一个进程与其说是硬性规定，不如说是一种建议。当你使用它时，在一个容器中运行多个进程是很好的，特别是在这种情况下，一个主进程 fork 工作人员。正如您在问题中所建议的那样，只需使用一个容器并允许它为每个核心 fork 一个进程。

在 EC2 上，实例类型具有多个 vCPU，它们将作为操作系统的核心出现。对于 ECS 集群，使用 EC2 实例类型，例如具有四个 vCPU 的 c3.xlarge。在 ECS 中，这转换为 4096 个 CPU 单元。如果您希望应用使用所有 4 个 vCPU，请创建一个需要 4096 个 cpu 单元的任务定义。

但是，如果您这样做只是为了阻止应用程序崩溃，您也可以在容器崩溃时使用重启策略来重启容器。不过，ECS 似乎还不支持重启策略。