A method for deploying multiple microservice environments on a single node using containers

Abstract

This invention provides a method for deploying multiple microservice environments on a single node using containers, belonging to the field of computer technology. The method includes first building a standardized and reusable Docker-in-Docker base image based on the Kylin operating system; then, using this Docker-in-Docker base image, replicating and starting multiple isolated environment instances on a single host machine; and deploying independent microservice platform applications in each of these isolated environment instances. The Docker-in-Docker base image automatically provides a running Docker engine environment upon startup. This invention completely eliminates the dependence on virtual machines, enabling rapid construction and instant replication of a single platform environment, while ensuring strong isolation between different delivery environments while maintaining a lightweight design.

Description

Technical Field

[0001] This invention relates to the deployment of microservice environments within containers, and more particularly to a method for deploying multiple microservice environments on a single node based on containers, belonging to the field of computer technology. Background Technology

[0002] With the deepening development of the information technology innovation industry and the continuous evolution of software architecture, integrated software platforms based on containerization technology have become the core carriers of enterprise digital transformation. Against this backdrop, our company's product delivery model presents a specific form: since the information technology environments of general customers do not usually come pre-installed with unified container cloud platform services, our products must be delivered in a complete form that integrates the "underlying container orchestration foundation and the upper-layer business microservice platform application".

[0003] However, the current technical solution of "physical server + virtual machine + Kylin operating system + (Docker / container cloud + microservice application)" used to achieve independent delivery of multiple such platforms faces several severe challenges in practice. First, this solution has low resource utilization and high costs, because each delivery platform needs to exclusively occupy complete virtual machine resources, and the full-featured server operating system and container orchestration components running inside it together generate huge resource overhead. Second, the deployment and startup cycle is extremely long. From virtual machine initialization to the final application deployment, the entire process can easily take several hours, which seriously restricts testing efficiency and delivery speed. In addition, the complexity of operation and maintenance management also increases dramatically. Maintaining multiple heterogeneous virtualization environments, operating system instances and container clusters, and ensuring their configuration consistency, brings a heavy operational burden.

[0004] Therefore, developing a solution that can break free from the constraints of virtual machine resources and provide a fast, efficient, and highly isolated deployment solution for multiple containerized platform environments for testing and R&D has become an urgent technical problem to be solved.

[0005] Currently, in testing and R&D scenarios, there are two main technical solutions to meet the needs of multiple independent environments, but both have significant drawbacks.

[0006] Option 1: Complete environment isolation based on virtual machines The current solution is "physical server + virtual machine + Kylin operating system + (Docker / container cloud + microservice application)". This solution creates an independent virtual machine for each required environment and fully deploys all components from the container runtime to the upper-layer microservice platform application within each virtual machine. This solution has the following drawbacks: 1. Extremely low resource utilization and high hardware costs: Each test environment needs to host a complete guest operating system kernel and its system processes, while also running container orchestration components, resulting in a significant amount of redundant consumption of CPU, memory, and storage resources. This severely limits the number of environment instances that a single physical server can support, and multiplies hardware procurement and maintenance costs.

[0007] 2. Inefficient environmental supply severely impacts the pace of research and development and testing: From creating virtual machines and installing operating systems to deploying Docker / container cloud clusters and finally deploying the application, the entire process can take several hours. Developers and testers face long waits and cannot obtain an immediately usable environment, which severely hinders agile development processes and the ability to iterate rapidly.

[0008] 3. High operational complexity and difficulty in ensuring environmental consistency: The operations and maintenance team needs to manage the virtualization layer, a large number of virtual machine instances, and their respective independent container environments simultaneously. Ensuring complete consistency of operating system versions, kernel parameters, container runtime versions, and container cloud configurations across all environments is extremely difficult. Even the slightest configuration drift can trigger troubleshooting problems, placing a heavy burden on operations and maintenance.

[0009] Option 2: Multi-tenant isolation based on a single container cloud cluster One feasible solution in the industry is to use a combination of "physical machine + Kylin operating system + a container cloud platform + multiple namespace-isolated microservice platform applications," attempting to optimize resource usage by sharing a container cloud platform. This involves creating independent naming frameworks for different projects within a shared container cloud cluster and deploying platform applications there. However, this solution has the following inherent limitations: 1. Unable to meet the verification requirements of a complete product delivery and testing process: The product delivery model includes the deployment and verification of the underlying container orchestration platform (container cloud platform and related middleware). The shared cluster model deprives the R&D and testing teams of control over the underlying infrastructure, making it impossible for them to fully rehearse and test the key processes of building the entire technology stack from scratch, resulting in a disconnect between the deliverables and the actual deployment environment.

[0010] 2. Insufficient isolation poses security and stability risks: The logical isolation provided by container cloud namespaces is not absolute. Applications from different projects or teams share the same cluster's control plane, kernel, and underlying network drivers. A defective application deployed by one team may cause a node's kernel to crash or access services from other projects through network policy vulnerabilities, thus causing cross-environment security risks and stability disruptions.

[0011] 3. Increased management and communication costs: This solution requires the platform operations team to create and manage independent, restricted access accounts and RBAC policies for each R&D testing group. This introduces additional user management and permission allocation work. Furthermore, any changes to the shared cluster itself (such as version upgrades or component maintenance) require notification to all teams using the cluster and collaborative testing, resulting in high communication and coordination costs and preventing the achievement of independent environmental autonomy.

[0012] In summary, existing technologies have significant shortcomings in providing efficient, isolated, and low-cost multi-platform environments for testing and development. Neither resource-intensive and slow-deployment virtual machine solutions nor shared container cloud cluster solutions, which cannot meet the full delivery process verification and pose isolation risks, can effectively balance the core requirements of resource efficiency, environment isolation, deployment speed, and management complexity. Therefore, there is an urgent need for an innovative technological solution to completely overcome these shortcomings and achieve rapid, flexible, and secure on-demand provisioning of microservice platform application environments. Summary of the Invention

[0013] To address the aforementioned issues, this invention provides a method for deploying multiple microservice environments on a single node based on containers, thereby eliminating the dependence on virtual machines and enabling rapid construction and instant replication of a single platform environment, while ensuring strong isolation between different delivery environments while maintaining lightweight design.

[0014] To achieve the above objectives, the technical solution of the present invention is as follows: a method for deploying multiple microservice environments on a single node based on containers, the method comprising first building a standardized and reusable Docker in Docker base image based on the Kylin operating system, then using the Docker in Docker base image to copy and start multiple isolated environment instances on a single host machine, and deploying independent microservice platform applications in the multiple isolated environment instances; The Docker in Docker base image automatically provides a running Docker engine environment upon startup.

[0015] Furthermore, building a standardized and reusable Docker in Docker base image based on the Kylin operating system includes the following process: Step S101: Select base image: Obtain the Docker image of the Kylin operating system as the base for building; Step S102: Install necessary system component packages: In the Dockerfile, execute the command to install necessary system component packages; Step S103: Install the Docker engine: In the Dockerfile, execute the command to deploy based on binary and install the specified version of the Docker engine; Step S104: Configure the Docker engine: Write and embed the Containerd configuration file and Docker Daemon configuration file optimized for the Docker in Docker environment, and set the image startup command as the systemd service startup entry point; write the containerd service file to the service configuration file loading directory so that the service is automatically loaded when systemd starts; Step S105: Write the startup script: For images that support both Docker and high-version Kubernetes clusters, add an environment variable to configure whether to enable the Docker service. When set to true, write the Docker service file to the service configuration file loading directory and set iptables rules. Step S106: Build and test the image: Complete the image build based on docker build; Step S107: Push to image repository: Push the built image to the image repository and push a list of multiple architectures to support pulling different architectures.

[0016] Furthermore, in step S101, the Docker image for the Kylin operating system is Kylin Server Operating System V10-SP3-2403.

[0017] Furthermore, in step S102, the necessary system component packages include `yum install systemd unix-utils`.

[0018] Furthermore, the files installed during step S103 when installing the Docker engine include containerd, runc, fuse-overlayfs, cni-plugins, crictl, docker, and doker-compose.

[0019] Furthermore, multiple isolated environment instances are replicated and started on a single host machine using the Docker in Docker base image, and independent microservice platform applications are deployed in each of these isolated environment instances, including the following process: Step S201, Host Environment Preparation: On the physical server, directly install the Kylin operating system and install and run the Docker engine through the package manager; Step S202: Create and run a Docker in Docker container instance: For each microservice platform application that needs to be deployed independently, use the command `docker run --privileged` on the physical server to create and start a privileged container from the Docker in Docker base image; the privileged container allows an independent Docker Daemon to run inside the container; Step S203: Docker in Docker environment internal daemon self-starting: After the privileged container starts, the startup script automatically completes the container initialization configuration, and then starts the container's systemd service, so that an independent and complete Containerd Daemon is started by the systemd service inside each container; Step S204: Deploy the microservice platform application within the Docker in Docker environment.

[0020] Furthermore, in step S201, the physical server has sufficient CPU, memory, and disk space to support running multiple Docker in Docker container instances.

[0021] Furthermore, in step S202, the microservice platform application includes deploying the microservice platform application for development, testing, project A, and project B respectively.

[0022] Furthermore, the process also includes deploying a unified entry gateway after step S204: if a Macvlan network card is used, it can support accessing the cluster via a bridged physical IP; if a bridged network card is used, common gateway components can be selected to expose the corresponding microservice platform application entry point.

[0023] The beneficial effects of the method for deploying multiple microservice environments on a single node based on containers in this invention are as follows: The key technology of this invention lies in proposing a design and implementation of a single-node containerized deployment solution for multiple microservice platform applications. Its key technical protection points are: (1) Proposing a Docker in Docker image for rapid replication and standardized management service foundation. This image is based on the Kylin operating system and has customized and modified containerd and docker-related services so that it can run an independent Docker engine in the Kylin operating system container. (2) Based on container technology and standardized images, providing a solution for running multiple microservice platform applications based on docker-compose or Kubernetes clusters on a single physical machine node. Its innovation lies in proposing a solution based on the Kylin operating system to quickly and automatically start "container virtual machines" and with lower resource consumption and usage compared to virtual machine solutions, reducing costs and increasing efficiency, so as to ensure the combined requirements of isolation, flexibility, resource efficiency and rapid deployment in modern software development processes.

[0024] This invention designs and implements a lightweight multi-microservice platform application deployment scheme based on Docker-in-Docker technology and a domestically developed operating system. It achieves extremely high resource utilization and deployment density. This invention completely abandons the traditional virtual machine layer, directly utilizing the host machine kernel through container native technology, eliminating the huge overhead of running a complete guest operating system in each environment. This allows a single physical server to support an order-of-magnitude increase in the number of environment instances it can simultaneously support, significantly reducing hardware procurement and maintenance costs, and providing a cost-effective solution for enterprises' large-scale testing and R&D under the background of information technology innovation.

[0025] This invention enables "one-click" instant copying and startup of multiple independent environments by pre-deploying the complex Docker and basic environment deployment process and embedding it into a reusable standardized image. This reduces the environment preparation cycle from several hours to minutes or even seconds, significantly improving the agility of R&D and testing teams and ensuring smooth product iteration.

[0026] This invention utilizes Docker's namespace isolation mechanism to provide kernel-level process, network, and file system isolation for each environment instance, achieving an effect comparable to virtual machines and effectively preventing interference between different projects or versions. Simultaneously, each environment possesses a complete and self-controllable Docker runtime, ensuring that users can deploy and test any complex platform relying on container technology, including Kubernetes clusters, without differentiation within it, thus meeting the requirements for complete delivery process verification.

[0027] This invention achieves high consistency across all environments, from underlying basic components to upper-layer platform configurations, through standardized image management and container orchestration. This fundamentally eliminates the "what works fine here" problem caused by environmental differences. Operations personnel are freed from maintaining complex virtual machine clusters and can efficiently manage the lifecycle of all environments through a unified containerized interface, significantly reducing operational complexity and human error rates. The entire solution, from the underlying domestic operating system to the middleware container technology and upper-layer management processes, uses technical components that meet the requirements of the domestic IT innovation ecosystem, constructing a secure, controllable, efficient, and externally independent complete technology stack, providing a solid technical foundation for digital transformation in key areas. Attached Figure Description

[0028] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments.

[0029] Figure 1 This is a schematic diagram of the system architecture of the method of the present invention; Figure 2 This is a flowchart illustrating the process of building a standardized Docker in Docker base image based on the Kylin operating system in this embodiment of the invention. Figure 3 This is a flowchart illustrating the deployment of multiple independent management services based on image in an embodiment of the present invention. Detailed Implementation

[0030] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Many specific details are set forth in the following description to provide a thorough understanding of the present invention. However, the present invention may also be implemented in other ways different from those described herein. Those skilled in the art can make similar extensions without departing from the spirit of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below.

[0031] This invention discloses a method for deploying multiple microservice environments on a single node using containers. The core objectives of this technical solution are: to completely eliminate dependence on virtual machines, thereby eradicating the resource overhead and performance degradation they cause; to achieve rapid construction and instant replication of a single platform environment, shortening the delivery cycle from hours to minutes; to ensure strong isolation between different delivery environments while maintaining lightweight design; and to fully support the deployment and verification of container orchestration frameworks within the environment, thus comprehensively meeting the delivery requirements of complex products. The main technical approach to achieving these objectives is roughly as follows: By leveraging container-native technologies, unnecessary operating system-level overhead is eliminated, enabling higher environment deployment density. This increases the environmental capacity of a single server by an order of magnitude, significantly reduces hardware costs, and allows limited computing resources to support more concurrent testing tasks.

[0032] This enables minute-level delivery of containerized infrastructure environments by reducing environment preparation time from hours to minutes through standardized environment images and automated orchestration. This allows developers and testers to access readily available, standalone environments, significantly accelerating the functional verification and bug fixing cycles.

[0033] By providing standardized environment templates and a unified management interface, version control and centralized management of environment configurations are achieved. Operations personnel can define environment specifications declaratively, ensuring high consistency across all environments from basic components to platform configurations, significantly reducing operational complexity and the rate of human error.

[0034] It provides more granular isolation units than virtual machines, supporting flexible resource allocation based on actual testing needs. Through container-level resource control and network isolation, it enables multi-level environment provisioning from individual services to complete platforms, making resource allocation more precise and efficient, and meeting diverse R&D testing needs.

[0035] Through the above solution, this invention will significantly reduce resource consumption and waste in R&D and testing environments, provide a more efficient and simpler environment deployment and operation mode, and meet the needs of development and testing for quickly launching environments for different versions and customized projects.

[0036] Example 1 This invention provides a method for deploying multiple microservice environments on a single node using containers. It utilizes Docker-in-Docker technology and the Kylin operating system to encapsulate a Kylin operating system container image and customizes it to enable the Kylin operating system container to have a running Docker engine integrated after startup, providing it for application use. The specific approach is as follows: 1. Achieve strong environment-level isolation using Docker in Docker technology. This invention abandons the traditional approach of achieving isolation through virtual machines, and instead utilizes Docker-in-Docker technology to build a lightweight, strongly isolated environment. For example... Figure 1 As shown, the system architecture underlying the method described in this invention includes an application layer, a platform environment layer, and a host machine. The application layer includes multiple domain management platform microservice containers. The platform environment layer runs multiple Docker-in-Docker containers on the host machine, and each of these Docker-in-Docker containers independently runs a set of microservice platform applications (corresponding to...). Figure 1 The platform uses microservice containers; the host machine runs the Kylin server operating system and has the Docker engine installed. The platform environment layer communicates with the application layer and the host machine.

[0037] Specifically, this invention does not simply refer to using a Docker client within a container, but rather to running a complete and independent Docker daemon process inside the container. This Docker-in-Docker container starts in privileged mode and has the ability to directly manage the container lifecycle within its own cgroup and namespace. Each such Docker-in-Docker container instance is a complete "container host" for all application containers running within it.

[0038] In this way, the present invention achieves absolute isolation between different environments at the container runtime level: different environments have their own independent image storage, network stack, process space and volume management. Operations within one environment (such as pulling an image or restarting a service) will not interfere with other environments. Its isolation effect is comparable to that of a virtual machine, but the resource overhead is far lower than that of a virtual machine.

[0039] 2. Construct a base image based on a domestically developed operating system. To achieve deep adaptation to the domestic IT innovation environment, the cornerstone of this invention is a customized Kylin operating system container image. For example... Figure 1 As shown, this invention is developed under the domestic IT innovation environment and the Kylin operating system environment. This invention selects the latest stable version of the Kylin server operating system V10-SP3-2403 and makes necessary modifications to it. This customization work includes: first, streamlining the base image and removing unnecessary packages to reduce its size; second, pre-installing a specific version of the Docker engine and all its dependencies, and configuring it to start in a specific way; finally, setting optimized kernel parameters and security policies to ensure that Docker in Docker can run stably and securely. The final image automatically runs a complete Docker daemon process upon startup, thus becoming a "out-of-the-box" and self-contained containerized basic environment unit.

[0040] 3. Achieve rapid replication and standardized management Based on the above two points, this invention enables rapid replication and standardized management of multiple environments. Operations personnel no longer need to repeatedly perform complex installation processes; they only need to pull this customized Kylin operating system and Docker in Docker image from a unified image repository, and then use container orchestration tools (such as Docker Compose) to launch multiple isolated instances with a single click. Each instance is a ready-to-use "container virtual machine" with an embedded Docker engine. R&D and testing teams can be authorized to access designated "container virtual machines" and freely deploy and test complete microservice application stacks within them using familiar Docker commands or Docker Compose files. They can even deploy a container cloud cluster within them, thus completely simulating a real delivery environment.

[0041] 4. Provides flexible resource and network control This invention provides fine-grained resource control for each container virtual machine environment instance through the host machine's container engine (such as Docker). Operations personnel can allocate specific CPU shares, memory limits, storage space, and network bandwidth to each environment instance, achieving fine-grained resource management. Simultaneously, by leveraging Docker's powerful network model, each container virtual machine container can be configured with an independent Bridge network or Macvlan network, ensuring complete isolation of network namespaces between different environments. This not only simulates complex network topologies but also eliminates mutual interference at the network layer. This design allows this invention to provide both strong isolation and the flexibility and agility lacking in virtual machine solutions.

[0042] In summary, this invention combines Docker-in-Docker technology with the Kylin operating system image to construct a novel containerized basic environment unit. This solution successfully achieves a domestically developed container environment that is more lightweight than virtual machine solutions while possessing strong isolation characteristics at the host machine level. It effectively solves the challenge of balancing resource efficiency, deployment speed, operational complexity, and environmental flexibility, providing efficient, reliable, and consistent underlying support for R&D and testing processes.

[0043] Example 2 This embodiment is based on embodiment 1, combined with... Figure 2 and Figure 3 The specific embodiments of the present invention are further described below. The method of the present invention includes building a standardized Docker-in-Docker base image based on the Kylin operating system and deploying multiple independent management services based on the image, wherein: I. Building a standardized Docker in Docker base image based on the Kylin operating system This step aims to create a reusable base image based on the Kylin operating system (corresponding to...). Figure 1 The Kylin server operating system (in China) automatically provides a running Docker engine environment upon startup. Figure 2 As shown, the process mainly includes the following: Step S101: Select a base image: Obtain the Docker image of the Kylin operating system (such as Kylin Server Operating System V10-SP3-2403) from the official Kylin repository (cr.kylinos.cn) as the base for building.

[0044] Step S102: Install necessary system component packages: In the Dockerfile, execute the command to install necessary system component packages (e.g., yum install systemd unix-utils).

[0045] Step S103: Install the Docker engine: In the Dockerfile, execute the command to deploy based on binary and install the specified version of the Docker engine, including installing containerd, runc, fuse-overlayfs, cni-plugins, crictl, docker, and doker-compose.

[0046] Step S104: Configure the Docker engine: Write and embed the Containerd configuration file ( / etc / containerd / cri-base.json) and Docker Daemon configuration file ( / etc / docker / daemon.json) optimized for the Docker in Docker environment, and set the image startup command to the systemd service startup entry point ( / sbin / init). Add the containerd service file to the service configuration file loading directory so that systemd automatically loads the service upon startup.

[0047] Step S105: Write the startup script: For images that support both Docker and high-version Kubernetes clusters (high-version clusters do not support the Docker engine and only use containerd), add environment variable configuration to enable the Docker service. When set to true, the Docker service file is written to the service configuration file loading directory, and iptables rules are set, etc.

[0048] Step S106: Build and test the image: Complete the image build based on docker build.

[0049] Step S107: Push to image repository: Push the built image to the image repository and push a list of multiple architectures to support pulling different architectures.

[0050] II. Deploying Multiple Independent Management Services Based on Image Mirroring This step utilizes the standardized image created in the first step, such as Figure 3 As shown, multiple isolated environment instances are quickly replicated and started on a single host machine, and each instance deploys its own independent microservice platform application. The specific process includes the following: Step S201, Host Environment Preparation: On the physical server (Host A), directly install the Kylin operating system, and install and run the Docker engine (Daemon B) using the package manager (dnf). Host A needs to have sufficient CPU, memory, and disk space to support running multiple Docker in Docker container instances.

[0051] Step S202: Create and run Docker in Docker container instances: For each microservice platform application that needs to be deployed independently (e.g., deploying microservice platform applications for development, testing, project A, and project B respectively), use the `docker run --privileged` command on host machine A to create and start a privileged container from the standardized image generated in step one (e.g., creating container C1 for the first set of services and container C2 for the second set of services). This privileged mode is the foundation of Docker in Docker, allowing an independent Docker daemon to run within the container.

[0052] Step S203: Docker-in-Docker environment internal daemon auto-start: After containers C1, C2, etc., start, the startup script will automatically complete the container initialization configuration, and then start the container's systemd service. This allows the systemd service to start an independent, complete Containerd daemon within each container (e.g., Daemon D1 in C1, Daemon D2 in C2). If the environment variable DOCKER_ENABLE is configured, the Docker daemon will also be started (e.g., Daemon D3 in C1, Daemon D4 in C2). These inner daemons are completely independent of the host machine's Daemon B and are isolated from each other between containers (e.g., between C1 and C2).

[0053] Step S204: Deploy the microservice platform application within the Docker in Docker environment: Enter the specific Docker in Docker container instance (e.g., enter container C1 via `docker exec -it C1 bash`). At this point, the environment is equivalent to a host machine with an independent Docker runtime. Within this environment, you can: Utilize the inner Docker Daemon D1 to deploy the first independent domain management platform service KCM1 according to standard procedures (e.g., using tools such as docker-compose).

[0054] Similarly, for container C2-CN, this process can be repeated. Multiple containers can be used to jointly deploy a Kubernetes cluster K and deploy the domain management platform KCM2 based on this cluster.

[0055] Step S205, (optional) Deploy a unified entry gateway: If a Macvlan network card is used, it can support accessing the cluster through the bridged physical IP. If a bridged network card is used, common gateway components (such as Nginx, Traefik, etc.) can be selected to expose the corresponding microservice platform application entry to the outside world.

[0056] Step S206, Management and Isolation: After completing the above deployment, host machine A runs the host Docker Daemon B, and multiple (N) independent Docker in Docker privileged containers C1, C2, ..., CN. Each Docker in Docker container C_i runs an independent Docker in Docker Daemon D_i, which is responsible for managing its own Docker service or Kubernetes cluster E_i and other microservice platform applications F_i.

[0057] Isolation: Through the Linux namespaces (processes, networks, mount points, etc.) and cgroups mechanism of the Docker container itself, strong kernel-level isolation is achieved between different Docker in Docker containers C_i and all services running inside them, so that they do not interfere with each other.

[0058] Resource allocation: The total resources of host machine A can be precisely allocated to each Docker in Docker container C_i through the host machine Docker Daemon B. The Daemon D_i within each Docker in Docker container then schedules and manages the resource usage of all its internal sub-containers (such as Kubernetes Pods) within this resource limit.

[0059] Through the two core steps described above, this invention successfully built multiple completely independent and fully functional microservice platform application environments on a single domestically produced physical node, perfectly meeting the combined requirements for isolation, flexibility, resource efficiency, and rapid deployment under the background of information technology innovation.

[0060] Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

Claims

1. A method for deploying multiple microservice environments on a single node based on containers, characterized in that, The method includes first building a standardized and reusable Docker in Docker base image based on the Kylin operating system, then using the Docker in Docker base image to copy and start multiple isolated environment instances on a single host machine, and deploying their own independent microservice platform applications in the multiple isolated environment instances. The Docker in Docker base image automatically provides a running Docker engine environment upon startup.

2. The method according to claim 1, characterized in that, Building standardized and reusable Docker in Docker base images based on the Kylin operating system includes the following process: Step S101: Select base image: Obtain the Docker image of the Kylin operating system as the base for building; Step S102: Install necessary system component packages: In the Dockerfile, execute the command to install necessary system component packages; Step S103: Install the Docker engine: In the Dockerfile, execute the command to deploy based on binary and install the specified version of the Docker engine; Step S104: Configure the Docker engine: Write and embed the Containerd configuration file and Docker Daemon configuration file optimized for the Docker in Docker environment, and set the image startup command as the systemd service startup entry point; write the containerd service file to the service configuration file loading directory so that the service is automatically loaded when systemd starts; Step S105: Write the startup script: For images that support both Docker and high-version Kubernetes clusters, add an environment variable to configure whether to enable the Docker service. When set to true, write the Docker service file to the service configuration file loading directory and set iptables rules. Step S106: Build and test the image: Complete the image build based on docker build; Step S107: Push to image repository: Push the built image to the image repository and push a list of multiple architectures to support pulling different architectures.

3. The method according to claim 2, characterized in that, In step S101, the Docker image of the Kylin operating system is Kylin Server Operating System V10-SP3-2403.

4. The method according to claim 2, characterized in that, In step S102, the necessary system component packages include `yum install systemd unix-utils`.

5. The method according to claim 2, characterized in that, The files installed during step S103 when installing the Docker engine include containerd, runc, fuse-overlayfs, cni-plugins, crictl, docker, and doker-compose.

6. The method according to claim 2, characterized in that, The process involves replicating and launching multiple isolated environment instances on a single host machine using a Docker in Docker base image, and deploying independent microservice platform applications within each of these isolated environment instances. Step S201, Host Environment Preparation: On the physical server, directly install the Kylin operating system and install and run the Docker engine through the package manager; Step S202: Create and run a Docker in Docker container instance: For each microservice platform application that needs to be deployed independently, use the command `docker run --privileged` on the physical server to create and start a privileged container from the Docker in Docker base image; the privileged container allows an independent Docker Daemon to run inside the container; Step S203: Docker in Docker environment internal daemon self-starting: After the privileged container starts, the startup script automatically completes the container initialization configuration, and then starts the container's systemd service, so that an independent and complete Containerd Daemon is started by the systemd service inside each container; Step S204: Deploy the microservice platform application within the Docker in Docker environment.

7. The method according to claim 6, characterized in that, In step S201, the physical server has sufficient CPU, memory, and disk space to support running multiple Docker in Docker container instances.

8. The method according to claim 6, characterized in that, Step S202 involves deploying the microservice platform application for development, testing, project A, and project B respectively.

9. The method according to claim 6, characterized in that, The process also includes deploying a unified entry gateway after step S204: if a Macvlan network card is used, it can support accessing the cluster via a bridged physical IP; if a bridged network card is used, common gateway components can be selected to expose the corresponding microservice platform application entry point.

Images