Docker关联使用的一些工具:Clip名字服务(转载)

Clip名字服务

Clip(http://blog.puppeter.com/read.php?7)是一个名字服务C/S架构，它将传统的IP管理维度替换为名字服务即有意义可记忆的String。Clip将IP对应的String关系保存在Server端。Client端可以下载SDK，通过SDK遍历Server端的String对应IP的关系，并在本地对获取的IP模块关系进行重新的组织与编排。传统服务器IP方式与String方式相比，String方式有3点优势：

　　  传统IP管理方式，IP由4组无意义的数字组成，比较难记忆。String更方便记忆；
　　  管理海量服务时，IP相似经常会导致运营故障，譬如A模块（10.131.24.37 ）和B模块（10.117.24.37），后两组数字一致，系统惯性的认为B模块就是A模块，发送配置导致线上故障。通过string管理方式可以规避此问题；
　　  String 可以解析1个IP，也可以解析一组IP ，根据IP也可以反解析String对应关系，使得管理一组服务更加方便。

　　Clip中的String由四段（字段含义idc-product-modules-group）组成，读者会发现String与Cmdb的结构很像：四级模块定位一个服务。但是为了充分利用资源我们的业务要求一个IP可能要对应多个服务，不同的服务有自己的波峰与波谷，在相同的IP上只要保证各业务的波峰不重叠就满足了业务的需求，也充分了利用资源。而在一台服务器上混合部署不同的业务模块，四级模块就只能定位到服务的IP级别，而无法精确定位到真正的服务，所以Clip名字服务在Cmdb的基础上增加了port端口，即五段（字段含义idc-product-modules-group-port）定位一个服务。我们可以将动态的IP通过Clip接口注册到指定含义的String上，通过Clip自带工具来解析实时的String对应IP关系，譬如：

# clip cstring -q idc-product-modules-group-port
192.168.0.1
192.168.0.2
192.168.0.3
192.168.0.4
192.168.0.5

Clip数据存储结构分为两层：
关系层保存了String对应IP或内部系统Cmdb的模块关系（见图3）。

Clip名字服务关系表（图3）
关系层数据含义见表1

关系层数据含义表1
数据层保存了String与IP的具体关系（见图4）。

Clip名字服务数据表（图4）

Clip名字服务在存储String对应IP关系基础上，在SDK上还提供了远程端口扫描、远程ssh、远程文件拷贝和查找String关系结构的工具子命令等，更多可以见http://blog.puppeter.com/read.php?7。

Clip名字服务与Docker应用
如笔者上文所提，离线系统的建设思路就是将离线业务通过Docker快速的部署在资源空闲的机器上，而空闲的机器是通过数据分析系统长期分析沉淀的结果，Clip名字服务就是这两种资源建立联系的桥梁，但只有Clip绑定关系还是不够的，还需要建立绑定关系String对应Docker环境的关系，所以在Clip名字服务的基础上我们又扩充了Docker的资源关系表。

Docker资源关系表图5
其中Docker资源使用的关系表的字段含义见表3：

我们来看一个需求案例：某视频转码业务在上海需要使用资源约1000核心，对应的关系表为表4

由于buffer资源不时在变动，我们需监控String (sh-buffer-qq-video-2877)整体核数是否低于mcount值，如果低于则出发自动扩容策略。同时也需针对Docker资源使用关系中的app_port字段来监控整体String (sh-buffer-qq-video-2877)业务是否处于健康状态。在这里我们沉淀了String (sh-buffer-qq-video-2877)的一些基础数据如负载、内存、网络和磁盘IO等为资源的调度奠定的基石（见图6）。

离线运营系统图6