下面将继续使用vfarcic/cloud-provisioning代码库(https://github.com/ vfarcic/cloud-provisioning)。它包含可以帮助我们的配置和脚本,你已经克隆了它。为了安全起见,我们将拉取最新的版本:
让我们创建第一个droplet:
在环境变量DIGITALOCEAN_REGION所定义的区域中,指定Docker Machine应该使用digitalocean驱动程序来创建一个实例。droplet的大小是1 GB,并且启用了private networking。
Docker Machine启用了一个DigitalOcean droplet,为它配置了Ubuntu,并安装和配置了Docker Engine。
毫无疑问,你已经注意到,每个人都试图为同一件事想出一个不同的名字。DigitalOcean也不例外。他们想出了“droplet”这个词。这是一个虚拟私有服务器的不同名称。同样的事情,不同的名称。
现在可以初始化集群了。节点之间的所有通信应该使用私有IP地址。不幸的是,docker-machine ip命令只返回公开的IP地址,因此,我们必须采用不同的方法来获得私有IP地址。
现在可以给droplets API发送一个GET请求:
部分输出如下:
droplets API会返回我们拥有的droplets(目前只有一个)的所有信息,我们只对新创建的名为swarm-1的实例的私有IP感兴趣。可以通过过滤结果得到私有IP,只包括名为swarm-1的droplet,并选择类型为私有的v4元素。
下面将使用jq(https://stedolan.github.io/jq/)过滤输出,并得到我们想要的东西。如果还没有jq,请下载并安装适合你的操作系统的jq发行版。发送请求、过滤结果并将私有IP存储为环境变量的命令如下:
我们向droplets API发送了一个GET请求,使用jq select语句来丢弃名为swarm-1以外的所有条目。后面跟着另一条select语句,该语句只返回私有地址。输出保存在环境变量MANAGER_IP中。
为了安全起见,可以输出新创建的变量的值:
输出如下:
现在以与前面几章相同的方式执行swarm init命令:
让我们确认集群确实已经初始化了:
输出如下(为简洁起见,移除了ID):
现在已经初始化了集群,可以添加更多的节点了。首先,创建两个新实例,并将它们作为manager加入集群中:
没有必要解释刚刚执行的命令,因为它们是以前使用过的命令的组合。
下面还将加入几个worker节点:(www.xing528.com)
让我们确认所有五个节点确实构成了集群:
输出如下(为简洁起见,移除了ID):
就是这样。集群已经就绪。剩下的就是部署几个服务并确认集群是否工作正常。
因为已经多次创建了服务,所以我们将使用vfarcic/docker-flow-proxy/ docker-compose-stack.yml(https://github.com/vfarcic/docker-flow-proxy/blob/master/ docker-compose-stack.yml)和vfarcic/go-demo/docker-compose-stack.yml(https://github.com/vfarcic/go-demo/blob/master/docker-compose-stack.yml)Compose stack来加速该过程。下面将创建proxy、swarm-listener、go-demo-db和go-demo服务:
非Windows用户不需要登录swarm-1机器,并且可以从其笔记本电脑上直接部署栈来实现相同的结果。
下载所有镜像需要一些时间。稍后,service ls命令的输出应该如下(为简洁起见,移除了ID):
让我们确认go-demo服务是可访问的:
输出如下:
使用Docker Machine和DigitalOcean API建立整个Swarm集群。这是我们所需的吗?这取决于我们为集群定义的需求。我们应该增加一些浮动IP地址。
DigitalOcean浮动IP地址是一个可公开访问的静态IP地址,可以分配给你的droplets。浮动IP地址也可以通过DigitalOcean的控制面板或API立即重新映射到同一数据中心的其他droplets。通过给入口点或网关以及你的服务器添加冗余,这种立即重新映射的能力能够让你创建没有单点失效的高可用性(HA)服务器基础设施。
换句话说,应该至少设置两个浮动IP地址,并将它们映射到集群中的两个droplets上。这两个(或更多)IP地址将被设置为DNS记录。这样,当一个实例发生故障时,可以使用一个新的实例替换它,可以在不影响用户的情况下重新映射弹性IP地址。
还可以做很多其他的改进。但是,这会让我们陷入尴尬的境地。现在使用的工具不是用来配置复杂集群的。
创建虚拟机的速度非常慢。Docker Machine花了很长时间为它配置Ubuntu并安装Docker Engine。在安装前,可以使用Docker Engine创建快照来节省时间。然而,如果这样做的话,那么将不再存在使用Docker Machine的主要原因。它的主要用处是简单化。一旦开始将与其他资源相关的配置复杂化,就会意识到简单化正在被大多数临时命令所取代。
当处理一个小型集群时,运行与API请求相结合的docker-machine非常有效,特别是,当想要创建一些快速且可能不太持久的东西时。最大的问题是,到目前为止,我们所做的一切都是临时命令。很可能我们无法在第二次重复相同的步骤。由于基础设施没有文档化,所以我们的团队无法知道集群的构成。
建议在DigitalOcean中使用docker-machine作为一种快捷实用的方式来创建一个集群,主要用于演示目的。只要集群相对较小,它对生产系统就是有用的。
如果想要建立一种更复杂、更大、更持久的解决方案,我们应该考虑其他选项。
让我们删除创建的集群,并从头开始探索备选方案:
如果你阅读了第12章,那么你可能会期待看到“Docker for DigitalOcean”的子章节。这样的东西并不存在。至少在我撰写本章的时候没有。因此,下面将直接进入Packer和Terraform。
免责声明:以上内容源自网络,版权归原作者所有,如有侵犯您的原创版权请告知,我们将尽快删除相关内容。