因此，我们正处于设计将应用程序部署到生产环境的管道阶段。我们有 5 个需要相互通信的服务，目前使用 docker 进行开发。我们正在研究 CodePipeline（github + CodeBuild + EB）进行部署，但我们怀疑是否将 Elastic Beanstalk 用于单个容器（即每个主机运行 1 个容器）或多个容器（在同一主机中运行多个容器）我从使用多容器中看到的唯一好处是成本效益高（为所有容器配备一组 ec2 实例比为仅运行 1 个容器配备一整组更便宜）。除此之外，由于在多个主机中管理多个容器的编排和任务调度，我只能看到多容器增加了额外的复杂性。那么最佳实践是什么？每个主机 1 个容器？还是每个主机多个容器？
答案1
单一 Docker Beanstalk 非常适合刚开始使用 Docker 的用户。它使用起来简单又熟悉，但会浪费资源。
多 Docker 更先进，但基本上遵循单 Docker 和 Beanstalk 的所有部署实践。多 Docker 将为您配置 ECS 集群并在每个实例上启动任务（而不是服务）。Beanstalk 脚本监视任务的状态，upstart 脚本负责启动/停止任务（它利用 ecs 代理来执行此操作）。实际上没有任何额外的复杂性，因为 Beanstalk 会处理所有这些。
每个实例只运行 1 个任务，因此任务随集群中的实例线性扩展，这使得它比单 Docker 浪费更少，成本相同（假设应用程序大小相同且扩展类似）。多 Docker 相对于单 Docker 的唯一真正好处是能够解耦应用程序的各个部分。
如果您开始使用多 Docker，那么您很快就会转向 ECS，因为它在运行容器方面更胜一筹。如果您从单 Docker 开始，那么您很快就会对单容器的局限性感到厌烦，要么转向多 Docker，要么转向 ECS Native。我的建议是完全跳过 Beanstalk，或者使用多 Docker 来感受和了解 ECS，然后再像大多数人一样放弃使用。
tl;dr 运行容器的最佳实践是设置集群，而不是使用 Beanstalk。
ps 现在有了 Fargate，您甚至根本不需要管理集群。