运维中的接入管理梳理

关于接入管理，之前是想做成接口型，通过配置组合起来，实现灵活的调用方案。

当时画了一个概要的图。

如果把上面的路径和技术序列联系起来，就可能是下面的一些解决方案。

接入方式提炼出两点：

系统层接入：

paramiko和ansible_adhoc

数据库接入

pymysql,mysqldb

在这个基础上，进行进一层的提炼，接入管理提炼出两点：

数据库层的接入可以提炼出DAO层，通过工厂模式来提供灵活的配置接入，这会是一个通用的接口，同时其他数据库的接入也可以通过这种方式带来接入，提炼的结果就是对于数据库类型和接入方式，即可完成数据库的接入管理，比如MySQL，我只需要输入mysql.mysqldb的方式即可通过mysqldb库的方式接入MySQL

同理系统层的接入是类似的情况，目前可以暂采用paramiko和ansible_adhoc两个选项即可。

至于上层的接入路径如何串联，按照通用的思路：

ops到db的路径，目前只有三类

1)ops_to_cm,cm_to_host,host_to_db

2)ops_to_cm,cm_to_db

3)ops_to_db

而同理ops到host的路径，只有以下几类：

1)ops_to_cm,cm_to_host

2)ops_to_host

最后还有第三类，是host_to_db

如果是没有一个完整的路径分析，可能得到的路径不是很完整。

这些其实就跟管理层的工作类似，需要根据实际的情况和配置来得到一个最优路径，然后由具体的任务层来负责执行。

所以上面的思路抽象之后，就是得到接入路径，然后执行接入任务。

这只能算是刚刚开始吧，还有几个问题需要弄明白。

比如ops_to_db的路径有三个，拿第一个来说，

1)ops_to_cm,cm_to_host,host_to_db

如果是最后的执行节点，host_to_db，如果使用pymysql,mysqldb两种执行方式，那么相应的库文件需要在host层面具备，而ops,cm端只是调用而已。

而如果是第三个

3)ops_to_db

则只需要保证ops端具有完整的库文件即可。

所以第一种路径太深，而且对于目标端的环境依赖要重一些，相对来说是不大推荐的。

第三种，需要ops端具有直连的权限，能够直接访问数据库，则ops端需要配备完善的接入管理。这个不能说不合理，只是对于ops来说会相对重一些。

那么第二种相对而言是比较好的，我们基于中控端去做，支持命令方式和驱动方式，中控端的配置对于所有的其他服务器都是适用的，这样我们能够基本达到中控的一个基本需求，这个算是对需求的收敛吧。

所以对于这个基本的接入管理需求，会分为：系统接入管理和数据库接入管理，映射到这个场景中，就是如下的一个初步选择

2)ops_to_cm,cm_to_db