關於接入管理，之前是想做成介面型，通過配置組合起來，實現靈活的呼叫方案。
當時畫了一個概要的圖。
如果把上面的路徑和技術序列聯絡起來，就可能是下面的一些解決方案。
| ops_to_cm | ssh,paramiko,ansible_adhoc |
| cm_to_host | ssh,paramiko,ansible_adhoc |
| host_to_db | command,pymysql,mysqldb |
| cm_to_db | ssh,pymysql,mysqldb |
| ops_to_db | pymysql,mysqldb |
| ops_to_host | ssh,paramiko,ansible_adhoc |
接入方式提煉出兩點：
系統層接入：
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