如何將Weblogic從虛擬機器遷移到容器
隨著PaaS和DevOps解決方案需求的增漲，我們可以看到那些執行在虛擬機器上或直接執行在裸機上的遺留應用程式，在實踐時會遇到一系列的障礙。分解和遷移的過程複雜度非常高。通常，為了獲得PaaS或CaaS模式的好處，應用程式所有者必須去重新設計他們的應用架構。
在這個文章裡，我們將分析把執行在虛擬機器上的Java 遺留應用程式遷移到基於容器平臺上的具體挑戰。使用Oracle WebLogic Server做為案例，我們將展示分解過程的具體步驟和遷移的結果。
遷移到容器的動機
對比Java EE應用執行在裸機的時代，硬體虛擬化已經是一個很大的進步。它給了我們解決多個應用間隔離及提高硬體利用率的能力。然而，Hypervisors（虛擬機器管理程式）在宿主機上會使用大量CPU和記憶體，且每個虛擬機器都要求擁有完整的作業系統、TCP棧和檔案系統。
每個虛擬機器都有固定的記憶體，只有部分的虛擬機器管理程式可以為通過記憶體膨脹（memory ballooning）機制的幫助為執行中的虛擬機器重新分配記憶體。所以為了應用程式未來的規模，我們在每個虛擬機器裡都會預留一些資源，但這些資源並沒有得到完全的利用。同時，由於在一個虛擬機器內例項間缺乏適當的隔離，這些資源也不能被其他的程式共享。
而容器通過共享宿主機的OS kernel、TCP棧、檔案系統和其他的系統資源，僅使用很少的資源和CPU就可以執行，進一步提高了效能和資源利用率。
這裡有兩種型別的容器——應用容器和系統容器。通常，一個應用容器執行時相當於一個單程序。而一個系統容器則像一個完整的作業系統，可以在一個單容器內執行作業系統所有的功能，比如systemd、SysVinit和通過openrc產生其他類似openssh、crond and syslogd的程序。兩種型別的容器在不同的使用場景都非常有用，而且在冗餘管理程序上不浪費記憶體，通常消耗的記憶體比虛擬機器少。然而，對於Java遺留應用程式的遷移只有使用系統容器可以不需要大量的應用重構。
不同於虛擬機器，對於執行中例項的容器資源的不需要重啟就可以很容易修改限制。而且這些在限制邊界內沒有被消耗的資源自動與在同一個物理節點上的其他容器共享。
此外，容器對於開發而言也非常有用，在建立，打包，測試應用方面用一種敏捷的方式加快應用的開始進度和提高應用的可擴充套件性。
這些在物理機上沒有被利用的資源可以很容易彈性擴充套件或新應用的容器使用。考慮到提高容器的隔離，不同型別的應用可以執行在相同的物理節點而不相互影響。這些可以平均提高已存在的基礎裝置資源利用率的3-10倍。
什麼是分解
在遷移過程中，程式分解是基本部分，它可以幫助把大的單塊應用分解成小的，按邏輯塊劃分的，和可以獨立執行程式。
以圖中顯示的是在從虛擬機器遷移到容器時應用的一個簡單的分解過程：
在虛擬機器中執行Java遺留應用程式
在軟體程式開發裡有句老話：遺留軟體是好的，只不過是還在執行的舊軟體。下面通過案例讓我們更精確的知道在Oracle Weblogic Server上它是怎麼工作的。
在虛擬機器中Oracle Weblogic Server的結構
在虛擬機器中執行時，Weblogic Server包含三種類型的例項：
- Administration Server.（管理伺服器）
- Node Manager.（節點管理器）
- Managed Server.（被管理伺服器）
管理伺服器是中心節點，通過它可以配置和管理叢集中的所有資源。它通過與節點管理器連線增加或刪除被管理節點。而被管理節點執行Web應用、EJBs、Web service和其他的資源。
通常，每個虛擬機器上執行一個節點管理器和多個被管服務伺服器，而一個管理伺服器則管理所有虛擬機器上的所有例項。
通過虛擬機器擴充套件 WebLogic
現在想象一下遇到流量高峰期需要擴充套件叢集，新的被管伺服器將會被加入到虛擬機器中用於處理增長的負載，直到沒有資源分配。
但是當流量還在不斷增長，而當前被管理服務的例項數量不足以處理負載時，則需要增加一個新的虛擬機器去處理程式的進一步增長的業務規模。
典型的通過多個虛擬機器對WebLogic進行擴充套件包括三個步驟：
- 提供一個提前配置好 Weblogic Server 模板的新虛擬機器
- 在新的虛擬機器上啟動一個節點管理器，並連線到管理伺服器上
- 新增一個新的被管理伺服器處理部分增長的業務負載
然後，這個擴充套件的步驟重複，在新增加的虛擬啟動更多的被管理伺服器直到資源限制。
在虛擬機器中執行WebLogic的劣勢
這樣執行Oracle WebLogic是一種資源利用率非常低下的方式，這裡有幾個資源浪費或未使用的點：
- 每個虛擬機器要求擁有完整的作業系統，TCP 棧和檔案系統，這些需要使用宿主機大量的 CPU 和記憶體。
- 這些資源的分配並非高度微粒化，在某些場景，所有當我們只需要增加一個被管理伺服器時也需要去準備一個完整的虛擬機器。
- 如果當一個虛擬機器的資源不足時，新增額外的 CPU 或僅是增加記憶體也需要重啟整個虛擬機器。
- 每個虛擬機器都需要節點管理器用來增加或刪除被管理節點，需要消耗額外的資源和增加額外複雜的配置。
- 在同一個虛擬機器裡執行的例項由於缺少隔離會相互影響，從而影響整個應用的效能。也出於這個原因，我們不能在同一個虛擬機器上混合搭配執行不同的應用程式。
- 虛擬機器的可移植性受限於一個廠商，所以當我們想從一個雲遷移到另一個雲會有一系列的問題。
- 在虛擬機器上做模板打包和實施CI/CD會非常慢和過程複雜。
從虛擬機器遷移到容器
這些天，我們找到多個設計用來在容器裡執行微服務的優秀應用伺服器和框架，比如 Spring Boot、WildFly Swarm、Payara Micro等等。無論如何，有一系列的伺服器設計執行在虛擬機器，比如Oracle WebLogic Server，這種型別的例項遷移到容器裡的任務更加複雜。這就是為什麼我們更關注這個主題。
WebLogic Server的分解
這些天通過Docker容器的幫助這個分解是一個相當容易的任務。首先，我們需要準備一個有WebLogic Server的容器映象。（映象可從Oracle的官方倉庫獲得）。
當Docker模板已經準備好，我們規定每個例項在獨立的容器裡：一個管理伺服器和需要數量的被管理伺服器。
在這裡，我們放棄了用於增加和刪除被管理節點的節點管理器。
遷移到容器後，和直接使用管理節點一樣，通過容器編排平臺和一系列WSLT指令碼，被管理伺服器例項可以被自動增加和刪除。
這樣，我們就得到了一個非常簡單的Weblogic Server Cluster結構。
因為容器比從頭開始配置或克隆更容易，這樣水平擴充套件過程變得非常細顆粒和平滑。還有，每個容器可以被快速啟動或停止，幾乎沒有停機時間。當和虛擬機器對比時容器更加輕量，所以排程容器時比排程虛擬機器使用更少的時間。
雖然將應用遷移到容器裡是一個挑戰，但是如果你知道怎麼管理它，可以獲得如下的好處：
- 每個容器消除獨立的完整作業系統，TCP 棧和檔案系統可以減少系統資源（ CPU 和記憶體）的使用。
- 通過在叢集拓撲裡刪除節點管理器可以簡化水平擴充套件。
- 通過容器可以共享未使用資源的能力可以自動化垂直擴充套件，而且不需要重啟就可以重新配置，非常容易。
- 通過在同一個物理機上使用獨立的容器隔離執行不同的應用，提高基礎裝置的利用率。
- 通過容器的可移植性解除在不同雲廠商的遷移約束。
可以使用相同的方式幫助分解應用的其他層，或應用其他的Java EE應用服務。在下一個主題，我們會通過一個特定的案例描述怎麼處理分解後資料的全過程。
陳愛珍譯/七牛雲佈道師
原文出處：Docker（微信訂閱號ID：dockerone）