容器化：為系統賦能，為團隊賦能

為什麼要容器化

作為測試人員，測試系統第一步，就是有個已經部署好的系統，能正常使用。那麼如果沒有部署好的系統或者沒有指定版本的系統，你會怎麼做呢？下面以如下場景來進行說明：

場景一：部署與移植

這裡的0表示，目前環境是全新的，作業系統是最小化安裝。在這樣的場景中，這樣的環境在部署系統中通常會遇到下面兩種應用程式

全新的應用程式，第一次安裝到該環境

這樣應用程式，遇到這樣的環境是最好的配對，隻要安裝包提供的完畢，系統部署是一個挺順利的過程，但一旦系統部署失敗，要把環境回退到0的狀态，如果是實體機這個實體機是比較大的，如果是虛拟機隻需要傳回到0的快照重新部署就好，那如果是使用容器呢？如果是使用容器技術，隻需要删除目前鏡像，重新拉取基礎鏡像部署就好。

但這裡要說明，不是所有的應用都适合容器化，如果對核心有依賴，不建議進行容器化。

存在多個版本的應用程式，移植到該環境

如果遇到這樣的場景，以虛拟機和實體機為例，你們在對這樣的系統，你們是如何進行移植？是類似與更新打怪還是直接複制應用系統目錄，然後缺什麼補什麼呢？

這樣的場景，為確定系統的功能正确性，需要進行全面分析，和全面的系統測試，來保證移植過來的系統能正常穩定的對外提供服務。

那如果系統是使用容器化，那隻需要在目前拉取最新版本的鏡像，運作起來就行，不需要考慮移植之後環境影響，因為系統運作環境由容器本身提供。

場景二：測試環境不充足

應用部署如果有實體機肯定是首選，一套系統獨占一套環境，避免環境污染。那現實往往是多項目并行，不可能一個項目獨占一套資源，往往是多項目并行，那在多項目并行測試環境不足的情況，但項目都需要上線這個時候會不會頭秃？在沒使用容器化的時候，這樣的情況，隻能排優先級，隻能先滿足高優先的，這時候就有一個項目要刮起。

對應用系統容器化，可以在之前一套測試環境上，運作多套應用系統，讓項目可以并行測試，增加項目的并行度。但這就要確定，每一套系統都要維護自己系統本身的鏡像。

容器可視化

通過上訴兩個場景，能發現容器兩大核心優勢：

• 在系統移植與部署方面配合腳本能實作一鍵部署及運作，減少環境依賴
• 不同系統之間擁有自身的鏡像，隔絕環境交叉感染，增加項目并行度，硬體環境最大化。

基于上述優勢，我們開始了探索容器化技術，萬事開頭難，這裡說下容器化道路上遇到的“妖魔鬼怪”。

如何對已有系統建構鏡像?

docker理論知識具備之後，那第一步就是建構系統鏡像。那如何選取時候應用系統的鏡像呢？在内網中沒有基礎鏡像，但外網的資源與目前應用作業系統版本不一緻，那要建構與應用作業系統版本一緻的鏡像呢？當時的想法是，那有沒有一種方法把已有的作業系統打包成一個鏡像呢？

通過可以把目前系統打包成鏡像：

tar -cvpf /tmp/base.tar --directory=/ --exclude=proc --exclude=sys --exclude=dev --exclude=run --exclude=boot .      

cat base.tar  | docker import --centos:7      

TIPS：個人推薦使用vm最小化安裝作業系統，然後再使用上述指令打包，這樣可以使鏡像盡可能小。

多項目并行如何管理容器?

早期沒有規範容器使用規約，項目成員都可以在主控端上直接使用docker run就拉取自己容器，使用之後，不進行删除，長期在背景運作，同時成員都是root權限，如果成員誤删容器，會影響其他項目測試，那有沒有一個好的軟體可以可視化管理目前項目容器呢？

基于此問題，我們調研然後可行性研究，選擇了Portainer作為容器可視化管理，每個使用者隻能看到自己建立的容器，管理者可以看到目前系統所有容器。

Portainer可以通過界面建立容器，也可以使用docker-compose子產品拉取一套項目環境，目前項目組，維護了對應的yaml檔案，用于管理容器及容器的網絡。目前項目使用portainer納入了兩個docker服務節點，後續規劃納入三台節點，用于項目安裝部署測試。

小結

對容器可視化，基本滿足目前團隊在項目中的使用。後續階段學習了K8S，并使用部門rancher對系統web進行容器化，通過應用商店可以直接拉取一套web服務，對應服務也會相應啟動，但rancher應用商店對目前項目成員作用不是很大，應為k8s對應用高度封裝，但系統測試會涉及安裝、回退測試，是以目前項目團隊更偏向于使用Portainer。

個人喜歡一句話：“能落地的技術才是好技術”，至于為什麼能堅持容器化主要有以下幾點:

其一、能落地并能給團隊賦能，提升測試效率，提升團隊技術；

其二、容器化為以後“一鍵測試”提供技術支撐；