一种在dockerswarm群集下隔离网络的方法与流程

本发明涉及容器、算法及网络代理领域，尤其涉及一种在dockerswarm群集下隔离网络的方法。

背景技术：

目前swarm群集中，一般情况下，所有的应用都在一个网络中，对于有些我们需要做特殊控制(如网络调用，权限控制，智能路由)的应用就不能做有效的把控。在依赖很多额外组件的情况下，可以实现上述所说的部分功能，但是对于应用的自身的应用来说，依赖组件过多会增加自身的负担，且很多组件会侵入代码，及其不友好。本发明通过在安装应用的过程中，绑定对应的代理与其一起运行在专属网络中，由代理对应用进行控制，以达到监控的效果。

技术实现要素：

本发明的目的是针对现有技术的不足提供了一种在dockerswarm群集下隔离网络的方法，通过给应用建立专属网络已经绑定代理程序，可以将应用所有的请求经过代理路由转发，这样代理就可以记录下应用所有的动作。而且我们可以控制代理程序控制访问权限，来达到给应用进行隔离的目的。

一种在dockerswarm群集下隔离网络的方法，具体包括如下步骤：

步骤1，基于与docker守护进程交互，调用守护进程提供的相关服务dockerswarmapi构建应用发布系统；

步骤2，将待发布的应用容器镜像、容器环境变量、资源限定、服务名称的相关信息通过消息队列客户端程序推送至kafka消息队列；

步骤3，发布系统拉取kafka消息，准备发布，通过类似拓扑排序算法确定待发布应用的关联关系，确定安装的先后顺序；

步骤4，通过dockerapi创建应用的专属网络启动链接docker守护进程程序，调用docker底层的createservice方法，将应用的镜像，环境变量，参数信息传递给守护进程，docker守护进程创建对应应用；

步骤5，通过dockerapi创建具体应用以及对应的代理程序和网络，应用置于步骤5的专属网络中，代理程序置于步骤5的专属网络和公用网络中；

步骤6，在专属网络和公用网络中，分别对应用和代理程序设置网络下别名。

作为本发明一种在dockerswarm群集下隔离网络的方法的进一步优选方案，在步骤1中，在安装dockerswarm的机器上，生成docker.sockunix域套接字，通过该套接字，可与docker守护进程通信，调用docker底层的各种服务；基于docker创建容器服务构建发布应用系统，进而通过调用docker底层功能创建相应的应用。

作为本发明一种在dockerswarm群集下隔离网络的方法的进一步优选方案，所述步骤5具体包括：

步骤5.1，通过docker守护进程提供的发布服务的功能创建代理程序；

步骤5.2，通过docker守护进程提供的创建网络功能创建应用的私有网络。

作为本发明一种在dockerswarm群集下隔离网络的方法的进一步优选方案，所述步骤6具体包括：

步骤6.1，设置代理程序在应用私有网络下的别名为固定名称；

步骤6.2，设置代理程序在公有网络下的别名为应用自身的名称。

作为本发明一种在dockerswarm群集下隔离网络的方法的进一步优选方案，调用dockerapi的方式采用绑定unix域套接字docker.sock来实现。

作为本发明一种在dockerswarm群集下隔离网络的方法的进一步优选方案，采用消息队列来现实交互，保证了交互的时序性以及稳定性。

作为本发明一种在dockerswarm群集下隔离网络的方法的进一步优选方案，创建私有网络，创建应用，以及设置网络下别名的都是通过调用dockerr底层服务来api实现。

作为本发明一种在dockerswarm群集下隔离网络的方法的进一步优选方案，通过图类似拓扑排序算法来确定应用安装的依赖性。

本发明采用以上技术方案与现有技术相比，具有以下技术效果：

1、本发明通过给应用建立专属网络已经绑定代理程序，可以将应用所有的请求经过代理路由转发，这样代理就可以记录下应用所有的动作；而且我们可以控制代理程序控制访问权限，来达到给应用进行隔离的目的。

2、本发明通过设置应用的专属网络，保证了该应用的所有活动只限制在专属网络中，所有对公有网络的操作都是通过代理程序转发，有效的控制了应用的安全性，避免产生一些不可控的现象。

3、通过记录每个应用对公有网络所有操作，后期可以通过大数据分析每个应用对于公有网络的依赖以及对于公有网络产生的影响。

附图说明

图1本发明应用关系图；

图2本发明springcloudzuul架构图；

图3本发明应用间调用效果图；

图4本发明整个方法流程图。

具体实施方式

本发明的方法的几个主要解决步骤如下：

一种在dockerswarm群集下隔离网络的方法，如图4所示，具体包括如下步骤：

步骤1，基于与docker守护进程交互，调用守护进程提供的相关服务dockerswarmapi构建应用发布系统；

步骤2，将待发布的应用容器镜像、容器环境变量、资源限定、服务名称的相关信息通过消息队列客户端程序推送至kafka消息队列；

步骤3，发布系统拉取kafka消息，准备发布，通过类似拓扑排序算法确定待发布应用的关联关系，确定安装的先后顺序；

步骤4，通过dockerapi创建应用的专属网络启动链接docker守护进程程序，调用docker底层的createservice方法，将应用的镜像，环境变量，参数信息传递给守护进程，docker守护进程创建对应应用；

步骤5，通过dockerapi创建具体应用以及对应的代理程序和网络，应用置于步骤5的专属网络中，代理程序置于步骤5的专属网络和公用网络中；

步骤6，在专属网络和公用网络中，分别对应用和代理程序设置网络下别名

基于以上的步骤，采用的具体实施过程如下：

第1步，在安装docker的机器上，找到docker运行产生的docker.sock文件，创建dockerclient客户端，用来发布应用，创建专属网络，创建代理程序。如果需要docker镜像仓库用户名密码健全，则设定鉴权参数。

第2步，通过kafkaconsumer不断拉取消息队列中的消息，来不断获取用户需要隔离的应用信息。

第3步，将拉取到的各个应用信息通过如下算法进行排序

算法描述：

a.有abcdefg这7个应用，假设c必须在a完成之后做，我们把这种关系定义为"依赖"，用符号"a-->c"标识，这7个应用如图1所示

b.列出所有的关联关系，生成依赖关系清单r，左右两边分别标记为rl关系清单和rr关系清单，如下：

a-->c

a-->d

a-->g

b-->c

d-->b

d-->e

f-->e

g-->f

b-->g

c.约定左边为依赖关系清单r，右边为事情清单，分隔符号“|”前边的事情表示已经排好，后边是等待排的事情

第一步：开始时，分隔符号在事情清单开始，表示所有事情均等待排序。将等待排序的清单中划掉rr关系清单中出现过的事情，将未划掉的放到分隔符前边，然后从依赖关系清单中同时划掉分隔符前边出现过的关系对，得到第二步图，此时事情a已经排好

第一步图：

第二步：重复第一步，得到第三步图，此时ad已经排序好。

第二步图：

第三步：重复第一步，得到第四步图，此时事情adb已经排好。

第三步图：

第四步：重复第一步，得到第五步图，此时事情adbcg已经排好。

第四步图：

第五步：重复第一步，得到第六步图，此时事情adbcgf已经排好。

第五步图：

第六步：重复第一步，得到第七步图，此时事情adbcgfe已经排好。

第六步图：--adbcgf|e

第七步图:--adbcgfe|

第4步，通过dockerclient提供的方法创建应用以及创建网络，具体实现步骤如下：

通过createservice方法创建应用：

根据应用的相关信息，组装成dockerclient需要的参数，调用创建应用方法创建应用，设置应用的相关属性。

通过createnetwork方法创建网络：创建过程中，会判断可用网段，以及之前创建过的记录，防止冲突。

第5步，创建代理程序，代理程序使用springcloudzuul来实现，zuul的架构图如下图2所示。filterfilemanager管理目录和轮询修改和新的groovy过滤器，其中的startpoller方法负责轮询。

zuulrunner会初始化一个requestcontext对象，该对象持有整个请求过程中的上下文数据，被所有过滤器锁共享。zuulrunner会执行具体的pre、routing、post以及error类型的过滤器，执行完成之后，返回返回具体的httpresponse对象。

代理程序通过设置自定义routing，日志记录过滤器，来实现将应用的请求智能转发，将请求进行记录，转发的示意图如图3所示，后期还可以设置其他过滤器来实现其他定制功能。主要实现逻辑如下：当应用访问公共网络中的其他服务的时候，修改专属网络内应用访问的url,使之强制转换为对应其他应用在公共网络中代理的地址，再通过代理的转发，真正访问到具体的服务。且记录每次请求的信息输入到日志文件，以供filebeat采集。

第6步，设置网络下别名；

在第4,5步下，已经实现了应用，代理，网络的安装，这一步中，通过设置应用，代理在不同网络下的endpoint。

有应用serviceaserviceb；

eg:调用过程servicea->serviceb,通过代理后，调用过程为servicea->proxya->proxyb->serviceb,如下图3所示。

设置过程：通过设置service和proxy在每个网络下的别名aliases，这样，在对应的网络中，就可以通过aliases来访问应用。

proxya在公用网络和专属网络a中，servicea只在专属网络a中，proxyb在公用网络和专属网络b中，serviceb只在专属网络b中

设置proxya在专属网络a中的别名为proxya，在公用网络中别名为servicea,proxyb在专属网络b中的别名为proxyb，在公用网络中的别名为serviceb。

调用过程经过springcloudzuul的自定义路由，路由过程如上面所描述，来完成servicea到serviceb的调用。