The article covers the below points:
- When, What and Why Managed Domain Mode?
- Complexify of Managed Domain Topology
- Running Multiple Processes in an Application Container
- Running Multiple Processes in a System Container
- Decomposition and Building Modified Topology
- WildFly Managed Domain in MilesWeb
- Create Standalone WildFly
- Get Clustered WildFly with Managed Domain Mode
- Application Availability among Workers
- Cloning Cluster in Domain Mode
Getting a WildFly standalone server in a container up and running is very easy today. But it’s difficult to enable clustering in Managed Domain mode, one of the key features of Java EE in general. As per some people, it isn’t at all possible in the cloud-native world as Java EE clustering was planned prior to the containers era. This is a very old query on the official developers’ portal which isn’t still answered with enough information.
Therefore, developers choose the only available option of standalone nodes as the production-ready option in containers that integrate clustering and management features from the 3rd party solutions. Or they simply keep on running applications in VMs and face complex issues that make the migration almost impossible.
But if developers are finding a solution to migrate from VMs to containers that already exist and properly working Java EE clusters in managed domain mode, what is the solution?
There were very few examples until today, (e.g. for GlassFish and WebLogic) for appropriate running and scaling of Java application servers in managed domain mode inside the containers. In several cases, having no knowledge or may be the absence of a working solution for the domain mode in containers leads to losing of integrated Java EE clustering features that become outdated.
But with managed domain mode everything becomes painless. A large number of large-scale and mission-critical applications such as banking as well as billing run on Java EE in VMs until now. The integration of Java EE clustering offers functionality that people need. This includes automated deployment and high-availability among the distributed Java application servers whatever may be the underlying infrastructure, and, also the Admin Panel for managing your cluster using a good UI.
When this rich functionality is merged with ready-to-go containers, you get a huge benefit by saving time and team’s efforts and it also allows fast iterations as most of the developers don’t actually deal with containers or VMs when the environment setup is partially automated.
When, What and Why Managed Domain Mode?
Every WildFly standalone server is managed independently with its own admin console. Simultaneously, the multiple instances of WildFly running in the domain mode share the same management interface called as the domain controller. Therefore, it is possible to execute commands and deploy applications to all running WildFly servers from a single place. You can consider the domain mode for the below cases as per the official documentation:
- Multi-server production environments that can use centralized management capabilities that a managed domain provides.
- In case of advanced development scenarios which involve interaction between multiple WildFly instances.
It is possible to run one big service or many small interrelated services per cluster running in managed domain mode. One can automatically deploy applications to such cluster – it means applications that run in VMs can be lifted and shifted to containers without the need of re-architecture. With this on-premise applications in the cloud can be replicated conveniently by avoiding re-design which is costly as well as time-consuming. This helps the legacy applications to benefit from cost-efficiency of cloud native features such as elastic compute and auto-scaling.
Complexify of Managed Domain Topology
Let’s take a look at the topology of WildFly cluster in managed domain mode demonstrated in the official documentation. The example below gives an idea of the complex managed domain architecture. This scheme is considered to be a classical Java EE topology in VMs or also called “legacy dragon” that should be controlled and decomposed properly into containers.
The above image gives you a better view of the topology and displays “hidden” Java processes running inside each VM or bare metal host. This will assist you greatly during the further decomposition.
- Worker Server – It is a JVM process in which the deployment of enterprise Java EE applications takes place and requests are handled.
- Host Controller – It is a JVM process responsible for the configuration of Worker Servers as well as synchronization between the Domain Controller and Servers.
- Process Controller – It is a JVM process that manages the Worker Servers’ lifecycle (start/stop/restart). Though it isn’t present in the original scheme, it is required to be considered while decomposition.
- Domain Controller – It is a type of Host Controller for acting as a master admin server (or orchestrator) at the cluster that runs in managed domain mode and offers a single pane for the management of distributed Worker Servers.
Running Multiple Processes in an Application Container
As in the above image, the VM1 contains 2 Java processes inside: Domain Controller and Process Controller. And every other VM contains at least 3 Java processes (or more, based on the number of server instances you need to run inside every host): Host Controllers, Process Controller and Worker Server(s).
Running the processes in containers is quite hard. This type of topology creates a conflict with the anti-pattern in the world of application containers. The official Docker documentation explains us the issues of running multiple Java processes inside the same container:
“It’s ok to have multiple processes, but to get the most benefit out of Docker, avoid one container being responsible for multiple aspects of your overall application.”
Running Multiple Processes in a System Container
But, the situation won’t be very bad. If the configuration is done properly, the domain mode works rightly within system containers. It is possible for the system containers to handle any number of processes required inside one container. These types of containers significantly help in simplifying migration from heavy VMs to a very lightweight virtualization. There are two popular options on the market OpenVZ and LXD. Additionally, system containers and application containers are balance and their combination offers VM characteristics for dockerized applications.
Besides system containers offer a better resource as well as isolated security in comparison to the application containers. Therefore, different projects’ applications can be safely hosted by the cloud providers on the same infrastructure, leading to cutting the ownership cost and management complexity. This leads to a side effect of system containers starting a bit slowly in comparison to the application containers, but are still much faster and slimmer than VMs.
Decomposition and Building Modified Topology
Let’ get started with our decomposition journey. The first rule can be found in the character of microservices which states that putting only one Worker Server per one container is always better. Also, only one server group is created per domain for all the containers inside the cluster. All these simple adjustments will help in giving incredible and required flexibility to vertically scale each Worker Server, scaling the group of containers horizontally by including new instances on demand and gaining resource usage efficiency.
Note: Each container runs 3 Java processes for handling incoming requests: Host Controller (HC), Process Controller (PC) and Worker Server (WS). Admin container runs 2 Java processes: Process Controller (PC) and Domain Controller (DC).
WildFly Managed Domain in MilesWeb
We have created a special embedded Auto-Clustering for WildFly that is enabled by default for new instances for facilitating the migration of legacy Java EE applications from VMs to containers.
The key benefit of this solution is that the multiple application servers get interconnected automatically on the environment topology change which implements the commonly used clustering configuration in managed domain mode.
Below are the steps for transformation of standalone WildFly server into the cluster with the help of a simple horizontal scaling, without performing manual configurations. In addition, we will mention the specifications of infrastructure topology along with the ways for getting appropriate development and production environments up and running inside MilesWeb PaaS powered by Jelastic.
Create Standalone WildFly
You can build the required topology with MilesWeb Paas powered by Jelastic using a convenient wizard:
Create a new environment.
- Select the right version of WildFly
- Set up vertical scaling limits
- Give a name to the environment if needed (e.g. wildfly12)
An email confirmation will be received into your inbox which will contain the credentials to the Admin Panel.
Now you can deploy the application to the just provided standalone server.
In the Deployment manager, click Deploy to button.
Mention the Context as required or just leave default ROOT value.
Ensure that your application is up and running by clicking on Open in browser near the created environment.
After logging in to your container via built-in Web SSH client, you’ll find only one running process of standalone server.
Get Clustered WildFly with Managed Domain Mode
WildFly clustering with domain mode is configured automatically with the help of horizontal scaling. The servers can be scaled both ways – manually or automatically.
While creating the environment or by changing its topology, you can add new servers via wizard.
Simply refer to the application server layer placed at the left-side of the environment panel, and add (+) nodes within the Horizontal Scaling frame.
You can change the number of servers automatically by setting up scaling triggers depending on resource usage within Settings > Auto Horizontal Scaling.
- initially while transforming from standalone to domain mode, your application will be down for about 1 minute
- there would be no downtime for all the further scaling changes that happen
- in case you start from 2 instances simultaneously, the domain mode will be created from the start, so there won’t be any downtime during the scaling.
Later, when the scaling is completed (manual or automatic), all the WildFly instances will join the cluster and work WildFly Managed Domain’s operation mode. There is automatic addition of Load Balancer and Domain Controller as needed components of the cluster.
This scaling leads to automatic redeployment of the previously deployed application to the remaining WildFly instances of the cluster. Replication of previously made via WildFly admin console,database connection pool configurations and other config customizations also occurs across the whole application server layer.
Check below how WildFly topology is changed from standalone mode to managed domain cluster:
Three processes are run by Worker Nodes instead of one as it was done in standalone mode:
- Process Controller
- Host Controller
- Worker Server
While Domain Controller node runs two processes:
- Process Controller
- Host Controller
Additionally, there is synchronization of topology changes and those are shown within WildFly Admin Panel.
Finally, you get a ready-to-use WildFly cluster that is scalable, making your applications’ hosting enormously flexible and cost-effective.
Application Availability among Workers
While transformation to the cluster, there is redeployment of the application deployed to the standalone server to all server instances. You can check this by clicking on Open in browser at each Worker.
Furthermore, you can ensure that the cluster provides high availability. For this, you need to click Restart node button for one or even two nodes and try accessing your application via Open in browser for the complete cluster.
There won’t be any interruptions in the application and it will be up and running.
Cloning Cluster in Domain Mode
When new application version is released or just some essential adjustments are done, checking how the newly implemented changes can affect the service work is a good practice. The MilesWeb PaaS helps you to achieve such testing ‘on-fly’ (i.e. with no service downtime and completely for your customers) with the Clone Environment option.
A cloned environment is actually a ready-to-work cluster copy with all the key modifications already done. Domain Controller node that is newly provided operates with the appropriate cloned Workers, which are already listed within its admin panel. And deployment of the application from the original environment is done to the cloned one. Thus, the only thing that remains is rechecking the code and custom server configurations of your application for the hardcoded IPs/domains and fixing them accordingly (if there are any issues).
This way, the implied changes can be applied to your environment copy without any effect on the actual production. For increasing the high availability of the system, MilesWeb makes use of multiple synchronized Load-Balancers located at different nodes in order to handle request at once. All those work with a single data storage, making them completely interchangeable if any issue occurs at one of the instances.
From this tutorial it is proved rebuilding the complete application architecture isn’t needed to gain the specified outcome from both managed domain mode and container technology. Migrating legacy projects from VMs to micro clusters with system containers isn’t a painful job. It results into high flexibility and efficiency for increasing competitive advantage. Just give it a try! Create your own cluster with MilesWeb PaaS.