笔者之前的文章一个15年ABAP老兵的倡议：理解这些基础知识，对ABAP开发有百利而无一害, 回顾了ABAP Netweaver服务器次要的组件。本文咱们就来聊聊ABAP Netweaver容器化这个话题。

笔者假设浏览本文的敌人，都据说过虚拟机和容器的概念， 并且对虚拟机和容器的区别有所理解。

容器与虚拟机的出发点很相似：对应用程序及其依赖进行隔离，生成一套可能随处运行的自包容单元；二者都可能使利用运行在一个虚构出的形象层里，解脱对传统物理硬件的依赖，使得计算资源的利用更加高效，能源效率与老本效益得以晋升。
容器在虚拟化水平上比虚拟机技术更进一步，解脱了前者对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服务器以容器的形式运行的平台。

SAP 社区已经有一篇博客：Installing SAP NW ABAP into Docker

这又是怎么一回事呢？咱们能够通过浏览博客理解作者是怎么做到的。

首先，咱们从SAP官网上能收费下载Netweaver的开发者试用版，ABAP版本号为7.52 SP04：

下载到本地，失去一个rar文件，解压之后执行外面的安装文件即可把ABAP Netweaver装置到本地。

因而SAP社区上的一群ABAP爱好者们，想到了一个点子：如果把下载的Netweaver安装文件，解压之后，将其内容构建成一个Docker镜像文件，在这个Docker镜像内实现Netweaver的装置和启动工作。如此一来，岂不是达到了在容器里运行ABAP Netweaver的目标？

咱们能够在这位ABAP爱好者的 github 仓库 上找到用来制作Docker镜像的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分发给其他人，无奈用于生产用处。

另一方面，通过这种容器化形式，Netweaver服务器的诸多组件，被搁置到同一个容器内，无奈通过简略地减少容器实例的形式，实现Netweaver解决能力的程度扩大。

正是因为意识到将Netweaver所有组件搁置于同一容器镜像内这种措施无奈施展容器技术的劣势，SAP Linux实验室的工程师们采取了另一种思路，即这篇SAP社区博客里给出的架构图所体现的，将Netweaver组件进行拆分，别离搁置于不同的容器编排逻辑单元中。

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...)

(2) 假如前文介绍的ABAP会话一致性的挑战曾经胜利解决，那么ABAP应用服务器实例的弹性伸缩，仅仅通过Kubernetes几条简略的命令行就可轻松实现。在ABAP传统部署场景下，削减新的应用服务器实例须要ABAP Basis人员进行繁琐配置的场面将不复存在。

除了在Kubernetes里通过人工敲命令行的形式调整Kubernetes的计算资源以外，Kubernetes原生就具备依据CPU或者内存的使用率，进行全自动伸缩的调整能力。这种齐全无需人工界入的资源调整性能，如果可能使用到ABAP Netweaver上，无疑给咱们留下了太多美妙的设想空间。

SAP技术在一直向前演变，ABAP也从未进行后退的脚步，让咱们活到老，学到老。感激浏览。