进军Docker 1.12,将代理与Swarm完美整合

我们将共同探讨如何利用其对各服务进行公开。我们还将尝试将一套代理机制整合至Swarm网络当中,从而更为充分地发挥1.12版本带来的优势。

在开始进行之前,我们需要设置一套用于演示的集群。

环境设置

要完成本示例,我们假定大家已经拥有一套版本为v0.8或者更高的Docker Machine,其中包含版本为v1.12或者更高的Docker Engine。最便捷的获取方法就是通过Docker Toolbox下载。

如果您是Windows用户,请利用Git Bas运行全部示例(通过Docker Toolbox安装)。

docker-machine create -d virtualbox node-1 docker-machine create -d virtualbox node-2 docker-machine create -d 
virtualbox node-3 eval $(docker-machine env node-1) docker swarm init \    --advertise-addr $(docker-machine ip node-1) \    --listen-addr $(docker-machine ip node-1):2377 TOKEN=$(docker swarm join-token -q worker) eval $(docker-machine env node-2) docker swarm join \    --token $TOKEN \    $(docker-machine ip node-1):2377 eval $(docker-machine env node-3) docker swarm join \    --token $TOKEN \    $(docker-machine ip node-1):2377

现在我们已经拥有了一套Swarm集群,接下来是部署一项服务。

20160810201612

包含三个节点的Docker Swarm集群

向集群中部署服务

为了检验新的Docker Swarm网络功能,我们首先创建以下两套网络。

eval $(docker-machine env node-1) docker network create --driver overlay proxy docker network create --driver 
overlay go-demo

其一(proxy)将用于代理与面向API公开的服务之间的通信。而其二(go-demo)则面向全部用于构建go-demo服务的容器。该服务包含两套容器,且利用MongoDB用于存储数据,而vfarcic/go-demo则作为配备API的后端。

我们将从数据库起步。由于其不会公共开放,因此不需要将其添加至代理当中。这里,我们直接将其附加至go-demo网络。

docker service create --name go-demo-db \  --network go-demo \  mongo

数据库上线并开始运行后,我们接下来部署后端。由于我们希望外部用户能够使用该API,因此应当将其纳入代理。我们将其同时附加至两套网络(proxy与go-demo)。

docker service create --name go-demo \  -e DB=go-demo-db \  --network go-demo \  --network proxy \ 
vfarcic/go-demo

20160810201605
由三台节点、两套网络与多套容器构成的Docker Swarm集群

现在两套容器都运行在集群当中,且能够彼此通过go-demo网络进行通信。下面将代理引入其中。我们这里使用HAProxy。

需要注意的是,我们并没有指定端口,这意味着没有任何一套容器能够为go-demo网络之外的请求所访问。

设置一项代理服务

我们可以通过多种方式建立代理机制。其一利用HAProxy创建一套新镜像,其中包含各配置文件。这种方式比较适合服务数量相对固定的情况。否则,我们应当创建一套每当有新服务(而非新版本发布)出现时即进行新配置的镜像。

通过第二种方法,其将以分卷形式存在,我们能够在必要时仅修改配置文件而非整套新镜像。然而,这种作法也存在弊端。在部署至一套集群时,我们应当尽可能避免使用分卷。接下来大家会看到,代理就是不需要分卷的机制之一。另外,–volume可替换为docker service命令中的—mount参数。

第三种选项是使用专门与Docker Swarm协作的代理之一。在这种情况下,我们将使用vfarcic/docker-flow-proxy容器,其由Docker Flow: Proxy项目创建而成。其基于HAProxy且拥有多项其它功能,允许我们通过发送HTTP请求对其进行重新配置。

下面一起来看:

docker service create --name proxy \    -p 80:80 \    -p 443:443 \    -p 8080:8080 \    --network proxy \    
-e MODE=swarm \    vfarcic/docker-flow-proxy

我们开启的端口80与443将负责处理互联网流量(HTTP与HTTPS)。第三个端口则为8080,我们将利用它向代理发送配置请求。另外,我们强调其应当归属于proxy网络。如此一来,由于go-demo也被附加至同一套网络,意味着代理能够通过SDN对其进行访问。

在这套代理的帮助下,我们实现了最实用的网络路由功能之一。无论大家在哪台服务器上运行该代理,我们都能够向任意节点发送请求,而Docker网络会确保其被重新定向至代理之一。

最后一项参数为环境变量MODE,其负责告知该代理,各容器将被部署至Swarm集群当中。请参阅项目的README文件(https://github.com/vfarcic/docker-flow-proxy)以了解更多细节信息。

20160810201555

配合代理服务的Docker Swarm集群

需要注意的是,该代理即使已经运行在某一节点当中,仍会被放置于其外以表达其在逻辑上的分离特性。

在开始之前,首先确认代理正在运行。

docker service ps proxy

如果其“最新状态(Last state)”为“运行(Running)”,则可继续。如果不然,请等待直到该服务上线并开始运行。

现在代理已经部署完成,我们应当确保其知晓go-demo服务的存在。

curl "$(docker-machine ip node-1):8080/v1/docker-flow-proxy/reconfigure?serviceName=go-demo&servicePath
=/demo&port=8080"

这条请求的作用是重新配置代理以指定服务名称(go-demo)、API的URL路径(/demo)以及该服务的内部端口(8080)。从现在开始,所有指向该代理且使用以/demo开头路径的请求都将被重新定向至go-demo服务。

现在我们可以测试代理是否按预期运行——发送一条HTTP请求进行验证。

curl -i $(docker-machine ip node-1)/demo/hello

该curl命令的输出结果如下所示。

HTTP/1.1 200 OKDate: Mon, 18 Jul 2016 23:11:31 GMTContent-Length: 14Content-Type: text/plain; charset=utf-8 
hello, world!

代理正常起效!它响应了HTTP status 200并向API返回了hello,world!

需要注意的是,这一过程与我们执行操作所在的具体节点无关。由于Docker网络(路由体系)负责实现负载均衡,因此我们能够前往任意服务器。作为示例,下面我们发送同样的请求,但这一次立足于node-3。

curl -i $(docker-machine ip node-3)/demo/hello

结果仍然完全相同。

下面让我们一起了解由该代理生成的配置。

代理配置

如果大家选择自行构建代理解决方案,那么当然需要了解如何配置代理并利用Docker网络中的各项新功能。

下面首先检查Docker Flow: Proxy为我们创建的配置。我们可以进入当前运行的容器并通过/cfg/haproxy.cfg文件查看这部分信息。不过问题是,找到由Docker Swarm运行的一套容器需要配合一点技巧。举例来说,如果我们利用Docker Compose部署此容器,那么其名称会存在一定规律,即使用__格式。而docker service命令会利用散列后的名称运行容器。在我的笔记本上,docker-flow-proxy的创建名称为proxy.1.e07jvhdb9e6s76mr9ol41u4sn。因此,要进入由Docker Swarm部署并运行的容器,我们需要对镜像名称进行过滤。

第一步,我们需要找到代理运行所在的具体节点。

docker service ps proxy

需要注意的是该node列中的值,同时确保在以下命令中使用该正确值。

eval $(docker-machine env node-1) # Change node-1 with the node value previously obtained

此命令将给出以下代理配置输出结果。

docker exec -it \    $(docker ps -q --filter "ancestor=vfarcic/docker-flow-proxy") \    cat /cfg/haproxy.cfg exit

配置信息中最重要的部分如下所示。

frontend services    bind *:80    bind *:443    option http-server-close     acl url_go-demo path_beg /demo    
use_backend go-demo-be if url_go-demo backend go-demo-be    server go-demo go-demo:8080

对于第一部分(frontend),熟悉HAProxy的朋友应该不会感到陌生。其接收来自端口80(HTTP)以及443(HTTPS)的请求。如果路径以/demo开头,其会被重新定向至后端go-demo处。在这里,各请求会被发送至go-demo在端口8080上的地址。此地址同时亦是我们所部署的服务名称。由于go-demo同proxy存在于同一网络当中,因此Docker能够确保该请求被重新定向至目标容器。很简单,对吧?我们无需再另行指定IP以及外部端口。

接下来的问题是,如何实现负载均衡。举例来说,我们要如何指定该代理跨越全部实例执行循环?

负载均衡

在开始进行负载均衡解释之前,首先创建几个go-demo服务实例。

eval $(docker-machine env node-1) docker service scale go-demo=5

稍等一会儿,就将有5个go-demo服务实例开始运行。

20160810201540

包含规模化go-demo服务与代理实例的Docker Swarm集群

我们该如何让代理将请求均衡至全部实例当中?答案是不用——我们并不需要执行特别的操作。

正常来讲,如果我们不使用Docker Swarm功能,则可使用以下配置方式:

backend go-demo-be    server instance_1 <INSTANCE_1_IP>:<INSTANCE_1_PORT>    server instance_2 <INSTANCE_2_IP>
:<INSTANCE_2_PORT>    server instance_3 <INSTANCE_3_IP>:<INSTANCE_3_PORT>    server instance_4 <INSTANCE_4_IP>
:<INSTANCE_4_PORT>    server instance_5 <INSTANCE_5_IP>:<INSTANCE_5_PORT>

然而在新的Docker网络当中,我们将不再需要进行上述配置。原本的作法只会在新副本添加或者删除时,给我们的实例监控与代理更新工作造成麻烦。

现在,Docker会帮助我们完成全部负载均衡工作。更准确地讲,当该代理将某条请求重新定向至go-demo时,其实际将其发送至Docker网络并由后者执行跨越全部服务副本(实例)的负载均衡。这套方案的意义在于,代理负责将端口80(或者443)重新定向至网络中的正确服务处,其它任务则全部由Docker完成。

大家可以随意向该服务发送更多请求,并检查其中一套副本的日志记录。在这里,大家会发现其接收到的请求约为总体请求数量的五分之一——与我们的服务实例数量恰好吻合。

总结

Docker网络与Docker 1.12及更高版本提供的Swarm相结合,无疑开启了一道通向更多新机遇的大门。不同容器与负载均衡之间的内部通信只是其中的一小部分,我们亦可以更为轻松地配置公开代理。另外,我们需要确保面向API进行公开的全部服务皆以代理形式接入同一网络。在此之后,我们要做的就是进行配置以将所有请求重新定向至目标服务名称。这样所有来自代理的请求都将指向Docker网络,并由后者跨越全部实例执行负载均衡。

但新的问题在于,这套方案的具体效率是否理想。毕竟我们在体系中引入了新的层。尽管过去我们也会使用代理以及服务,但现在Docker网络会在二者之间建立负载均衡机制。答案是,由此带来的运行负担非常有限。Docker利用Linux IPVS实现负载均衡,其作为Linux内核的组成部分已经拥有超过15年历史,而且事实证明其是一种极为高效的负载均衡实现方式。事实上,其速度表现远远优于nginx或者HAProxy。

下一个问题是,我们是否需要代理机制。是的,当然需要。Docker所使用的IPVS只负责实现负载均衡。我们还需要一套代理以接收来自端口80与443的请求,并根据其实际路径将其重新定向至各目标服务。在此基础之上,我们还可以利用它执行多种任务,包括SSL握手以及验证等等。

那么这种作法存在哪些缺点?首先想到的肯定是粘性会话。如果我们希望同一用户向同一实例发送请求,那么这套方案显然并不适用。另一个问题是,我们是否应当在服务之内实现粘性会话,或者应该将其作为独立实体。这个问题我们在本文中暂时不作讨论,只需要明确这里提到的方案并不适用于粘性会话即可。

那么其具备哪些优势?首先,整个实现过程非常简单。我们用不着在部署新副本时对代理进行重新配置。如此一来,整个流程将非常便捷。由于我们不需要包含全部端口IP及端口的列表,因此也就无需使用Registrator以及Consul Template之类的工具。过去,我们需要利用Registrator以监控Docker事件,并将IP及端口保存在键值存储方案(例如Consul)当中。信息存储完成后,我们会利用Consul Template重新创建代理配置。虽然不少项目都能简化这一流程,但Docker Swarm与Docker网格的再现从根本上降低了其实施难度。

Docker Flow: Proxy——要还是不要?

在本文中,我们讲述了如何利用Docker Flow: Proxy项目配置HAProxy。其中包含HAProxy及一系列其它API,允许我们利用简单的HTTP请求对代理进行重新配置。另外,其还消除了对手动配置或者模板的依赖性。

在另一方面,建立自定义解决方案的流程也变得更为简单。本文只稍稍列举几项重点即解释了整个构建过程,这在nginx或者HAProxy配置工作中是完全无法想象的。

所以我的建议是先尝试一下Docker Flow: Proxy,而后再做决定。

接下来该做些什么?

今天我们已经总结了Docker v1.12带来的一系列Swarm与网络新功能,特别是在公开代理方面的改进。

那么我们是不是就能够成功运行Swarm群集了呢?还差得远!本文仅仅只是开始,我们还有大量问题有待回答。Docker Compose发生了哪些改变?我们该如何在不造成停机的前提下部署新版本?是否还有其它值得一试的工具?

后续的内容,也敬请大家期待!

分享到:更多 ()