SAP ABAP Netweaver容器化, 不可能完成的任务吗？
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也从未停止前进的脚步，让我们活到老，学到老。感谢阅读。
更多阅读
- Jerry的ABAP, Java和JavaScript乱炖
- ABAP开发人员未来应该学些什么
- Jerry 2017年的五一小长假：8种经典排序算法的ABAP实现
- Jerry的ABAP原创技术文章合集
- 300行ABAP代码实现一个最简单的区块链原型
- 使用Java+SAP云平台+SAP Cloud Connector调用ABAP On-Premise系统里的函数
- 在SAP云平台的CloudFoundry环境下消费ABAP On-Premise OData服务
- ABAP vs Java， 蛙泳 vs 自由泳
- 聊聊C语言和ABAP
- 动手使用ABAP Channel开发一些小工具，提升日常工作效率
- 我用ABAP做过的那些无聊的事情
- 不喜欢SAP GUI？那试试用Eclipse进行ABAP开发吧
- 使用Visual Studio Code编写和激活ABAP代码
- 你的ABAP程序给佛祖开过光么？来试试Jerry这个小技巧
- 在SAP云平台ABAP编程环境上编写第一段ABAP程序
- SAP官方发布的ABAP编程规范
- ABAP Code Inspector那些隐藏的功能，您都知道吗？
- 还在用ABAP进行SAP产品的二次开发？来了解下这种全新的二次开发理念吧
- ABAP Netweaver体内的那些寄生式编程语言
- 从SAP社区上的一篇博客开始，聊聊SAP产品命名背后的那份情怀
- 云端的ABAP Restful服务开发
- 如何在SAP云平台ABAP编程环境里把CDS view暴露成OData服务
- 使用abapGit在ABAP On-Premises系统和SAP云平台ABAP环境之间进行代码传输
- 30分钟用Restful ABAP Programming模型开发一个支持增删改查的Fiori应用
- Jerry带您了解Restful ABAP Programming模型系列之二：Action和Validation的实现
- Jerry带您了解Restful ABAP Programming模型系列之三：云端ABAP应用调试
- SAP云平台上的ABAP编程环境里如何消费第三方服务
- ABAP开发者上云的时候到了 - 现在大家可以免费使用SAP云平台ABAP环境的试用版了
- 学而不思则罔 - SAP云平台ABAP编程环境的由来和适用场景
- SAP云平台里的三叉戟应用
- 如何基于Restful ABAP Programming模型开发并部署一个支持增删改查的Fiori应用
- SAP 2019 TechEd Key Note解读：云时代下SAP从业人员如何做二次开发？
- 有哪些ABAP关键字和语法，到了ABAP云环境上就没办法用了？
- ABAP开发环境终于支持以驼峰命名法自动格式化ABAP变量名了
- 利用ABAP 740的新关键字REDUCE完成一个实际工作任务
- 一段让人瑟瑟发抖的ABAP代码
- 昨日万圣节ABAP怪兽级代码谜团，公布答案啦
- 介绍一种在ABAP内核态进行内表高效拷贝的方法
- 使用SAP Cloud Application Programming模型开发OData的一个实际例子
- 当ABAP遇见普罗米修斯
- 使用ABAP绘制可伸缩矢量图
- ABAP开发环境语法高亮的那些事儿
- SAP错误消息调试之七种武器：让所有的错误消息都能被定位
- 使用ABAP操作Excel的几种方法
- SAP GUI里的收藏夹事务码管理工具
- SAP GUI和Windows注册表
- 有了Debug权限就能干坏事？小心了，你的一举一动尽在系统监控中
- ABAP CCDEF, CCIMP, CCMAC, CCAU, CMXXX这些东东是什么鬼
- 实现ABAP条件断点的三种方式
- 使用SAT跟踪监控从浏览器打开的SAP应用的性能和调用栈
- 一个13年ABAP老兵的建议：了解这些基础知识，对ABAP开发有百利而无一害