關於接入管理,之前是想做成介面型,通過配置組合起來,實現靈活的呼叫方案。
當時畫了一個概要的圖。
如果把上面的路徑和技術序列聯絡起來,就可能是下面的一些解決方案。
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