Jerry之前的文章 一個13年ABAP老兵的建議：了解這些基礎知識，對ABAP開發(fā)有百利而無一害, 回顧了ABAP Netweaver服務器主要的組件。本文咱們就來聊聊ABAP Netweaver容器化這個話題。

Jerry假定閱讀本文的朋友，都聽說過虛擬機和容器的概念， 并且對虛擬機和容器的區(qū)別有所了解。

容器與虛擬機的出發(fā)點很類似：對應用程序及其依賴進行隔離，生成一套能夠隨處運行的自容納單元；二者都能夠使應用運行在一個虛擬出的抽象層里，擺脫對傳統(tǒng)物理硬件的依賴，使得計算資源的利用更加高效，能源效率與成本效益得以提升。

容器在虛擬化程度上比虛擬機技術(shù)更進一步，擺脫了前者對Hypervisor層的依賴，直接利用宿主機的內(nèi)核，抽象層比虛擬機更少，更加輕量化，同虛擬機技術(shù)相比能達到更高的物理資源利用率，因此更受當今云服務提供商的青睞。

Docker是一個開源的應用容器引擎，是當今最流行的容器技術(shù)之一。

那么SAP ABAP Netweaver，能否利用Docker引擎，讓它運行在容器里呢？

SAP官方的note 1122387 - Linux: SAP Support in virtualized environments給出了答案：截至2020年1月17日，答案是不支持。SAP官方不支持將ABAP應用服務器運行在容器或者容器編排環(huán)境內(nèi)。比如目前業(yè)界流行的Docker和LXC，以及運行在Google Cloud Platform, Microsoft Azure, AWS上的Kubernetes Cluster，都不是SAP官方支持的能夠?qū)BAP Netweaver服務器以容器的方式運行的平臺。
https://launchpad.support.sap.com/#/notes/1122387

那么在2018年5月的時候，SAP社區(qū)有一篇博客：

Installing SAP NW ABAP into Docker
https://blogs.sap.com/2018/05/30/installing-sap-nw-abap-into-docker/

這又是怎么一回事呢？我們可以通過閱讀博客了解作者是怎么做到的。

首先，我們從SAP官網(wǎng)上能免費下載Netweaver的開發(fā)者試用版，ABAP版本號為7.52 SP04：

https://developers.sap.com/trials-downloads.html?search=7.52%20SP04

下載到本地，得到一個rar文件，解壓之后執(zhí)行里面的安裝文件即可把ABAP Netweaver安裝到本地。

因此SAP社區(qū)上的一群ABAP愛好者們，想到了一個點子：如果把下載的Netweaver安裝文件，解壓之后，將其內(nèi)容構(gòu)建成一個Docker鏡像文件，在這個Docker鏡像內(nèi)完成Netweaver的安裝和啟動工作。如此一來，豈不是達到了在容器里運行ABAP Netweaver的目的？

我們可以在這位ABAP愛好者的github倉庫上找到用來制作Docker鏡像的Dockerfile文件，從中了解到該容器鏡像的制作過程：

https://github.com/tobiashofmann/sap-nw-abap-docker/blob/master/Dockerfile

這個Dockerfile構(gòu)建的鏡像選擇了openSUSE Leap作為母鏡像，該鏡像提供了ABAP Netweaver運行的Linux操作系統(tǒng)。

Dockerfile的第一行用FROM關(guān)鍵字指定了這個基準鏡像的名稱：

第16行用COPY將事先從SAP官網(wǎng)下載好的存儲在宿主機NW752文件夾下的Netweaver開發(fā)者版本安裝文件，拷貝到容器鏡像里，然后第22行用RUN關(guān)鍵字運行安裝腳本。

安裝完畢后，執(zhí)行47行的啟動腳本run.sh, 這樣就能在容器里啟動Netweaver服務器了。

這個容器鏡像制作好之后，只需要簡單地使用docker run命令行，就能啟動一個新的容器運行實例了。從SAP官網(wǎng)下載的Netweaver開發(fā)者版本，就運行在這個新啟動的容器實例里。

我們回顧這種做法，發(fā)現(xiàn)Docker技術(shù)較之虛擬機的優(yōu)點并沒有體現(xiàn)出來，按照博客作者提供的信息，通過這種方式制作出的鏡像文件的大小超過了100GB，如此巨型的鏡像文件幾乎無法通過Docker Hub分發(fā)給其他人，無法用于生產(chǎn)用途。

另一方面，通過這種容器化方式，Jerry之前文章 一個13年ABAP老兵的建議：了解這些基礎知識，對ABAP開發(fā)有百利而無一害 介紹的Netweaver服務器的諸多組件，被放置到同一個容器內(nèi)，無法通過簡單地增加容器實例的方式，實現(xiàn)Netweaver處理能力的水平擴展。

正是因為意識到將Netweaver所有組件放置于同一容器鏡像內(nèi)這種措施無法發(fā)揮容器技術(shù)的優(yōu)勢，SAP Linux實驗室的工程師們采取了另一種思路，即這篇SAP社區(qū)博客里給出的架構(gòu)圖所體現(xiàn)的，將Netweaver組件進行拆分，分別放置于不同的容器編排邏輯單元中。

Proof of Concept: Deploying ABAP in Kubernetes
https://blogs.sap.com/2020/02/06/proof-of-concept-deploying-abap-in-kubernetes

上面的架構(gòu)圖里并沒有看到容器的影子，而Jerry之前文章介紹的ASCS(ABAP SAP Central Services instances)和AS(Application Server，應用服務器)，被放置到了名為Pod的邏輯單元里。

Kubernetes是容器編排和管理的平臺，不直接操作容器，而是將一個或多個功能上相關(guān)的容器封裝到稱之為Pod的邏輯單元中，我們可以簡單的把Pod理解成容器的集合。

一個SAP系統(tǒng)由一個ASCS實例和一個或多個AS實例構(gòu)成，對于ASCS里包含的組件，比如之前介紹過的消息服務器，Enqueue服務器，Dispatcher等等，每個組件分別構(gòu)建不同的容器鏡像，再將這些鏡像封裝到一個單獨的ASCS Pod里。

而ABAP Netweaver支持多AS實例部署的這種特性，恰巧能讓Kubernetes原生支持的Horizontal Pod Autoscaler機制大顯身手。將AS單獨制作成容器鏡像并放入AS Pod里，通過Kubernetes的Deployment Unit管理這些Pod，從理論上說，可以使用Kubernetes命令行進行ABAP應用服務器的水平擴展。

這種思路將ABAP Netweaver的組件分別進行容器化，大大縮小了每個組件對應的容器鏡像文件的尺寸，使得應用服務器實例能夠根據(jù)實際計算能力的需求變化，進行動態(tài)伸縮。如果想將這種方法應用到生產(chǎn)場景中，面臨的一些挑戰(zhàn)有：

(1) Kubernetes對待Pod的方式是官網(wǎng)里所謂的Cattle-like treatment，即Kubernetes就是Pod的上帝，可以根據(jù)實際需要，隨時創(chuàng)建新的Pod或銷毀已有的Pod，而運行在Pod內(nèi)的應用消費者，完全感知不到Pod的這些變化。另一方面，我們知道，運行在ABAP Netweaver上的很多應用都是有狀態(tài)的事務，比如編輯一個訂單之前，用戶先點擊編輯按鈕，此時應用會往Enqueue服務器發(fā)起一個申請鎖的請求，成功獲取鎖之后繼續(xù)編輯操作。如果此時運行該事務的AS實例所在的Pod正好被Kubernetes銷毀了，那該用戶尚未結(jié)束的編輯操作該如何處理？再比如某個Pod內(nèi)的AS實例正在運行很多后臺作業(yè)，那么這種Pod可以被Kubernetes銷毀么？

這種挑戰(zhàn)簡單概括起來，就是如何調(diào)和Kubernetes Pod的水平伸縮機制和ABAP Netweaver的有狀態(tài)事務處理(會話一致性)的需求。

(2) 在ABAP Netweaver容器化以前，大部分組件是在同一物理網(wǎng)絡下彼此通信。容器化之后，組件與組件之間的通信會多經(jīng)過一層Kubernetes的網(wǎng)絡層，這使得整個系統(tǒng)的復雜度增加。

(3) 我們知道ABAP Netweaver有很多種同第三方系統(tǒng)集成的途徑：RFC，Web Service，OData，IDOC等等。將ABAP容器化之后，以前這些技術(shù)是否仍然可以在不需要調(diào)整Netweaver核心實現(xiàn)的前提下繼續(xù)工作，需要進行實際的驗證。

所謂No pain，no gain，付出總會有收獲。如果ABAP成功容器化之后，理論上我們會享受到哪些容器技術(shù)帶來的便利呢？

(1) ABAP的安裝和部署過程將會大大簡化。假設出現(xiàn)了官方的ABAP容器鏡像和Kubernetes Deployment文件，我們可以僅僅用幾行簡單的命令行，在任何支持容器和Kubernetes的平臺上，輕松完成ABAP的安裝和部署。

(上圖來自博客：
https://www.itsfullofstars.de/2017/09/dockerfile-for-sap-netweaver-abap-7-5x-developer-edition/)

(2) 假設前文介紹的ABAP會話一致性的挑戰(zhàn)已經(jīng)成功解決，那么ABAP應用服務器實例的彈性伸縮，僅僅通過Kubernetes幾條簡單的命令行就可輕松實現(xiàn)。在ABAP傳統(tǒng)部署場景下，增添新的應用服務器實例需要ABAP Basis人員進行繁瑣配置的局面將不復存在。

除了在Kubernetes里通過人工敲命令行的方式調(diào)整Kubernetes的計算資源以外，Kubernetes原生就具有根據(jù)CPU或者內(nèi)存的使用率，進行全自動伸縮的調(diào)整能力。這種完全無需人工界入的資源調(diào)整功能，如果能夠運用到ABAP Netweaver上，無疑給我們留下了太多美好的想象空間。

SAP技術(shù)在不斷向前演化，ABAP也從未停止前進的腳步，讓我們活到老，學到老。感謝閱讀。

要獲取更多Jerry的原創(chuàng)文章，請關(guān)注公眾號"汪子熙":

總結(jié)

以上是生活随笔為你收集整理的SAP ABAP Netweaver容器化, 不可能完成的任务吗？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。