跨網路拷貝檔案的簡單實踐(r3筆記第67天)
在實際的專案中可能要訪問生產環境是需要各種安全驗證和設定的,畢竟客戶的資料是最寶貴的資源。一般來說,客戶會把一部分訪問的許可權開放出來。這樣在系統出現問題的時候,能夠更快更高效的處理問題。 下面是一個簡單的圖表,能夠說明一下其中一個專案的網路訪問情況。 右邊的綠色區域是公司內部的環境,其中生產問題復現環境的許可權較高,這個許可權只會分配給部分的人,而開發測試環境是公開環境,開發測試人員都可以訪問。 左邊的區域是現場環境,生產環境包括現網環境和容災切換環境,這個是根據需求可以切換的。同時現場測試環境是客戶開發給我們的一個訪問環境,我們可以通過公司的網路直接訪問到現場的測試環境,然後通過現場測試環境來逐步的切換,直到連線到生產環境。
![](https://img.796t.com/res/2022/05-04/05/ce817fde4037bd8e2b6b03af949a9760.jpeg)
在系統升級和業務問題較多的時候,會嘗試從生產環境中抽取很小的一部分資料,把資料以dump的形式拷貝到公司內部環境中的生產問題復現環境中。這樣可以並行的排查很多不同的問題。
在問題比較多的時候,總是會收到比較多的郵件請求來拷貝dump檔案,其實明白了原理無非就是通過scp/sftp等形式把檔案一步一步的拷貝。做多了就感覺是體力活了。而且如果大半夜出現緊急問題,需要排查,需要拷貝檔案的時候自己雖然比較忙乎,但是這種拷貝檔案的工作還是比較苦悶的。
自己下決心來改進一下。
首先是訪問生產環境的許可權,我們申請了一個只讀使用者,只有許可權可以訪問到一個指定的目錄。這樣這個賬戶就可以開放給開發測試人員,不至於出現一些人為操作,他們只能夠從生產指定的目錄下拷貝檔案到現場測試環境。
沒法修改任何檔案。從某種程度上就杜絕了一些潛在的問題。
其次是現場測試環境和公司內部環境之間的訪問是單向的,意思就是隻能通過公司內部網路來連線現場測試環境,不能夠通過現場測試環境來連線公司內部環境。這樣的話,如果要把檔案從現場測試環境拷貝到生產問題復現環境的話,使用scp的時候就會有問題。因為生產問題復現環境是不能隨便開放給開發測試人員的。所以考慮設定開發測試環境和生產問題復現環境是單向訪問。開發測試環境和現場測試環境之間是單向訪問。
按照這個思路一個dump檔案要從生產環境拷貝的流程就是
生產環境->現場測試環境->開發測試環境->生產問題復現環境 整個流程都是單向的,需要配置單向的信任關係。這樣就可以使用shell指令碼來動態的實現了。
-->通過開發測試環境來獲取現場測試環境的檔案
這個部分是關鍵環節。可以在開發測試環境中使用下面的形式來呼叫
scp xxxx@現場測試環境:xxxxxx .
我寫了如下的指令碼來做了進一步的校驗。
check_file_valid=`ssh [email protected] "ksh check_file.sh ~/copyban_dump_copy/$1"`
file_not_exist_code=`echo $check_file_valid |grep WARNING|wc -l`
#echo $file_not_exist_code
if [[ $file_not_exist_code -eq 1 ]]
then
echo 'WARNING- source file doesnt exist,please check and try again!'
else
scp xxxx1@現場測試環境:~/dump_copy/$1 .
scp $1 xxxxx2@生產問題復現環境:~/dump_copy
fi
if [ -f $1 ]
then
echo 'file '$1' exists!'
else
echo 'WARNING -file '$1 ' doesnt exist!'
fi
這樣的話,我如果輸入的檔案不存在或者名字不正確。就會先做校驗。
$ ksh scpuat.sh aaa
WARNING- source file doesnt exist,please check and try again!
如果檔案存在,就開始把檔案先拷貝到開發測試環境中,然後拷貝到生產問題復現環境中。
一個簡單例子如下,檔案在內網傳輸會快很多,之間基本沒有多少的延遲。
$ ksh scpuat.sh test
test 100% 37 0.0KB/s 0.0KB/s 00:00
test 100% 37 0.0KB/s 0.0KB/s 00:00