Docker Machine是我们探讨过的最弱的解决方案。它基于即时命令，仅提供一种创建EC2实例和安装Docker Engine的方法。它使用Ubuntu 15.10作为基本的AMI。这个版本的Ubuntu不仅很旧，而且是临时的发行版。如果要选择使用Ubuntu，那么应该选择16.04长期支持版（LTS）。
此外，因为Docker Machine仍然不支持Swarm模式，所以需要在执行docker swarm init和docker swarm join命令之前手动打开端口。为此，我们需要将Docker Machine与AWS控制台、AWS CLI或者CloudFormation相结合。
如果Docker Machine可以为Swarm模式提供最小设置（就像它在旧的独立的Swarm中所做的那样），那么对于小型群集来说，这可能是一个不错的选择。
像现在这样，Docker Machine在与AWS中的Swarm集群一起工作时，提供的唯一真正的好处是在远程节点上安装Docker Engine，并且能够使用docker-machine env命令让本地Docker客户端与远端集群进行无缝通信。Docker Engine的安装很简单，单靠这些是不够的。从另外一方面看，生产环境中不应该使用docker-machine env命令。这两个好处都太微不足道了。
目前Docker Machine的许多问题可以通过一些额外的参数来解决（例如，--amazonec2-ami），并与其他工具相结合。然而，这只会减少Docker Machine的主要好处。它应该是简单的并能工作得很好。这在Docker 1.12版本之前是部分正确的。现在，至少在AWS中，它已经落后了。(www.xing528.com)
这是否意味着我们在使用AWS时应该放弃Docker Machine呢？当然不是。当我们想要创建一个临时集群来演示或者尝试一些新特性时，它仍然是有用的。另外，如果你不想花时间学习其他工具，只想要一些你熟悉的东西，那么Docker Machine可能仍是正确的选择。我不确定这是不是你的情况。
本书中，你能读到这些，就说明你确实希望探索更好的集群管理方法。
最后的建议是，当你想要在本地模拟一个Swarm集群时，就像前面章节所做的那样，Docker Machine始终是一个可选的工具。但对于AWS来说，还有更好的选择。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
