Shulou(Shulou.com)06/01 Report--

DC/OS is how to solve the problem, I believe that many inexperienced people do not know what to do, so this paper summarizes the causes of the problem and solutions, through this article I hope you can solve this problem.

Many organizations are overwhelmed by this challenge because they are often encouraged to rebuild applications and migrate them to Docker containers or PaaS platforms, such as Redhat's OpenShift or Pivotal's Cloud Foundry. Unfortunately, refactoring applications sometimes takes a lot of time or has a lot of technical limitations, so that these plans are doomed to fail before they start.

The good news is that companies don't have to rewrite their applications or migrate them completely to the cloud to solve these problems. There are solutions that allow enterprises to benefit from a modern application architecture without having to rewrite the application. One solution is to use Mesosphere DC/OS, which allows traditional applications to run on new platforms without any code changes. DC/OS also provides features to simplify application deployment and expansion, improve security, update patches faster, and save on resource usage and licensing costs.

DC/OS includes two application orchestration methods, one is Marathon (an integrated component within DC/OS). Marathon is a choreographer verified by the actual production environment, which not only supports the scheduling of container applications but also supports the deployment of binary software, so you can run applications without modifying the traditional program code. For applications that can be migrated to Docker, DC/OS also provides another option-Kubernetes, where users can deploy Kubernetes services with one click in DC/OS. In this way, organizations can run Java EE applications and Docker container applications on a unified platform.

Next, let's discuss how to run Java EE on next-generation platforms and how Mesosphere DC/OS can address some of the operational challenges they pose.

Traditional Java EE application expansion may take several months

Many developers have more or less encountered a scenario where it takes a long time or even six months to complete the task of adding new server resources to an existing application cluster. It would be nice to have these extensions planned in advance, but what if they are faced with sudden demand changes? In addition, when a new resource is added, will the user really remove the server from the application cluster once the resource is idle later? I'm afraid not. It would be wise to always ensure that the application has extra capacity, but this will result in higher administrative costs, higher power consumption, and larger data center footprint. In addition, these servers occupied by applications cannot be used to support other types of applications.

A modern approach to this problem is to use Mesosphere DC/OS to manage a data center-scale cluster. Mesosphere DC/OS can pool new infrastructure resources throughout the data and treat them as a huge pool of resources. Developers can use DC/OS to automatically deploy applications to existing resources in a self-service manner without having to migrate applications to Docker.

With DC/OS, applications can easily deploy and scale flexibly with traditional applications in seconds. The application owner can immediately respond to the needs of the business, and the infrastructure operator business does not have to worry about how many resources are still unused or the licensed number of virtual machines.

DC/OS can run on any Linux, and unlike virtualization technology, DC/OS takes up very few resources, so applications can make full use of the resources in the infrastructure platform. DC/OS also ensures the effective isolation and efficiency of resources. And use the corresponding access control mechanism to ensure that these resources are used properly to ensure the maximum use of resources, while not affecting the performance of the application.

Passwords are difficult to manage and are often made public

A long time ago, password management was much simpler than it is now. At that time, all that was needed to protect the application was to set a password on the configuration file and ensure that outsiders could not access the console and connect to the database. With the passage of time, in order to complete the daily maintenance and emergency debugging of the application, more and more people in the organization will have access to the password.

The problem becomes more serious when plaintext passwords or explosive applications share the credentials of the same database. In some organizations, changing a database password often results in having to change hundreds of application configuration files. Changing passwords sometimes means restarting and interrupting the application, so most passwords in the database rarely change. However, current and outgoing employees in the organization may know these passwords, so applications and databases face significant security risks.

In this case, if there is a key set manager and can be tightly integrated with the application deployment, the above burden can be greatly reduced. Mesosphere DC/OS has a built-in secure key set memory. To reduce unnecessary business interruption, you can create a new password without changing the original password, then remap the key to the new password, and finally update the application to complete the password reconfiguration. Through the key, the user can change the password frequently, thus actively avoiding the risk that many people know the password.

There are some unstable factors in traditional Java application.

Another challenge for traditional applications such as Java EE is that memory leaks and connection hangs often occur. Many enterprises use cron automation to restart applications at night, which usually results in application outages as short as a few minutes to a few hours. However, in today's world where applications require continuity within 24 or 7 hours, such interruptions are sometimes unacceptable.

With Mesosphere DC/OS, enterprises can set application-level health checks and bind them to each running application instance. When the application responds abnormally, DC/OS will restart the process, and the original application will remain running until the new application with clean memory and connection pool runs. In this way, DC/OS ensures the reliability of traditional applications without requiring developers to change the code and stop the application.

The patch upgrade is not timely and inconvenient.

We are often exposed to news related to data leaks, which are caused by attacks on applications or platforms, which are sometimes caused by patches, environments, unreasonable or outdated libraries (JAR files) and code vulnerabilities.

Mesosphere DC/OS provides CLI/UI/API and other ways to deploy applications to solve these problems. Enterprises can directly use CLI and UI to deploy applications, and can also integrate API with tools such as Jenkins and Gitlab. The platform opens up a variety of tools to ensure the security of traditional applications in the whole process and use.

Low-risk migration of Java EE applications through DC/OS

Mesosphere DC/OS provides a very secure distributed platform to host your traditional applications, and you can flexibly choose Marathon or Kubernetes to orchestrate your applications according to your needs.

To complete the migration of Java enterprise applications, we need to:

1. List the applications to be migrated and the configurations related to the applications.

2. Decide whether to deploy directly with binaries (JAR,WAR) or by building Docker images to dynamically load application binaries.

3. Upload the source code and related configuration files to the source code management repository, such as JFrog,Nexus, and then integrate with CI/CD servers such as Jenkins to build an appropriate pipeline.

4. Create and protect the Secret of encrypted DC/OS, such as user name, password, configuration file, certificate, etc.

5. Create application deployment files (such as Marathon's JSON file or Kubernetes's YAML file), define a health check policy for the application, and select an appropriate application group for the application. If necessary, you can also set a health policy and a planned restart without downtime.

After reading the above, have you mastered how DC/OS solves the problem? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.