Windows system >> Linux system Tutorial >> Linux Tutorial

How to migrate Weblogic from a virtual machine to a container

As the demand for PaaS and DevOps solutions grows, we can see that legacy applications running on virtual machines or running directly on bare metal encounter a series of obstacles in practice. The process of decomposition and migration is very complex. Often, in order to get the benefits of PaaS or CaaS mode, application owners must redesign their application architecture.

In this article, we'll analyze the specific challenges of migrating Java legacy applications running on virtual machines to container-based platforms. Using Oracle WebLogic Server as a case, we will show the specific steps of the decomposition process and the results of the migration.

Motion to migrate to container

Comparing Java EE applications running in the era of bare metal, hardware virtualization has been a big step forward. It gives us the ability to resolve isolation between multiple applications and improve hardware utilization. However, Hypervisors use a lot of CPU and memory on the host, and each virtual machine requires a full operating system
, TCP stack, and file system.

Each virtual machine has fixed memory, and only a subset of hypervisors can redistribute memory for running virtual machines with the help of a memory ballooning mechanism. So in order to scale the future of the application, we reserve some resources in each virtual machine, but these resources are not fully utilized. At the same time, these resources cannot be shared by other programs due to the lack of proper isolation between instances within a virtual machine.

The container can be run with only a small amount of resources and CPU through the OS kernel, TCP stack, file system and other system resources of the shared host, further improving performance and resource utilization. .

There are two types of containers —— application containers and system containers. Typically, an application container runs as a single process. A system container is like a complete operating system, which can perform all the functions of the operating system in a single container, such as systemd, SysVinit, and other processes like openssh, crond and syslogd generated by openrc. Both types of containers are very useful in different usage scenarios, and do not waste memory on redundant management processes, typically consuming less memory than virtual machines. However, the migration of Java legacy applications can only require a large amount of application refactoring using system containers.

Different from virtual machines, it is easy to modify the restrictions on the container resources of the running instance without restarting. Moreover, these resources that are not consumed within the restricted boundaries are automatically shared with other containers on the same physical node.

In addition, containers are also very useful for development, using an agile approach to creating, packaging, and testing applications to speed up application start-up and increase application scalability.

These resources that are not utilized on physical machines can be easily extended or used by new application containers. Given the increased isolation of containers, different types of applications can run on the same physical node without affecting each other. These can average 3-10 times the utilization of existing infrastructure resources.

What is decomposition?

In the migration process, program decomposition is the basic part, which can help to break large single-block applications into small, logical blocks, and can run independently. program.

The figure shows a simple decomposition process applied when migrating from a virtual machine to a container:

Running Java legacy in a virtual machine Applications

There is an old saying in software development: legacy software is good, just old software that is still running. Let's take a closer look at how it works on Oracle Weblogic Server.

Structure of Oracle Weblogic Server in Virtual Machines

When running in a virtual machine, Weblogic Server contains three types of instances:

Administration Server.

Node Manager.

Managed Server.

The management server is the central node through which you can configure and manage the cluster. All resources in . It adds or removes managed nodes by connecting to the Node Manager. The managed node runs web applications, EJBs, web services, and other resources.

Typically, one node manager and multiple managed service servers are running on each virtual machine, and one management server manages all instances on all virtual machines.

Extending WebLogic with Virtual Machines

Now imagine that you will need to scale your cluster when traffic spikes occur, and new managed servers will be added to the virtual machine to handle the growing load until There is no resource allocation.

But when traffic is still growing and the number of instances of currently managed services is insufficient to handle the load, a new virtual machine is needed to handle the further growth of the program.

Typical extension of WebLogic through multiple virtual machines involves three steps:

Providing a new virtual machine with Weblogic Server templates configured in advance

In a new virtual Start a node manager on the machine and connect to the management server

Add a new managed server to handle part of the growing business load

Then, this extension The steps are repeated, and the newly added virtual boot starts more managed servers until the resource is restricted.

The disadvantage of running WebLogic in a virtual machine

Running Oracle WebLogic in this way is a very low resource utilization method. Here are a few resources waste. Or unused points:

Each virtual machine requires a full operating system, TCP stack and file system, which requires a large amount of CPU and memory on the host.

The allocation of these resources is not highly fragmented. In some scenarios, all of us need to prepare a complete virtual machine when we only need to add a managed server.

If you add extra CPU or just increase memory when a virtual machine has insufficient resources, you need to restart the entire virtual machine.

Each virtual machine requires a node manager to add or remove managed nodes, which consumes additional resources and adds additional complex configuration.

Instances running in the same virtual machine can affect each other's performance due to lack of isolation. For this reason, we can't mix and match different applications on the same virtual machine.

The portability of virtual machines is limited to one vendor, so there are a number of issues when we want to migrate from one cloud to another.

Packaging and implementing CI/CD on a virtual machine can be very slow and complicated.

Migrating from a virtual machine to a container

These days, we found several excellent application servers and frameworks designed to run microservices in containers, such as Spring Boot, WildFly Swarm. , Payara Micro, etc. In any case, there are a series of server designs running on virtual machines, such as Oracle WebLogic Server, and the task of migrating instances of this type into containers is more complicated. This is why we are more concerned about this topic.

WebLogic Server Decomposition

The decomposition of these days is a fairly easy task with the help of Docker containers. First, we need to prepare a container image with WebLogic Server. (Mirroring is available from Oracle's official repository).

When the Docker template is ready, we specify each instance in a separate container: a management server and the required number of managed servers.

Here, we gave up the node manager for adding and removing managed nodes.

After migrating to a container, the managed server instance can be automatically added and removed through the container orchestration platform and a series of WSLT scripts, just like the management node.

This way, we get a very simple Weblogic Server Cluster structure.

Because containers are easier to configure or clone from scratch, the horizontal expansion process becomes very fine-grained and smooth. Also, each container can be quickly started or stopped with almost no downtime. Containers are much lighter when compared to virtual machines, so scheduling containers is less time consuming than scheduling virtual machines.

The benefits of running WebLogic in a container

While migrating an application to a container is a challenge, but if you know how to manage it, you can get the following benefits:

Each container eliminates a separate, complete operating system, and the TCP stack and file system reduce the use of system resources (CPU and memory).

Simplify horizontal scaling by removing Node Manager from the cluster topology.

The ability to share unused resources through containers can automate vertical scaling and can be reconfigured without rebooting, very easy.

Improve the utilization of infrastructure by using separate containers to isolate different applications on the same physical machine.

Unlocking the migration constraints of different cloud vendors through container portability.

You can use the same way to help break down other layers of your application, or apply other Java EE application services. In the next topic, we will describe how to handle the entire process of decomposed data through a specific case.