Jerry之前的文章 一個13年ABAP老兵的建議：了解這些基礎知識，對ABAP開發有百利而無一害, 回顧了ABAP Netweaver伺服器主要的元件。本文咱們就來聊聊ABAP Netweaver容器化這個話題。
Jerry假定閱讀本文的朋友，都聽說過虛拟機和容器的概念， 并且對虛拟機和容器的差別有所了解。
容器與虛拟機的出發點很類似：對應用程式及其依賴進行隔離，生成一套能夠随處運作的自容納單元；二者都能夠使應用運作在一個虛拟出的抽象層裡，擺脫對傳統實體硬體的依賴，使得計算資源的利用更加高效，能源效率與成本效益得以提升。
容器在虛拟化程度上比虛拟機技術更進一步，擺脫了前者對Hypervisor層的依賴，直接利用主控端的核心，抽象層比虛拟機更少，更加輕量化，同虛拟機技術相比能達到更高的實體資源使用率，是以更受當今雲服務提供商的青睐。
Docker是一個開源的應用容器引擎，是當今最流行的容器技術之一。
那麼SAP ABAP Netweaver，能否利用Docker引擎，讓它運作在容器裡呢？
SAP官方的note 1122387 - Linux: SAP Support in virtualized environments給出了答案：截至2020年1月17日，答案是不支援。SAP官方不支援将ABAP應用伺服器運作在容器或者容器編排環境内。比如目前業界流行的Docker和LXC，以及運作在Google Cloud Platform, Microsoft Azure, AWS上的Kubernetes Cluster，都不是SAP官方支援的能夠将ABAP Netweaver伺服器以容器的方式運作的平台。
https://launchpad.support.sap.com/#/notes/1122387
那麼在2018年5月的時候，SAP社群有一篇部落格：
Installing SAP NW ABAP into Docker
https://blogs.sap.com/2018/05/30/installing-sap-nw-abap-into-docker/ 這又是怎麼一回事呢？我們可以通過閱讀部落格了解作者是怎麼做到的。
首先，我們從SAP官網上能免費下載下傳Netweaver的開發者試用版，ABAP版本号為7.52 SP04：
https://developers.sap.com/trials-downloads.html?search=7.52%20SP04 下載下傳到本地，得到一個rar檔案，解壓之後執行裡面的安裝檔案即可把ABAP Netweaver安裝到本地。
是以SAP社群上的一群ABAP愛好者們，想到了一個點子：如果把下載下傳的Netweaver安裝檔案，解壓之後，将其内容建構成一個Docker鏡像檔案，在這個Docker鏡像内完成Netweaver的安裝和啟動工作。如此一來，豈不是達到了在容器裡運作ABAP Netweaver的目的？
我們可以在這位ABAP愛好者的github倉庫上找到用來制作Docker鏡像的Dockerfile檔案，從中了解到該容器鏡像的制作過程：
https://github.com/tobiashofmann/sap-nw-abap-docker/blob/master/Dockerfile這個Dockerfile建構的鏡像選擇了openSUSE Leap作為母鏡像，該鏡像提供了ABAP Netweaver運作的Linux作業系統。
Dockerfile的第一行用FROM關鍵字指定了這個基準鏡像的名稱：
第16行用COPY将事先從SAP官網下載下傳好的存儲在主控端NW752檔案夾下的Netweaver開發者版本安裝檔案，拷貝到容器鏡像裡，然後第22行用RUN關鍵字運作安裝腳本。
安裝完畢後，執行47行的啟動腳本run.sh, 這樣就能在容器裡啟動Netweaver伺服器了。
這個容器鏡像制作好之後，隻需要簡單地使用docker run指令行，就能啟動一個新的容器運作執行個體了。從SAP官網下載下傳的Netweaver開發者版本，就運作在這個新啟動的容器執行個體裡。
我們回顧這種做法，發現Docker技術較之虛拟機的優點并沒有展現出來，按照部落格作者提供的資訊，通過這種方式制作出的鏡像檔案的大小超過了100GB，如此巨型的鏡像檔案幾乎無法通過Docker Hub分發給其他人，無法用于生産用途。
另一方面，通過這種容器化方式，Jerry之前文章 一個13年ABAP老兵的建議：了解這些基礎知識，對ABAP開發有百利而無一害 介紹的Netweaver伺服器的諸多元件，被放置到同一個容器内，無法通過簡單地增加容器執行個體的方式，實作Netweaver處理能力的水準擴充。
正是因為意識到将Netweaver所有元件放置于同一容器鏡像内這種措施無法發揮容器技術的優勢，SAP Linux實驗室的工程師們采取了另一種思路，即這篇SAP社群部落格裡給出的架構圖所展現的，将Netweaver元件進行拆分，分别放置于不同的容器編排邏輯單元中。
Proof of Concept: Deploying ABAP in Kubernetes
https://blogs.sap.com/2020/02/06/proof-of-concept-deploying-abap-in-kubernetes 上面的架構圖裡并沒有看到容器的影子，而Jerry之前文章介紹的ASCS(ABAP SAP Central Services instances)和AS(Application Server，應用伺服器)，被放置到了名為Pod的邏輯單元裡。
Kubernetes是容器編排和管理的平台，不直接操作容器，而是将一個或多個功能上相關的容器封裝到稱之為Pod的邏輯單元中，我們可以簡單的把Pod了解成容器的集合。
一個SAP系統由一個ASCS執行個體和一個或多個AS執行個體構成，對于ASCS裡包含的元件，比如之前介紹過的消息伺服器，Enqueue伺服器，Dispatcher等等，每個元件分别建構不同的容器鏡像，再将這些鏡像封裝到一個單獨的ASCS Pod裡。
而ABAP Netweaver支援多AS執行個體部署的這種特性，恰巧能讓Kubernetes原生支援的Horizontal Pod Autoscaler機制大顯身手。将AS單獨制作成容器鏡像并放入AS Pod裡，通過Kubernetes的Deployment Unit管理這些Pod，從理論上說，可以使用Kubernetes指令行進行ABAP應用伺服器的水準擴充。
這種思路将ABAP Netweaver的元件分别進行容器化，大大縮小了每個元件對應的容器鏡像檔案的尺寸，使得應用伺服器執行個體能夠根據實際計算能力的需求變化，進行動态伸縮。如果想将這種方法應用到生産場景中，面臨的一些挑戰有：
(1) Kubernetes對待Pod的方式是官網裡所謂的Cattle-like treatment，即Kubernetes就是Pod的上帝，可以根據實際需要，随時建立新的Pod或銷毀已有的Pod，而運作在Pod内的應用消費者，完全感覺不到Pod的這些變化。另一方面，我們知道，運作在ABAP Netweaver上的很多應用都是有狀态的事務，比如編輯一個訂單之前，使用者先點選編輯按鈕，此時應用會往Enqueue伺服器發起一個申請鎖的請求，成功擷取鎖之後繼續編輯操作。如果此時運作該事務的AS執行個體所在的Pod正好被Kubernetes銷毀了，那該使用者尚未結束的編輯操作該如何處理？再比如某個Pod内的AS執行個體正在運作很多背景作業，那麼這種Pod可以被Kubernetes銷毀麼？
這種挑戰簡單概括起來，就是如何調和Kubernetes Pod的水準伸縮機制和ABAP Netweaver的有狀态事務處理(會話一緻性)的需求。
(2) 在ABAP Netweaver容器化以前，大部分元件是在同一實體網絡下彼此通信。容器化之後，元件與元件之間的通信會多經過一層Kubernetes的網絡層，這使得整個系統的複雜度增加。
(3) 我們知道ABAP Netweaver有很多種同第三方系統內建的途徑：RFC，Web Service，OData，IDOC等等。将ABAP容器化之後，以前這些技術是否仍然可以在不需要調整Netweaver核心實作的前提下繼續工作，需要進行實際的驗證。
所謂No pain，no gain，付出總會有收獲。如果ABAP成功容器化之後，理論上我們會享受到哪些容器技術帶來的便利呢？
(1) ABAP的安裝和部署過程将會大大簡化。假設出現了官方的ABAP容器鏡像和Kubernetes Deployment檔案，我們可以僅僅用幾行簡單的指令行，在任何支援容器和Kubernetes的平台上，輕松完成ABAP的安裝和部署。
(上圖來自部落格：
https://www.itsfullofstars.de/2017/09/dockerfile-for-sap-netweaver-abap-7-5x-developer-edition/)(2) 假設前文介紹的ABAP會話一緻性的挑戰已經成功解決，那麼ABAP應用伺服器執行個體的彈性伸縮，僅僅通過Kubernetes幾條簡單的指令行就可輕松實作。在ABAP傳統部署場景下，增添新的應用伺服器執行個體需要ABAP Basis人員進行繁瑣配置的局面将不複存在。
除了在Kubernetes裡通過人工敲指令行的方式調整Kubernetes的計算資源以外，Kubernetes原生就具有根據CPU或者記憶體的使用率，進行全自動伸縮的調整能力。這種完全無需人工界入的資源調整功能，如果能夠運用到ABAP Netweaver上，無疑給我們留下了太多美好的想象空間。
SAP技術在不斷向前演化，ABAP也從未停止前進的腳步，讓我們活到老，學到老。感謝閱讀。