共计 3505 个字符，预计需要花费 9 分钟才能阅读完成。
笔者之前的文章一个 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 也从未进行后退的脚步，让咱们活到老，学到老。感激浏览。
