運(yùn)維開發(fā)中的接入管理方法是什么

這篇文章主要介紹“運(yùn)維開發(fā)中的接入管理方法是什么”的相關(guān)知識(shí)，小編通過實(shí)際案例向大家展示操作過程，操作方法簡單快捷，實(shí)用性強(qiáng)，希望這篇“運(yùn)維開發(fā)中的接入管理方法是什么”文章能幫助大家解決問題。

如果把上面的路徑和技術(shù)序列聯(lián)系起來，就可能是下面的一些解決方案。

接入方式提煉出兩點(diǎn)：

系統(tǒng)層接入：

paramiko和ansible_adhoc

數(shù)據(jù)庫接入

pymysql,mysqldb

在這個(gè)基礎(chǔ)上，進(jìn)行進(jìn)一層的提煉，接入管理提煉出兩點(diǎn)：

數(shù)據(jù)庫層的接入可以提煉出DAO層，通過工廠模式來提供靈活的配置接入，這會(huì)是一個(gè)通用的接口，同時(shí)其他數(shù)據(jù)庫的接入也可以通過這種方式帶來接入，提煉的結(jié)果就是對于數(shù)據(jù)庫類型和接入方式，即可完成數(shù)據(jù)庫的接入管理，比如MySQL，我只需要輸入mysql.mysqldb的方式即可通過mysqldb庫的方式接入MySQL

同理系統(tǒng)層的接入是類似的情況，目前可以暫采用paramiko和ansible_adhoc兩個(gè)選項(xiàng)即可。

至于上層的接入路徑如何串聯(lián)，按照通用的思路：

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

如果是沒有一個(gè)完整的路徑分析，可能得到的路徑不是很完整。

這些其實(shí)就跟管理層的工作類似，需要根據(jù)實(shí)際的情況和配置來得到一個(gè)最優(yōu)路徑，然后由具體的任務(wù)層來負(fù)責(zé)執(zhí)行。

所以上面的思路抽象之后，就是得到接入路徑，然后執(zhí)行接入任務(wù)。

這只能算是剛剛開始吧，還有幾個(gè)問題需要弄明白。

比如ops_to_db的路徑有三個(gè)，拿第一個(gè)來說，

1)ops_to_cm,cm_to_host,host_to_db

如果是最后的執(zhí)行節(jié)點(diǎn)，host_to_db，如果使用pymysql,mysqldb兩種執(zhí)行方式，那么相應(yīng)的庫文件需要在host層面具備，而ops,cm端只是調(diào)用而已。

而如果是第三個(gè)

3)ops_to_db

則只需要保證ops端具有完整的庫文件即可。

所以第一種路徑太深，而且對于目標(biāo)端的環(huán)境依賴要重一些，相對來說是不大推薦的。

第三種，需要ops端具有直連的權(quán)限，能夠直接訪問數(shù)據(jù)庫，則ops端需要配備完善的接入管理。這個(gè)不能說不合理，只是對于ops來說會(huì)相對重一些。

那么第二種相對而言是比較好的，我們基于中控端去做，支持命令方式和驅(qū)動(dòng)方式，中控端的配置對于所有的其他服務(wù)器都是適用的，這樣我們能夠基本達(dá)到中控的一個(gè)基本需求，這個(gè)算是對需求的收斂吧。

所以對于這個(gè)基本的接入管理需求，會(huì)分為：系統(tǒng)接入管理和數(shù)據(jù)庫接入管理，映射到這個(gè)場景中，就是如下的一個(gè)初步選擇

2)ops_to_cm,cm_to_db

關(guān)于“運(yùn)維開發(fā)中的接入管理方法是什么”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)，可以關(guān)注億速云行業(yè)資訊頻道，小編每天都會(huì)為大家更新不同的知識(shí)點(diǎn)。