适用于AWS的Docker和EC2上的纯Docker部署
目的是使用群集生产级的8容器应用程序。
看来（ECS撇开）我们面临着两个select：
-
使用所谓的docker-for-aws ，通过一个cloudformation模板进行（swarm）configuration。
-
像往常一样设置我们的VPC，安装docker引擎，引导swarm（通过init / join等），并将我们的应用程序部署在正常的EC2实例中。
这两种方法之间的唯一区别是docker-for-aws执行的swarm bootstrap？
docker-for-aws与普通AWS VPCconfiguration相比有什么其他好处？
谢谢
如果您需要提供跨不同云提供商的可移植性，请使用Docker团队提供的AWS CloudFormation模板。 如果你只需要在AWS上运行 – ECS应该没问题。 但是，您需要花一点时间来弄清楚服务发现如何在那里工作。 Swarm的好处在于它使得它非常简单，只需通过其服务名称访问服务，就像使用内置负载平衡的DNS名称一样。
使用它自动创build新环境相当容易，如果您稍后需要使用Azure或Google Cloud，则只需使用模板即可使Docker集群准备就绪。
Docker团队已经将相当多的东西放到了这个模板中 ，除非你真的需要，否则你真的不想重新创build它们。 例如，如果您不使用静态IP（相当典型的情况），而且其中一个pipe理器死了 – 您不能重新启动它。 您将需要手动重新将其join群集。 AWS的Docker通过IP通过DynamoDB进行同步，并使用其他提供商特定的技术使故障转移/恢复工作顺利进行。 另一个例子是日志logging – 他们将日志自动推送到CloudWatch，这非常方便。
如果使用Swarm模板，请提供有关自动configuration环境的一些提示：
- 使用一些infra自动化工具来创build每个环境的VPC。 使用该工具提供的一些模板，以免自己写得太多。 使用单独的VPC使得所有的环境都非常独立，并且更容易处理，更less的机会把事情搞砸。 另外，您可能会在以后的环境中添加更多元素，例如RDS。 如果你控制你的VPC的创build，那么做起来更容易，并保持所有相关的资源在同一个。 假设DEV1环境的DB位于DEV1 VPC中
- 连接运行由Docker提供的AWS Cloud Formation模板以在此VPC内部署Swarm集群（他们有一个单独的模板）
我对自动化的偏好是Terraform。 它让我能够描述一个理想的基础设施状态，而不是如何实现它。
我会说不，基本上还有其他的好处。
然而，如果你想实现docker-for-aws模板提供的所有/几个东西，我相信你的第二个要点应该包含更多。
例如
- logging到CloudWatch
- 设置EFS进行持久性/共享
- 创build子网和路由表
- 创build和configuration弹性负载均衡器
- 基本的自动缩放为您的节点
也许更多，我现在不记得了。
该模板还会将一堆关于相关资源的信息吸收到您的EC2实例中，以使其适用于所有Docker服务。
我一直在使用docker-for-aws模板，并已经开始欣赏很多自动化的东西。 而我不明白我改变，以官方模板为基础。
我会和ECS一起去解决roll your own问题。 除非您的组织有努力重新deviseAWS提供的服务和集成，作为产品的一部分; 你将会人为地把自己画成一个未来变化的angular落。 Do not re-invent the wheel 。
基本上@Jonatan说的是什么。 build立解决scheme来整合已经存在的内容是…当您可以在您的业务/应用程序的其他部分工作时，尝试一些痛苦。