如何将Weblogic从虚拟机迁移到容器

随着PaaS和DevOps解决方案需求的增涨，我们可以看到那些运行在虚拟机上或直接运行在裸机上的遗留应用程序，在实践时会遇到一系列的障碍。分解和迁移的过程复杂度非常高。通常，为了获得PaaS或CaaS模式的好处，应用程序所有者必须去重新设计他们的应用架构。

在这个文章里，我们将分析把运行在虚拟机上的Java 遗留应用程序迁移到基于容器平台上的具体挑战。使用Oracle WebLogic Server做为案例，我们将展示分解过程的具体步骤和迁移的结果。

迁移到容器的动机

对比Java EE应用运行在裸机的时代，硬件虚拟化已经是一个很大的进步。它给了我们解决多个应用间隔离及提高硬件利用率的能力。然而，Hypervisors（虚拟机管理程序）在宿主机上会使用大量CPU和内存，且每个虚拟机都要求拥有完整的操作系统、TCP栈和文件系统。

每个虚拟机都有固定的内存，只有部分的虚拟机管理程序可以为通过内存膨胀（memory ballooning）机制的帮助为运行中的虚拟机重新分配内存。所以为了应用程序未来的规模，我们在每个虚拟机里都会预留一些资源，但这些资源并没有得到完全的利用。同时，由于在一个虚拟机内实例间缺乏适当的隔离，这些资源也不能被其他的程序共享。

而容器通过共享宿主机的OS kernel、TCP栈、文件系统和其他的系统资源，仅使用很少的资源和CPU就可以运行，进一步提高了性能和资源利用率。

这里有两种类型的容器——应用容器和系统容器。通常，一个应用容器运行时相当于一个单进程。而一个系统容器则像一个完整的操作系统，可以在一个单容器内执行操作系统所有的功能，比如systemd、SysVinit和通过openrc产生其他类似openssh、crond and syslogd的进程。两种类型的容器在不同的使用场景都非常有用，而且在冗余管理进程上不浪费内存，通常消耗的内存比虚拟机少。然而，对于Java遗留应用程序的迁移只有使用系统容器可以不需要大量的应用重构。

不同于虚拟机，对于运行中实例的容器资源的不需要重启就可以很容易修改限制。而且这些在限制边界内没有被消耗的资源自动与在同一个物理节点上的其他容器共享。

此外，容器对于开发而言也非常有用，在创建，打包，测试应用方面用一种敏捷的方式加快应用的开始进度和提高应用的可扩展性。

这些在物理机上没有被利用的资源可以很容易弹性扩展或新应用的容器使用。考虑到提高容器的隔离，不同类型的应用可以运行在相同的物理节点而不相互影响。这些可以平均提高已存在的基础设备资源利用率的3-10倍。

什么是分解

在迁移过程中，程序分解是基本部分，它可以帮助把大的单块应用分解成小的，按逻辑块划分的，和可以独立运行程序。

以图中显示的是在从虚拟机迁移到容器时应用的一个简单的分解过程：

 

在虚拟机中运行Java遗留应用程序

在软件程序开发里有句老话：遗留软件是好的，只不过是还在运行的旧软件。下面通过案例让我们更精确的知道在Oracle Weblogic Server上它是怎么工作的。

在虚拟机中Oracle Weblogic Server的结构

在虚拟机中运行时，Weblogic Server包含三种类型的实例：

• Administration Server.（管理服务器）
• Node Manager.（节点管理器）
• Managed Server.（被管理服务器）

管理服务器是中心节点，通过它可以配置和管理集群中的所有资源。它通过与节点管理器连接增加或删除被管理节点。而被管理节点运行Web应用、EJBs、Web service和其他的资源。

通常，每个虚拟机上运行一个节点管理器和多个被管服务服务器，而一个管理服务器则管理所有虚拟机上的所有实例。

通过虚拟机扩展 WebLogic

现在想象一下遇到流量高峰期需要扩展集群，新的被管服务器将会被加入到虚拟机中用于处理增长的负载，直到没有资源分配。

但是当流量还在不断增长，而当前被管理服务的实例数量不足以处理负载时，则需要增加一个新的虚拟机去处理程序的进一步增长的业务规模。

典型的通过多个虚拟机对WebLogic进行扩展包括三个步骤：

1. 提供一个提前配置好 Weblogic Server 模板的新虚拟机
2. 在新的虚拟机上启动一个节点管理器，并连接到管理服务器上
3. 添加一个新的被管理服务器处理部分增长的业务负载

然后，这个扩展的步骤重复，在新增加的虚拟启动更多的被管理服务器直到资源限制。

 

在虚拟机中运行WebLogic的劣势

这样运行Oracle WebLogic是一种资源利用率非常低下的方式，这里有几个资源浪费或未使用的点：

1. 每个虚拟机要求拥有完整的操作系统，TCP 栈和文件系统，这些需要使用宿主机大量的 CPU 和内存。
2. 这些资源的分配并非高度微粒化，在某些场景，所有当我们只需要增加一个被管理服务器时也需要去准备一个完整的虚拟机。
3. 如果当一个虚拟机的资源不足时，添加额外的 CPU 或仅是增加内存也需要重启整个虚拟机。
4. 每个虚拟机都需要节点管理器用来增加或删除被管理节点，需要消耗额外的资源和增加额外复杂的配置。
5. 在同一个虚拟机里运行的实例由于缺少隔离会相互影响，从而影响整个应用的性能。也出于这个原因，我们不能在同一个虚拟机上混合搭配运行不同的应用程序。
6. 虚拟机的可移植性受限于一个厂商，所以当我们想从一个云迁移到另一个云会有一系列的问题。
7. 在虚拟机上做模板打包和实施CI/CD会非常慢和过程复杂。

从虚拟机迁移到容器

这些天，我们找到多个设计用来在容器里运行微服务的优秀应用服务器和框架，比如 Spring Boot、WildFly Swarm、Payara Micro等等。无论如何，有一系列的服务器设计运行在虚拟机，比如Oracle WebLogic Server，这种类型的实例迁移到容器里的任务更加复杂。这就是为什么我们更关注这个主题。

WebLogic Server的分解

这些天通过Docker容器的帮助这个分解是一个相当容易的任务。首先，我们需要准备一个有WebLogic Server的容器镜像。（镜像可从Oracle的官方仓库获得）。

当Docker模板已经准备好，我们规定每个实例在独立的容器里：一个管理服务器和需要数量的被管理服务器。

在这里，我们放弃了用于增加和删除被管理节点的节点管理器。

迁移到容器后，和直接使用管理节点一样，通过容器编排平台和一系列WSLT脚本，被管理服务器实例可以被自动增加和删除。

这样，我们就得到了一个非常简单的Weblogic Server Cluster结构。

因为容器比从头开始配置或克隆更容易，这样水平扩展过程变得非常细颗粒和平滑。还有，每个容器可以被快速启动或停止，几乎没有停机时间。当和虚拟机对比时容器更加轻量，所以调度容器时比调度虚拟机使用更少的时间。

运行WebLogic在容器中的好处

虽然将应用迁移到容器里是一个挑战，但是如果你知道怎么管理它，可以获得如下的好处：

1. 每个容器消除独立的完整操作系统，TCP 栈和文件系统可以减少系统资源（ CPU 和内存）的使用。
2. 通过在集群拓扑里删除节点管理器可以简化水平扩展。
3. 通过容器可以共享未使用资源的能力可以自动化垂直扩展，而且不需要重启就可以重新配置，非常容易。
4. 通过在同一个物理机上使用独立的容器隔离运行不同的应用，提高基础设备的利用率。
5. 通过容器的可移植性解除在不同云厂商的迁移约束。

可以使用相同的方式帮助分解应用的其他层，或应用其他的Java EE应用服务。在下一个主题，我们会通过一个特定的案例描述怎么处理分解后数据的全过程。

陈爱珍译/七牛云布道师

原文出处：Docker（微信订阅号ID：dockerone）

本文链接：https://www.yunweipai.com/9987.html