基于aws创建docker_选择合适的工具在AWS中创建和管理Docker Swarm集群

基于aws创建docker

Swarm Mode席卷了Docker调度。 您在实验室或通过在本地设置一些VM并将它们加入Swarm群集中进行了尝试。 现在是时候将其移至下一个级别并在AWS中创建集群。 您应该使用哪些工具来做到这一点？ 您应该如何设置AWS Swarm集群？

如果您和我一样，则已经放弃了通过AWS Console手动创建服务器，使用SSH输入每个服务器以及运行将安装Docker Engine并将其与其他节点连接的命令的选项。 您不仅仅知道这些，还想要一个可靠，自动化的过程来创建和维护集群。

在众多选项中，我们可以选择在AWS中创建一个Docker Swarm集群，而这三者都是众志成城的。 我们可以将Docker Machine与AWS CLI配合使用，将Docker for AWS作为CloudFormation模板使用，并将Packer与Terraform配合使用。 也就是说，绝不是我们可以使用的工具的最终清单。 时间有限，我对自己保证，本文将比《 战争与和平》短，所以我不得不在某些地方划清界限。 我认为，这三种组合是您选择的最佳人选。 即使您确实选择了其他选择，这篇文章也希望可以使您对可能要采取的方向有所了解。

您很可能不会同时使用所有三种组合，因此百万美元的问题是哪一种？

只有你可以回答那个问题。 现在，您已经拥有了应与想要完成的知识相结合的实践经验。 每个用例都是不同的，没有一种组合最适合每个人。

不管怎样，我将提供一个简短的概述以及一些可能适合每种组合的用例。

还是不去Docker机器？

Docker Machine是我们探索的最弱的解决方案。 它基于临时命令，仅提供创建EC2实例和安装Docker Engine的一种方法。 它使用Ubuntu 15.10作为基本AMI。 它不仅旧，而且是临时版本。 如果选择使用Ubuntu，则正确的选择是16.04 LTS（长期支持）。

而且，Docker Machine仍然不支持Swarm Mode，因此我们需要在执行docker swarm init和docker swarm join命令之前手动打开端口。 为此，我们需要将Docker Machine与AWS Console，AWS CLI或CloudFormation结合使用。

如果Docker Machine至少为Swarm Mode提供最少的设置（就像旧的Standalone 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中，它是落后的。

这是否意味着在使用AWS时我们应该丢弃Docker Machine？ 不总是。 当我们要创建用于演示目的的临时群集或尝试一些新功能时，它仍然很有用。 另外，如果您不想花时间学习其他工具，而只想要您熟悉的东西，那么Doc​​ker Machine可能是正确的选择。 我怀疑那是你的情况。 您正在阅读本文的事实告诉我，您确实想探索管理集群的更好方法。

最终建议是当您要在本地模拟Swarm集群时，保持Docker Machine为首选工具。 AWS有更好的选择。

到Docker for AWS还是不到Docker for AWS？

适用于AWS的 Docker与Docker Machine相反。 它是您的Swarm集群的完整解决方案。 尽管Docker Machine在创建EC2实例和安装Docker Engine方面所做的工作不多，但Docker for AWS设置了许多我们可能很难自行设置的事情。 自动伸缩组，VPC，子网和ELB只是我们获得的部分内容。

使用Docker for AWS创建和管理Swarm集群几乎不需要做任何事情。 选择所需的管理人员数量和数量，单击“ 创建堆栈”按钮，然后等待几分钟。 这里的所有都是它的。

还有更多。 适用于AWS的Docker带有专门设计用于运行容器的新操作系统。

对Docker for AWS的如此多赞誉不可避免地意味着它是最佳选择？ 不必要。 这取决于您的需求和用例。 如果您需要Docker for AWS提供的产品，那么选择就很简单。 去吧。 另一方面，如果您想更改其某些方面或添加未包括的内容，则可能会遇到困难。 修改或扩展它并不容易。

例如， 适用于AWS的Docker会将所有日志输出到Amazon CloudWatch 。 只要CloudWatch是您要保存日志的位置，那就太好了。 另一方面，如果您更喜欢ELK堆栈，DataDog或任何其他日志记录解决方案，则会发现更改默认设置并不是一件容易的事。

让我们来看另一个例子。 如果您想添加永久性存储该怎么办。 您可能在所有服务器上都安装了EFS卷，但这不是最佳解决方案。 您可能想尝试RexRay或Flocker。 如果是这样，您将再次发现扩展系统并不是那么简单。 您可能最终会修改CloudFormation模板，并且冒着无法升级到适用于AWS版本的新Docker的风险。

我是否提到Docker for AWS仍处于测试阶段？ 在撰写本文时，它或多或少是稳定的，但是仍然存在问题。 否则，它将不是beta。

所有这些负面因素并不意味着您应该放弃Docker for AWS 。 这是一个很棒的解决方案，随着时间的流逝，它只会变得更好。

最终建议是使用Docker for AWS，如果它提供（几乎）所需的一切，或者您不想从头开始开发解决方案。 无论您将要使用哪种工具，如果您已经有一组需要满足的要求，那么最大的阻碍就是。

如果您决定将群集托管在AWS中，并且不想花时间学习其所有服务的工作原理，请不要再读了。 您需要的是适用于AWS的Docker 。 它使您无需了解安全组，VPC，弹性IP以及您可能需要或可能不需要的其他服务。

要地形还是不地形？

当与Packer结合使用时，Terraform是一个很好的选择。 HashiCorp设法制作了另一种工具来改变我们配置和配置服务器的方式。 这样的表扬引出了一个问题，我们应该使用Docker for AWS还是将Packer与Terraform结合使用？

与在大多数情况下容易被拒绝的Docker Machine不同，是很难解决使用Terraform还是Docker for AWS的难题。 使用Terraform可能需要一些时间才能使群集具备所需的一切状态。 这不是开箱即用的解决方案。 您必须自己编写配置。 如果您有使用AWS的经验，那么这样的壮举应该不会造成太大的麻烦。 另一方面，如果AWS不是您的最强项，那么定义所有内容可能会花费您一段时间。

尽管如此，我还是会放弃学习AWS作为选择其中一项的理由。 即使您使用了像Docker for AWS这样的现成解决方案，您仍然应该了解AWS。 否则，您将面临无法对基础结构问题做出React的风险。 不要以为任何事情都会使您免于理解AWS的复杂性。 问题仅在于您是在创建集群之前还是之后都将学习详细信息。

最终建议是，如果您想控制构成集群的所有组件，或者已经有了一组需要遵循的规则，则将Terraform与Packer一起使用。 准备花费一些时间来调整配置，直到达到最佳设置为止。 与适用于AWS的Docker不同，您在一小时内将无法定义功能全面的集群。 如果您要这样做 ，请选择Docker for AWS 。 另一方面，当您配置Terraform进行所需的所有操作时，结果将很漂亮。

最终裁决

我们应该使用什么？ 我们如何做出决定？ 由了解自己正在做的事情的人创建的功能齐全的集群（ 适用于AWS的Docker ）与由您制作的功能全面的集群（ Terraform ）。 Beta（ 适用于AWS的Docker ）与您想要标记自己的解决方案（ Terraform ）的任何东西。 超出您需要的东西（ 适用于AWS的Docker ），而不仅仅是您想要的资源（ Terraform ）。

做出选择很难。 适用于AWS的Docker仍太年轻，可能是一个不成熟的解决方案。 Docker人们将继续开发它，并且在不久的将来它几乎肯定会变得更好。 Terraform可以让您自由付出代价。

就个人而言，我将密切关注Docker for AWS的改进，并保留稍后作出裁决的权利。 在那之前，我更倾向于Terraform。 我喜欢建造东西。 这是一次非常狭窄的胜利，应该尽快重新审视。

翻译自: https://www.javacodegeeks.com/2016/12/choosing-right-tools-create-manage-docker-swarm-clusters-aws.html

基于aws创建docker